From github.com+592810+efge at openjdk.java.net  Thu Apr  1 00:36:28 2021
From: github.com+592810+efge at openjdk.java.net (Florent Guillaume)
Date: Thu, 1 Apr 2021 00:36:28 GMT
Subject: RFR: 8037397: Lost nested character class after intersection &&
In-Reply-To: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
Message-ID: <myczce5JY6cDFrkza5K1sIKNDCc8F5-vrSqpGQOpG0Q=.7c660d9b-b0ac-4fdc-9305-6520f181a58c@github.com>

On Wed, 31 Mar 2021 20:38:33 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones.

src/java.base/share/classes/java/util/regex/Pattern.java line 2666:

> 2664:                             } else { // abc&&def
> 2665:                                 unread();
> 2666:                                 if(right == null) {

Missing space after `if`. There will be a unit test as well?

(Please tell me if these comments aren't suitable or relevant, as I'm not involved in the project.)

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

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

From xgong at openjdk.java.net  Thu Apr  1 03:39:43 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 1 Apr 2021 03:39:43 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
Message-ID: <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>

> Currently "VectorMask.andNot()" is not vectorized:
>     public VectorMask<E> andNot(VectorMask<E> m) {
>         // FIXME: Generate good code here.
>         return bOp(m, (i, a, b) -> a && !b);
>     }
> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
> can be vectorized as well by calling them.
> 
> The performance gain is >100% for such a simple JMH:
>   @Benchmark
>   public Object andNot(Blackhole bh) {
>     boolean[] mask = fm.apply(SPECIES.length());
>     boolean[] r = fmt.apply(SPECIES.length());
>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
> 
>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>           rm = rm.andNot(vmask);
>         }
>     }
>     return rm;
>   }

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

  Move the changing to AbstractMask.andNot and revert changes in VectorMask
  
  Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
  CustomizedGitHooks: yes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3211/files
  - new: https://git.openjdk.java.net/jdk/pull/3211/files/ccb73d92..33ac041e

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

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

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

From xgong at openjdk.java.net  Thu Apr  1 03:50:18 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 1 Apr 2021 03:50:18 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <4nYUWzXPdlo6tL9f4j7pTj8ArbRtFSZEHRae7P17UBE=.0d1f8bd8-ff98-49a5-b6d7-d5a4856bcaf0@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <4nYUWzXPdlo6tL9f4j7pTj8ArbRtFSZEHRae7P17UBE=.0d1f8bd8-ff98-49a5-b6d7-d5a4856bcaf0@github.com>
Message-ID: <7-bXxH3_wFxlJaN7-G6HnbWnrAgT8dqurUIYg9nCR-k=.f99cd05a-9ed2-4d74-965d-c81511db354f@github.com>

On Wed, 31 Mar 2021 16:42:09 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Would you mind updating the existing `AbstractMask.andNot` implementation? rather than changing `VectorMask.andNot`. That fits in with the current implementation pattern.

Hi @PaulSandoz , thanks for looking at this PR. I'v updated the patch according to your comments. Would you mind having look at it again? Thanks so much!

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

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

From maurizio.cimadamore at oracle.com  Thu Apr  1 09:35:55 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 1 Apr 2021 10:35:55 +0100
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <5985B06A-7F50-43E4-80B8-CB653B135FFD@oracle.com>
References: <10e8c9d1-fd93-5f34-d4cf-0d6e044b8501@gmail.com>
 <84b24edc-a822-a91c-f9dd-759cb1de70f7@oracle.com>
 <5985B06A-7F50-43E4-80B8-CB653B135FFD@oracle.com>
Message-ID: <b0815cd2-778e-87fb-3f8e-51ee7b7d2c95@oracle.com>


On 31/03/2021 23:54, Dan Smith wrote:
>> On Mar 31, 2021, at 3:27 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>> What I'd be curious though, is if the @ValueBased annotation could be enhanced to say _which_ primitive class default you want (and then javac could enforce extra checks if you pick the "val" default). If something like this was feasible (cc'ing Dan), maybe some of the friction here could be removed?
> You mean annotate a class with "pretend this class's name represents a value type" and then implement the associated null checks in javac, even though we don't actually have value types yet?
>
> I'd expect that to run into a number of problems related to the fact that the language model hasn't actually been updated to include primitive classes or value types yet. Plus the lack of features like reference types (Foo.ref) would be limiting for programmers who need them. Plus binary incompatibility?value types need special encoding in class files, and those class files aren't legal yet; when they are, you risk mismatches.
>
> In this case I think the straightforward approach of just completing and delivering the Valhalla features is better than trying to spin off a small taste of them early.

You are right - there are more aspects to this than just null checks - 
binary compatibility seems especially problematic.

Thanks for the explanation!

Maurizio

>

From jlaskey at openjdk.java.net  Thu Apr  1 11:04:53 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 1 Apr 2021 11:04:53 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v40]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <fEKAfhnYWrQk2SbRWHbXdEAgxh-c_BPlD-7Rhizhj8A=.255d9fa0-064f-4497-8fab-49a99a5f1664@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:

 - Merge branch 'master' into 8248862
 - Correct return type of RandomGeneratorFactory.of
 - Merge branch 'master' into 8248862
 - CSR review revisions
 - CSR review updates
 - Removed @since from nextDouble ThreadLocalRandom
 - RandomGeneratorFactory::all(Class<T> category) @implNote was out of date
 - Clarify all()
 - Cleaned up ints(), longs(), doubles()
 - Merge branch 'master' into 8248862
 - ... and 66 more: https://git.openjdk.java.net/jdk/compare/011f6d13...5a23b4f1

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

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=39
  Stats: 12968 lines in 26 files changed: 11202 ins; 1588 del; 178 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

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

From herrick at openjdk.java.net  Thu Apr  1 12:14:39 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 1 Apr 2021 12:14:39 GMT
Subject: RFR: JDK-8264403: [macos]: App names containing '.' characters
 results in an error message when launching [v2]
In-Reply-To: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
References: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
Message-ID: <y-M1o-qELn1yiCs9OxY3LMt4tu_lFTYbD-n5kgVrHEs=.119269ff-065a-41c8-b2e6-5e0794d0babd@github.com>

> Deriving the cfg file name is broken on mac and linux when the application name has a "." in it.

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

  JDK-8264403: [macos]: App names containing '.' characters results in an error message when launching

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3288/files
  - new: https://git.openjdk.java.net/jdk/pull/3288/files/1fe2699e..25102702

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

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

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

From herrick at openjdk.java.net  Thu Apr  1 12:14:40 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 1 Apr 2021 12:14:40 GMT
Subject: RFR: JDK-8264403: [macos]: App names containing '.' characters
 results in an error message when launching [v2]
In-Reply-To: <zdbfxDkZszM9KvTiwN0cI2XbGyQzGmzzGebiiTfuYJE=.0d42edaf-2cde-4421-bc44-2f2e1a4cd76d@github.com>
References: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
 <zdbfxDkZszM9KvTiwN0cI2XbGyQzGmzzGebiiTfuYJE=.0d42edaf-2cde-4421-bc44-2f2e1a4cd76d@github.com>
Message-ID: <_-_ZeEaWxlseC9n5GRzHZxbxNUNrSNCEaFVd-4f1ERs=.f2e6d9aa-9732-4e61-8135-6df10a83b36a@github.com>

On Wed, 31 Mar 2021 21:59:55 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8264403: [macos]: App names containing '.' characters results in an error message when launching
>
> src/jdk.jpackage/share/native/common/FileUtils.h line 76:
> 
>> 74: 
>> 75:     // extract the name from the launcher path
>> 76:     tstring extractName(const tstring& path);
> 
> Function name seems to be misleading. 
> If it specifically designed to be applied to executables, I'd name it `stripExecutableSuffix()`. On Unix implementation would return passed in string as is without calling `basename()` and on Windows would just strip ".exe" suffix not calling `basename()` either.
> The use would be: `FileUtils::mkpath() << appDirPath << (FileUtils::stripExecutableSuffix(FileUtils::basename(launcherPath)) + _T(".cfg"));`

makes sense - updated as requested

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

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

From herrick at openjdk.java.net  Thu Apr  1 12:19:21 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 1 Apr 2021 12:19:21 GMT
Subject: RFR: JDK-8264403: [macos]: App names containing '.' characters
 results in an error message when launching [v3]
In-Reply-To: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
References: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
Message-ID: <3DAhfW8Qb02XYSKUm3zvI_rbIBEJ14WI1DWEHwMRrJA=.8024482b-aef8-4de0-956f-e01271b7240e@github.com>

> Deriving the cfg file name is broken on mac and linux when the application name has a "." in it.

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

  Fix trailing whitespace

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3288/files
  - new: https://git.openjdk.java.net/jdk/pull/3288/files/25102702..b83578c2

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

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

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

From jlaskey at openjdk.java.net  Thu Apr  1 12:20:24 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 1 Apr 2021 12:20:24 GMT
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
Message-ID: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>

We should never close the jimage since java threads can still be running after a hard exit().

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

Commit messages:
 - 8166727: javac crashed: [jimage.dll+0x1942] ImageStrings::find+0x28

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

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

From jfranck at openjdk.java.net  Thu Apr  1 12:59:16 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Thu, 1 Apr 2021 12:59:16 GMT
Subject: RFR: 8169629: Annotations with lambda expressions cause
 AnnotationFormatError
In-Reply-To: <gD7qFYsjwU-W7Z84CPc5aZbc2gBFaTM8RvyxeP41nBQ=.049861b7-0717-471f-bbb7-8b14c01a2ede@github.com>
References: <gD7qFYsjwU-W7Z84CPc5aZbc2gBFaTM8RvyxeP41nBQ=.049861b7-0717-471f-bbb7-8b14c01a2ede@github.com>
Message-ID: <H878ScmiSagZ8uHQua_jwsLR0HESPs2zMHkRIoVFYwI=.bf8210a7-862b-4ef0-b542-6ffd624b6593@github.com>

On Wed, 31 Mar 2021 21:32:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The stricter checks added by
>     8035781: Improve equality for annotations
> in creating the proxy objects used to implement annotations has an unintended by-catch of rejecting annotation's whose type has, say, a field initialized with a lambda expression. While uncommon, it is legal code to have a field in an annotation type.
> 
> The updated checks skip over the sort of synthetic method used for the initialization.
> 
> Some different compilation tactics were used before and after nest mates, so the test includes compilation and testing under both situations.

Other than the potentially unused var, looks good to me.

src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java line 497:

> 495:         Method currentMethod = null;
> 496:         for(Method method : memberMethods) {
> 497:             currentMethod = method;

I can't see any use of currentMethod, am I missing something?

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

Marked as reviewed by jfranck (Reviewer).

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

From rriggs at openjdk.java.net  Thu Apr  1 14:24:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 1 Apr 2021 14:24:18 GMT
Subject: RFR: 8037397: Lost nested character class after intersection &&
In-Reply-To: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
Message-ID: <AUVhBclJRTbqzA0jiR0f9swp73YrA5d_jYQxp0riKEs=.925329ed-56ab-4135-9e39-60c97ccea063@github.com>

On Wed, 31 Mar 2021 20:38:33 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones.

Please add a test.

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

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

From asemenyuk at openjdk.java.net  Thu Apr  1 14:55:25 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 1 Apr 2021 14:55:25 GMT
Subject: RFR: JDK-8264403: [macos]: App names containing '.' characters
 results in an error message when launching [v3]
In-Reply-To: <3DAhfW8Qb02XYSKUm3zvI_rbIBEJ14WI1DWEHwMRrJA=.8024482b-aef8-4de0-956f-e01271b7240e@github.com>
References: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
 <3DAhfW8Qb02XYSKUm3zvI_rbIBEJ14WI1DWEHwMRrJA=.8024482b-aef8-4de0-956f-e01271b7240e@github.com>
Message-ID: <Tjnfa1ZJ-YC_T9u3L0D02qwQUO3T0kBKuvJddXW2zks=.f8d9df84-169c-48be-b4d5-caa34110f963@github.com>

On Thu, 1 Apr 2021 12:19:21 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> Deriving the cfg file name is broken on mac and linux when the application name has a "." in it.
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix trailing whitespace

Marked as reviewed by asemenyuk (Reviewer).

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

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

From jpai at openjdk.java.net  Thu Apr  1 15:02:58 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 1 Apr 2021 15:02:58 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v3]
In-Reply-To: <UX_PIU0pgWPZnI_jsSBiE6w-D5KD0PQGSOORZKtRzQY=.d126b8fc-0658-4adc-b6cc-bb57e9d054ca@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
 <UX_PIU0pgWPZnI_jsSBiE6w-D5KD0PQGSOORZKtRzQY=.d126b8fc-0658-4adc-b6cc-bb57e9d054ca@github.com>
Message-ID: <51etfLTxZoIdvAf8SqESmwl5LhivbcOqx46tzCig6ps=.6f2a87ff-892e-426f-a02b-ea62489ffe5b@github.com>

On Wed, 31 Mar 2021 17:22:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Alan's review feedback for -C help text
>>  - Keep -xfP backward compatible but don't allow -C/--dir with -xfP
>
> Some additional comments basically suggesting that we test --extract in addition to -x

Thank you for the reviews, Lance. The latest version of this PR has taken into account most of these comments. There's one review comment which hasn't resulted in a change and I've added a reply to that review comment explaining my thoughts.

> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1427:
> 
>> 1425:             return rc;    // leading '/' or 'dot-dot' only path
>> 1426:         }
>> 1427:         File f = new File(xdestDir, name.replace('/', File.separatorChar));
> 
> Could you please add a comment regarding xdestDir and also correct the typo on line 1418 'requres' -> 'requires'

Fixed the typo and also added code comment about the `xdestDir` usage and semantics. If the new comment needs clarification/changes, do let me know.

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 62:
> 
>> 60:         Could not create a temporary file
>> 61: error.extract.multiple.dest.dir=\
>> 62:         You may not specify more than one directory for extracting the jar
> 
> Perhaps something similar to:
> 
> You may not specify  the  '-C' or '--dir' option more than once with the '-x' option

Done

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 64:
> 
>> 62:         You may not specify more than one directory for extracting the jar
>> 63: error.extract.pflag.not.allowed=\
>> 64:         -P option cannot be used when extracting a jar to a specific location
> 
> Perhaps something similar to
> 
> You may not specify '-Px'  with the '-C' or '--dir' options

Makes sense. I've updated the PR with this change.

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 167:
> 
>> 165:         (in = {0}) (out= {1})
>> 166: out.extract.dir=\
>> 167:         extracting to {0}
> 
> Perhaps 'Extracting to directory: {0}'

Updated the message to say `extracting to directory: {0}`. I decided to use lower case for `extracting` to keep it consistent with other similar messages that get logged here.

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 249:
> 
>> 247: \  -C DIR                     Change to the specified directory and include the\n\
>> 248: \                             following file. When used in extract mode, extracts\n\
>> 249: \                             the jar to the specified directory
> 
> Should this be updated on line 187 as well in the compatibility mode section?

Updated in latest version of the PR.

> test/jdk/tools/jar/JarExtractTest.java line 152:
> 
>> 150:         return abs;
>> 151:     }
>> 152: 
> 
> Please add a comment to each test giving a high level overview of what it does as it will help future maintainers

Done in latest update to this PR

> test/jdk/tools/jar/JarExtractTest.java line 175:
> 
>> 173:         final String dest = "foo-bar";
>> 174:         System.out.println("Extracting " + testJarPath + " to " + dest);
>> 175:         final int exitCode = JAR_TOOL.run(System.out, System.err, "-x", "-f", testJarPath.toString(),
> 
> Perhaps add a DataProvider so you can test --extract as well?

Not a data provider but the latest version of PR tests --extract as well

> test/jdk/tools/jar/JarExtractTest.java line 216:
> 
>> 214:         final Path jarPath = createJarWithPFlagSemantics();
>> 215:         // extract with -P flag without any explicit destination directory (expect the extraction to work fine)
>> 216:         final String[] args = new String[]{"-xvfP", jarPath.toString()};
> 
> Perhaps add a DataProvider so you can test --extract as well?

Not a data provider but the latest version of PR tests --extract as well

> test/jdk/tools/jar/JarExtractTest.java line 239:
> 
>> 237:      */
>> 238:     @Test
>> 239:     public void testExtractWithDirPFlagNotAllowed() throws Exception {
> 
> I would include --extract in your testing options

Done in latest version of the PR

> test/jdk/tools/jar/JarExtractTest.java line 240:
> 
>> 238:     @Test
>> 239:     public void testExtractWithDirPFlagNotAllowed() throws Exception {
>> 240:         final String expectedErrMsg = "-P option cannot be used when extracting a jar to a specific location";
> 
> Probably need to add a comment that this must match the entry in jar.properties

Added a comment mentioning where this message is sourced from.

> test/jdk/tools/jar/JarExtractTest.java line 247:
> 
>> 245:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-P", "-C", "."});
>> 246:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-P", "--dir", "."});
>> 247:         cmdArgs.add(new String[]{"-xvfP", testJarPath.toString(), "-C", tmpDir});
> 
> Perhaps add a DataProvider so you can test --extract as well?

Not a data provider but the latest version of PR tests `--extract` as well.

> test/jdk/tools/jar/JarExtractTest.java line 262:
> 
>> 260:      */
>> 261:     @Test
>> 262:     public void testLegacyCompatibilityMode() throws Exception {
> 
> Perhaps add a DataProvider so you can test --extract as well?

So from what I understand of the code in the jar tool the "legacy compatibility" mode stands for using the single hypen option and clubbing multiple options into one. Something like `-xvfP` instead of `-x -v -f -P` and this legacy compatibility mode isn't applicable for the long form options like `--extract`. So IMO using `--extract` here won't work. Let me know if I have misunderstood this review comment or the semantics of the legacy compatibility mode.

> test/jdk/tools/jar/JarExtractTest.java line 282:
> 
>> 280:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-C", tmpDir, "-C", tmpDir});
>> 281:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir, "--dir", tmpDir});
>> 282:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir, "-C", tmpDir});
> 
> Perhaps use a DataProvider so you can test --extract as well?

Done

> test/jdk/tools/jar/JarExtractTest.java line 300:
> 
>> 298:     public void testExtractPartialContent() throws Exception {
>> 299:         final String tmpDir = Files.createTempDirectory(Path.of("."), "8173970-").toString();
>> 300:         final String[] cmdArgs = new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir,
> 
> Perhaps add a DataProvider so you can test --extract as well?

Didn't use a data provider, but did add tests for `--extract` as well, in the latest version of this PR.

> test/jdk/tools/jar/JarExtractTest.java line 307:
> 
>> 305:         // make sure only the specific files were extracted
>> 306:         final Stream<Path> paths = Files.walk(Path.of(tmpDir));
>> 307:         Assert.assertEquals(paths.count(), 6, "Unexpected number of files/dirs in " + tmpDir);
> 
> Should '6' be in a local variable to make it clearer or at a minimum a comment

The latest update to the PR includes a comment explaining what this number represents.

> test/jdk/tools/jar/JarExtractTest.java line 332:
> 
>> 330:      */
>> 331:     private void testExtract(final String dest) throws Exception {
>> 332:         final String[] args = new String[]{"-x", "-f", testJarPath.toString(), "-C", dest};
> 
> Perhaps add a DataProvider so you can test --extract as well?

The latest version of the PR tests the `--extract` as well.

> test/jdk/tools/jar/JarExtractTest.java line 367:
> 
>> 365:     }
>> 366: 
>> 367:     private static Path createJarWithPFlagSemantics() throws IOException {
> 
> Perhaps add a comment as to what the method does

Done

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

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

From jpai at openjdk.java.net  Thu Apr  1 15:02:42 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 1 Apr 2021 15:02:42 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v4]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <xIE8AvPWcFR_f-z7z4Om_zSn1J8_xUXY6egI9MHIrNU=.8ae9c4f6-cd29-4f46-ab82-47ea43052205@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with seven additional commits since the last revision:

 - Lance's review - include tests for --extract long form option
 - cleanup after each test
 - Adjust test for new error messages
 - Lance's review - add a code comment for xdestDir
 - Lance's review - updates to the help messages in jar.properties
 - Lance's review - add comment to the magic number 6 in the tests
 - Lance's review - add comments to test methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2752/files
  - new: https://git.openjdk.java.net/jdk/pull/2752/files/3df602d2..b5de6e3d

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

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

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

From psandoz at openjdk.java.net  Thu Apr  1 15:16:26 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 1 Apr 2021 15:16:26 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
Message-ID: <bH97iO9EOXZRcKTS2zyOBwfqJLoRUiP-wFzccuKb-fg=.bd983da8-9b58-4bb3-b8a3-395ef669aafc@github.com>

On Thu, 1 Apr 2021 03:39:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently "VectorMask.andNot()" is not vectorized:
>>     public VectorMask<E> andNot(VectorMask<E> m) {
>>         // FIXME: Generate good code here.
>>         return bOp(m, (i, a, b) -> a && !b);
>>     }
>> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
>> can be vectorized as well by calling them.
>> 
>> The performance gain is >100% for such a simple JMH:
>>   @Benchmark
>>   public Object andNot(Blackhole bh) {
>>     boolean[] mask = fm.apply(SPECIES.length());
>>     boolean[] r = fmt.apply(SPECIES.length());
>>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
>> 
>>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>>           rm = rm.andNot(vmask);
>>         }
>>     }
>>     return rm;
>>   }
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the changing to AbstractMask.andNot and revert changes in VectorMask
>   
>   Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
>   CustomizedGitHooks: yes

Looks good.

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

Marked as reviewed by psandoz (Reviewer).

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

From jbachorik at openjdk.java.net  Thu Apr  1 15:44:11 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 1 Apr 2021 15:44:11 GMT
Subject: RFR: 8203359: Container level resources events [v4]
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <l-sOKsQhEQB22KcszHAIJyQLQboXQZq0RilDES2SkMU=.8d966abc-cccf-4a80-86f3-7126e70e63ed@github.com>

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

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

 - Remove unused test files
 - Initial test support for JFR container events

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3126/files
  - new: https://git.openjdk.java.net/jdk/pull/3126/files/82570022..79c91f57

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

  Stats: 117 lines in 4 files changed: 99 ins; 6 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126

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

From dfuchs at openjdk.java.net  Thu Apr  1 16:00:15 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 1 Apr 2021 16:00:15 GMT
Subject: RFR: 8264048: Fix caching in Jar URL connections when an entry is
 missing [v2]
In-Reply-To: <D8au5a1Xx4NlUqMVWmU3XZJ8W03xN3oVJxgfajzfpS4=.f2db26da-357b-4591-9cd6-1e3ffaf91154@github.com>
References: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>
 <D8au5a1Xx4NlUqMVWmU3XZJ8W03xN3oVJxgfajzfpS4=.f2db26da-357b-4591-9cd6-1e3ffaf91154@github.com>
Message-ID: <4eRG5jrls0JP5gJZGEvbfUPjicAulCa7UdJO8SWfhKc=.63b6fc71-a7a0-43d7-a3d9-e21da3af4bca@github.com>

On Wed, 31 Mar 2021 12:47:50 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Current fix tries to tackle an issue with URL connection referencing non-existing Jar file entries:
>> If an entry that doesn't exist is specified in an URL connection the underlying Jar file is still cached even if an exception is thrown after that. Such behavior prevents the caller, for instance, a `URLClassLoader`, from closing a Jar file.
>> 
>> The proposed fix checks if entry exists before caching a Jar file (only for cases with enabled caching):
>> - If entry exists - jar file is cached if it wasn't cached before
>> - If entry doesn't exist and jar file wasn't cached before - jar file is closed and exception is thrown
>> - If entry doesn't exist and jar file was cached before - jar file is kept cached and exception is thrown
>> 
>> 
>> The following tests have been used to verify the fix:
>> - New regression tests
>> - ``:jdk_core:`` tests
>> - `api/java_util`,`api/java_net` JCK tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264048: Remove old version of RemoveJar test

Marked as reviewed by dfuchs (Reviewer).

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

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

From jbachorik at openjdk.java.net  Thu Apr  1 16:00:38 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 1 Apr 2021 16:00:38 GMT
Subject: RFR: 8203359: Container level resources events
In-Reply-To: <kfY9mi-n8TsPGlK_QctCmtzxsgr0bs5VrGxepAtI4xc=.549f72df-9639-4d3c-a9d6-40d2aab1509f@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <32-BO7tExbAStlYsma_g-oc8kw-kj3HSyhJOP-qAjLk=.6c4d8c45-1a64-4b5a-8767-7307c297b3d8@github.com>
 <guLUz-SeGYnE6_eRBBNQgyWIoC7XoemXN5iyGVHFlMU=.9e1ee611-1e1d-477d-bf7f-df29a93f7149@github.com>
 <kfY9mi-n8TsPGlK_QctCmtzxsgr0bs5VrGxepAtI4xc=.549f72df-9639-4d3c-a9d6-40d2aab1509f@github.com>
Message-ID: <8JHw6MbcfjniWnYayJja7shthcZX-KWA2D_LrMQdhNM=.170772c2-cd50-49f9-acc4-18e2eb7137da@github.com>

On Fri, 26 Mar 2021 11:05:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Does each getter call result in parsing /proc, or do things aggregated over several calls or hooks?
>> 
>> Do you have any data how expensive the invocations are? 
>> 
>> You could for example try to measure it by temporary making the events durational, and fetch the values between begin() and end(), and perhaps show a 'jfr print --events Container* recording.jfr' printout. 
>> 
>> If possible, it would be interesting to get some idea about the startup cost as well
>> 
>> If not too much overhead, I think it would be nice to skip the "flag" in the .jfcs, and always record the events in a container environment.
>> 
>> I know there is a way to test JFR using Docker, maybe @mseledts could provide information? Some sanity tests would be good to have.
>
>> Does each getter call result in parsing /proc, or do things aggregated over several calls or hooks?
> 
> From the looks of it the event emitting code uses `Metrics.java` interface for retrieving the info. Each call to a method exposed by Metrics result in file IO on some cgroup (v1 or v2) interface file(s) in `/sys/fs/...`. I don't see any aggregation being done.
> 
> On the hotspot side, we implemented some caching for frequent calls (JDK-8232207, JDK-8227006), but we didn't do that yet for the Java side since there wasn't any need (so far). If calls are becoming frequent with this it should be reconsidered.
> 
> So +1 on getting some data on what the perf penalty of this is.

Thanks to all for chiming in!

I have added the tests to `test/hotspot/jtreg/containers/docker/TestJFREvents.java` where there already were some templates for the container event data.

As for the performance - as expected, extracting the data from `/proc` is not exactly cheap. On my test c5.4xlarge instance I am getting an average wall-clock time to generate the usage/throttling events (one instance of each) of ~15ms.
I would argue that 15ms per 30s (the default emission period for those events) might be acceptable to start with. 

Caching of cgroups parsed data would help if the emission period is shorter than the cache TTL. This is exacerbated by the fact that (almost) each container event type requires data from a different cgroups control file - hence the data will not be shared between the event type instances even if cached. Realistically, caching benefits would become visible only for sub-second emission periods.

If the caching is still required I would suggest having a follow up ticket just for that - it will require setting up some benchmarks to justify the changes that would need to be done in the metrics implementation.

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

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

From darcy at openjdk.java.net  Thu Apr  1 16:47:54 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 1 Apr 2021 16:47:54 GMT
Subject: RFR: 8169629: Annotations with lambda expressions cause
 AnnotationFormatError [v2]
In-Reply-To: <gD7qFYsjwU-W7Z84CPc5aZbc2gBFaTM8RvyxeP41nBQ=.049861b7-0717-471f-bbb7-8b14c01a2ede@github.com>
References: <gD7qFYsjwU-W7Z84CPc5aZbc2gBFaTM8RvyxeP41nBQ=.049861b7-0717-471f-bbb7-8b14c01a2ede@github.com>
Message-ID: <gLOTdl2qbCNx3UeJK6yOG7J9A-1hNA2Q_-U9iNJjafs=.bad6019e-3ca6-4ee7-b4ba-ccc984f51b71@github.com>

> The stricter checks added by
>     8035781: Improve equality for annotations
> in creating the proxy objects used to implement annotations has an unintended by-catch of rejecting annotation's whose type has, say, a field initialized with a lambda expression. While uncommon, it is legal code to have a field in an annotation type.
> 
> The updated checks skip over the sort of synthetic method used for the initialization.
> 
> Some different compilation tactics were used before and after nest mates, so the test includes compilation and testing under both situations.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3294/files
  - new: https://git.openjdk.java.net/jdk/pull/3294/files/818df21d..db79e3c8

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

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

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

From darcy at openjdk.java.net  Thu Apr  1 16:47:57 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 1 Apr 2021 16:47:57 GMT
Subject: RFR: 8169629: Annotations with lambda expressions cause
 AnnotationFormatError [v2]
In-Reply-To: <H878ScmiSagZ8uHQua_jwsLR0HESPs2zMHkRIoVFYwI=.bf8210a7-862b-4ef0-b542-6ffd624b6593@github.com>
References: <gD7qFYsjwU-W7Z84CPc5aZbc2gBFaTM8RvyxeP41nBQ=.049861b7-0717-471f-bbb7-8b14c01a2ede@github.com>
 <H878ScmiSagZ8uHQua_jwsLR0HESPs2zMHkRIoVFYwI=.bf8210a7-862b-4ef0-b542-6ffd624b6593@github.com>
Message-ID: <cw9nURQAaKf1PS_VBkUhR6TRpGhOjvvMjhRczNAYDXg=.bc50799b-8cf8-4d65-9a1d-3667a0902cd8@github.com>

On Thu, 1 Apr 2021 12:36:56 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java line 497:
> 
>> 495:         Method currentMethod = null;
>> 496:         for(Method method : memberMethods) {
>> 497:             currentMethod = method;
> 
> I can't see any use of currentMethod, am I missing something?

Remnant of a second fix I pulled out for separate handling; I'll remove before pushing. Thanks.

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

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

From darcy at openjdk.java.net  Thu Apr  1 16:50:21 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 1 Apr 2021 16:50:21 GMT
Subject: Integrated: 8169629: Annotations with lambda expressions cause
 AnnotationFormatError
In-Reply-To: <gD7qFYsjwU-W7Z84CPc5aZbc2gBFaTM8RvyxeP41nBQ=.049861b7-0717-471f-bbb7-8b14c01a2ede@github.com>
References: <gD7qFYsjwU-W7Z84CPc5aZbc2gBFaTM8RvyxeP41nBQ=.049861b7-0717-471f-bbb7-8b14c01a2ede@github.com>
Message-ID: <s3wxRmjQSvno1x2kRsqEb2dpfGrSKms4vN7JLh2OXek=.24ffb403-cd3d-4d5b-9382-b925555d01f0@github.com>

On Wed, 31 Mar 2021 21:32:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The stricter checks added by
>     8035781: Improve equality for annotations
> in creating the proxy objects used to implement annotations has an unintended by-catch of rejecting annotation's whose type has, say, a field initialized with a lambda expression. While uncommon, it is legal code to have a field in an annotation type.
> 
> The updated checks skip over the sort of synthetic method used for the initialization.
> 
> Some different compilation tactics were used before and after nest mates, so the test includes compilation and testing under both situations.

This pull request has now been integrated.

Changeset: 328e9514
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/328e9514
Stats:     27 lines in 2 files changed: 23 ins; 0 del; 4 mod

8169629: Annotations with lambda expressions cause AnnotationFormatError

Reviewed-by: jfranck

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

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

From jvernee at openjdk.java.net  Thu Apr  1 17:01:51 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 1 Apr 2021 17:01:51 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector
Message-ID: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>

This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.

The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.

In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.

Rather than sticking on a band aid, the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).

The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.

The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.

As a result of these changes a lot of code was unused and has been removed in this patch.

Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).

Here are some numbers from the added benchmark:

Before:
Benchmark                                    Mode  Cnt    Score    Error  Units
TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
(as you can see, just the Object[] with arity less than 10 case is fast here)
After:
Benchmark                                    Mode  Cnt  Score   Error  Units
TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op

Thanks,
Jorn

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

Commit messages:
 - WIP - clean up
 - Completely implement collect in lambdaform
 - WIP - fix MH collector perf, with jumbo arity bandaid

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

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

From iklam at openjdk.java.net  Thu Apr  1 17:40:24 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 1 Apr 2021 17:40:24 GMT
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
Message-ID: <2p6rqT2_ggbZhL1Jy4g0l_OpqfBNMKvPuOfY8owUQ04=.6c4f1371-437e-4b7a-b39b-64f193d90cc2@github.com>

On Thu, 1 Apr 2021 11:48:21 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> We should never close the jimage since java threads can still be running after a hard exit().

LGTM.

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

Marked as reviewed by iklam (Reviewer).

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

From darcy at openjdk.java.net  Thu Apr  1 18:20:44 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 1 Apr 2021 18:20:44 GMT
Subject: RFR: 8264610: Number.{byteValue, shortValue} spec should use @implSpec
Message-ID: <Zc93bOnIB_p26k5w1lOBX7uyyxIiodxNeElUoJXSyOs=.4969e8b0-a56c-4b47-a1fe-87294c2a375a@github.com>

Please review this small code change and its accompanying CSR:

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

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

Commit messages:
 - Update second method.
 - 8264609: Number.shortValue spec should use @implSpec

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

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

From alanb at openjdk.java.net  Thu Apr  1 18:22:13 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 1 Apr 2021 18:22:13 GMT
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
Message-ID: <_ctT57Zek8k0XjTFlfwCmqqTlADvQV_yff7dQDrbsjQ=.035b0412-cdd3-4bd4-89e0-218e86f2e78a@github.com>

On Thu, 1 Apr 2021 11:48:21 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> We should never close the jimage since java threads can still be running after a hard exit().

src/java.base/share/native/libjimage/imageFile.cpp line 219:

> 217: // WARNING: Should never close the jimage file.
> 218: //          Threads may still be running at shutdown.
> 219: #if 0

Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted.

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

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

From jlaskey at openjdk.java.net  Thu Apr  1 18:51:29 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 1 Apr 2021 18:51:29 GMT
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <_ctT57Zek8k0XjTFlfwCmqqTlADvQV_yff7dQDrbsjQ=.035b0412-cdd3-4bd4-89e0-218e86f2e78a@github.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
 <_ctT57Zek8k0XjTFlfwCmqqTlADvQV_yff7dQDrbsjQ=.035b0412-cdd3-4bd4-89e0-218e86f2e78a@github.com>
Message-ID: <u5zETzxDG4Caki1s4Z0OeybX7OdGqOOW7Tta-4dyu0I=.56185994-fb85-4372-8f73-b3327ef27e4f@github.com>

On Thu, 1 Apr 2021 18:19:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We should never close the jimage since java threads can still be running after a hard exit().
>
> src/java.base/share/native/libjimage/imageFile.cpp line 219:
> 
>> 217: // WARNING: Should never close the jimage file.
>> 218: //          Threads may still be running at shutdown.
>> 219: #if 0
> 
> Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted.

Leaving the code as an example of what is required to close in case the topic gets revisited in the future and I get hit by a bus or dementia.

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

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

From jrose at openjdk.java.net  Thu Apr  1 19:16:19 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Thu, 1 Apr 2021 19:16:19 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector
In-Reply-To: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
Message-ID: <akZ-gXcA8Vvr389w0X1ZGYQJGSPr7iBQKHY6LAlw36k=.b8950920-b4ce-4306-8355-3e90f1df1318@github.com>

On Thu, 1 Apr 2021 13:25:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
> 
> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
> 
> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
> 
> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
> 
> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
> 
> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
> 
> As a result of these changes a lot of code was unused and has been removed in this patch.
> 
> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
> 
> Here are some numbers from the added benchmark:
> 
> Before:
> Benchmark                                    Mode  Cnt    Score    Error  Units
> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
> (as you can see, just the Object[] with arity less than 10 case is fast here)
> After:
> Benchmark                                    Mode  Cnt  Score   Error  Units
> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
> 
> Thanks,
> Jorn

So many red deletion lines; I'm looking at a beautiful sunset!
It's a sunset for some very old code, some of the first code
I wrote for method handles, long before Lambda Forms
made this sort of task easier.

Thanks very much for cleaning this out.  See a few
minor comments on some diff lines.

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 651:

> 649:     }
> 650: 
> 651:     LambdaForm collectArgumentArrayForm(int pos, MethodHandle arrayCollector) {

It's counter-intuitive that removing a LFE tactic would be harmless.
Each LFE tactic is a point where LFs can be shared, reducing footprint.
But in this case `collectArgumentArrayForm` is always paired with
`collectArgumentsForm`, so the latter takes care of sharing.
The actual code which makes the arrays is also shared, via
`Makers.TYPED_COLLECTORS` (unchanged).

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1342:

> 1340:     }
> 1341: 
> 1342:     // Array identity function (used as getConstantHandle(MH_arrayIdentity)).

If this is no longer used, remove it.

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1903:

> 1901:     }
> 1902: 
> 1903:     private static LambdaForm makeCollectorForm(MethodType basicType, MethodHandle storeFunc) {

This reads very well.  It is the right way to do this job with LFs.
There is a slight risk that the JIT will fail to inline the tiny MHs
that (a) construct arrays and (b) poke elements into them.
If that happens, then perhaps the bytecode generator can
treat them as intrinsics.  Maybe that's worth a comment in
the code, to help later readers?

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

Marked as reviewed by jrose (Reviewer).

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

From psandoz at openjdk.java.net  Thu Apr  1 19:22:19 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 1 Apr 2021 19:22:19 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector
In-Reply-To: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
Message-ID: <_rGqipYkniAqcFVS6DRfaz71wHMWuxH2I1fk9UxNwHs=.4226fd59-b7c1-4c89-a69e-8be528ab72e3@github.com>

On Thu, 1 Apr 2021 13:25:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
> 
> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
> 
> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
> 
> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
> 
> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
> 
> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
> 
> As a result of these changes a lot of code was unused and has been removed in this patch.
> 
> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
> 
> Here are some numbers from the added benchmark:
> 
> Before:
> Benchmark                                    Mode  Cnt    Score    Error  Units
> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
> (as you can see, just the Object[] with arity less than 10 case is fast here)
> After:
> Benchmark                                    Mode  Cnt  Score   Error  Units
> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
> 
> Thanks,
> Jorn

That's an elegant solution.

At first i thought it might unduly perturb lambda form generation and caching. but you slotted a different lambda form implementation underneath the varargs implementation.

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1277:

> 1275:             if (intrinsicName == Intrinsic.IDENTITY) {
> 1276:                 MethodType resultType = type().asCollectorType(arrayType, type().parameterCount() - 1, arrayLength);
> 1277:                 MethodHandle collector = MethodHandleImpl.makeCollector(arrayType, arrayLength);

Should `MethodHandleImpl.varargsArray` still be used here since it performs arity checking and caching? 

Maybe the arity checks are performed by `asCollectorType`, but that would still leave the caching.

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

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

From psandoz at openjdk.java.net  Thu Apr  1 19:26:15 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 1 Apr 2021 19:26:15 GMT
Subject: RFR: 8264610: Number.{byteValue,
 shortValue} spec should use @implSpec
In-Reply-To: <Zc93bOnIB_p26k5w1lOBX7uyyxIiodxNeElUoJXSyOs=.4969e8b0-a56c-4b47-a1fe-87294c2a375a@github.com>
References: <Zc93bOnIB_p26k5w1lOBX7uyyxIiodxNeElUoJXSyOs=.4969e8b0-a56c-4b47-a1fe-87294c2a375a@github.com>
Message-ID: <hB2Oh_wtE3cYB5uvwEwv2lx2R5W5taiLXpk3_dObzaE=.67397b3a-8c16-4649-b541-8f9c02f2610d@github.com>

On Thu, 1 Apr 2021 18:12:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small code change and its accompanying CSR:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8264610

Marked as reviewed by psandoz (Reviewer).

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

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

From jvernee at openjdk.java.net  Thu Apr  1 19:29:31 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 1 Apr 2021 19:29:31 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector
In-Reply-To: <_rGqipYkniAqcFVS6DRfaz71wHMWuxH2I1fk9UxNwHs=.4226fd59-b7c1-4c89-a69e-8be528ab72e3@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <_rGqipYkniAqcFVS6DRfaz71wHMWuxH2I1fk9UxNwHs=.4226fd59-b7c1-4c89-a69e-8be528ab72e3@github.com>
Message-ID: <-nMkaw5aYYFBo7GJtCheNx_ED3E9eSvs-uuulpEiyLc=.407c7b1f-f4b7-4832-9670-31786573a836@github.com>

On Thu, 1 Apr 2021 19:12:42 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
>> 
>> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
>> 
>> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
>> 
>> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
>> 
>> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
>> 
>> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
>> 
>> As a result of these changes a lot of code was unused and has been removed in this patch.
>> 
>> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
>> 
>> Here are some numbers from the added benchmark:
>> 
>> Before:
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
>> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
>> (as you can see, just the Object[] with arity less than 10 case is fast here)
>> After:
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
>> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
>> 
>> Thanks,
>> Jorn
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1277:
> 
>> 1275:             if (intrinsicName == Intrinsic.IDENTITY) {
>> 1276:                 MethodType resultType = type().asCollectorType(arrayType, type().parameterCount() - 1, arrayLength);
>> 1277:                 MethodHandle collector = MethodHandleImpl.makeCollector(arrayType, arrayLength);
> 
> Should `MethodHandleImpl.varargsArray` still be used here since it performs arity checking and caching? 
> 
> Maybe the arity checks are performed by `asCollectorType`, but that would still leave the caching.

Ah right, good catch! This is a leftover from moving things around and should indeed use `varargsArray`.

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

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

From jvernee at openjdk.java.net  Thu Apr  1 19:29:31 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 1 Apr 2021 19:29:31 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector
In-Reply-To: <akZ-gXcA8Vvr389w0X1ZGYQJGSPr7iBQKHY6LAlw36k=.b8950920-b4ce-4306-8355-3e90f1df1318@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <akZ-gXcA8Vvr389w0X1ZGYQJGSPr7iBQKHY6LAlw36k=.b8950920-b4ce-4306-8355-3e90f1df1318@github.com>
Message-ID: <AUlpGLA5DWjMq6OQlRABlh01zSMuoaIllqFQHpyYCS4=.15d9c431-dfa4-456a-b56f-293ad3be6b07@github.com>

On Thu, 1 Apr 2021 19:09:14 GMT, John R Rose <jrose at openjdk.org> wrote:

>> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
>> 
>> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
>> 
>> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
>> 
>> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
>> 
>> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
>> 
>> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
>> 
>> As a result of these changes a lot of code was unused and has been removed in this patch.
>> 
>> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
>> 
>> Here are some numbers from the added benchmark:
>> 
>> Before:
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
>> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
>> (as you can see, just the Object[] with arity less than 10 case is fast here)
>> After:
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
>> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
>> 
>> Thanks,
>> Jorn
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1342:
> 
>> 1340:     }
>> 1341: 
>> 1342:     // Array identity function (used as getConstantHandle(MH_arrayIdentity)).
> 
> If this is no longer used, remove it.

Yes, it looks like this can be removed. Good catch!

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

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

From jvernee at openjdk.java.net  Thu Apr  1 19:33:11 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 1 Apr 2021 19:33:11 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector
In-Reply-To: <akZ-gXcA8Vvr389w0X1ZGYQJGSPr7iBQKHY6LAlw36k=.b8950920-b4ce-4306-8355-3e90f1df1318@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <akZ-gXcA8Vvr389w0X1ZGYQJGSPr7iBQKHY6LAlw36k=.b8950920-b4ce-4306-8355-3e90f1df1318@github.com>
Message-ID: <XIYWhyGbsdWtgtapiVHqrnHWISvb62mlHhS5IuZ6oM0=.2f98b2c9-5c6e-4123-ab32-539764c5687a@github.com>

On Thu, 1 Apr 2021 19:09:53 GMT, John R Rose <jrose at openjdk.org> wrote:

>> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
>> 
>> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
>> 
>> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
>> 
>> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
>> 
>> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
>> 
>> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
>> 
>> As a result of these changes a lot of code was unused and has been removed in this patch.
>> 
>> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
>> 
>> Here are some numbers from the added benchmark:
>> 
>> Before:
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
>> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
>> (as you can see, just the Object[] with arity less than 10 case is fast here)
>> After:
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
>> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
>> 
>> Thanks,
>> Jorn
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1903:
> 
>> 1901:     }
>> 1902: 
>> 1903:     private static LambdaForm makeCollectorForm(MethodType basicType, MethodHandle storeFunc) {
> 
> This reads very well.  It is the right way to do this job with LFs.
> There is a slight risk that the JIT will fail to inline the tiny MHs
> that (a) construct arrays and (b) poke elements into them.
> If that happens, then perhaps the bytecode generator can
> treat them as intrinsics.  Maybe that's worth a comment in
> the code, to help later readers?

Good idea, I'll leave some notes.

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

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

From bpb at openjdk.java.net  Thu Apr  1 19:33:16 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 1 Apr 2021 19:33:16 GMT
Subject: RFR: 8264610: Number.{byteValue,
 shortValue} spec should use @implSpec
In-Reply-To: <Zc93bOnIB_p26k5w1lOBX7uyyxIiodxNeElUoJXSyOs=.4969e8b0-a56c-4b47-a1fe-87294c2a375a@github.com>
References: <Zc93bOnIB_p26k5w1lOBX7uyyxIiodxNeElUoJXSyOs=.4969e8b0-a56c-4b47-a1fe-87294c2a375a@github.com>
Message-ID: <lDPB0yBvPaAFBauEu3SkPV0TW63YtcJaTvixjq9JIBw=.08c74887-6d94-4fc3-8747-cde53e5f6c60@github.com>

On Thu, 1 Apr 2021 18:12:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small code change and its accompanying CSR:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8264610

CSR also reviewed.

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

Marked as reviewed by bpb (Reviewer).

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

From darcy at openjdk.java.net  Thu Apr  1 19:50:24 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 1 Apr 2021 19:50:24 GMT
Subject: Integrated: 8264609 : Number.{byteValue,
 shortValue} spec should use @implSpec
In-Reply-To: <Zc93bOnIB_p26k5w1lOBX7uyyxIiodxNeElUoJXSyOs=.4969e8b0-a56c-4b47-a1fe-87294c2a375a@github.com>
References: <Zc93bOnIB_p26k5w1lOBX7uyyxIiodxNeElUoJXSyOs=.4969e8b0-a56c-4b47-a1fe-87294c2a375a@github.com>
Message-ID: <Zze_gZfUZm1wFCBQ1QYvJ8xA28AYhIfneHtfVCPluTY=.9aa313ce-483b-4d91-a45a-54ee2f4f4fdf@github.com>

On Thu, 1 Apr 2021 18:12:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small code change and its accompanying CSR:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8264610

This pull request has now been integrated.

Changeset: b953386d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b953386d
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8264609: Number.{byteValue, shortValue} spec should use @implSpec

Reviewed-by: psandoz, bpb

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

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

From jlaskey at openjdk.java.net  Thu Apr  1 19:54:46 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 1 Apr 2021 19:54:46 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v41]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <UMIWhmjmbfxm1butME1_SsczUymqrAjOHRpop6hZKv8=.26a34b0c-4173-436a-87f9-258b733a8ae1@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

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

  Fix NotCompliantCauseTest to not rely on Random not being a bean

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/5a23b4f1..c5fb77f9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=40
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=39-40

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

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

From herrick at openjdk.java.net  Thu Apr  1 20:43:11 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 1 Apr 2021 20:43:11 GMT
Subject: Integrated: JDK-8264403: [macos]: App names containing '.' characters
 results in an error message when launching
In-Reply-To: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
References: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
Message-ID: <wj5Bg5dLZTk95AeZyGJiAyN9lfrG2EMtEBBLno_tYl4=.ac38e321-7b29-4c82-ba48-9f3abf777781@github.com>

On Wed, 31 Mar 2021 19:30:10 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Deriving the cfg file name is broken on mac and linux when the application name has a "." in it.

This pull request has now been integrated.

Changeset: 04f24fe9
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/04f24fe9
Stats:     81 lines in 5 files changed: 78 ins; 1 del; 2 mod

8264403: [macos]: App names containing '.' characters results in an error message when launching

Reviewed-by: asemenyuk

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

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

From naoto at openjdk.java.net  Thu Apr  1 21:04:29 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 1 Apr 2021 21:04:29 GMT
Subject: RFR: 8264544: Case-insensitive comparison issue with supplementary
 characters.
Message-ID: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>

Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

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

Commit messages:
 - 8264544: Case-insensitive comparison issue with supplementary characters.

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

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

From igraves at openjdk.java.net  Thu Apr  1 21:09:42 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 1 Apr 2021 21:09:42 GMT
Subject: RFR: 8037397: Lost nested character class after intersection &&
 [v2]
In-Reply-To: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
Message-ID: <wpSqmKhhzijtA5AZScyl-oo4FYiscSw_3ojFJh16Wjs=.48404b9e-33b8-4563-8f9a-7077fc203958@github.com>

> Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones.

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

  Fixing missing space

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3291/files
  - new: https://git.openjdk.java.net/jdk/pull/3291/files/76cf0be2..2a783a1e

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

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

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

From darcy at openjdk.java.net  Thu Apr  1 22:22:44 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 1 Apr 2021 22:22:44 GMT
Subject: RFR: 8205502: Make exception message from AnnotationInvocationHandler
 more informative
Message-ID: <mFwp02ke3gpeIDVRSzRMuXAVQLU7X2wc7e6bYF185Wg=.704ea7fb-4fd8-468b-a7ff-2f85b144848d@github.com>

Simple change to make the exception/error messages more informative for various malformed annotation situations.

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

Commit messages:
 - Appease jcheck.
 - 8205502: Make exception message from AnnotationInvocationHandler more informative

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

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

From bpb at openjdk.java.net  Thu Apr  1 22:27:21 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 1 Apr 2021 22:27:21 GMT
Subject: RFR: 8205502: Make exception message from
 AnnotationInvocationHandler more informative
In-Reply-To: <mFwp02ke3gpeIDVRSzRMuXAVQLU7X2wc7e6bYF185Wg=.704ea7fb-4fd8-468b-a7ff-2f85b144848d@github.com>
References: <mFwp02ke3gpeIDVRSzRMuXAVQLU7X2wc7e6bYF185Wg=.704ea7fb-4fd8-468b-a7ff-2f85b144848d@github.com>
Message-ID: <-EQlbSw-fg5FTpqTMEUWSXmFM-oHm9NkuPb0wth2_V4=.22eeb65e-bd4a-4642-834e-0849255d69b7@github.com>

On Thu, 1 Apr 2021 22:15:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple change to make the exception/error messages more informative for various malformed annotation situations.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

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

From naoto at openjdk.java.net  Thu Apr  1 22:31:25 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 1 Apr 2021 22:31:25 GMT
Subject: RFR: 8205502: Make exception message from
 AnnotationInvocationHandler more informative
In-Reply-To: <mFwp02ke3gpeIDVRSzRMuXAVQLU7X2wc7e6bYF185Wg=.704ea7fb-4fd8-468b-a7ff-2f85b144848d@github.com>
References: <mFwp02ke3gpeIDVRSzRMuXAVQLU7X2wc7e6bYF185Wg=.704ea7fb-4fd8-468b-a7ff-2f85b144848d@github.com>
Message-ID: <j8Q_Y13Pp9kW0tYOyTn2fiVFBkQUgVqUYeUpxxNv1fA=.85d9069b-3f52-409e-83dc-e479a17d8bdb@github.com>

On Thu, 1 Apr 2021 22:15:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple change to make the exception/error messages more informative for various malformed annotation situations.

Marked as reviewed by naoto (Reviewer).

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

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

From joehw at openjdk.java.net  Thu Apr  1 22:35:22 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 1 Apr 2021 22:35:22 GMT
Subject: RFR: 8264544: Case-insensitive comparison issue with
 supplementary characters.
In-Reply-To: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
References: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
Message-ID: <vN8FGFeOSfM1ueg8T0W2Xh-ghpjZDcycXf5ezyTonFI=.81a5324a-4078-488e-9ca6-11b0828ad594@github.com>

On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

Marked as reviewed by joehw (Reviewer).

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

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

From iris at openjdk.java.net  Thu Apr  1 22:48:25 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 1 Apr 2021 22:48:25 GMT
Subject: RFR: 8264544: Case-insensitive comparison issue with
 supplementary characters.
In-Reply-To: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
References: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
Message-ID: <cjesnh9zr2KJpmIcAFrB81Gr4AaETp-an79klF3ZVag=.93dcfb86-8ecb-4fee-94a9-ee9114d6e26e@github.com>

On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

Marked as reviewed by iris (Reviewer).

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

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

From iris at openjdk.java.net  Thu Apr  1 22:59:25 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 1 Apr 2021 22:59:25 GMT
Subject: RFR: 8205502: Make exception message from
 AnnotationInvocationHandler more informative
In-Reply-To: <mFwp02ke3gpeIDVRSzRMuXAVQLU7X2wc7e6bYF185Wg=.704ea7fb-4fd8-468b-a7ff-2f85b144848d@github.com>
References: <mFwp02ke3gpeIDVRSzRMuXAVQLU7X2wc7e6bYF185Wg=.704ea7fb-4fd8-468b-a7ff-2f85b144848d@github.com>
Message-ID: <ktqCx8G_PKg_Z6aHaMnc6baxSFx1f3YDPAkA9we6H9U=.26f0c6c3-2d54-44b8-aa29-3f6cfc02bfca@github.com>

On Thu, 1 Apr 2021 22:15:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple change to make the exception/error messages more informative for various malformed annotation situations.

Marked as reviewed by iris (Reviewer).

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

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

From darcy at openjdk.java.net  Thu Apr  1 23:16:27 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 1 Apr 2021 23:16:27 GMT
Subject: Integrated: 8205502: Make exception message from
 AnnotationInvocationHandler more informative
In-Reply-To: <mFwp02ke3gpeIDVRSzRMuXAVQLU7X2wc7e6bYF185Wg=.704ea7fb-4fd8-468b-a7ff-2f85b144848d@github.com>
References: <mFwp02ke3gpeIDVRSzRMuXAVQLU7X2wc7e6bYF185Wg=.704ea7fb-4fd8-468b-a7ff-2f85b144848d@github.com>
Message-ID: <hyiaFWqopfSf50hyX-HH_RdkhH_RnTJDryOFlFIFg6E=.a96a719f-3e6a-4549-b6df-d7e3e4542447@github.com>

On Thu, 1 Apr 2021 22:15:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple change to make the exception/error messages more informative for various malformed annotation situations.

This pull request has now been integrated.

Changeset: 66d9961c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/66d9961c
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8205502: Make exception message from AnnotationInvocationHandler more informative

Reviewed-by: bpb, naoto, iris

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

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

From dongbo at openjdk.java.net  Fri Apr  2 03:10:57 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 2 Apr 2021 03:10:57 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

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

 - Merge branch 'master' into aarch64.base64.decode
 - copyright
 - trivial fixes
 - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
 - Merge branch 'master' into aarch64.base64.decode
 - 8256245: AArch64: Implement Base64 decoding intrinsic

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3228/files
  - new: https://git.openjdk.java.net/jdk/pull/3228/files/e658ebf4..16ebc471

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

  Stats: 7270 lines in 287 files changed: 5225 ins; 950 del; 1095 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3228.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228

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

From xgong at openjdk.java.net  Fri Apr  2 03:26:16 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 2 Apr 2021 03:26:16 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <bH97iO9EOXZRcKTS2zyOBwfqJLoRUiP-wFzccuKb-fg=.bd983da8-9b58-4bb3-b8a3-395ef669aafc@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
 <bH97iO9EOXZRcKTS2zyOBwfqJLoRUiP-wFzccuKb-fg=.bd983da8-9b58-4bb3-b8a3-395ef669aafc@github.com>
Message-ID: <Fo4Qw_h0xKs4kBtdlv5mXy6mhh4e9hxWTs7YtC8a678=.9f90b57a-9146-4473-8036-7aee3a36b217@github.com>

On Thu, 1 Apr 2021 15:13:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the changing to AbstractMask.andNot and revert changes in VectorMask
>>   
>>   Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
>>   CustomizedGitHooks: yes
>
> Looks good.

Thanks for your review @PaulSandoz !

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

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

From dongbo at openjdk.java.net  Fri Apr  2 07:08:33 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 2 Apr 2021 07:08:33 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <Nn9jqfMe-xnqho_oiJKjJwTMc7rRUy3cjrB0E0RpsqY=.34512df4-3587-4b8c-96e2-af4d82851c8f@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
 <vxrUJagEcM97odeOocaFBJjZC_lNQwiuGmJwD0s-7wc=.d75d3029-2513-405c-afa3-f1ed8e7af5a1@github.com>
 <Nn9jqfMe-xnqho_oiJKjJwTMc7rRUy3cjrB0E0RpsqY=.34512df4-3587-4b8c-96e2-af4d82851c8f@github.com>
Message-ID: <zhrOSmz2aytq_cXzp88IC5wXiTw3fyjfPD6XPxx7dkY=.4f3a7845-f33e-49ef-8488-eaf81c2c1020@github.com>

On Tue, 30 Mar 2021 03:24:16 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>>> I think I can rewrite this part as loops.
>>> With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?
>> 
>> Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified.
>
>> > With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?
>> 
>> Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified.
> 
> Hi, @theRealAph @nick-arm 
> 
> The code is updated. The error handling in SIMD case was rewriten as loops.
> 
> Also combined the two non-SIMD code blocks into one.
> Due to we have only one non-SIMD loop now, it is moved into `generate_base64_decodeBlock`.
> The size of the stub is 692 bytes, the non-SIMD loop takes about 92 bytes if my calculation is right.
> 
> Verified with tests `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java`.
> Compared with previous implementation, the performance changes are negligible.
> 
> Other comments are addressed too. Thanks.

PING... Any suggestions on the updated commit?

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

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

From alanb at openjdk.java.net  Fri Apr  2 07:34:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 2 Apr 2021 07:34:29 GMT
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <u5zETzxDG4Caki1s4Z0OeybX7OdGqOOW7Tta-4dyu0I=.56185994-fb85-4372-8f73-b3327ef27e4f@github.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
 <_ctT57Zek8k0XjTFlfwCmqqTlADvQV_yff7dQDrbsjQ=.035b0412-cdd3-4bd4-89e0-218e86f2e78a@github.com>
 <u5zETzxDG4Caki1s4Z0OeybX7OdGqOOW7Tta-4dyu0I=.56185994-fb85-4372-8f73-b3327ef27e4f@github.com>
Message-ID: <8va8xgeb9JwkDs9e0WnHH4n2NZpe1nzaBvq35qclyX8=.c492c22e-9887-4766-a4f1-dea32f9853da@github.com>

On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/native/libjimage/imageFile.cpp line 219:
>> 
>>> 217: // WARNING: Should never close the jimage file.
>>> 218: //          Threads may still be running at shutdown.
>>> 219: #if 0
>> 
>> Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted.
>
> Leaving the code as an example of what is required to close in case the topic gets revisited in the future and I get hit by a bus or dementia.

Okay although I assume someone will spot this and be tempted to remove it.

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

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

From alanb at openjdk.java.net  Fri Apr  2 07:34:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 2 Apr 2021 07:34:29 GMT
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
Message-ID: <mophz6TB7r4ksLMA-rRbU_gq8AVHxVJMIwEE1rQd6aY=.98acd5c7-1f26-4d49-b642-3235d82135f8@github.com>

On Thu, 1 Apr 2021 11:48:21 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> We should never close the jimage since java threads can still be running after a hard exit().

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.java.net  Fri Apr  2 08:09:19 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 2 Apr 2021 08:09:19 GMT
Subject: RFR: 8264544: Case-insensitive comparison issue with
 supplementary characters.
In-Reply-To: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
References: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
Message-ID: <DvgSbZ1DzT3lVeAqbG-ZWWxJ25Bjaba57Ch4iAXHD0s=.da81f7c1-c8bf-4a75-814f-833b86a93733@github.com>

On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

Marked as reviewed by alanb (Reviewer).

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

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

From aph at openjdk.java.net  Fri Apr  2 08:41:34 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 08:41:34 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
Message-ID: <UP7i84Aa4xFdcVL0LyL4jGGXKEPeJo91xQsTOGU-Xeg=.1877b9d8-3468-40cc-8c02-9f5ae13703ed@github.com>

On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into aarch64.base64.decode
>  - copyright
>  - trivial fixes
>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>  - Merge branch 'master' into aarch64.base64.decode
>  - 8256245: AArch64: Implement Base64 decoding intrinsic

test/micro/org/openjdk/bench/java/util/Base64Decode.java line 85:

> 83:         }
> 84:     }
> 85: 

Are there any existing test cases for failing inputs?

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

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

From aph at openjdk.java.net  Fri Apr  2 08:49:29 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 08:49:29 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
Message-ID: <8yiJSbnHVrZTDGmKi7oQygWvCR8Gyvv4iSLdEAAez7I=.fa47a77d-54f1-4b60-94af-ad1aefb40470@github.com>

On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into aarch64.base64.decode
>  - copyright
>  - trivial fixes
>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>  - Merge branch 'master' into aarch64.base64.decode
>  - 8256245: AArch64: Implement Base64 decoding intrinsic

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5811:

> 5809:     __ ldrb(r12, __ post(src, 1));
> 5810:     __ ldrb(r13, __ post(src, 1));
> 5811:     // get the de-code

For loads and four post increments rather than one load and a few BFMs? Why?

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

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

From aph at openjdk.java.net  Fri Apr  2 08:49:24 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 08:49:24 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
Message-ID: <iu1E9W1adVNrVe6PynoXaGNrO3TL4eI1BvNuepqmlqw=.703f223a-50aa-401e-8a62-3dcba33cda63@github.com>

On Mon, 29 Mar 2021 03:28:54 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> > Please consider losing the non-SIMD case. It doesn't result in any significant gain.
> 
> The non-SIMD case is useful for MIME decoding performance.

Your test results suggest that it isn't useful for that, surely?

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

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

From lzang at openjdk.java.net  Fri Apr  2 08:53:57 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 2 Apr 2021 08:53:57 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v4]
In-Reply-To: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
Message-ID: <xmzaiHrMrTacyNl6hq54Gsq30-AyHM2R8SirIKyzpsA=.a3dce628-0e81-4588-aba2-ef8fd94b2e4d@github.com>

> 4890732: GZIPOutputStream doesn't support optional GZIP fields

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

  add class GZIPHeaderData, refine testcases

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3072/files
  - new: https://git.openjdk.java.net/jdk/pull/3072/files/9b7dabfe..03b3e966

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

  Stats: 633 lines in 3 files changed: 421 ins; 183 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

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

From lzang at openjdk.java.net  Fri Apr  2 08:56:36 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 2 Apr 2021 08:56:36 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v3]
In-Reply-To: <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
Message-ID: <z-VtWLNFeho201QW1vLymWa3vB-TSkwMElKw_seESeM=.c5d67dac-2543-4bd4-b5d3-dfc15e56d4fa@github.com>

On Wed, 24 Mar 2021 10:25:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi Lance?
>> Thanks a lot for your review. I will update the PR ASAP. 
>> May I ask your help to also review the CSR? Thanks!
>> 
>> BRs,
>> Lin
>
> Hi Lin,
> 
> On Mar 24, 2021, at 2:51 AM, Lin Zang ***@***.******@***.***>> wrote:
> 
> 
> 
> Hi Lance?
> Thanks a lot for your review. I will update the PR ASAP.
> May I ask your help to also review the CSR?
> 
> I believe we need to flush out some of the issues I raised that were not test related as they will result in updates to the javadoc which will require an update to the CSR.
> 
> 
> 
> Thanks!
> 
> BRs,
> Lin
> 
> ?
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/3072#issuecomment-805549600>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABQPFO5R4INTAUFZ3QS6WL3TFGDXHANCNFSM4ZMLU6SA>.
> 
> ***@***.***
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> ***@***.******@***.***>

Dear @LanceAndersen,
Here I added a class `GZIPHeaderData` which is defined to hold all gzip header members, and make it an argument of the GZIPOutputStream constructor.  Would you like to help review and check whether this change looks reasonable?

BTW, this pr still lack of the negative test cases, I plan to add it when the constructor API is fixed.

Thanks!
Lin

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

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

From njian at openjdk.java.net  Fri Apr  2 10:04:17 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Fri, 2 Apr 2021 10:04:17 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
Message-ID: <SP6eBURfOt9R8efu6XZ16lXlPhvkvzBXO1vUV7Iyamw=.81b8b978-83b3-4d57-80af-f3a39042d611@github.com>

On Thu, 1 Apr 2021 03:39:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently "VectorMask.andNot()" is not vectorized:
>>     public VectorMask<E> andNot(VectorMask<E> m) {
>>         // FIXME: Generate good code here.
>>         return bOp(m, (i, a, b) -> a && !b);
>>     }
>> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
>> can be vectorized as well by calling them.
>> 
>> The performance gain is >100% for such a simple JMH:
>>   @Benchmark
>>   public Object andNot(Blackhole bh) {
>>     boolean[] mask = fm.apply(SPECIES.length());
>>     boolean[] r = fmt.apply(SPECIES.length());
>>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
>> 
>>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>>           rm = rm.andNot(vmask);
>>         }
>>     }
>>     return rm;
>>   }
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the changing to AbstractMask.andNot and revert changes in VectorMask
>   
>   Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
>   CustomizedGitHooks: yes

LGTM

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

Marked as reviewed by njian (Committer).

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

From xgong at openjdk.java.net  Fri Apr  2 10:04:17 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 2 Apr 2021 10:04:17 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <SP6eBURfOt9R8efu6XZ16lXlPhvkvzBXO1vUV7Iyamw=.81b8b978-83b3-4d57-80af-f3a39042d611@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
 <SP6eBURfOt9R8efu6XZ16lXlPhvkvzBXO1vUV7Iyamw=.81b8b978-83b3-4d57-80af-f3a39042d611@github.com>
Message-ID: <7bsAUC0QJ7brBAXu7bTwWuHV4mV4KKCnuPNH8ymY94k=.e545103d-b5f8-46af-92bf-4a236c75d6b6@github.com>

On Fri, 2 Apr 2021 09:59:31 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the changing to AbstractMask.andNot and revert changes in VectorMask
>>   
>>   Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
>>   CustomizedGitHooks: yes
>
> LGTM

Thanks for the review @nsjian !

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

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

From xgong at openjdk.java.net  Fri Apr  2 10:04:18 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 2 Apr 2021 10:04:18 GMT
Subject: Integrated: 8264109: Add vectorized implementation for
 VectorMask.andNot()
In-Reply-To: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
Message-ID: <L-ekfJb77kLc9SVKmwFAvp5krGfe7p21os3H3M8k_jw=.4c19752a-113f-44d7-81f9-e1c10c33df13@github.com>

On Fri, 26 Mar 2021 01:50:33 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently "VectorMask.andNot()" is not vectorized:
>     public VectorMask<E> andNot(VectorMask<E> m) {
>         // FIXME: Generate good code here.
>         return bOp(m, (i, a, b) -> a && !b);
>     }
> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
> can be vectorized as well by calling them.
> 
> The performance gain is >100% for such a simple JMH:
>   @Benchmark
>   public Object andNot(Blackhole bh) {
>     boolean[] mask = fm.apply(SPECIES.length());
>     boolean[] r = fmt.apply(SPECIES.length());
>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
> 
>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>           rm = rm.andNot(vmask);
>         }
>     }
>     return rm;
>   }

This pull request has now been integrated.

Changeset: 7d0a0bad
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7d0a0bad
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8264109: Add vectorized implementation for VectorMask.andNot()

Reviewed-by: psandoz, njian

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

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

From aph at openjdk.java.net  Fri Apr  2 10:20:25 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 10:20:25 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
Message-ID: <T7PlCTv8zluDpuWuogYW0PZknpj7HZjzeG8RrblWCes=.edf34990-3533-4f2f-b9aa-7ce571d96c59@github.com>

On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into aarch64.base64.decode
>  - copyright
>  - trivial fixes
>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>  - Merge branch 'master' into aarch64.base64.decode
>  - 8256245: AArch64: Implement Base64 decoding intrinsic

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5802:

> 5800:     // The 1st character of the input can be illegal if the data is MIME encoded.
> 5801:     // We cannot benefits from SIMD for this case. The max line size of MIME
> 5802:     // encoding is 76, with the PreProcess80B blob, we actually use no-simd

"cannot benefit"

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

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

From aph at openjdk.java.net  Fri Apr  2 10:20:20 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 10:20:20 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <zhrOSmz2aytq_cXzp88IC5wXiTw3fyjfPD6XPxx7dkY=.4f3a7845-f33e-49ef-8488-eaf81c2c1020@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
 <vxrUJagEcM97odeOocaFBJjZC_lNQwiuGmJwD0s-7wc=.d75d3029-2513-405c-afa3-f1ed8e7af5a1@github.com>
 <Nn9jqfMe-xnqho_oiJKjJwTMc7rRUy3cjrB0E0RpsqY=.34512df4-3587-4b8c-96e2-af4d82851c8f@github.com>
 <zhrOSmz2aytq_cXzp88IC5wXiTw3fyjfPD6XPxx7dkY=.4f3a7845-f33e-49ef-8488-eaf81c2c1020@github.com>
Message-ID: <Mk6kt6w3URs4k9Ouu4RNKWqByTFsDbW96SM7UlEii0Y=.e6c8d5dc-33f3-4933-942f-be5671ca777b@github.com>

On Fri, 2 Apr 2021 07:05:26 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> PING... Any suggestions on the updated commit?

Once you reply to the comments, sure.

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

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

From jbachorik at openjdk.java.net  Fri Apr  2 11:16:27 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 2 Apr 2021 11:16:27 GMT
Subject: RFR: 8203359: Container level resources events
In-Reply-To: <8JHw6MbcfjniWnYayJja7shthcZX-KWA2D_LrMQdhNM=.170772c2-cd50-49f9-acc4-18e2eb7137da@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <32-BO7tExbAStlYsma_g-oc8kw-kj3HSyhJOP-qAjLk=.6c4d8c45-1a64-4b5a-8767-7307c297b3d8@github.com>
 <guLUz-SeGYnE6_eRBBNQgyWIoC7XoemXN5iyGVHFlMU=.9e1ee611-1e1d-477d-bf7f-df29a93f7149@github.com>
 <kfY9mi-n8TsPGlK_QctCmtzxsgr0bs5VrGxepAtI4xc=.549f72df-9639-4d3c-a9d6-40d2aab1509f@github.com>
 <8JHw6MbcfjniWnYayJja7shthcZX-KWA2D_LrMQdhNM=.170772c2-cd50-49f9-acc4-18e2eb7137da@github.com>
Message-ID: <bL2OiNaHEbwKbhJVaDRMg1VBV514EWwEHDMMBzbgX-c=.2dd0f33c-f642-4e8a-a279-5f88d0364f50@github.com>

On Thu, 1 Apr 2021 15:55:59 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>>> Does each getter call result in parsing /proc, or do things aggregated over several calls or hooks?
>> 
>> From the looks of it the event emitting code uses `Metrics.java` interface for retrieving the info. Each call to a method exposed by Metrics result in file IO on some cgroup (v1 or v2) interface file(s) in `/sys/fs/...`. I don't see any aggregation being done.
>> 
>> On the hotspot side, we implemented some caching for frequent calls (JDK-8232207, JDK-8227006), but we didn't do that yet for the Java side since there wasn't any need (so far). If calls are becoming frequent with this it should be reconsidered.
>> 
>> So +1 on getting some data on what the perf penalty of this is.
>
> Thanks to all for chiming in!
> 
> I have added the tests to `test/hotspot/jtreg/containers/docker/TestJFREvents.java` where there already were some templates for the container event data.
> 
> As for the performance - as expected, extracting the data from `/proc` is not exactly cheap. On my test c5.4xlarge instance I am getting an average wall-clock time to generate the usage/throttling events (one instance of each) of ~15ms.
> I would argue that 15ms per 30s (the default emission period for those events) might be acceptable to start with. 
> 
> Caching of cgroups parsed data would help if the emission period is shorter than the cache TTL. This is exacerbated by the fact that (almost) each container event type requires data from a different cgroups control file - hence the data will not be shared between the event type instances even if cached. Realistically, caching benefits would become visible only for sub-second emission periods.
> 
> If the caching is still required I would suggest having a follow up ticket just for that - it will require setting up some benchmarks to justify the changes that would need to be done in the metrics implementation.

I tried to measure the startup regression and here are my observations:
* Startup is not affected unless the application is started with JFR
* The extra events and hooks take ~5ms on my work machine
* It is possible not to register those events and hooks in a non-container env - then the overhead is 20-50us which it takes to figure out whether running in container

In order to minimize the effect this change will have on the startup I would suggest using conditional registration unless I hear strong objections to that.

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

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

From jbachorik at openjdk.java.net  Fri Apr  2 11:50:06 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 2 Apr 2021 11:50:06 GMT
Subject: RFR: 8203359: Container level resources events [v5]
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <n1_phYyzxiNgjWeHkNxmuvc3dawaEJqUzDpRBKJrOBc=.1e98d2e1-5649-41ee-a6ad-5511764950e6@github.com>

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

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

  Report container type and register events conditionally

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3126/files
  - new: https://git.openjdk.java.net/jdk/pull/3126/files/79c91f57..2514b1a7

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

  Stats: 41 lines in 2 files changed: 24 ins; 8 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126

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

From jbachorik at openjdk.java.net  Fri Apr  2 12:01:09 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 2 Apr 2021 12:01:09 GMT
Subject: RFR: 8203359: Container level resources events [v6]
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <7rb5DZHhB7TmiMHH_NirecJ4ckqi1NnsrRde8H5ZK20=.f00528d5-731e-4f82-94a6-cc9eb30ab5b1@github.com>

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

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

  Doh

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3126/files
  - new: https://git.openjdk.java.net/jdk/pull/3126/files/2514b1a7..78dc85d3

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

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

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

From dl at openjdk.java.net  Fri Apr  2 12:21:47 2021
From: dl at openjdk.java.net (Doug Lea)
Date: Fri, 2 Apr 2021 12:21:47 GMT
Subject: RFR: JDK-8264572 reinsert common pool parallelism assignment
Message-ID: <EBf2cOu6XlzwPk6sK6BjtrArN8gCDphWEXMSaY6h4XI=.91b76c24-6c6b-457b-a498-e519fcfe43b6@github.com>

This reinserts setting common pool parallelism inadvertently clobbered in JDK-8259800

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

Commit messages:
 - Reinsert omitted assignment
 - Reinsert omitted assignment

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

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

From jbachorik at openjdk.java.net  Fri Apr  2 12:33:03 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 2 Apr 2021 12:33:03 GMT
Subject: RFR: 8203359: Container level resources events [v7]
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <VfQQscAw_gy6to6NS4kUlABJ_ErFH4_9denWYtB9zE0=.ff5ad719-110a-46c2-97d2-b2641b065949@github.com>

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

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

  Remove trailing spaces

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3126/files
  - new: https://git.openjdk.java.net/jdk/pull/3126/files/78dc85d3..f4372e23

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

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

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

From jvernee at openjdk.java.net  Fri Apr  2 13:17:55 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 2 Apr 2021 13:17:55 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]
In-Reply-To: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
Message-ID: <H_Jbm1rHBxRQ_pv4w-SUZJU3T-pPf0KN8gzbmWc3s5Y=.fcc73798-0d0a-4b58-93db-7e6ed47265f8@github.com>

> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
> 
> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
> 
> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
> 
> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
> 
> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
> 
> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
> 
> As a result of these changes a lot of code was unused and has been removed in this patch.
> 
> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
> 
> Here are some numbers from the added benchmark:
> 
> Before:
> Benchmark                                    Mode  Cnt    Score    Error  Units
> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
> (as you can see, just the Object[] with arity less than 10 case is fast here)
> After:
> Benchmark                                    Mode  Cnt  Score   Error  Units
> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
> 
> Thanks,
> Jorn

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

  - Address review comments
  - Use cached version of store func getter
  - Use ARRAY_STORE intrinsic for array stores
  - Generate direct call to Array.newInstance instead of using an array constructor handle
  - Intrinsify call to Array.newInstance if the component type is constant

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3306/files
  - new: https://git.openjdk.java.net/jdk/pull/3306/files/46bc5d19..313ffaaf

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

  Stats: 57 lines in 2 files changed: 27 ins; 19 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3306/head:pull/3306

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

From alanb at openjdk.java.net  Fri Apr  2 13:23:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 2 Apr 2021 13:23:07 GMT
Subject: RFR: JDK-8264572 reinsert common pool parallelism assignment
In-Reply-To: <EBf2cOu6XlzwPk6sK6BjtrArN8gCDphWEXMSaY6h4XI=.91b76c24-6c6b-457b-a498-e519fcfe43b6@github.com>
References: <EBf2cOu6XlzwPk6sK6BjtrArN8gCDphWEXMSaY6h4XI=.91b76c24-6c6b-457b-a498-e519fcfe43b6@github.com>
Message-ID: <YfGi5cHx_UsS2658JF7mMft3imfx1JFD9d8vn1meThU=.55db95c0-8ed4-44ed-a26a-93dbe3e3f7fc@github.com>

On Fri, 2 Apr 2021 10:52:45 GMT, Doug Lea <dl at openjdk.org> wrote:

> This reinserts setting common pool parallelism inadvertently clobbered in JDK-8259800

This looks okay to me, I just wonder if we should have a test to the value of getCommonPoolParallelism.

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

Marked as reviewed by alanb (Reviewer).

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

From jvernee at openjdk.java.net  Fri Apr  2 13:26:26 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 2 Apr 2021 13:26:26 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]
In-Reply-To: <_rGqipYkniAqcFVS6DRfaz71wHMWuxH2I1fk9UxNwHs=.4226fd59-b7c1-4c89-a69e-8be528ab72e3@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <_rGqipYkniAqcFVS6DRfaz71wHMWuxH2I1fk9UxNwHs=.4226fd59-b7c1-4c89-a69e-8be528ab72e3@github.com>
Message-ID: <3mIWCpGajYbFjNpY0FllaJe19jHwv4zPtQBeZdsyGKo=.f0a491a8-e3a1-468c-86e7-8e49863e0fa3@github.com>

On Thu, 1 Apr 2021 19:19:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Address review comments
>>   - Use cached version of store func getter
>>   - Use ARRAY_STORE intrinsic for array stores
>>   - Generate direct call to Array.newInstance instead of using an array constructor handle
>>   - Intrinsify call to Array.newInstance if the component type is constant
>
> That's an elegant solution.
> 
> At first i thought it might unduly perturb lambda form generation and caching. but you slotted a different lambda form implementation underneath the varargs implementation.

I've address review comments, plus some other things:

- I realized that I was calling the uncached version of the store function factory. Fixed that.
- I also realized that there's already an `ARRAY_STORE` intrinsic, which I'm now using to avoid generating a call.
- I also realized that since we only have 1 array creation handle per lambda form, we can instead generate a direct call to `Array::newInstance` instead of going through the array constructor handle (which also avoids having to use a BoundMethodHandle).
- Finally, I added an instrinsic, under the old `NEW_ARRAY` name, that intrinsifies a call to `Array::newInstance` if the component type argument is constant (which it is in this case).

As a result, the lambda form is now fully intrinsified (no more calls in the generated bytecode) e.g.:

static java.lang.Object collector001_LLLL_L(java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object);
    Code:
       0: iconst_3
       1: anewarray     #12                 // class java/lang/String
       4: astore        4
       6: aload         4
       8: checkcast     #14                 // class "[Ljava/lang/String;"
      11: dup
      12: astore        4
      14: iconst_0
      15: aload_1
      16: checkcast     #12                 // class java/lang/String
      19: aastore
      20: aload         4
      22: iconst_1
      23: aload_2
      24: checkcast     #12                 // class java/lang/String
      27: aastore
      28: aload         4
      30: iconst_2
      31: aload_3
      32: checkcast     #12                 // class java/lang/String
      35: aastore
      36: aload         4
      38: areturn

Thanks,
Jorn

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

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

From dl at openjdk.java.net  Fri Apr  2 14:03:28 2021
From: dl at openjdk.java.net (Doug Lea)
Date: Fri, 2 Apr 2021 14:03:28 GMT
Subject: RFR: JDK-8264572 reinsert common pool parallelism assignment
In-Reply-To: <YfGi5cHx_UsS2658JF7mMft3imfx1JFD9d8vn1meThU=.55db95c0-8ed4-44ed-a26a-93dbe3e3f7fc@github.com>
References: <EBf2cOu6XlzwPk6sK6BjtrArN8gCDphWEXMSaY6h4XI=.91b76c24-6c6b-457b-a498-e519fcfe43b6@github.com>
 <YfGi5cHx_UsS2658JF7mMft3imfx1JFD9d8vn1meThU=.55db95c0-8ed4-44ed-a26a-93dbe3e3f7fc@github.com>
Message-ID: <lZsg8UH_dJ1bmyJOJ4QI5TwyIHePWeCXIRro4BzboHs=.56acdda4-c646-41aa-ada9-1769b1e1158e@github.com>

On Fri, 2 Apr 2021 13:20:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This reinserts setting common pool parallelism inadvertently clobbered in JDK-8259800
>
> This looks okay to me, I just wonder if we should have a test to the value of getCommonPoolParallelism.

We once had a test, but now that Runtime.availableProcessors (the only means of checking) can return varying values, we can't include in tck  tests. The error here wasn't caught  because we didn't run the usual performance tests (that catch these problems immediately) because I was focused only on JDK-8259800. Sorry.

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

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

From vlivanov at openjdk.java.net  Fri Apr  2 14:07:30 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 2 Apr 2021 14:07:30 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]
In-Reply-To: <H_Jbm1rHBxRQ_pv4w-SUZJU3T-pPf0KN8gzbmWc3s5Y=.fcc73798-0d0a-4b58-93db-7e6ed47265f8@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <H_Jbm1rHBxRQ_pv4w-SUZJU3T-pPf0KN8gzbmWc3s5Y=.fcc73798-0d0a-4b58-93db-7e6ed47265f8@github.com>
Message-ID: <if64GQJjc-2qlh68BZwEq58oijuAProMFrn7KC_0SBQ=.ef224d7c-a90a-4d7c-a457-10b3f99748bf@github.com>

On Fri, 2 Apr 2021 13:17:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
>> 
>> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
>> 
>> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
>> 
>> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
>> 
>> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
>> 
>> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
>> 
>> As a result of these changes a lot of code was unused and has been removed in this patch.
>> 
>> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
>> 
>> Here are some numbers from the added benchmark:
>> 
>> Before:
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
>> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
>> (as you can see, just the Object[] with arity less than 10 case is fast here)
>> After:
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
>> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Address review comments
>   - Use cached version of store func getter
>   - Use ARRAY_STORE intrinsic for array stores
>   - Generate direct call to Array.newInstance instead of using an array constructor handle
>   - Intrinsify call to Array.newInstance if the component type is constant

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 874:

> 872:                 case NEW_ARRAY:
> 873:                     Class<?> rtype = name.function.methodType().returnType();
> 874:                     if (isStaticallyNameable(rtype)) {

Why do you remote `isStaticallyNameable(rtype)` check? 

It is there for a reason: only a very limited set of classes can be directly referenced from LF bytecode.

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1897:

> 1895:         // field of the receiver handle.
> 1896:         // This is left as a followup enhancement, as it needs to be investigated if this causes
> 1897:         // profile pollution.

Profile pollution shouldn't be a problem here: both types (element type + array type) will be constants attached to the "receiver" BMH instance and during inlining will be fetched from there.  

I'm fine with handling it as a separate RFE.

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

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

From jvernee at openjdk.java.net  Fri Apr  2 14:45:22 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 2 Apr 2021 14:45:22 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]
In-Reply-To: <if64GQJjc-2qlh68BZwEq58oijuAProMFrn7KC_0SBQ=.ef224d7c-a90a-4d7c-a457-10b3f99748bf@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <H_Jbm1rHBxRQ_pv4w-SUZJU3T-pPf0KN8gzbmWc3s5Y=.fcc73798-0d0a-4b58-93db-7e6ed47265f8@github.com>
 <if64GQJjc-2qlh68BZwEq58oijuAProMFrn7KC_0SBQ=.ef224d7c-a90a-4d7c-a457-10b3f99748bf@github.com>
Message-ID: <SWoYrFkh2BLEqD36F6eGhevxBeJFRt0KCx_LK-Ha9jU=.0c74bca0-93d3-4d40-b603-13717c3bfaae@github.com>

On Fri, 2 Apr 2021 13:56:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Address review comments
>>   - Use cached version of store func getter
>>   - Use ARRAY_STORE intrinsic for array stores
>>   - Generate direct call to Array.newInstance instead of using an array constructor handle
>>   - Intrinsify call to Array.newInstance if the component type is constant
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 874:
> 
>> 872:                 case NEW_ARRAY:
>> 873:                     Class<?> rtype = name.function.methodType().returnType();
>> 874:                     if (isStaticallyNameable(rtype)) {
> 
> Why do you remote `isStaticallyNameable(rtype)` check? 
> 
> It is there for a reason: only a very limited set of classes can be directly referenced from LF bytecode.

I removed the `NEW_ARRAY` intrinsic altogether at first, but added it back in the latest commit. I didn't add the check since I was not aware of the restriction.

Good to know, will add a check.

> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1897:
> 
>> 1895:         // field of the receiver handle.
>> 1896:         // This is left as a followup enhancement, as it needs to be investigated if this causes
>> 1897:         // profile pollution.
> 
> Profile pollution shouldn't be a problem here: both types (element type + array type) will be constants attached to the "receiver" BMH instance and during inlining will be fetched from there.  
> 
> I'm fine with handling it as a separate RFE.

That's what I thought as well (but not 100% sure). I can partially roll back the last commit so the code still uses an injected array constructor handle, and then it should be easy to add caching in the cases where the component type is a reference type.

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

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

From vlivanov at openjdk.java.net  Fri Apr  2 15:15:32 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 2 Apr 2021 15:15:32 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]
In-Reply-To: <SWoYrFkh2BLEqD36F6eGhevxBeJFRt0KCx_LK-Ha9jU=.0c74bca0-93d3-4d40-b603-13717c3bfaae@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <H_Jbm1rHBxRQ_pv4w-SUZJU3T-pPf0KN8gzbmWc3s5Y=.fcc73798-0d0a-4b58-93db-7e6ed47265f8@github.com>
 <if64GQJjc-2qlh68BZwEq58oijuAProMFrn7KC_0SBQ=.ef224d7c-a90a-4d7c-a457-10b3f99748bf@github.com>
 <SWoYrFkh2BLEqD36F6eGhevxBeJFRt0KCx_LK-Ha9jU=.0c74bca0-93d3-4d40-b603-13717c3bfaae@github.com>
Message-ID: <0eYHPEW_QRXhPVLj4o-GOP2cwbcQDetCq4Te7V3dcpc=.2044da6e-e51c-4840-b960-f2ad107d7b5b@github.com>

On Fri, 2 Apr 2021 14:41:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 874:
>> 
>>> 872:                 case NEW_ARRAY:
>>> 873:                     Class<?> rtype = name.function.methodType().returnType();
>>> 874:                     if (isStaticallyNameable(rtype)) {
>> 
>> Why do you remote `isStaticallyNameable(rtype)` check? 
>> 
>> It is there for a reason: only a very limited set of classes can be directly referenced from LF bytecode.
>
> I removed the `NEW_ARRAY` intrinsic altogether at first, but added it back in the latest commit. I didn't add the check since I was not aware of the restriction (looks like some of the tests failed as well).
> 
> Good to know, will add a check.

Also, please, add a test case for such scenario. It should be trivial: just use a class defined by the test (loaded by `AppClassLoader`).

>> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1897:
>> 
>>> 1895:         // field of the receiver handle.
>>> 1896:         // This is left as a followup enhancement, as it needs to be investigated if this causes
>>> 1897:         // profile pollution.
>> 
>> Profile pollution shouldn't be a problem here: both types (element type + array type) will be constants attached to the "receiver" BMH instance and during inlining will be fetched from there.  
>> 
>> I'm fine with handling it as a separate RFE.
>
> That's what I thought as well (but not 100% sure). I can partially roll back the last commit so the code still uses an injected array constructor handle, and then it should be easy to add caching in the cases where the component type is a reference type.

Whatever you prefer. I'm fine with it either way.

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

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

From igraves at openjdk.java.net  Fri Apr  2 15:48:50 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 2 Apr 2021 15:48:50 GMT
Subject: RFR: 8037397: Lost nested character class after intersection &&
 [v3]
In-Reply-To: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
Message-ID: <1YvVmkT1sxIh2B3jgGPtphdYjNRHrvCfmGl6l5RZWKg=.6081df5b-b416-4201-b799-c0e126c474aa@github.com>

> Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones.

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

  Adding a test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3291/files
  - new: https://git.openjdk.java.net/jdk/pull/3291/files/2a783a1e..9a46443d

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

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

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

From igraves at openjdk.java.net  Fri Apr  2 15:48:53 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 2 Apr 2021 15:48:53 GMT
Subject: RFR: 8037397: Lost nested character class after intersection &&
 [v3]
In-Reply-To: <AUVhBclJRTbqzA0jiR0f9swp73YrA5d_jYQxp0riKEs=.925329ed-56ab-4135-9e39-60c97ccea063@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
 <AUVhBclJRTbqzA0jiR0f9swp73YrA5d_jYQxp0riKEs=.925329ed-56ab-4135-9e39-60c97ccea063@github.com>
Message-ID: <vs7Ko0ruXgiYCEnllsz4f-4gWrTL-8Oj5SJv9gZjSFQ=.39fdb046-bd98-4527-9256-530fe303ebdb@github.com>

On Thu, 1 Apr 2021 14:21:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a test.
>
> Please add a test.

Tagging with CSR because this will impact a long-standing (buggy) behavior.

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

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

From igraves at openjdk.java.net  Fri Apr  2 15:48:56 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 2 Apr 2021 15:48:56 GMT
Subject: RFR: 8037397: Lost nested character class after intersection &&
 [v3]
In-Reply-To: <myczce5JY6cDFrkza5K1sIKNDCc8F5-vrSqpGQOpG0Q=.7c660d9b-b0ac-4fdc-9305-6520f181a58c@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
 <myczce5JY6cDFrkza5K1sIKNDCc8F5-vrSqpGQOpG0Q=.7c660d9b-b0ac-4fdc-9305-6520f181a58c@github.com>
Message-ID: <s05y1-Tr5m20-9dvQYBdmDoU8OMv3CE4HKk5PJYwgMs=.fab4abe6-c01c-447e-819b-fd207f5a3cbf@github.com>

On Thu, 1 Apr 2021 00:33:26 GMT, Florent Guillaume <github.com+592810+efge at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a test.
>
> src/java.base/share/classes/java/util/regex/Pattern.java line 2666:
> 
>> 2664:                             } else { // abc&&def
>> 2665:                                 unread();
>> 2666:                                 if(right == null) {
> 
> Missing space after `if`. There will be a unit test as well?
> 
> (Please tell me if these comments aren't suitable or relevant, as I'm not involved in the project.)

Yep, they are suitable thanks!

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

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

From naoto at openjdk.java.net  Fri Apr  2 16:36:21 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 2 Apr 2021 16:36:21 GMT
Subject: Integrated: 8264544: Case-insensitive comparison issue with
 supplementary characters.
In-Reply-To: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
References: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
Message-ID: <YvO3fUqJ_4PhXxktKL5067WPGEoGkIps-xJG-PHgwEQ=.e20acbb5-596a-487d-bdf4-87aa9243c5a1@github.com>

On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

This pull request has now been integrated.

Changeset: 6c145c47
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6c145c47
Stats:     11 lines in 3 files changed: 3 ins; 0 del; 8 mod

8264544: Case-insensitive comparison issue with supplementary characters.

Co-authored-by: Chris Johnson <chriswjohnson.jdk at gmail.com>
Reviewed-by: joehw, iris, alanb

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

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

From sspitsyn at openjdk.java.net  Fri Apr  2 17:17:24 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 2 Apr 2021 17:17:24 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <CU8ip-eXtf0s8gc20flTzNVYfthdqwqcHzBbxQp_7Bc=.cb558101-29c9-4e5f-8334-6b5e8c79ecd3@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

Joe,
The Serviceability part looks good.
Thanks,
Serguei

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

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

From igraves at openjdk.java.net  Fri Apr  2 19:15:39 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 2 Apr 2021 19:15:39 GMT
Subject: RFR: 8037397: Lost nested character class after intersection &&
 [v4]
In-Reply-To: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
Message-ID: <pnHWhDOJDGyiifOryf7TpNv-677pJv3_XiKUqr75dRc=.c421eff9-ee20-447b-a65e-beb5a5f98cdb@github.com>

> Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones.

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

  Bumping copyright date.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3291/files
  - new: https://git.openjdk.java.net/jdk/pull/3291/files/9a46443d..de0fa217

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

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

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

From rriggs at openjdk.java.net  Fri Apr  2 19:15:39 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Apr 2021 19:15:39 GMT
Subject: RFR: 8037397: Lost nested character class after intersection &&
 [v3]
In-Reply-To: <1YvVmkT1sxIh2B3jgGPtphdYjNRHrvCfmGl6l5RZWKg=.6081df5b-b416-4201-b799-c0e126c474aa@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
 <1YvVmkT1sxIh2B3jgGPtphdYjNRHrvCfmGl6l5RZWKg=.6081df5b-b416-4201-b799-c0e126c474aa@github.com>
Message-ID: <gcd-B3wL-dI8SKPmV7WEjqdbINGRGSbFXBfO2NS3NRY=.f870bed5-af4b-4942-9461-4ec42b70b310@github.com>

On Fri, 2 Apr 2021 15:48:50 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a test.

Update copyright before push.

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

Marked as reviewed by rriggs (Reviewer).

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

From bpb at openjdk.java.net  Fri Apr  2 21:53:40 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 2 Apr 2021 21:53:40 GMT
Subject: RFR: 8264512: jdk/test/jdk/java/util/prefs/ExportNode.java relies on
 default platform encoding
Message-ID: <0OQKXp0bWcbNFp8Ut3v_GzzZCVOGC_cuJtGvUNrgzYw=.f9c21e46-d7b6-4e43-8ee3-cc8e42946d88@github.com>

This test emits to a `java.io.ByteArrayOutputStream` the contents of a `java.utils.prefs.Preferences` node. The `UTF-8` character encoding is used [1]. The `ByteArrayOutputStream` is then converted to a `String` using `toString()` which uses the platform's default character set [2]. The resulting `String` is then checked for the node names that it should and should not contain.

This change proposes to use `ByteArrayOutputStream.toString(String)` to obtain the string [3] to maintain consistency of the encoding. It also adds throwing a `RuntimeException` if the node string is not as expected. It is unclear why this test was not already throwing such an exception.

[1] https://docs.oracle.com/en/java/javase/16/docs/api/java.prefs/java/util/prefs/Preferences.html#exportNode(java.io.OutputStream)
[2] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/io/ByteArrayOutputStream.html#toString()
[3] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/io/ByteArrayOutputStream.html#toString(java.lang.String)

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

Commit messages:
 - 8264512: jdk/test/jdk/java/util/prefs/ExportNode.java relies on default platform encoding

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

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

From naoto at openjdk.java.net  Fri Apr  2 22:14:31 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 2 Apr 2021 22:14:31 GMT
Subject: RFR: 8264512: jdk/test/jdk/java/util/prefs/ExportNode.java relies
 on default platform encoding
In-Reply-To: <0OQKXp0bWcbNFp8Ut3v_GzzZCVOGC_cuJtGvUNrgzYw=.f9c21e46-d7b6-4e43-8ee3-cc8e42946d88@github.com>
References: <0OQKXp0bWcbNFp8Ut3v_GzzZCVOGC_cuJtGvUNrgzYw=.f9c21e46-d7b6-4e43-8ee3-cc8e42946d88@github.com>
Message-ID: <limY4OFii5NOdRZaXiwlMmhK_NYc_uiDs4NsqjPZHCc=.64fb5cb5-8059-4aa3-9816-b342690d81d1@github.com>

On Fri, 2 Apr 2021 21:45:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This test emits to a `java.io.ByteArrayOutputStream` the contents of a `java.utils.prefs.Preferences` node. The `UTF-8` character encoding is used [1]. The `ByteArrayOutputStream` is then converted to a `String` using `toString()` which uses the platform's default character set [2]. The resulting `String` is then checked for the node names that it should and should not contain.
> 
> This change proposes to use `ByteArrayOutputStream.toString(String)` to obtain the string [3] to maintain consistency of the encoding. It also adds throwing a `RuntimeException` if the node string is not as expected. It is unclear why this test was not already throwing such an exception.
> 
> [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.prefs/java/util/prefs/Preferences.html#exportNode(java.io.OutputStream)
> [2] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/io/ByteArrayOutputStream.html#toString()
> [3] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/io/ByteArrayOutputStream.html#toString(java.lang.String)

Looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From dl at openjdk.java.net  Fri Apr  2 22:47:22 2021
From: dl at openjdk.java.net (Doug Lea)
Date: Fri, 2 Apr 2021 22:47:22 GMT
Subject: Integrated: JDK-8264572: ForkJoinPool.getCommonPoolParallelism()
 reports always 1
In-Reply-To: <EBf2cOu6XlzwPk6sK6BjtrArN8gCDphWEXMSaY6h4XI=.91b76c24-6c6b-457b-a498-e519fcfe43b6@github.com>
References: <EBf2cOu6XlzwPk6sK6BjtrArN8gCDphWEXMSaY6h4XI=.91b76c24-6c6b-457b-a498-e519fcfe43b6@github.com>
Message-ID: <iFdIK-XDLy9ho08HxAHRGexamF4YrExzrvm2HH0xuM4=.cdaa54ec-8d4f-41b2-bc73-ad057fbb09ec@github.com>

On Fri, 2 Apr 2021 10:52:45 GMT, Doug Lea <dl at openjdk.org> wrote:

> This reinserts setting common pool parallelism inadvertently clobbered in JDK-8259800

This pull request has now been integrated.

Changeset: cec66cf8
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cec66cf8
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8264572: ForkJoinPool.getCommonPoolParallelism() reports always 1

Reviewed-by: alanb

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

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

From ralph.goers at dslextreme.com  Fri Apr  2 23:47:39 2021
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Fri, 2 Apr 2021 16:47:39 -0700
Subject: Garbage Free Check
Message-ID: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>

Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.

The code we have simply does

public void init(MutableInstant mutableInstant) {
    Instant instant = java.time.Clock.systemUTC().instant();
    mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
}
In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
Ideally we would really like something like

public void init(MutableInstant mutableInstant) {
   	java.time.Clock.systemUTC().initInstant(mutableInstant);
}

where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.

This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.

Do you know of another way to do this? Am I missing something?

Ralph

From carfield at carfield.com.hk  Sat Apr  3 11:58:02 2021
From: carfield at carfield.com.hk (Carfield Yim)
Date: Sat, 3 Apr 2021 22:58:02 +1100
Subject: Faster double parser?
Message-ID: <CACfbOvfg3futQZaJQXMbp7+5EVuSEQKUkj23f-Wsh_Nk-Yv=vw@mail.gmail.com>

HI all, just aware of this project,
https://github.com/wrandelshofer/FastDoubleParser, not sure if it good idea
to use this as default Double Parser in JVM?

From david.holmes at oracle.com  Sat Apr  3 12:49:33 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 3 Apr 2021 22:49:33 +1000
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <8va8xgeb9JwkDs9e0WnHH4n2NZpe1nzaBvq35qclyX8=.c492c22e-9887-4766-a4f1-dea32f9853da@github.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
 <_ctT57Zek8k0XjTFlfwCmqqTlADvQV_yff7dQDrbsjQ=.035b0412-cdd3-4bd4-89e0-218e86f2e78a@github.com>
 <u5zETzxDG4Caki1s4Z0OeybX7OdGqOOW7Tta-4dyu0I=.56185994-fb85-4372-8f73-b3327ef27e4f@github.com>
 <8va8xgeb9JwkDs9e0WnHH4n2NZpe1nzaBvq35qclyX8=.c492c22e-9887-4766-a4f1-dea32f9853da@github.com>
Message-ID: <a126b720-7a4c-2d9f-6988-4b7636546939@oracle.com>

On 2/04/2021 5:34 pm, Alan Bateman wrote:
> On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
> 
>>> src/java.base/share/native/libjimage/imageFile.cpp line 219:
>>>
>>>> 217: // WARNING: Should never close the jimage file.
>>>> 218: //          Threads may still be running at shutdown.
>>>> 219: #if 0
>>>
>>> Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted.
>>
>> Leaving the code as an example of what is required to close in case the topic gets revisited in the future and I get hit by a bus or dementia.
> 
> Okay although I assume someone will spot this and be tempted to remove it.

I didn't comment on this as I assumed it would contravene core-libs 
coding guidelines. I'm suprised to see dead code kept this way (there 
are existing cases elsewhere but it isn't considered good form). 
Previous code can always be retrieved from the repo history.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3304
> 

From james.laskey at oracle.com  Sat Apr  3 14:02:15 2021
From: james.laskey at oracle.com (Jim Laskey)
Date: Sat, 3 Apr 2021 14:02:15 +0000
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <a126b720-7a4c-2d9f-6988-4b7636546939@oracle.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
 <_ctT57Zek8k0XjTFlfwCmqqTlADvQV_yff7dQDrbsjQ=.035b0412-cdd3-4bd4-89e0-218e86f2e78a@github.com>
 <u5zETzxDG4Caki1s4Z0OeybX7OdGqOOW7Tta-4dyu0I=.56185994-fb85-4372-8f73-b3327ef27e4f@github.com>
 <8va8xgeb9JwkDs9e0WnHH4n2NZpe1nzaBvq35qclyX8=.c492c22e-9887-4766-a4f1-dea32f9853da@github.com>,
 <a126b720-7a4c-2d9f-6988-4b7636546939@oracle.com>
Message-ID: <2150B25B-F847-4198-8791-8009D58D6078@oracle.com>

Is it in bad form to declare a #define CLOSE_JIMAGE 0 ?

??

> On Apr 3, 2021, at 9:49 AM, David Holmes <David.Holmes at oracle.com> wrote:
> 
> ?On 2/04/2021 5:34 pm, Alan Bateman wrote:
>> On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
>>>> src/java.base/share/native/libjimage/imageFile.cpp line 219:
>>>> 
>>>>> 217: // WARNING: Should never close the jimage file.
>>>>> 218: //          Threads may still be running at shutdown.
>>>>> 219: #if 0
>>>> 
>>>> Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted.
>>> 
>>> Leaving the code as an example of what is required to close in case the topic gets revisited in the future and I get hit by a bus or dementia.
>> Okay although I assume someone will spot this and be tempted to remove it.
> 
> I didn't comment on this as I assumed it would contravene core-libs coding guidelines. I'm suprised to see dead code kept this way (there are existing cases elsewhere but it isn't considered good form). Previous code can always be retrieved from the repo history.
> 
> Cheers,
> David
> 
>> -------------
>> PR: https://git.openjdk.java.net/jdk/pull/3304

From chris.w.dennis at gmail.com  Sat Apr  3 15:12:57 2021
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Sat, 3 Apr 2021 15:12:57 +0000
Subject: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <BLAPR20MB4177F862D3DEBFE859D533B7AE659@BLAPR20MB4177.namprd20.prod.outlook.com>
References: <BLAPR20MB4177F862D3DEBFE859D533B7AE659@BLAPR20MB4177.namprd20.prod.outlook.com>
Message-ID: <BLAPR20MB41773DC6EF41338328CA0104AE799@BLAPR20MB4177.namprd20.prod.outlook.com>

A gentle prod. Am I misunderstanding procedure here?

From: Chris Dennis <chris.w.dennis at gmail.com>
Date: Monday, March 22, 2021 at 2:28 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: 8214761: Bug in parallel Kahan summation implementation
I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but have been stuck waiting on OCA signatory status to be confirmed. Did something get lost in the shuffle or do I just need to be more patient.

Thanks,

Chris

From pavel.rappo at oracle.com  Sat Apr  3 18:35:07 2021
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Sat, 3 Apr 2021 18:35:07 +0000
Subject: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <BLAPR20MB41773DC6EF41338328CA0104AE799@BLAPR20MB4177.namprd20.prod.outlook.com>
References: <BLAPR20MB4177F862D3DEBFE859D533B7AE659@BLAPR20MB4177.namprd20.prod.outlook.com>
 <BLAPR20MB41773DC6EF41338328CA0104AE799@BLAPR20MB4177.namprd20.prod.outlook.com>
Message-ID: <692862AD-6F1C-4171-9764-6F92E2590570@oracle.com>

Hey Chris,

I don't know exactly what triggers removal of the "oca" and "oca-verify" labels. The only OCA entry for Chris Dennis I could find [1] had a different GitHub username. Did you mistype it or it belongs to another person? Mind you, that person's GitHub page is 404.

-Pavel

[1] https://oca.opensource.oracle.com/?ojr=contrib-list

> On 3 Apr 2021, at 16:12, Chris Dennis <chris.w.dennis at gmail.com> wrote:
> 
> A gentle prod. Am I misunderstanding procedure here?
> 
> From: Chris Dennis <chris.w.dennis at gmail.com>
> Date: Monday, March 22, 2021 at 2:28 PM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: 8214761: Bug in parallel Kahan summation implementation
> I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but have been stuck waiting on OCA signatory status to be confirmed. Did something get lost in the shuffle or do I just need to be more patient.
> 
> Thanks,
> 
> Chris


From chris.w.dennis at gmail.com  Sat Apr  3 20:11:01 2021
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Sat, 3 Apr 2021 20:11:01 +0000
Subject: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <692862AD-6F1C-4171-9764-6F92E2590570@oracle.com>
References: <BLAPR20MB4177F862D3DEBFE859D533B7AE659@BLAPR20MB4177.namprd20.prod.outlook.com>
 <BLAPR20MB41773DC6EF41338328CA0104AE799@BLAPR20MB4177.namprd20.prod.outlook.com>,
 <692862AD-6F1C-4171-9764-6F92E2590570@oracle.com>
Message-ID: <BLAPR20MB4177CA8B1284A208DBA517C3AE799@BLAPR20MB4177.namprd20.prod.outlook.com>

I?m pretty certain that is meant to be me but ?chris_dennis? is a now defunct java.net username and not a Github one. The username appears in this list https://oca.opensource.oracle.com/?ojr=old-contrib-list#t too as: ?Terracotta Inc. (Christopher Dennis), OpenJDK, chris_dennis?. My Github username is tied to the previous commits I?ve authored though: https://github.com/openjdk/jdk/commits?author=chrisdennis. I also believe there should be a signed OCA for my current employer ?Software AG? too since I?ve contributed under it to both OpenJDK and JSR-107.

Chris


From: Pavel Rappo <pavel.rappo at oracle.com>
Date: Saturday, April 3, 2021 at 2:35 PM
To: Chris Dennis <chris.w.dennis at gmail.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: 8214761: Bug in parallel Kahan summation implementation
Hey Chris,

I don't know exactly what triggers removal of the "oca" and "oca-verify" labels. The only OCA entry for Chris Dennis I could find [1] had a different GitHub username. Did you mistype it or it belongs to another person? Mind you, that person's GitHub page is 404.

-Pavel

[1] https://oca.opensource.oracle.com/?ojr=contrib-list

> On 3 Apr 2021, at 16:12, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>
> A gentle prod. Am I misunderstanding procedure here?
>
> From: Chris Dennis <chris.w.dennis at gmail.com>
> Date: Monday, March 22, 2021 at 2:28 PM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: 8214761: Bug in parallel Kahan summation implementation
> I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but have been stuck waiting on OCA signatory status to be confirmed. Did something get lost in the shuffle or do I just need to be more patient.
>
> Thanks,
>
> Chris

From powers.anirvan at gmail.com  Sat Apr  3 20:11:48 2021
From: powers.anirvan at gmail.com (Anirvan Sarkar)
Date: Sun, 4 Apr 2021 05:11:48 +0900
Subject: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <692862AD-6F1C-4171-9764-6F92E2590570@oracle.com>
References: <BLAPR20MB4177F862D3DEBFE859D533B7AE659@BLAPR20MB4177.namprd20.prod.outlook.com>
 <BLAPR20MB41773DC6EF41338328CA0104AE799@BLAPR20MB4177.namprd20.prod.outlook.com>
 <692862AD-6F1C-4171-9764-6F92E2590570@oracle.com>
Message-ID: <CAEQxcvF8Y5rsnaXYaKbs3+1hBEtFFvEhT-kNz3DKTO-mbVr0Xw@mail.gmail.com>

Hi Pavel,

I think I have the same issue as Chris.

The new OCA contributors list [1] is incorrectly linking the user names to
GitHub as compared to the old contributors list [2].
It seems the new OCA contributors list is assuming that the GitHub username
of past contributors is the same as the username of the project, when they
had signed the OCA in the past.

When I had signed OCA a few years back for the OpenJFX project, I had
provided my username as *anirvan.sarkar*.
This was my username on java.net / javafx-jira.kenai.com (the old JIRA for
JavaFX project).
But my GitHub username is *AnirvanSarkar*, not *anirvan.sarkar* which user
does not exist on GitHub.

[1] : https://oca.opensource.oracle.com/?ojr=contrib-list
[2] : https://oca.opensource.oracle.com/?ojr=old-contrib-list


On Sun, 4 Apr 2021 at 03:35, Pavel Rappo <pavel.rappo at oracle.com> wrote:

> Hey Chris,
>
> I don't know exactly what triggers removal of the "oca" and "oca-verify"
> labels. The only OCA entry for Chris Dennis I could find [1] had a
> different GitHub username. Did you mistype it or it belongs to another
> person? Mind you, that person's GitHub page is 404.
>
> -Pavel
>
> [1] https://oca.opensource.oracle.com/?ojr=contrib-list
>
> > On 3 Apr 2021, at 16:12, Chris Dennis <chris.w.dennis at gmail.com> wrote:
> >
> > A gentle prod. Am I misunderstanding procedure here?
> >
> > From: Chris Dennis <chris.w.dennis at gmail.com>
> > Date: Monday, March 22, 2021 at 2:28 PM
> > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > Subject: 8214761: Bug in parallel Kahan summation implementation
> > I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 -
> but have been stuck waiting on OCA signatory status to be confirmed. Did
> something get lost in the shuffle or do I just need to be more patient.
> >
> > Thanks,
> >
> > Chris
>
>

-- 
Anirvan

From david.holmes at oracle.com  Sat Apr  3 23:07:56 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 4 Apr 2021 09:07:56 +1000
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <2150B25B-F847-4198-8791-8009D58D6078@oracle.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
 <_ctT57Zek8k0XjTFlfwCmqqTlADvQV_yff7dQDrbsjQ=.035b0412-cdd3-4bd4-89e0-218e86f2e78a@github.com>
 <u5zETzxDG4Caki1s4Z0OeybX7OdGqOOW7Tta-4dyu0I=.56185994-fb85-4372-8f73-b3327ef27e4f@github.com>
 <8va8xgeb9JwkDs9e0WnHH4n2NZpe1nzaBvq35qclyX8=.c492c22e-9887-4766-a4f1-dea32f9853da@github.com>
 <a126b720-7a4c-2d9f-6988-4b7636546939@oracle.com>
 <2150B25B-F847-4198-8791-8009D58D6078@oracle.com>
Message-ID: <d925b207-0182-434b-5441-710a00b35ed0@oracle.com>

On 4/04/2021 12:02 am, Jim Laskey wrote:
> Is it in bad form to declare a #define CLOSE_JIMAGE 0 ?

Still dead code.

This is a core-libs style call anyway.

Cheers,
David

> ??
> 
>> On Apr 3, 2021, at 9:49 AM, David Holmes <David.Holmes at oracle.com> wrote:
>>
>> ?On 2/04/2021 5:34 pm, Alan Bateman wrote:
>>> On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
>>>>> src/java.base/share/native/libjimage/imageFile.cpp line 219:
>>>>>
>>>>>> 217: // WARNING: Should never close the jimage file.
>>>>>> 218: //          Threads may still be running at shutdown.
>>>>>> 219: #if 0
>>>>>
>>>>> Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted.
>>>>
>>>> Leaving the code as an example of what is required to close in case the topic gets revisited in the future and I get hit by a bus or dementia.
>>> Okay although I assume someone will spot this and be tempted to remove it.
>>
>> I didn't comment on this as I assumed it would contravene core-libs coding guidelines. I'm suprised to see dead code kept this way (there are existing cases elsewhere but it isn't considered good form). Previous code can always be retrieved from the repo history.
>>
>> Cheers,
>> David
>>
>>> -------------
>>> PR: https://git.openjdk.java.net/jdk/pull/3304

From james.laskey at oracle.com  Sun Apr  4 01:20:15 2021
From: james.laskey at oracle.com (Jim Laskey)
Date: Sun, 4 Apr 2021 01:20:15 +0000
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <d925b207-0182-434b-5441-710a00b35ed0@oracle.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
 <_ctT57Zek8k0XjTFlfwCmqqTlADvQV_yff7dQDrbsjQ=.035b0412-cdd3-4bd4-89e0-218e86f2e78a@github.com>
 <u5zETzxDG4Caki1s4Z0OeybX7OdGqOOW7Tta-4dyu0I=.56185994-fb85-4372-8f73-b3327ef27e4f@github.com>
 <8va8xgeb9JwkDs9e0WnHH4n2NZpe1nzaBvq35qclyX8=.c492c22e-9887-4766-a4f1-dea32f9853da@github.com>
 <a126b720-7a4c-2d9f-6988-4b7636546939@oracle.com>
 <2150B25B-F847-4198-8791-8009D58D6078@oracle.com>,
 <d925b207-0182-434b-5441-710a00b35ed0@oracle.com>
Message-ID: <8026E42F-5698-4340-B01E-81FF8DDE6BE3@oracle.com>

I?ll remove the code and elucidate in the commentary. 

??

> On Apr 3, 2021, at 8:08 PM, David Holmes <David.Holmes at oracle.com> wrote:
> 
> ?On 4/04/2021 12:02 am, Jim Laskey wrote:
>> Is it in bad form to declare a #define CLOSE_JIMAGE 0 ?
> 
> Still dead code.
> 
> This is a core-libs style call anyway.
> 
> Cheers,
> David
> 
>> ??
>>>> On Apr 3, 2021, at 9:49 AM, David Holmes <David.Holmes at oracle.com> wrote:
>>> 
>>> ?On 2/04/2021 5:34 pm, Alan Bateman wrote:
>>>> On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
>>>>>> src/java.base/share/native/libjimage/imageFile.cpp line 219:
>>>>>> 
>>>>>>> 217: // WARNING: Should never close the jimage file.
>>>>>>> 218: //          Threads may still be running at shutdown.
>>>>>>> 219: #if 0
>>>>>> 
>>>>>> Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted.
>>>>> 
>>>>> Leaving the code as an example of what is required to close in case the topic gets revisited in the future and I get hit by a bus or dementia.
>>>> Okay although I assume someone will spot this and be tempted to remove it.
>>> 
>>> I didn't comment on this as I assumed it would contravene core-libs coding guidelines. I'm suprised to see dead code kept this way (there are existing cases elsewhere but it isn't considered good form). Previous code can always be retrieved from the repo history.
>>> 
>>> Cheers,
>>> David
>>> 
>>>> -------------
>>>> PR: https://git.openjdk.java.net/jdk/pull/3304

From aph at redhat.com  Sun Apr  4 08:53:25 2021
From: aph at redhat.com (Andrew Haley)
Date: Sun, 4 Apr 2021 09:53:25 +0100
Subject: Faster double parser?
In-Reply-To: <CACfbOvfg3futQZaJQXMbp7+5EVuSEQKUkj23f-Wsh_Nk-Yv=vw@mail.gmail.com>
References: <CACfbOvfg3futQZaJQXMbp7+5EVuSEQKUkj23f-Wsh_Nk-Yv=vw@mail.gmail.com>
Message-ID: <c90e64c1-506a-0928-8934-8e9a1f6b9b3a@redhat.com>

On 4/3/21 12:58 PM, Carfield Yim wrote:
> HI all, just aware of this project,
> https://github.com/wrandelshofer/FastDoubleParser, not sure if it good idea
> to use this as default Double Parser in JVM?

We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html

As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph at redhat.com  Sun Apr  4 08:56:08 2021
From: aph at redhat.com (Andrew Haley)
Date: Sun, 4 Apr 2021 09:56:08 +0100
Subject: Faster double parser?
In-Reply-To: <c90e64c1-506a-0928-8934-8e9a1f6b9b3a@redhat.com>
References: <CACfbOvfg3futQZaJQXMbp7+5EVuSEQKUkj23f-Wsh_Nk-Yv=vw@mail.gmail.com>
 <c90e64c1-506a-0928-8934-8e9a1f6b9b3a@redhat.com>
Message-ID: <74fc6eb4-fdae-27dd-2a65-a387d50df729@redhat.com>

On 4/4/21 9:53 AM, Andrew Haley wrote:
> On 4/3/21 12:58 PM, Carfield Yim wrote:
>> HI all, just aware of this project,
>> https://github.com/wrandelshofer/FastDoubleParser, not sure if it good idea
>> to use this as default Double Parser in JVM?
> 
> We also have a candidate for a String -> toDouble

Argh. Double -> String.

> parser from Raffaello Giulietti:
-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From Alan.Bateman at oracle.com  Mon Apr  5 08:08:34 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 5 Apr 2021 09:08:34 +0100
Subject: Faster double parser?
In-Reply-To: <c90e64c1-506a-0928-8934-8e9a1f6b9b3a@redhat.com>
References: <CACfbOvfg3futQZaJQXMbp7+5EVuSEQKUkj23f-Wsh_Nk-Yv=vw@mail.gmail.com>
 <c90e64c1-506a-0928-8934-8e9a1f6b9b3a@redhat.com>
Message-ID: <5565a5c5-7cf8-a055-2f60-656791bca527@oracle.com>

On 04/04/2021 09:53, Andrew Haley wrote:
> :
> We also have a candidate for a String -> toDouble parser from Raffaello
> Giulietti:
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
>
> As far as I can see there's nothing wrong with it, but it got stuck in
> review. This was a bad failure of our review processes, I'm afraid. I
> wonder if we will do any better with this one.

Yeah, there was a lengthy discussion about this at the OpenJDK Committer 
Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had 
both put time into looking at the proposal it but the conclusion was 
that Raffaello's paper "The Schubfach way to render doubles" needed a 
review from from an expert in this area. Guy Steele was mentioned but I 
don't know if he was approached about it.

-Alan

From aph at redhat.com  Mon Apr  5 11:11:45 2021
From: aph at redhat.com (Andrew Haley)
Date: Mon, 5 Apr 2021 12:11:45 +0100
Subject: Faster double parser?
In-Reply-To: <5565a5c5-7cf8-a055-2f60-656791bca527@oracle.com>
References: <CACfbOvfg3futQZaJQXMbp7+5EVuSEQKUkj23f-Wsh_Nk-Yv=vw@mail.gmail.com>
 <c90e64c1-506a-0928-8934-8e9a1f6b9b3a@redhat.com>
 <5565a5c5-7cf8-a055-2f60-656791bca527@oracle.com>
Message-ID: <b4524ff9-bb26-eea9-9618-494c44e44b1f@redhat.com>

On 4/5/21 9:08 AM, Alan Bateman wrote:
> On 04/04/2021 09:53, Andrew Haley wrote:
>> :
>> We also have a candidate for a String -> toDouble parser from Raffaello
>> Giulietti:
>>
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
>>
>> As far as I can see there's nothing wrong with it, but it got stuck in
>> review. This was a bad failure of our review processes, I'm afraid. I
>> wonder if we will do any better with this one.
> 
> Yeah, there was a lengthy discussion about this at the OpenJDK Committer 
> Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had 
> both put time into looking at the proposal it but the conclusion was 
> that Raffaello's paper "The Schubfach way to render doubles" needed a 
> review from from an expert in this area.

I wonder. The implementation has even been proved correct for floats by
exhaustion. (Of course that's not possible for doubles.)

I submit, therefore, that we could at least use the float version without
reasonable fear of breaking something.

We seem to be paralysed by this one.

> Guy Steele was mentioned but I don't know if he was approached about it.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From jvernee at openjdk.java.net  Mon Apr  5 11:57:08 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 5 Apr 2021 11:57:08 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v3]
In-Reply-To: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
Message-ID: <irGlYG-wlIo8_j-SdVi3y2An0zZ_9aZjOzGAtu4q4Bo=.dd495d68-238f-4e54-97a4-a039701ffc37@github.com>

> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
> 
> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
> 
> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
> 
> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
> 
> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
> 
> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
> 
> As a result of these changes a lot of code was unused and has been removed in this patch.
> 
> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
> 
> Here are some numbers from the added benchmark:
> 
> Before:
> Benchmark                                    Mode  Cnt    Score    Error  Units
> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
> (as you can see, just the Object[] with arity less than 10 case is fast here)
> After:
> Benchmark                                    Mode  Cnt  Score   Error  Units
> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
> 
> Thanks,
> Jorn

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

  - Revert back to injected constructor handle
  - Add lambda form sharing
  - Add test case for collecting a custom class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3306/files
  - new: https://git.openjdk.java.net/jdk/pull/3306/files/313ffaaf..dbba7910

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

  Stats: 68 lines in 4 files changed: 32 ins; 22 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3306/head:pull/3306

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

From jvernee at openjdk.java.net  Mon Apr  5 11:57:08 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 5 Apr 2021 11:57:08 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v2]
In-Reply-To: <0eYHPEW_QRXhPVLj4o-GOP2cwbcQDetCq4Te7V3dcpc=.2044da6e-e51c-4840-b960-f2ad107d7b5b@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <H_Jbm1rHBxRQ_pv4w-SUZJU3T-pPf0KN8gzbmWc3s5Y=.fcc73798-0d0a-4b58-93db-7e6ed47265f8@github.com>
 <if64GQJjc-2qlh68BZwEq58oijuAProMFrn7KC_0SBQ=.ef224d7c-a90a-4d7c-a457-10b3f99748bf@github.com>
 <SWoYrFkh2BLEqD36F6eGhevxBeJFRt0KCx_LK-Ha9jU=.0c74bca0-93d3-4d40-b603-13717c3bfaae@github.com>
 <0eYHPEW_QRXhPVLj4o-GOP2cwbcQDetCq4Te7V3dcpc=.2044da6e-e51c-4840-b960-f2ad107d7b5b@github.com>
Message-ID: <VzNN9EkuC1FCUsl1ld7Oo2erQxtEiQEw5YugNDGhU30=.7bce4b83-40fe-4a9d-b7cc-753770836ca1@github.com>

On Fri, 2 Apr 2021 15:12:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> That's what I thought as well (but not 100% sure). I can partially roll back the last commit so the code still uses an injected array constructor handle, and then it should be easy to add caching in the cases where the component type is a reference type.
>
> Whatever you prefer. I'm fine with it either way.

I found it easier to add sharing now, since it makes the intrinsic redundant (and it can be removed again).

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

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

From jvernee at openjdk.java.net  Mon Apr  5 12:03:08 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 5 Apr 2021 12:03:08 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v3]
In-Reply-To: <3mIWCpGajYbFjNpY0FllaJe19jHwv4zPtQBeZdsyGKo=.f0a491a8-e3a1-468c-86e7-8e49863e0fa3@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <_rGqipYkniAqcFVS6DRfaz71wHMWuxH2I1fk9UxNwHs=.4226fd59-b7c1-4c89-a69e-8be528ab72e3@github.com>
 <3mIWCpGajYbFjNpY0FllaJe19jHwv4zPtQBeZdsyGKo=.f0a491a8-e3a1-468c-86e7-8e49863e0fa3@github.com>
Message-ID: <phgz5utflNTg-L27drsq4bv7a3of8iq1a7mxkqcJrOE=.1430c940-1d08-40e5-bb32-23a643dd8d3c@github.com>

On Fri, 2 Apr 2021 13:23:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> That's an elegant solution.
>> 
>> At first i thought it might unduly perturb lambda form generation and caching. but you slotted a different lambda form implementation underneath the varargs implementation.
>
> I've addressed review comments, plus some other things:
> 
> - I realized that I was calling the uncached version of the store function factory. Fixed that.
> - I also realized that there's already an `ARRAY_STORE` intrinsic, which I'm now using to avoid generating a call.
> - I also realized that since we only have 1 array creation handle per lambda form, we can instead generate a direct call to `Array::newInstance` instead of going through the array constructor handle (which also avoids having to use a BoundMethodHandle).
> - Finally, I added an instrinsic, under the old `NEW_ARRAY` name, that intrinsifies a call to `Array::newInstance` if the component type argument is constant (which it is in this case).
> 
> As a result, the lambda form is now fully intrinsified (no more calls in the generated bytecode) e.g.:
> 
> static java.lang.Object collector001_LLLL_L(java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object);
>     Code:
>        0: iconst_3
>        1: anewarray     #12                 // class java/lang/String
>        4: astore        4
>        6: aload         4
>        8: checkcast     #14                 // class "[Ljava/lang/String;"
>       11: dup
>       12: astore        4
>       14: iconst_0
>       15: aload_1
>       16: checkcast     #12                 // class java/lang/String
>       19: aastore
>       20: aload         4
>       22: iconst_1
>       23: aload_2
>       24: checkcast     #12                 // class java/lang/String
>       27: aastore
>       28: aload         4
>       30: iconst_2
>       31: aload_3
>       32: checkcast     #12                 // class java/lang/String
>       35: aastore
>       36: aload         4
>       38: areturn
> 
> Thanks,
> Jorn

Addressed latest review comments:
- Reverted back to using an injected constructor handle (to be able to take advantage of lambda form sharing)
- Added lambda form sharing for empty and reference arrays
- Added a test case for a custom class to VarargsArrayTest, which catches the illegal access error in the intrinsified case that Vlad pointed out (though the itrinsic itself is now removed).

I also had to switch back to the un-cached version for creating the array element setter, since the cached version casts the array to be a specific type, and if the lambda form is shared, this won't work (e.g. casting an Object[] to String[], depending on the order of creating the collectors). Adding caching there is left as a followup.

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

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

From vlivanov at openjdk.java.net  Mon Apr  5 12:45:13 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 5 Apr 2021 12:45:13 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v3]
In-Reply-To: <irGlYG-wlIo8_j-SdVi3y2An0zZ_9aZjOzGAtu4q4Bo=.dd495d68-238f-4e54-97a4-a039701ffc37@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <irGlYG-wlIo8_j-SdVi3y2An0zZ_9aZjOzGAtu4q4Bo=.dd495d68-238f-4e54-97a4-a039701ffc37@github.com>
Message-ID: <UrCTha2c6m3lWsl3350r871xM99iKYgCAzwQ7lKsFAg=.136788e7-acfd-4868-91b7-24e34262e30d@github.com>

On Mon, 5 Apr 2021 11:57:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
>> 
>> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
>> 
>> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
>> 
>> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
>> 
>> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
>> 
>> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
>> 
>> As a result of these changes a lot of code was unused and has been removed in this patch.
>> 
>> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
>> 
>> Here are some numbers from the added benchmark:
>> 
>> Before:
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
>> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
>> (as you can see, just the Object[] with arity less than 10 case is fast here)
>> After:
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
>> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Revert back to injected constructor handle
>   - Add lambda form sharing
>   - Add test case for collecting a custom class

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1909:

> 1907:         boolean isSharedLambdaForm = parameterCount == 0 || basicType.parameterType(0) == Object.class;
> 1908:         if (isSharedLambdaForm) {
> 1909:             LambdaForm lform = basicType.form().cachedLambdaForm(MethodTypeForm.LF_COLLECTOR);

How does sharing work w.r.t. array store check? Unless you put `storeFunc` on the BMH, I don't see how sharing preserves proper check.

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

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

From vlivanov at openjdk.java.net  Mon Apr  5 12:45:13 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 5 Apr 2021 12:45:13 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v3]
In-Reply-To: <UrCTha2c6m3lWsl3350r871xM99iKYgCAzwQ7lKsFAg=.136788e7-acfd-4868-91b7-24e34262e30d@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <irGlYG-wlIo8_j-SdVi3y2An0zZ_9aZjOzGAtu4q4Bo=.dd495d68-238f-4e54-97a4-a039701ffc37@github.com>
 <UrCTha2c6m3lWsl3350r871xM99iKYgCAzwQ7lKsFAg=.136788e7-acfd-4868-91b7-24e34262e30d@github.com>
Message-ID: <e-E3eHg3uhkhPQotdPhrY_BJQC3UzgpiMNBgWVMFxH0=.e55aeb75-314a-4b70-8179-ae8bc0ce6e32@github.com>

On Mon, 5 Apr 2021 12:37:06 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Revert back to injected constructor handle
>>   - Add lambda form sharing
>>   - Add test case for collecting a custom class
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1909:
> 
>> 1907:         boolean isSharedLambdaForm = parameterCount == 0 || basicType.parameterType(0) == Object.class;
>> 1908:         if (isSharedLambdaForm) {
>> 1909:             LambdaForm lform = basicType.form().cachedLambdaForm(MethodTypeForm.LF_COLLECTOR);
> 
> How does sharing work w.r.t. array store check? Unless you put `storeFunc` on the BMH, I don't see how sharing preserves proper check.

Nevermind, it's the type of the method handle produced by `makeCollector` which ensures that all the arguments have proper type.

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

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

From vlivanov at openjdk.java.net  Mon Apr  5 12:53:31 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 5 Apr 2021 12:53:31 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v3]
In-Reply-To: <irGlYG-wlIo8_j-SdVi3y2An0zZ_9aZjOzGAtu4q4Bo=.dd495d68-238f-4e54-97a4-a039701ffc37@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <irGlYG-wlIo8_j-SdVi3y2An0zZ_9aZjOzGAtu4q4Bo=.dd495d68-238f-4e54-97a4-a039701ffc37@github.com>
Message-ID: <xF14SwSa5RucTRiVTzWIGSMmP1cVGL8_zVofyNcxCmM=.ec5d6afd-27ca-4243-bc65-16364d3cc249@github.com>

On Mon, 5 Apr 2021 11:57:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
>> 
>> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
>> 
>> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
>> 
>> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
>> 
>> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
>> 
>> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
>> 
>> As a result of these changes a lot of code was unused and has been removed in this patch.
>> 
>> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
>> 
>> Here are some numbers from the added benchmark:
>> 
>> Before:
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
>> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
>> (as you can see, just the Object[] with arity less than 10 case is fast here)
>> After:
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
>> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Revert back to injected constructor handle
>   - Add lambda form sharing
>   - Add test case for collecting a custom class

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1883:

> 1881: 
> 1882:         MethodHandle newArray = MethodHandles.arrayConstructor(arrayType);
> 1883:         MethodHandle storeFunc = ArrayAccessor.getAccessor(arrayType, ArrayAccess.SET);

I'd move `storeFunc` into `makeCollectorForm()` and use erased accessor there (`ArrayAccessor.OBJECT_ARRAY_SETTER`). 

(It is interesting that `OBJECT_ARRAY_SETTER` is `ARRAY_STORE` intrinsic.)

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

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

From jlaskey at openjdk.java.net  Mon Apr  5 14:15:43 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 14:15:43 GMT
Subject: RFR: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28 [v2]
In-Reply-To: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
Message-ID: <RgzcCD0uSeVijUIRTSwT9DK7IM1LRBuBhMf1vg-nMAY=.0573d179-a9aa-4700-ae79-60c69d3f3f39@github.com>

> We should never close the jimage since java threads can still be running after a hard exit().

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

  Remove dead code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3304/files
  - new: https://git.openjdk.java.net/jdk/pull/3304/files/515bba9d..3b6be82f

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

  Stats: 23 lines in 2 files changed: 5 ins; 17 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3304.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3304/head:pull/3304

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

From jlaskey at openjdk.java.net  Mon Apr  5 14:15:44 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 14:15:44 GMT
Subject: Integrated: 8166727: javac crashed: [jimage.dll+0x1942]
 ImageStrings::find+0x28
In-Reply-To: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
References: <JsY3FtBzeoDd_dDVkqB-LL8ZE8ez-fvNbF0LV8Tor9c=.af3139d2-a38f-45b6-ad38-9a1d38c44a0b@github.com>
Message-ID: <QgMLIGCJ9O_pDu7sdEnW0KiMafpazWu7NjI9kQsUiiM=.5d04145d-81c0-4d38-bb3c-d59138e13a2f@github.com>

On Thu, 1 Apr 2021 11:48:21 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> We should never close the jimage since java threads can still be running after a hard exit().

This pull request has now been integrated.

Changeset: a8005efd
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a8005efd
Stats:     17 lines in 2 files changed: 5 ins; 11 del; 1 mod

8166727: javac crashed: [jimage.dll+0x1942] ImageStrings::find+0x28

Reviewed-by: iklam, alanb

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

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

From jvernee at openjdk.java.net  Mon Apr  5 14:16:37 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 5 Apr 2021 14:16:37 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v4]
In-Reply-To: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
Message-ID: <6ibsK_G3CpKFi7Cy_DgJXfqKepIDjPnGzZDO_RGxK9s=.addd649c-11d9-4444-bcb6-d4e15b677003@github.com>

> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
> 
> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
> 
> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
> 
> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
> 
> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
> 
> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
> 
> As a result of these changes a lot of code was unused and has been removed in this patch.
> 
> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
> 
> Here are some numbers from the added benchmark:
> 
> Before:
> Benchmark                                    Mode  Cnt    Score    Error  Units
> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
> (as you can see, just the Object[] with arity less than 10 case is fast here)
> After:
> Benchmark                                    Mode  Cnt  Score   Error  Units
> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
> 
> Thanks,
> Jorn

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

  Review comment: Rearrange code to explicitly reference erased setter

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3306/files
  - new: https://git.openjdk.java.net/jdk/pull/3306/files/dbba7910..72ccf282

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

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

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

From jlaskey at openjdk.java.net  Mon Apr  5 14:20:56 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 14:20:56 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v42]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <oORuxOAi-tXeZ2a4ndnX1PaaIFPV99_A-s-4eSMLdlk=.28984004-6ce0-4f27-bd36-15480bfe4218@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:

 - Merge branch 'master' into 8248862
 - Fix NotCompliantCauseTest to not rely on Random not being a bean
 - Merge branch 'master' into 8248862
 - Correct return type of RandomGeneratorFactory.of
 - Merge branch 'master' into 8248862
 - CSR review revisions
 - CSR review updates
 - Removed @since from nextDouble ThreadLocalRandom
 - RandomGeneratorFactory::all(Class<T> category) @implNote was out of date
 - Clarify all()
 - ... and 68 more: https://git.openjdk.java.net/jdk/compare/a8005efd...ffd982b0

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

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=41
  Stats: 12973 lines in 27 files changed: 11202 ins; 1590 del; 181 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

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

From jvernee at openjdk.java.net  Mon Apr  5 14:23:39 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 5 Apr 2021 14:23:39 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v3]
In-Reply-To: <xF14SwSa5RucTRiVTzWIGSMmP1cVGL8_zVofyNcxCmM=.ec5d6afd-27ca-4243-bc65-16364d3cc249@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <irGlYG-wlIo8_j-SdVi3y2An0zZ_9aZjOzGAtu4q4Bo=.dd495d68-238f-4e54-97a4-a039701ffc37@github.com>
 <xF14SwSa5RucTRiVTzWIGSMmP1cVGL8_zVofyNcxCmM=.ec5d6afd-27ca-4243-bc65-16364d3cc249@github.com>
Message-ID: <6oTDGVRTR-jxvqkgQ850mba4VRjH052ZyKmzdsTiw3w=.1d2a02a9-8217-458e-8b22-bb3b867471c3@github.com>

On Mon, 5 Apr 2021 12:48:07 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Revert back to injected constructor handle
>>   - Add lambda form sharing
>>   - Add test case for collecting a custom class
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1883:
> 
>> 1881: 
>> 1882:         MethodHandle newArray = MethodHandles.arrayConstructor(arrayType);
>> 1883:         MethodHandle storeFunc = ArrayAccessor.getAccessor(arrayType, ArrayAccess.SET);
> 
> I'd move `storeFunc` into `makeCollectorForm()` and use erased accessor there (`ArrayAccessor.OBJECT_ARRAY_SETTER`). 
> 
> (It is interesting that `OBJECT_ARRAY_SETTER` is `ARRAY_STORE` intrinsic.)

Done. I think it's also more obvious this way that the erased setter is being used. Good suggestion.

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

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

From vlivanov at openjdk.java.net  Mon Apr  5 15:42:25 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 5 Apr 2021 15:42:25 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v4]
In-Reply-To: <6ibsK_G3CpKFi7Cy_DgJXfqKepIDjPnGzZDO_RGxK9s=.addd649c-11d9-4444-bcb6-d4e15b677003@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <6ibsK_G3CpKFi7Cy_DgJXfqKepIDjPnGzZDO_RGxK9s=.addd649c-11d9-4444-bcb6-d4e15b677003@github.com>
Message-ID: <FsZWABVuY2-l2YDy4bDWmxlIytjWFyGOrQ5V8beuwoo=.e23157b7-ca68-434b-8ce8-6f7bff06566a@github.com>

On Mon, 5 Apr 2021 14:16:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
>> 
>> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
>> 
>> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
>> 
>> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
>> 
>> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
>> 
>> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
>> 
>> As a result of these changes a lot of code was unused and has been removed in this patch.
>> 
>> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
>> 
>> Here are some numbers from the added benchmark:
>> 
>> Before:
>> Benchmark                                    Mode  Cnt    Score    Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
>> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
>> (as you can see, just the Object[] with arity less than 10 case is fast here)
>> After:
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
>> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
>> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
>> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
>> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
>> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: Rearrange code to explicitly reference erased setter

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From jlaskey at openjdk.java.net  Mon Apr  5 16:32:36 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 16:32:36 GMT
Subject: Integrated: 8248862: Implement Enhanced Pseudo-Random Number
 Generators
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <CQL13GfcYH5gjNEaMfGWznVrYaAi6Ml_WTwPZIusv4A=.c91cd7cb-1e52-49f4-bc68-56b75c7bf2c7@github.com>

On Wed, 18 Nov 2020 13:45:12 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

This pull request has now been integrated.

Changeset: a0ec2cb2
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a0ec2cb2
Stats:     12973 lines in 27 files changed: 11202 ins; 1590 del; 181 mod

8248862: Implement Enhanced Pseudo-Random Number Generators

Reviewed-by: darcy

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

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

From bpb at openjdk.java.net  Mon Apr  5 16:45:23 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 5 Apr 2021 16:45:23 GMT
Subject: Integrated: 8264512: jdk/test/jdk/java/util/prefs/ExportNode.java
 relies on default platform encoding
In-Reply-To: <0OQKXp0bWcbNFp8Ut3v_GzzZCVOGC_cuJtGvUNrgzYw=.f9c21e46-d7b6-4e43-8ee3-cc8e42946d88@github.com>
References: <0OQKXp0bWcbNFp8Ut3v_GzzZCVOGC_cuJtGvUNrgzYw=.f9c21e46-d7b6-4e43-8ee3-cc8e42946d88@github.com>
Message-ID: <lS8ERyl4lKRzlOtYQHp573CKyVu8vDwzI1jsjj7LtMs=.172ff464-3b27-4207-bfa5-c8c978002d67@github.com>

On Fri, 2 Apr 2021 21:45:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This test emits to a `java.io.ByteArrayOutputStream` the contents of a `java.utils.prefs.Preferences` node. The `UTF-8` character encoding is used [1]. The `ByteArrayOutputStream` is then converted to a `String` using `toString()` which uses the platform's default character set [2]. The resulting `String` is then checked for the node names that it should and should not contain.
> 
> This change proposes to use `ByteArrayOutputStream.toString(String)` to obtain the string [3] to maintain consistency of the encoding. It also adds throwing a `RuntimeException` if the node string is not as expected. It is unclear why this test was not already throwing such an exception.
> 
> [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.prefs/java/util/prefs/Preferences.html#exportNode(java.io.OutputStream)
> [2] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/io/ByteArrayOutputStream.html#toString()
> [3] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/io/ByteArrayOutputStream.html#toString(java.lang.String)

This pull request has now been integrated.

Changeset: 104e925d
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/104e925d
Stats:     39 lines in 1 file changed: 21 ins; 0 del; 18 mod

8264512: jdk/test/jdk/java/util/prefs/ExportNode.java relies on default platform encoding

Reviewed-by: naoto

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

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

From jvernee at openjdk.java.net  Mon Apr  5 16:46:18 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 5 Apr 2021 16:46:18 GMT
Subject: RFR: 8264288: Performance issue with MethodHandle.asCollector [v4]
In-Reply-To: <FsZWABVuY2-l2YDy4bDWmxlIytjWFyGOrQ5V8beuwoo=.e23157b7-ca68-434b-8ce8-6f7bff06566a@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
 <6ibsK_G3CpKFi7Cy_DgJXfqKepIDjPnGzZDO_RGxK9s=.addd649c-11d9-4444-bcb6-d4e15b677003@github.com>
 <FsZWABVuY2-l2YDy4bDWmxlIytjWFyGOrQ5V8beuwoo=.e23157b7-ca68-434b-8ce8-6f7bff06566a@github.com>
Message-ID: <1BBM7gx0puF4CrvIDDY8cBVXNOTX1CWXfiZp_nTqDW4=.ded3a1df-b8ba-495e-aa83-6f8f7293cd78@github.com>

On Mon, 5 Apr 2021 15:39:39 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment: Rearrange code to explicitly reference erased setter
>
> Looks good.

Thanks for the reviews. I've submitted one more tier1-3 test run and if that's all green I'll go ahead and integrate this.

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

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

From brian.burkhalter at oracle.com  Mon Apr  5 16:52:59 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 5 Apr 2021 16:52:59 +0000
Subject: Faster double parser?
In-Reply-To: <b4524ff9-bb26-eea9-9618-494c44e44b1f@redhat.com>
References: <CACfbOvfg3futQZaJQXMbp7+5EVuSEQKUkj23f-Wsh_Nk-Yv=vw@mail.gmail.com>
 <c90e64c1-506a-0928-8934-8e9a1f6b9b3a@redhat.com>
 <5565a5c5-7cf8-a055-2f60-656791bca527@oracle.com>
 <b4524ff9-bb26-eea9-9618-494c44e44b1f@redhat.com>
Message-ID: <E984C214-D87E-4D4C-89F1-D01A9D190180@oracle.com>


On Apr 5, 2021, at 4:11 AM, Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>> wrote:

On 4/5/21 9:08 AM, Alan Bateman wrote:
On 04/04/2021 09:53, Andrew Haley wrote:
:
We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html

As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.

Yeah, there was a lengthy discussion about this at the OpenJDK Committer
Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
both put time into looking at the proposal it but the conclusion was
that Raffaello's paper "The Schubfach way to render doubles" needed a
review from from an expert in this area.

I spent some time on it a while back but got bogged down.

I wonder. The implementation has even been proved correct for floats by
exhaustion. (Of course that's not possible for doubles.)

I exhaustively verified it for floats. I also ran round-trip tests for doubles which ran for days without error. Of course one can only disprove by counterexample, not prove by anecdote.

I submit, therefore, that we could at least use the float version without
reasonable fear of breaking something.

That is a good suggestion.

We seem to be paralysed by this one.

Guy Steele was mentioned but I don't know if he was approached about it.

Indirectly.

Another aspect which was raised was supportability: is it sufficiently understood for us to support? On that note I would ask ?Is FloatingDecimal sufficiently understood to support?? I think the answer to both questions is the same.

Brian


From brian.burkhalter at oracle.com  Mon Apr  5 17:09:21 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 5 Apr 2021 17:09:21 +0000
Subject: Faster double parser?
In-Reply-To: <E984C214-D87E-4D4C-89F1-D01A9D190180@oracle.com>
References: <CACfbOvfg3futQZaJQXMbp7+5EVuSEQKUkj23f-Wsh_Nk-Yv=vw@mail.gmail.com>
 <c90e64c1-506a-0928-8934-8e9a1f6b9b3a@redhat.com>
 <5565a5c5-7cf8-a055-2f60-656791bca527@oracle.com>
 <b4524ff9-bb26-eea9-9618-494c44e44b1f@redhat.com>
 <E984C214-D87E-4D4C-89F1-D01A9D190180@oracle.com>
Message-ID: <41D5FA2A-EA25-4A37-83E1-5041B1867DC4@oracle.com>

The mailing list mangled formatting. My comments are prefixed below by ?->?.

On Apr 5, 2021, at 9:52 AM, Brian Burkhalter <brian.burkhalter at oracle.com<mailto:brian.burkhalter at oracle.com>> wrote:

On Apr 5, 2021, at 4:11 AM, Andrew Haley <aph at redhat.com<mailto:aph at redhat.com><mailto:aph at redhat.com>> wrote:

On 4/5/21 9:08 AM, Alan Bateman wrote:
On 04/04/2021 09:53, Andrew Haley wrote:
:
We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html

As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.

Yeah, there was a lengthy discussion about this at the OpenJDK Committer
Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
both put time into looking at the proposal it but the conclusion was
that Raffaello's paper "The Schubfach way to render doubles" needed a
review from from an expert in this area.

-> I spent some time on it a while back but got bogged down.

I wonder. The implementation has even been proved correct for floats by
exhaustion. (Of course that's not possible for doubles.)

-> I exhaustively verified it for floats. I also ran round-trip tests for doubles which ran for days without error. Of course one can only disprove by counterexample, not prove by anecdote.

I submit, therefore, that we could at least use the float version without
reasonable fear of breaking something.

-> That is a good suggestion.

We seem to be paralysed by this one.

Guy Steele was mentioned but I don't know if he was approached about it.

-> Indirectly.

-> Another aspect which was raised was supportability: is it sufficiently understood for us to support? On that note I would ask ?Is FloatingDecimal sufficiently understood to support?? I think the answer to both questions is the same.


From brian.burkhalter at oracle.com  Mon Apr  5 17:09:26 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 5 Apr 2021 17:09:26 +0000
Subject: Faster double parser?
In-Reply-To: <E984C214-D87E-4D4C-89F1-D01A9D190180@oracle.com>
References: <CACfbOvfg3futQZaJQXMbp7+5EVuSEQKUkj23f-Wsh_Nk-Yv=vw@mail.gmail.com>
 <c90e64c1-506a-0928-8934-8e9a1f6b9b3a@redhat.com>
 <5565a5c5-7cf8-a055-2f60-656791bca527@oracle.com>
 <b4524ff9-bb26-eea9-9618-494c44e44b1f@redhat.com>
 <E984C214-D87E-4D4C-89F1-D01A9D190180@oracle.com>
Message-ID: <BFAAFD21-6832-4719-B558-03392C6FDD02@oracle.com>

The mailing list mangled formatting. My comments are prefixed below by ?->?.

On Apr 5, 2021, at 9:52 AM, Brian Burkhalter <brian.burkhalter at oracle.com<mailto:brian.burkhalter at oracle.com>> wrote:

On Apr 5, 2021, at 4:11 AM, Andrew Haley <aph at redhat.com<mailto:aph at redhat.com><mailto:aph at redhat.com>> wrote:

On 4/5/21 9:08 AM, Alan Bateman wrote:
On 04/04/2021 09:53, Andrew Haley wrote:
:
We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html

As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.

Yeah, there was a lengthy discussion about this at the OpenJDK Committer
Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
both put time into looking at the proposal it but the conclusion was
that Raffaello's paper "The Schubfach way to render doubles" needed a
review from from an expert in this area.

-> I spent some time on it a while back but got bogged down.

I wonder. The implementation has even been proved correct for floats by
exhaustion. (Of course that's not possible for doubles.)

-> I exhaustively verified it for floats. I also ran round-trip tests for doubles which ran for days without error. Of course one can only disprove by counterexample, not prove by anecdote.

I submit, therefore, that we could at least use the float version without
reasonable fear of breaking something.

-> That is a good suggestion.

We seem to be paralysed by this one.

Guy Steele was mentioned but I don't know if he was approached about it.

-> Indirectly.

-> Another aspect which was raised was supportability: is it sufficiently understood for us to support? On that note I would ask ?Is FloatingDecimal sufficiently understood to support?? I think the answer to both questions is the same.


From jlaskey at openjdk.java.net  Mon Apr  5 17:13:33 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 17:13:33 GMT
Subject: RFR: 8264729: Orphan file - shouldn't be in sources.
Message-ID: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>

open/src/java.base/share/native/random/create_ziggurat_tables.c should not be in the sources.

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

Commit messages:
 - 8264729: Orphan file - shouldn't be in sources.

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

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

From erikj at openjdk.java.net  Mon Apr  5 17:17:15 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 5 Apr 2021 17:17:15 GMT
Subject: RFR: 8264729: Orphan file - shouldn't be in sources.
In-Reply-To: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
References: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
Message-ID: <FgxXhOYk9OM9lBpsNllsBCozyYrGxoaCOVT2ZtLV3EM=.f872e89a-19e3-4e96-a5f1-8165f73f0e4f@github.com>

On Mon, 5 Apr 2021 17:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> open/src/java.base/share/native/random/create_ziggurat_tables.c should not be in the sources.

Marked as reviewed by erikj (Reviewer).

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

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

From bpb at openjdk.java.net  Mon Apr  5 17:33:24 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 5 Apr 2021 17:33:24 GMT
Subject: RFR: 8264729: Orphan file - shouldn't be in sources.
In-Reply-To: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
References: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
Message-ID: <wh76Ki9c8EQkICQzbhIBdVLm0ALxt8UfyVyPUGKXUpA=.3514e9fd-51ea-4d36-b9e6-a91083d0a914@github.com>

On Mon, 5 Apr 2021 17:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> open/src/java.base/share/native/random/create_ziggurat_tables.c should not be in the sources.

Marked as reviewed by bpb (Reviewer).

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

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

From jlaskey at openjdk.java.net  Mon Apr  5 17:36:45 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 17:36:45 GMT
Subject: RFR: 8264729: Orphan file - shouldn't be in sources. [v2]
In-Reply-To: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
References: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
Message-ID: <QWhan1CizI9q560Z0lrg2ECKNjVRVSg5SpJYDwbhHW8=.549b442a-d48b-4404-9356-a98255a6eeef@github.com>

> open/src/java.base/share/native/random/create_ziggurat_tables.c should not be in the sources.

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

  Tests with bad copyright dates.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3343/files
  - new: https://git.openjdk.java.net/jdk/pull/3343/files/c003d155..3ae2db7d

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

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

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

From jlaskey at openjdk.java.net  Mon Apr  5 17:44:37 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 17:44:37 GMT
Subject: RFR: 8264729: Orphan file - shouldn't be in sources. [v3]
In-Reply-To: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
References: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
Message-ID: <bvnghIkhC2-fe6FPyWCedDMP55O30j8nKeeFJ7QyUnQ=.c34eb2b4-5224-4d88-8b0d-fab1c9df65eb@github.com>

> open/src/java.base/share/native/random/create_ziggurat_tables.c should not be in the sources.

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

  One more file missing copyright date

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3343/files
  - new: https://git.openjdk.java.net/jdk/pull/3343/files/3ae2db7d..90219a77

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

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

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

From erikj at openjdk.java.net  Mon Apr  5 18:44:22 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 5 Apr 2021 18:44:22 GMT
Subject: RFR: 8264729: Random check-in failing header checks. [v3]
In-Reply-To: <bvnghIkhC2-fe6FPyWCedDMP55O30j8nKeeFJ7QyUnQ=.c34eb2b4-5224-4d88-8b0d-fab1c9df65eb@github.com>
References: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
 <bvnghIkhC2-fe6FPyWCedDMP55O30j8nKeeFJ7QyUnQ=.c34eb2b4-5224-4d88-8b0d-fab1c9df65eb@github.com>
Message-ID: <bZoAzewAK2WalVOHAjL7hx8x3NQ4P7Xsyw9Hlka31t8=.f2ef9283-3a28-43d2-9d3a-d7ad3dbcb3f9@github.com>

On Mon, 5 Apr 2021 17:44:37 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> open/src/java.base/share/native/random/create_ziggurat_tables.c should not be in the sources.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One more file missing copyright date

test/jdk/java/util/Random/RandomTestBsi1999.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

Shouldn't this be:
2012, 2021,

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

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

From jlaskey at openjdk.java.net  Mon Apr  5 18:53:30 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 18:53:30 GMT
Subject: RFR: 8264729: Random check-in failing header checks. [v3]
In-Reply-To: <bZoAzewAK2WalVOHAjL7hx8x3NQ4P7Xsyw9Hlka31t8=.f2ef9283-3a28-43d2-9d3a-d7ad3dbcb3f9@github.com>
References: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
 <bvnghIkhC2-fe6FPyWCedDMP55O30j8nKeeFJ7QyUnQ=.c34eb2b4-5224-4d88-8b0d-fab1c9df65eb@github.com>
 <bZoAzewAK2WalVOHAjL7hx8x3NQ4P7Xsyw9Hlka31t8=.f2ef9283-3a28-43d2-9d3a-d7ad3dbcb3f9@github.com>
Message-ID: <uzQ3zAHH9eehtYsg6EwOJNusJRroqA0qDLQw0Kis2XE=.f602b172-8ee4-4c5a-89b6-75e760c911e4@github.com>

On Mon, 5 Apr 2021 18:41:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   One more file missing copyright date
>
> test/jdk/java/util/Random/RandomTestBsi1999.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Shouldn't this be:
> 2012, 2021,

The earlier dates were while under development. As far as I know, this is the first time they appear. But I can change if that is the consensus.

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

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

From jlaskey at openjdk.java.net  Mon Apr  5 19:01:47 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 19:01:47 GMT
Subject: RFR: 8264729: Random check-in failing header checks. [v4]
In-Reply-To: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
References: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
Message-ID: <geml2hPjTXqArOIkKk5mKGHkhBbOEktux7raZVVwxVM=.d4c2277b-3296-490e-848f-9982f71d27ca@github.com>

> open/src/java.base/share/native/random/create_ziggurat_tables.c should not be in the sources.

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

  Include initial date.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3343/files
  - new: https://git.openjdk.java.net/jdk/pull/3343/files/90219a77..4aacf704

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

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

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

From jlaskey at openjdk.java.net  Mon Apr  5 19:06:25 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 5 Apr 2021 19:06:25 GMT
Subject: Integrated: 8264729: Random check-in failing header checks.
In-Reply-To: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
References: <1j0itFK-O6gDxuxcszTfA_pI_8c6fxwTEune7LIBflw=.b9068e2a-eb59-4676-afd2-4b468eea0915@github.com>
Message-ID: <3-pGCoyJKIkkhlVJuud3X3EhkD6CLymaGot6s46y8_Y=.7822f5c7-85a4-4b22-810e-51c20230c3cc@github.com>

On Mon, 5 Apr 2021 17:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> open/src/java.base/share/native/random/create_ziggurat_tables.c should not be in the sources.

This pull request has now been integrated.

Changeset: 92018991
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/92018991
Stats:     715 lines in 6 files changed: 23 ins; 688 del; 4 mod

8264729: Random check-in failing header checks.

Reviewed-by: erikj, bpb

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

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

From ralph.goers at dslextreme.com  Mon Apr  5 19:21:37 2021
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Mon, 5 Apr 2021 12:21:37 -0700
Subject: Garbage Free Clock
In-Reply-To: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
Message-ID: <704D98DD-0FEA-45B3-86C8-77012DEEB503@dslextreme.com>

Does anyone have any thoughts or suggestions on this please?

Ralph

> On Apr 2, 2021, at 4:47 PM, Ralph Goers <ralph.goers at dslextreme.com> wrote:
> 
> Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.
> 
> The code we have simply does
> 
> public void init(MutableInstant mutableInstant) {
>    Instant instant = java.time.Clock.systemUTC().instant();
>    mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
> }
> In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
> Ideally we would really like something like
> 
> public void init(MutableInstant mutableInstant) {
>   	java.time.Clock.systemUTC().initInstant(mutableInstant);
> }
> 
> where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.
> 
> This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.
> 
> Do you know of another way to do this? Am I missing something?
> 
> Ralph



From asemenyuk at openjdk.java.net  Mon Apr  5 19:54:44 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 5 Apr 2021 19:54:44 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers
Message-ID: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>

Use value of `--icon` jpackage CLI option to set icon for exe installers.

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

Commit messages:
 - 8236127: Use value of --icon CLI option to set icon for exe installers

Changes: https://git.openjdk.java.net/jdk/pull/3347/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3347&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236127
  Stats: 205 lines in 2 files changed: 188 ins; 7 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3347.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3347/head:pull/3347

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

From brian.goetz at oracle.com  Mon Apr  5 19:56:26 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 5 Apr 2021 15:56:26 -0400
Subject: Garbage Free Check
In-Reply-To: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
Message-ID: <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>

Project Valhalla will allow Instant to be migrated to a primitive class, 
which would address your problem.

On 4/2/2021 7:47 PM, Ralph Goers wrote:
> Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.
>
> The code we have simply does
>
> public void init(MutableInstant mutableInstant) {
>      Instant instant = java.time.Clock.systemUTC().instant();
>      mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
> }
> In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
> Ideally we would really like something like
>
> public void init(MutableInstant mutableInstant) {
>     	java.time.Clock.systemUTC().initInstant(mutableInstant);
> }
>
> where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.
>
> This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.
>
> Do you know of another way to do this? Am I missing something?
>
> Ralph


From jvernee at openjdk.java.net  Mon Apr  5 20:09:27 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 5 Apr 2021 20:09:27 GMT
Subject: Integrated: 8264288: Performance issue with MethodHandle.asCollector
In-Reply-To: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
References: <VgcIHmsD93SAiK3ABFqE9hzk3SLMjyEwoQ1xgd_yYzA=.d08cf3d3-2285-4f05-8463-d9c803fbe3ce@github.com>
Message-ID: <KXNjDty1N74297T4kclSRfAdCx1wbZBnN4QIkdNgDjE=.ca3176bf-4096-41f0-bf0f-d44f9e99f335@github.com>

On Thu, 1 Apr 2021 13:25:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch speeds up MethodHandle.asCollector handles where the array type is not Object[], as well as speeding up all collectors where the arity is greater than 10.
> 
> The old code is creating a collector handle by combining a set of hard coded methods for collecting arguments into an Object[], up to a maximum of ten elements, and then copying this intermediate array into a final array.
> 
> In principle, it shouldn't matter how slow (or fast) this handle is, because it should be replaced by existing bytecode intrinsification which does the right thing. But, through investigation it turns out that the intrinsification is only being applied in a very limited amount of cases: Object[] with max 10 elements only, only for the intermediate collector handles. Every other collector shape incurs overhead because it essentially ends up calling the ineffecient fallback handle.
> 
> Rather than sticking on a band aid (I tried this, but it turned out to be very tricky to untangle the existing code), the new code replaces the existing implementation with a collector handle implemented using a LambdaForm, which removes the need for intrinsification, and also greatly reduces code-complexity of the implementation. (I plan to expose this collector using a public API in the future as well, so users don't have to go through MHs::identity to make a collector).
> 
> The old code was also using a special lambda form transform for collecting arguments into an array. I believe this was done to take advantage of the existing-but-limited bytecode intrinsification, at least for Object[] with less than 10 elements.
> 
> The new code just uses the existing collect arguments transform with the newly added collector handle as filter, and this works just as well for the existing case, but as a bonus is also much simpler, since no separate transform is needed. Using the collect arguments transform should also improve sharing.
> 
> As a result of these changes a lot of code was unused and has been removed in this patch.
> 
> Testing: tier 1-3, benchmarking using TypedAsCollector (part of the patch), as well as another variant of the benchmark that used a declared static identity method instead of MHs::identity (not included). Before/after comparison of MethodHandleAs* benchmarks (no differences there).
> 
> Here are some numbers from the added benchmark:
> 
> Before:
> Benchmark                                    Mode  Cnt    Score    Error  Units
> TypedAsCollector.testIntCollect              avgt   30  189.156 ?  1.796  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  660.549 ? 10.159  ns/op
> TypedAsCollector.testObjectCollect           avgt   30    7.092 ?  0.042  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30   65.225 ?  0.546  ns/op
> TypedAsCollector.testStringCollect           avgt   30   28.511 ?  0.243  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30   57.054 ?  0.635  ns/op
> (as you can see, just the Object[] with arity less than 10 case is fast here)
> After:
> Benchmark                                    Mode  Cnt  Score   Error  Units
> TypedAsCollector.testIntCollect              avgt   30  6.569 ? 0.131  ns/op
> TypedAsCollector.testIntCollectHighArity     avgt   30  8.923 ? 0.066  ns/op
> TypedAsCollector.testObjectCollect           avgt   30  6.813 ? 0.035  ns/op
> TypedAsCollector.testObjectCollectHighArity  avgt   30  9.718 ? 0.066  ns/op
> TypedAsCollector.testStringCollect           avgt   30  6.737 ? 0.016  ns/op
> TypedAsCollector.testStringCollectHighArity  avgt   30  9.618 ? 0.052  ns/op
> 
> Thanks,
> Jorn

This pull request has now been integrated.

Changeset: b7baca7f
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b7baca7f
Stats:     535 lines in 10 files changed: 177 ins; 338 del; 20 mod

8264288: Performance issue with MethodHandle.asCollector

Reviewed-by: jrose, vlivanov

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

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

From roger.riggs at oracle.com  Mon Apr  5 20:26:14 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 5 Apr 2021 16:26:14 -0400
Subject: Garbage Free Check
In-Reply-To: <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
 <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>
Message-ID: <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>

Hi,

Java does not have a data type with enough resolution to hold a full 
nanosecond value.
Hence the implementation of Instant holding seconds and nanos.

There is an long dormant enhancement request to return micro-seconds as 
a long.
8196003 <https://bugs.openjdk.java.net/browse/JDK-8196003> java.time 
Instant and Duration methods for microseconds

That might be useful if the application gets enough resolution from 
microseconds.
There might be some clever interpolation between System.currentTimeMillis()
and adjusting with System.nanoTime().
Though it would likely not be exactly synchronized with the values from 
Instant.

Regards, Roger


On 4/5/21 3:56 PM, Brian Goetz wrote:
> Project Valhalla will allow Instant to be migrated to a primitive 
> class, which would address your problem.
>
> On 4/2/2021 7:47 PM, Ralph Goers wrote:
>> Log4j 2 supports the notion of a PreciseClock - one that can be 
>> initialized to something more precise than a millisecond. At the same 
>> time it also supports running with no heap allocations in certain 
>> circumstances. I am in the process of moving our master branch to 
>> require Java 11 as the minimum. In doing so I am encountering unit 
>> test errors while verifying that logging is garbage free. They all 
>> occur allocating an Instant.
>>
>> The code we have simply does
>>
>> public void init(MutableInstant mutableInstant) {
>> ???? Instant instant = java.time.Clock.systemUTC().instant();
>> mutableInstant.initFromEpochSecond(instant.getEpochSecond(), 
>> instant.getNano());
>> }
>> In our previous tests we had thought the allocation was being 
>> eliminated due to escape analysis since the data is being extracted 
>> from the Instant and not passed along. However, after upgrading the 
>> Google test library and the JDK version it appears that is not the case.
>> Ideally we would really like something like
>>
>> public void init(MutableInstant mutableInstant) {
>> ??????? java.time.Clock.systemUTC().initInstant(mutableInstant);
>> }
>>
>> where Mutable instant would implement an interface that has the two 
>> set methods.The method would execute the same logic that is in the 
>> instant() method but instead of creating a new Instant it would call 
>> the set methods for the provided object.
>>
>> This would allow us to either have the MutableInstants in 
>> ThreadLocals or some other mechanism to ensure they are thread safe 
>> and have no heap allocations. As it stands now I see no way to gain 
>> access to the higher precision clock without memory allocation.
>>
>> Do you know of another way to do this? Am I missing something?
>>
>> Ralph
>


From almatvee at openjdk.java.net  Tue Apr  6 00:42:14 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 6 Apr 2021 00:42:14 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers
In-Reply-To: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
Message-ID: <7BMeq49qASZXn23QGnyXLrEoN6FBKF7Kz7YZoYAoVeM=.7d1a47c0-90e1-4cd1-b20a-ece8dabe9745@github.com>

On Mon, 5 Apr 2021 19:46:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Use value of `--icon` jpackage CLI option to set icon for exe installers.

Marked as reviewed by almatvee (Committer).

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

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

From ralph.goers at dslextreme.com  Tue Apr  6 06:17:10 2021
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Mon, 5 Apr 2021 23:17:10 -0700
Subject: Garbage Free Check
In-Reply-To: <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
 <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>
 <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>
Message-ID: <3928DCCA-DDB1-4217-B4EE-08DC11158B60@dslextreme.com>

Yes, I am aware that the Instant is constructed from the two values. That is exactly why I was hoping I could pass in an object where the values of those two fields could be injected. This would still allow Instant to be immutable but allow Log4j to update one of the pre-existing Clock instances it is managing. That would require that a new Interface be defined with the two set methods and a new static method in the Clock class.

Getting the value in microseconds would probably be a middle ground that could also work considering that is the best resolution available on most hardware today. 

Whichever is implemented I suspect getting it back ported to Java 11 is unlikely? According to the surveys I?ve seen the majority of users are still on Java 8. Given that, I?d be surprised if there is a mad rush to adopt Java 17 very soon. Given where things are I?m not even sure how likely it is this could make it in for Java 17.  The irony here is that the folks who need to run garbage free are also the ones most likely to need a Clock with higher resolution. Right now they can?t have both.

Ralph

> On Apr 5, 2021, at 1:26 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi,
> 
> Java does not have a data type with enough resolution to hold a full nanosecond value.
> Hence the implementation of Instant holding seconds and nanos.
> 
> There is an long dormant enhancement request to return micro-seconds as a long.
> 8196003 <https://bugs.openjdk.java.net/browse/JDK-8196003> java.time Instant and Duration methods for microseconds
> 
> That might be useful if the application gets enough resolution from microseconds.
> There might be some clever interpolation between System.currentTimeMillis()
> and adjusting with System.nanoTime().
> Though it would likely not be exactly synchronized with the values from Instant.
> 
> Regards, Roger
> 
> 
> On 4/5/21 3:56 PM, Brian Goetz wrote:
>> Project Valhalla will allow Instant to be migrated to a primitive class, which would address your problem.
>> 
>> On 4/2/2021 7:47 PM, Ralph Goers wrote:
>>> Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.
>>> 
>>> The code we have simply does
>>> 
>>> public void init(MutableInstant mutableInstant) {
>>>      Instant instant = java.time.Clock.systemUTC().instant();
>>> mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
>>> }
>>> In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
>>> Ideally we would really like something like
>>> 
>>> public void init(MutableInstant mutableInstant) {
>>>         java.time.Clock.systemUTC().initInstant(mutableInstant);
>>> }
>>> 
>>> where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.
>>> 
>>> This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.
>>> 
>>> Do you know of another way to do this? Am I missing something?
>>> 
>>> Ralph
>> 
> 
> 



From dongbo at openjdk.java.net  Tue Apr  6 06:58:03 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 6 Apr 2021 06:58:03 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v4]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <eEt8wWNkzqD7QZ5Cjk6l6_72WbwqZy8a6d_pRTjh4oQ=.3d028758-b688-4998-9325-6ab5822a22dd@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

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

  load data with one ldrw, add JMH tests for error inputs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3228/files
  - new: https://git.openjdk.java.net/jdk/pull/3228/files/16ebc471..54a75f05

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

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

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

From dongbo at openjdk.java.net  Tue Apr  6 07:25:57 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 6 Apr 2021 07:25:57 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v5]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - conflicts resolved
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into aarch64.base64.decode
 - resovling conflicts
 - load data with one ldrw, add JMH tests for error inputs
 - Merge branch 'master' into aarch64.base64.decode
 - copyright
 - trivial fixes
 - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
 - Merge branch 'master' into aarch64.base64.decode
 - 8256245: AArch64: Implement Base64 decoding intrinsic

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

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

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

From dongbo at openjdk.java.net  Tue Apr  6 08:04:12 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 6 Apr 2021 08:04:12 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <Mk6kt6w3URs4k9Ouu4RNKWqByTFsDbW96SM7UlEii0Y=.e6c8d5dc-33f3-4933-942f-be5671ca777b@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
 <vxrUJagEcM97odeOocaFBJjZC_lNQwiuGmJwD0s-7wc=.d75d3029-2513-405c-afa3-f1ed8e7af5a1@github.com>
 <Nn9jqfMe-xnqho_oiJKjJwTMc7rRUy3cjrB0E0RpsqY=.34512df4-3587-4b8c-96e2-af4d82851c8f@github.com>
 <zhrOSmz2aytq_cXzp88IC5wXiTw3fyjfPD6XPxx7dkY=.4f3a7845-f33e-49ef-8488-eaf81c2c1020@github.com>
 <Mk6kt6w3URs4k9Ouu4RNKWqByTFsDbW96SM7UlEii0Y=.e6c8d5dc-33f3-4933-942f-be5671ca777b@github.com>
Message-ID: <PJmMVOec8NRmY2RRgiirbiCe9xvJm_vXdW53mlVjWMo=.03639f65-71d9-4cfa-92c7-f85ff81d505e@github.com>

On Fri, 2 Apr 2021 10:17:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> PING... Any suggestions on the updated commit?
>
>> PING... Any suggestions on the updated commit?
> 
> Once you reply to the comments, sure.

>
> Are there any existing test cases for failing inputs?
>
I added one, the error character is injected at the paramized index of the encoded data.
There are no big differences for small error injected index, seems too much time is took by exception handing.
Witnessed ~2x performance improvements as expected. The JMH tests:
### Kunpeng 916, intrinsic?tested with `-jar benchmarks.jar testBase64WithErrorInputsDecode -p errorIndex=3,64,144,208,272,1000,20000 -p maxNumBytes=1`
Base64Decode.testBase64WithErrorInputsDecode             3           4              1  avgt   10   3696.151 ? 202.783  ns/op
Base64Decode.testBase64WithErrorInputsDecode            64           4              1  avgt   10   3899.269 ? 178.289  ns/op
Base64Decode.testBase64WithErrorInputsDecode           144           4              1  avgt   10   3902.022 ? 163.611  ns/op
Base64Decode.testBase64WithErrorInputsDecode           208           4              1  avgt   10   3982.423 ? 256.638  ns/op
Base64Decode.testBase64WithErrorInputsDecode           272           4              1  avgt   10   3984.545 ? 144.282  ns/op
Base64Decode.testBase64WithErrorInputsDecode          1000           4              1  avgt   10   4532.959 ? 310.068  ns/op
Base64Decode.testBase64WithErrorInputsDecode         20000           4              1  avgt   10  17578.148 ? 631.600  ns/op
### Kunpeng 916, default?tested with `-XX:-UseBASE64Intrinsics -jar benchmarks.jar testBase64WithErrorInputsDecode -p errorIndex=3,64,144,208,272,1000,20000 -p maxNumBytes=1`
Base64Decode.testBase64WithErrorInputsDecode             3           4              1  avgt   10   3760.330 ? 261.672  ns/op
Base64Decode.testBase64WithErrorInputsDecode            64           4              1  avgt   10   3900.326 ? 121.632  ns/op
Base64Decode.testBase64WithErrorInputsDecode           144           4              1  avgt   10   4041.428 ? 174.435  ns/op
Base64Decode.testBase64WithErrorInputsDecode           208           4              1  avgt   10   4177.670 ? 214.433  ns/op
Base64Decode.testBase64WithErrorInputsDecode           272           4              1  avgt   10   4324.020 ? 106.826  ns/op
Base64Decode.testBase64WithErrorInputsDecode          1000           4              1  avgt   10   5476.469 ? 171.647  ns/op
Base64Decode.testBase64WithErrorInputsDecode         20000           4              1  avgt   10  34163.743 ? 162.263  ns/op

>
> Your test results suggest that it isn't useful for that, surely?
>
The results suggest non-SIMD code provides ~11.9% improvements for MIME decoding.
Furthermore, according to local tests, we may have about ~30% performance regression for MIME decoding without non-SIMD code.

In worst case, a MIME line has only 4 base64 encoded characters and a newline string consisted of error inputs, e.g. `\r\n`.
When the instrinsic encounter an illegal character (`\r`), it has to exit.
Then the Java code will pass the next illegal source byte (`\n`) to the intrinsic.
With only SIMD code, it will execute too much wasty instructions before it can detect the error.
Whie with non-SIMD code, the instrinsic will execute only one non-SIMD round for this error input.

>
> For loads and four post increments rather than one load and a few BFMs? Why?
>
Nice suggestion. Done, thanks.

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

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

From aph at openjdk.java.net  Tue Apr  6 09:47:31 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 6 Apr 2021 09:47:31 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <2JT6v2dKf3XicURmOEsdociN7j0SgmVwYdQMr8PaU-c=.9963e17e-44de-4576-9726-c1b15bd7f4e7@github.com>

On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.

What is the reasoning here? Sure, there can be illegal characters at the start, but what if there are not? The generic logic uses decodeBlock() even in the MIME case, because we don't know that there certainly will be illegal characters.

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

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

From aefimov at openjdk.java.net  Tue Apr  6 10:47:31 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 6 Apr 2021 10:47:31 GMT
Subject: Integrated: 8264048: Fix caching in Jar URL connections when an entry
 is missing
In-Reply-To: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>
References: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>
Message-ID: <eC7fMg3UgQEzWc-5QxEaPg-ugfQO_IUUoVGuDCRMERo=.4b548179-afd9-4eb2-9b5a-a18ce070d6e1@github.com>

On Tue, 30 Mar 2021 11:30:48 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> Current fix tries to tackle an issue with URL connection referencing non-existing Jar file entries:
> If an entry that doesn't exist is specified in an URL connection the underlying Jar file is still cached even if an exception is thrown after that. Such behavior prevents the caller, for instance, a `URLClassLoader`, from closing a Jar file.
> 
> The proposed fix checks if entry exists before caching a Jar file (only for cases with enabled caching):
> - If entry exists - jar file is cached if it wasn't cached before
> - If entry doesn't exist and jar file wasn't cached before - jar file is closed and exception is thrown
> - If entry doesn't exist and jar file was cached before - jar file is kept cached and exception is thrown
> 
> 
> The following tests have been used to verify the fix:
> - New regression tests
> - ``:jdk_core:`` tests
> - `api/java_util`,`api/java_net` JCK tests

This pull request has now been integrated.

Changeset: a611c462
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a611c462
Stats:     372 lines in 6 files changed: 346 ins; 2 del; 24 mod

8264048: Fix caching in Jar URL connections when an entry is missing

Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Reviewed-by: bchristi, dfuchs

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

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

From dongbo at openjdk.java.net  Tue Apr  6 11:19:36 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 6 Apr 2021 11:19:36 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <2JT6v2dKf3XicURmOEsdociN7j0SgmVwYdQMr8PaU-c=.9963e17e-44de-4576-9726-c1b15bd7f4e7@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <2JT6v2dKf3XicURmOEsdociN7j0SgmVwYdQMr8PaU-c=.9963e17e-44de-4576-9726-c1b15bd7f4e7@github.com>
Message-ID: <ThSwvJE2dDAfcx9XR0aeQ_0-YTnyEuFQ_HAF0qZs-pc=.c8601884-fa0d-4a88-8b68-ba5ac8b26c8f@github.com>

On Tue, 6 Apr 2021 09:44:28 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> What is the reasoning here? Sure, there can be illegal characters at the start, but what if there are not? The generic logic uses decodeBlock() even in the MIME case, because we don't know that there certainly will be illegal characters.

This code block only process 80B of the inputs.
If no illegal characters were found, the stub will use the SIMD instructions to process the rest of the inputs if the data length is large enough, i.e. >= 64B, to form up at least one SIMD round.

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

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

From aph at openjdk.java.net  Tue Apr  6 14:07:26 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 6 Apr 2021 14:07:26 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v5]
In-Reply-To: <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com>
Message-ID: <rqcpOO-iWcmNJ_MQnX-3ZB0q89o5Avx1Iu8WDLOs_lE=.bfed903b-572e-4aff-8430-f5b01302c2b7@github.com>

On Tue, 6 Apr 2021 07:25:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - conflicts resolved
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into aarch64.base64.decode
>  - resovling conflicts
>  - load data with one ldrw, add JMH tests for error inputs
>  - Merge branch 'master' into aarch64.base64.decode
>  - copyright
>  - trivial fixes
>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>  - Merge branch 'master' into aarch64.base64.decode
>  - 8256245: AArch64: Implement Base64 decoding intrinsic

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5800:

> 5798:     __ br(Assembler::LT, Process4B);
> 5799: 
> 5800:     // The 1st character of the input can be illegal if the data is MIME encoded.

Why is this sentence here? It is very misleading.

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

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

From aph at openjdk.java.net  Tue Apr  6 14:07:28 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 6 Apr 2021 14:07:28 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <T7PlCTv8zluDpuWuogYW0PZknpj7HZjzeG8RrblWCes=.edf34990-3533-4f2f-b9aa-7ce571d96c59@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
 <T7PlCTv8zluDpuWuogYW0PZknpj7HZjzeG8RrblWCes=.edf34990-3533-4f2f-b9aa-7ce571d96c59@github.com>
Message-ID: <W232T35L00czxXOLnQkQTlR5dRUh2lJGEMfT9RRoEuM=.500f1793-cc57-4d03-ac4a-0f5c53fac309@github.com>

On Fri, 2 Apr 2021 10:01:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into aarch64.base64.decode
>>  - copyright
>>  - trivial fixes
>>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>>  - Merge branch 'master' into aarch64.base64.decode
>>  - 8256245: AArch64: Implement Base64 decoding intrinsic
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5802:
> 
>> 5800:     // The 1st character of the input can be illegal if the data is MIME encoded.
>> 5801:     // We cannot benefits from SIMD for this case. The max line size of MIME
>> 5802:     // encoding is 76, with the PreProcess80B blob, we actually use no-simd
> 
> "cannot benefit"

OK, so I now understand what is actually going on here, and it has nothing to do with illegal first characters.
The problem is that the maximum block length the decode will be supplied with is 76 bytes, and there isn't enough time for the SIMD to be worthwhile. So the comment should be "In the MIME case, the line length cannot be more than 76 bytes (see RFC 2045.) This is too short a block for SIMD to be worthwhile, so we use non-SIMD here."

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

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

From herrick at openjdk.java.net  Tue Apr  6 14:42:23 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 6 Apr 2021 14:42:23 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers
In-Reply-To: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
Message-ID: <QCsa1caEoTKWcbMckUTUgkZL5x8_fsGjoyE7WJb5PpM=.36a4e787-f87e-4d01-bc54-23396de30dfe@github.com>

On Mon, 5 Apr 2021 19:46:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Use value of `--icon` jpackage CLI option to set icon for exe installers.

Marked as reviewed by herrick (Reviewer).

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

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

From herrick at openjdk.java.net  Tue Apr  6 14:48:37 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 6 Apr 2021 14:48:37 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers
In-Reply-To: <QCsa1caEoTKWcbMckUTUgkZL5x8_fsGjoyE7WJb5PpM=.36a4e787-f87e-4d01-bc54-23396de30dfe@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
 <QCsa1caEoTKWcbMckUTUgkZL5x8_fsGjoyE7WJb5PpM=.36a4e787-f87e-4d01-bc54-23396de30dfe@github.com>
Message-ID: <A749J7GzrFyBQAme0LhtgDzo_L7ftqGsS3nhU3ff4iQ=.97a63b31-8c04-4c77-9085-2b7e2c2fb987@github.com>

On Tue, 6 Apr 2021 14:39:07 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> Use value of `--icon` jpackage CLI option to set icon for exe installers.
>
> Marked as reviewed by herrick (Reviewer).

One question -
ICON is only a valid option for creating app launcher.  If creating an installer using --app-image option it would not be a vlid option.
Does this change imply we should change ValidOptions to change:
         options.put(CLIOptions.ICON.getId(), USE.LAUNCHER);
to
         options.put(CLIOptions.ICON.getId(), USE.ALL);

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Apr  6 15:51:31 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 6 Apr 2021 15:51:31 GMT
Subject: RFR: JDK-8264454 : Jaxp unit test from open jdk needs to be
 improved
In-Reply-To: <hjYWCsb8W14zg-jXGR9J1N6WTh1yJ6HtrfmjqhR_Ogs=.4772f9aa-b5ba-400d-9df8-e484666fea58@github.com>
References: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
 <hjYWCsb8W14zg-jXGR9J1N6WTh1yJ6HtrfmjqhR_Ogs=.4772f9aa-b5ba-400d-9df8-e484666fea58@github.com>
Message-ID: <4op_qg2tPivO0vJTaY_vqtfrx2Cc2tX2SbGfrMg_tCM=.5c5efe5d-b832-4157-90b2-9b3eb8359059@github.com>

On Wed, 31 Mar 2021 04:19:46 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> JDK-8264454 : Jaxp unit test from open jdk needs to be improved
>
> test/jaxp/javax/xml/jaxp/unittest/common/Bug6350682.java line 47:
> 
>> 45:     @Test
>> 46:     public void testSAXParserFactory() {
>> 47:         runWithAllPerm(() -> Thread.currentThread().setContextClassLoader(null));
> 
> To address item 4 (the environment is changed), a note, something like "this test runs in othervm" can be added here or to the summary.

Added the comment

> test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6937964Test.java line 204:
> 
>> 202: 
>> 203:                 // does it have the right value?
>> 204:                 if (!expectedLex.equals(duration.toString())) {
> 
> Can be changed to assertEquals

done

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Apr  6 16:40:27 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 6 Apr 2021 16:40:27 GMT
Subject: RFR: JDK-8264454 : Jaxp unit test from open jdk needs to be
 improved
In-Reply-To: <hjYWCsb8W14zg-jXGR9J1N6WTh1yJ6HtrfmjqhR_Ogs=.4772f9aa-b5ba-400d-9df8-e484666fea58@github.com>
References: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
 <hjYWCsb8W14zg-jXGR9J1N6WTh1yJ6HtrfmjqhR_Ogs=.4772f9aa-b5ba-400d-9df8-e484666fea58@github.com>
Message-ID: <rY4WE_9uG8K67mI_BZwNVcYEyAjppfPwtTYMxhqBoe8=.97e0c457-adfc-4391-8ed1-1473215aef18@github.com>

On Wed, 31 Mar 2021 05:04:31 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> JDK-8264454 : Jaxp unit test from open jdk needs to be improved
>
> test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6937964Test.java line 200:
> 
>> 198:                 } catch (IllegalStateException illegalStateException) {
>> 199:                     // TODO; this test really should pass
>> 200:                     System.err.println("Please fix this bug that is being ignored, for now: " + illegalStateException.getMessage());
> 
> Do we still have such a bug?

Yes, test is still trowing IllegalStateException.

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

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

From jlaskey at openjdk.java.net  Tue Apr  6 16:40:53 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 6 Apr 2021 16:40:53 GMT
Subject: RFR: 8264791: java/util/Random/RandomTestBsi1999.java failed
 "java.security.SecureRandom nextFloat consecutive"
Message-ID: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>

SecureRandom is stochastic and will become unpredictable over time (hence the intermittent nature.

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

Commit messages:
 - 8264791: java/util/Random/RandomTestBsi1999.java failed "java.security.SecureRandom nextFloat consecutive"

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

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

From jlaskey at openjdk.java.net  Tue Apr  6 16:46:06 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 6 Apr 2021 16:46:06 GMT
Subject: RFR: 8264791: java/util/Random/RandomTestBsi1999.java failed
 "java.security.SecureRandom nextFloat consecutive" [v2]
In-Reply-To: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
References: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
Message-ID: <vZYWYtS1d0_3WPtO9c2qz3fxlkn4GoRpkMXEmjQ97BQ=.39d6d005-c435-4b7a-bd78-00eacaf4223b@github.com>

> SecureRandom is stochastic and will become unpredictable over time (hence the intermittent nature.

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

  Add bug number

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3359/files
  - new: https://git.openjdk.java.net/jdk/pull/3359/files/94d04892..5f39180e

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

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Apr  6 16:47:02 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 6 Apr 2021 16:47:02 GMT
Subject: RFR: JDK-8264454 : Jaxp unit test from open jdk needs to be
 improved [v2]
In-Reply-To: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
References: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
Message-ID: <cO8gRIaLlyHrjyzUoV-sd8M0_qWm-BZu5ECzLzrg9bY=.09f8f080-09f6-4301-a16d-0e450c9d2466@github.com>

> JDK-8264454 : Jaxp unit test from open jdk needs to be improved

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

  Implemented the review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3274/files
  - new: https://git.openjdk.java.net/jdk/pull/3274/files/2775a644..3f258897

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

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Apr  6 16:53:03 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 6 Apr 2021 16:53:03 GMT
Subject: RFR: JDK-8264454 : Jaxp unit test from open jdk needs to be
 improved [v3]
In-Reply-To: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
References: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
Message-ID: <OQ4YPUa1sCmcuRu89j8Iifln8da5QhJwQIOtuXBJrAY=.8d4dcf50-d90e-421e-83e1-7aee3db5e570@github.com>

> JDK-8264454 : Jaxp unit test from open jdk needs to be improved

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

  Updated copyright year.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3274/files
  - new: https://git.openjdk.java.net/jdk/pull/3274/files/3f258897..002bdffc

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

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

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

From peter.levart at gmail.com  Tue Apr  6 16:53:59 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 6 Apr 2021 18:53:59 +0200
Subject: Garbage Free Check
In-Reply-To: <3928DCCA-DDB1-4217-B4EE-08DC11158B60@dslextreme.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
 <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>
 <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>
 <3928DCCA-DDB1-4217-B4EE-08DC11158B60@dslextreme.com>
Message-ID: <04020c3c-f56d-8488-cd14-0e3b80f124f3@gmail.com>

Hi Ralph,


Which version of JDK did you try running the code. I tried the following 
benchmark:


@BenchmarkMode(Mode.AverageTime)
@Fork(value = 1)
@Warmup(iterations = 5, time = 1)
@Measurement(iterations = 10, time = 1)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class InstantBench {

 ??? @Benchmark
 ??? public long epochMilli() {
 ??????? Instant instant = Clock.systemUTC().instant();
 ??????? return instant.toEpochMilli();
 ??? }
}


And didn't get any heap allocation on either JDK 11:


Benchmark Mode? Cnt?? Score??? Error?? Units
InstantBench.epochMilli????????????????????? avgt?? 10? 34.722 ?? 
0.328?? ns/op
InstantBench.epochMilli:?gc.alloc.rate?????? avgt?? 10? ? 10???????????? 
MB/sec
InstantBench.epochMilli:?gc.alloc.rate.norm? avgt?? 10? ? 
10?????????????? B/op
InstantBench.epochMilli:?gc.count??????????? avgt?? 10???? ? 0?????????? 
counts


..nor on JDK 16:


Benchmark Mode? Cnt?? Score??? Error?? Units
InstantBench.epochMilli????????????????????? avgt?? 10? 33.612 ?? 
0.258?? ns/op
InstantBench.epochMilli:?gc.alloc.rate?????? avgt?? 10? ? 10???????????? 
MB/sec
InstantBench.epochMilli:?gc.alloc.rate.norm? avgt?? 10? ? 
10?????????????? B/op
InstantBench.epochMilli:?gc.count??????????? avgt?? 10???? ? 0?????????? 
counts


Regards, Peter

On 4/6/21 8:17 AM, Ralph Goers wrote:
> Yes, I am aware that the Instant is constructed from the two values. That is exactly why I was hoping I could pass in an object where the values of those two fields could be injected. This would still allow Instant to be immutable but allow Log4j to update one of the pre-existing Clock instances it is managing. That would require that a new Interface be defined with the two set methods and a new static method in the Clock class.
>
> Getting the value in microseconds would probably be a middle ground that could also work considering that is the best resolution available on most hardware today.
>
> Whichever is implemented I suspect getting it back ported to Java 11 is unlikely? According to the surveys I?ve seen the majority of users are still on Java 8. Given that, I?d be surprised if there is a mad rush to adopt Java 17 very soon. Given where things are I?m not even sure how likely it is this could make it in for Java 17.  The irony here is that the folks who need to run garbage free are also the ones most likely to need a Clock with higher resolution. Right now they can?t have both.
>
> Ralph
>
>> On Apr 5, 2021, at 1:26 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>
>> Hi,
>>
>> Java does not have a data type with enough resolution to hold a full nanosecond value.
>> Hence the implementation of Instant holding seconds and nanos.
>>
>> There is an long dormant enhancement request to return micro-seconds as a long.
>> 8196003 <https://bugs.openjdk.java.net/browse/JDK-8196003> java.time Instant and Duration methods for microseconds
>>
>> That might be useful if the application gets enough resolution from microseconds.
>> There might be some clever interpolation between System.currentTimeMillis()
>> and adjusting with System.nanoTime().
>> Though it would likely not be exactly synchronized with the values from Instant.
>>
>> Regards, Roger
>>
>>
>> On 4/5/21 3:56 PM, Brian Goetz wrote:
>>> Project Valhalla will allow Instant to be migrated to a primitive class, which would address your problem.
>>>
>>> On 4/2/2021 7:47 PM, Ralph Goers wrote:
>>>> Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.
>>>>
>>>> The code we have simply does
>>>>
>>>> public void init(MutableInstant mutableInstant) {
>>>>       Instant instant = java.time.Clock.systemUTC().instant();
>>>> mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
>>>> }
>>>> In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
>>>> Ideally we would really like something like
>>>>
>>>> public void init(MutableInstant mutableInstant) {
>>>>          java.time.Clock.systemUTC().initInstant(mutableInstant);
>>>> }
>>>>
>>>> where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.
>>>>
>>>> This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.
>>>>
>>>> Do you know of another way to do this? Am I missing something?
>>>>
>>>> Ralph
>>
>

From bpb at openjdk.java.net  Tue Apr  6 16:54:31 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 6 Apr 2021 16:54:31 GMT
Subject: RFR: 8264791: java/util/Random/RandomTestBsi1999.java failed
 "java.security.SecureRandom nextFloat consecutive" [v2]
In-Reply-To: <vZYWYtS1d0_3WPtO9c2qz3fxlkn4GoRpkMXEmjQ97BQ=.39d6d005-c435-4b7a-bd78-00eacaf4223b@github.com>
References: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
 <vZYWYtS1d0_3WPtO9c2qz3fxlkn4GoRpkMXEmjQ97BQ=.39d6d005-c435-4b7a-bd78-00eacaf4223b@github.com>
Message-ID: <POvUXOD3YNCLruxsmcilh5nRvy5XbWFn_djgM2IwSOE=.781f46cb-1263-4ab3-9f5f-eb3c7579d399@github.com>

On Tue, 6 Apr 2021 16:46:06 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> SecureRandom is stochastic and will become unpredictable over time (hence the intermittent nature).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug number

Marked as reviewed by bpb (Reviewer).

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

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

From darcy at openjdk.java.net  Tue Apr  6 16:54:30 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 6 Apr 2021 16:54:30 GMT
Subject: RFR: 8264791: java/util/Random/RandomTestBsi1999.java failed
 "java.security.SecureRandom nextFloat consecutive" [v2]
In-Reply-To: <vZYWYtS1d0_3WPtO9c2qz3fxlkn4GoRpkMXEmjQ97BQ=.39d6d005-c435-4b7a-bd78-00eacaf4223b@github.com>
References: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
 <vZYWYtS1d0_3WPtO9c2qz3fxlkn4GoRpkMXEmjQ97BQ=.39d6d005-c435-4b7a-bd78-00eacaf4223b@github.com>
Message-ID: <w6qZuyuvsZKn-OBew6P5bD3uP-_mwG4OhV_k6OKBEY8=.2495bd60-9bb7-444c-b75f-576261676416@github.com>

On Tue, 6 Apr 2021 16:46:06 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> SecureRandom is stochastic and will become unpredictable over time (hence the intermittent nature).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug number

Marked as reviewed by darcy (Reviewer).

test/jdk/java/util/Random/RandomTestBsi1999.java line 442:

> 440:             setRNG(factory.name());
> 441: 
> 442:             if (factory.name().equals("Random")) {

A string-switch on the currentRNG name might be better structured here.

test/jdk/java/util/Random/RandomTestBsi1999.java line 443:

> 441: 
> 442:             if (currentRNG.equals("SecureRandom")) {
> 443:                 // Bug: 8264791

It is generally not necessary to include bug ids in the text of changesets.

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

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

From dcubed at openjdk.java.net  Tue Apr  6 16:54:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 6 Apr 2021 16:54:31 GMT
Subject: RFR: 8264791: java/util/Random/RandomTestBsi1999.java failed
 "java.security.SecureRandom nextFloat consecutive" [v2]
In-Reply-To: <vZYWYtS1d0_3WPtO9c2qz3fxlkn4GoRpkMXEmjQ97BQ=.39d6d005-c435-4b7a-bd78-00eacaf4223b@github.com>
References: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
 <vZYWYtS1d0_3WPtO9c2qz3fxlkn4GoRpkMXEmjQ97BQ=.39d6d005-c435-4b7a-bd78-00eacaf4223b@github.com>
Message-ID: <QJAA3S9UMT--IbtFtAaud4M4Lu4705riBR_FZ4FEOUI=.51c4ec4a-f995-48cc-9eb7-b242d38a50a0@github.com>

On Tue, 6 Apr 2021 16:46:06 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> SecureRandom is stochastic and will become unpredictable over time (hence the intermittent nature).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug number

Marked as reviewed by dcubed (Reviewer).

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

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

From dcubed at openjdk.java.net  Tue Apr  6 16:54:32 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 6 Apr 2021 16:54:32 GMT
Subject: RFR: 8264791: java/util/Random/RandomTestBsi1999.java failed
 "java.security.SecureRandom nextFloat consecutive" [v2]
In-Reply-To: <w6qZuyuvsZKn-OBew6P5bD3uP-_mwG4OhV_k6OKBEY8=.2495bd60-9bb7-444c-b75f-576261676416@github.com>
References: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
 <vZYWYtS1d0_3WPtO9c2qz3fxlkn4GoRpkMXEmjQ97BQ=.39d6d005-c435-4b7a-bd78-00eacaf4223b@github.com>
 <w6qZuyuvsZKn-OBew6P5bD3uP-_mwG4OhV_k6OKBEY8=.2495bd60-9bb7-444c-b75f-576261676416@github.com>
Message-ID: <JsZciUMvLtwBPIhk02QwpzAlWSiKm6HRCYtsDCDRV7k=.f864df9f-a076-4678-aa6e-1c369cfbcad4@github.com>

On Tue, 6 Apr 2021 16:45:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add bug number
>
> test/jdk/java/util/Random/RandomTestBsi1999.java line 443:
> 
>> 441: 
>> 442:             if (currentRNG.equals("SecureRandom")) {
>> 443:                 // Bug: 8264791
> 
> It is generally not necessary to include bug ids in the text of changesets.

Should you add an "@bug 8264791" in the header instead?

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

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

From jlaskey at openjdk.java.net  Tue Apr  6 17:02:59 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 6 Apr 2021 17:02:59 GMT
Subject: RFR: 8264791: java/util/Random/RandomTestBsi1999.java failed
 "java.security.SecureRandom nextFloat consecutive" [v3]
In-Reply-To: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
References: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
Message-ID: <O6Ng9wzjhf-rHa_8obUDWQV5Syb0hCp7W6Y4BlQrNYM=.f3b70230-46a2-4e1f-8a35-9d9271580b0a@github.com>

> SecureRandom is stochastic and will become unpredictable over time (hence the intermittent nature).

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

  Remove bug number

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3359/files
  - new: https://git.openjdk.java.net/jdk/pull/3359/files/5f39180e..6e3f3055

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

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

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

From jlaskey at openjdk.java.net  Tue Apr  6 17:09:34 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 6 Apr 2021 17:09:34 GMT
Subject: Integrated: 8264791: java/util/Random/RandomTestBsi1999.java failed
 "java.security.SecureRandom nextFloat consecutive"
In-Reply-To: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
References: <j5_w3z_-Qv6oMvxJ1iU_g0HTnCVC14CWHxCT2k4i9RE=.5ea23dc8-908b-45c4-86c8-95c3cabce8dc@github.com>
Message-ID: <PVj0q9Vt54Bq-w36jxiAFBXtCCVHNaRjHPlybTk0MV4=.c044c3a4-993f-4549-be79-ad0fbe0f59ef@github.com>

On Tue, 6 Apr 2021 16:33:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> SecureRandom is stochastic and will become unpredictable over time (hence the intermittent nature).

This pull request has now been integrated.

Changeset: 0f13e227
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0f13e227
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8264791: java/util/Random/RandomTestBsi1999.java failed "java.security.SecureRandom nextFloat consecutive"

Reviewed-by: darcy, bpb, dcubed

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

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

From asemenyuk at openjdk.java.net  Tue Apr  6 17:14:39 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 6 Apr 2021 17:14:39 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers
In-Reply-To: <A749J7GzrFyBQAme0LhtgDzo_L7ftqGsS3nhU3ff4iQ=.97a63b31-8c04-4c77-9085-2b7e2c2fb987@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
 <QCsa1caEoTKWcbMckUTUgkZL5x8_fsGjoyE7WJb5PpM=.36a4e787-f87e-4d01-bc54-23396de30dfe@github.com>
 <A749J7GzrFyBQAme0LhtgDzo_L7ftqGsS3nhU3ff4iQ=.97a63b31-8c04-4c77-9085-2b7e2c2fb987@github.com>
Message-ID: <e2VBtwwTzLSd82mSDPHTcUm18gyyMN5aF68zshEKhQ0=.cc771a35-ca32-422b-81ce-67638a3fb395@github.com>

On Tue, 6 Apr 2021 14:45:26 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> Marked as reviewed by herrick (Reviewer).
>
> One question -
> ICON is only a valid option for creating app launcher.  If creating an installer using --app-image option it would not be a vlid option.
> Does this change imply we should change ValidOptions to change:
>          options.put(CLIOptions.ICON.getId(), USE.LAUNCHER);
> to
>          options.put(CLIOptions.ICON.getId(), USE.ALL);

Good point! I'll add corresponding test case and update ValidOptions accordingly.

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

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

From asemenyuk at openjdk.java.net  Tue Apr  6 18:01:02 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 6 Apr 2021 18:01:02 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers [v2]
In-Reply-To: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
Message-ID: <zAmNPkcCBduhh36Jk6wl3CeGWAor6x8fwfmZaAJCW1Y=.73b847ae-4d8f-4580-a1f5-d578eaa15d37@github.com>

> Use value of `--icon` jpackage CLI option to set icon for exe installers.

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

  Make --icon option applicable in installer mode

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3347/files
  - new: https://git.openjdk.java.net/jdk/pull/3347/files/e88a1816..36ec66de

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

  Stats: 36 lines in 5 files changed: 21 ins; 11 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3347.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3347/head:pull/3347

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

From herrick at openjdk.java.net  Tue Apr  6 18:11:33 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 6 Apr 2021 18:11:33 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers [v2]
In-Reply-To: <zAmNPkcCBduhh36Jk6wl3CeGWAor6x8fwfmZaAJCW1Y=.73b847ae-4d8f-4580-a1f5-d578eaa15d37@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
 <zAmNPkcCBduhh36Jk6wl3CeGWAor6x8fwfmZaAJCW1Y=.73b847ae-4d8f-4580-a1f5-d578eaa15d37@github.com>
Message-ID: <__mlXt7etOcrwoS65ndzu96xJKnmLhRWoLHoZ3Qn5KI=.7ab937fa-b7b0-472b-aa15-9f5be8f878ca@github.com>

On Tue, 6 Apr 2021 18:01:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Use value of `--icon` jpackage CLI option to set icon for exe installers.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make --icon option applicable in installer mode

Marked as reviewed by herrick (Reviewer).

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

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

From headius at headius.com  Tue Apr  6 19:30:30 2021
From: headius at headius.com (Charles Oliver Nutter)
Date: Tue, 6 Apr 2021 14:30:30 -0500
Subject: Why doesn't Channels.newChannel(OutputStream) flush?
Message-ID: <CAE-f1xQbb4a1W6vyTcQ-9mLy9Hf0+XdNvVbohvsdbQPke-b7bw@mail.gmail.com>

While debugging some subprocess logic in JRuby today I came to the
realization that the WritableByteChannel returned by
Channels.newChannel(OutputStream) is "broken".

https://github.com/jruby/jruby/pull/6649/commits/5a6912caf3adb70fb4c210c73ae02fbf16f404d9

The issue arises when the provided stream is itself buffered, as is
the case for Process.getOutputStream. Because neither Channel nor
WritableByteChannel provide a way to flush (as Channels are expected
to be "raw" unbuffered IO), data written to the wrapper will not
propagate to the the other end of the stream until the intermediate
buffer has been filled. A flush can only be performed if you have
direct access to the underlying stream, which is generally impossible
if using this wrapper to interact with a Channel-related API.

I would propose that the default OutputStream Channel wrapper should
flush() after every non-zero write (or potentially after every write,
if the underlying stream is not altogether honest about how many bytes
were written).

Can someone provide a counter example for why the wrapper should *not*
flush (current behavior)? What would be harmed by making this change?
I can come up with nothing.

 Additional reasons to flush:

* Early propagation of IO errors due to the underlying stream no
longer being flushable.
* More responsive, possibly reducing IO stutter for APIs using the wrapper.

That first one could be seen as a negative but I can only see it as a
positive (raise the error at the time of the bad write, not once the
buffer is filled many writes later).

- Charlie

From brian.burkhalter at oracle.com  Tue Apr  6 20:38:24 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 6 Apr 2021 20:38:24 +0000
Subject: Why doesn't Channels.newChannel(OutputStream) flush?
In-Reply-To: <CAE-f1xQbb4a1W6vyTcQ-9mLy9Hf0+XdNvVbohvsdbQPke-b7bw@mail.gmail.com>
References: <CAE-f1xQbb4a1W6vyTcQ-9mLy9Hf0+XdNvVbohvsdbQPke-b7bw@mail.gmail.com>
Message-ID: <4DE1EA44-925D-4A2D-A1E5-EF98993C1E2F@oracle.com>

Hello,

This does not sound unreasonable to me, although I do not know the historical context of the design decisions involved, on which I expect that Alan Bateman will comment tomorrow.

As to the implementation, it might be just to modify java.nio.channels.Channels$WritableByteChannelImpl.write() to flush the wrapped stream in the sync block after the write loop.

Brian

On Apr 6, 2021, at 12:30 PM, Charles Oliver Nutter <headius at headius.com<mailto:headius at headius.com>> wrote:

While debugging some subprocess logic in JRuby today I came to the
realization that the WritableByteChannel returned by
Channels.newChannel(OutputStream) is "broken".

https://github.com/jruby/jruby/pull/6649/commits/5a6912caf3adb70fb4c210c73ae02fbf16f404d9

The issue arises when the provided stream is itself buffered, as is
the case for Process.getOutputStream. Because neither Channel nor
WritableByteChannel provide a way to flush (as Channels are expected
to be "raw" unbuffered IO), data written to the wrapper will not
propagate to the the other end of the stream until the intermediate
buffer has been filled. A flush can only be performed if you have
direct access to the underlying stream, which is generally impossible
if using this wrapper to interact with a Channel-related API.

I would propose that the default OutputStream Channel wrapper should
flush() after every non-zero write (or potentially after every write,
if the underlying stream is not altogether honest about how many bytes
were written).

Can someone provide a counter example for why the wrapper should *not*
flush (current behavior)? What would be harmed by making this change?
I can come up with nothing.

Additional reasons to flush:

* Early propagation of IO errors due to the underlying stream no
longer being flushable.
* More responsive, possibly reducing IO stutter for APIs using the wrapper.

That first one could be seen as a negative but I can only see it as a
positive (raise the error at the time of the bad write, not once the
buffer is filled many writes later).


From igraves at openjdk.java.net  Tue Apr  6 20:42:50 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 6 Apr 2021 20:42:50 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits
Message-ID: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>

This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

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

Commit messages:
 - Fixing rounding issue with BigDecimal and %g formatting flags

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

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

From headius at headius.com  Tue Apr  6 21:05:03 2021
From: headius at headius.com (Charles Oliver Nutter)
Date: Tue, 6 Apr 2021 16:05:03 -0500
Subject: Why doesn't Channels.newChannel(OutputStream) flush?
In-Reply-To: <4DE1EA44-925D-4A2D-A1E5-EF98993C1E2F@oracle.com>
References: <CAE-f1xQbb4a1W6vyTcQ-9mLy9Hf0+XdNvVbohvsdbQPke-b7bw@mail.gmail.com>
 <4DE1EA44-925D-4A2D-A1E5-EF98993C1E2F@oracle.com>
Message-ID: <CAE-f1xQshu4NVVe2aYcqxVcNofaWKawLLQRG3bj7-vN6RQog9A@mail.gmail.com>

I agree, adding a simple flush basically solves this issue. I look
forward to hearing whether there's any good reason not to do so.

On Tue, Apr 6, 2021 at 3:38 PM Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
>
> Hello,
>
> This does not sound unreasonable to me, although I do not know the historical context of the design decisions involved, on which I expect that Alan Bateman will comment tomorrow.
>
> As to the implementation, it might be just to modify java.nio.channels.Channels$WritableByteChannelImpl.write() to flush the wrapped stream in the sync block after the write loop.
>
> Brian
>
> On Apr 6, 2021, at 12:30 PM, Charles Oliver Nutter <headius at headius.com> wrote:
>
> While debugging some subprocess logic in JRuby today I came to the
> realization that the WritableByteChannel returned by
> Channels.newChannel(OutputStream) is "broken".
>
> https://github.com/jruby/jruby/pull/6649/commits/5a6912caf3adb70fb4c210c73ae02fbf16f404d9
>
> The issue arises when the provided stream is itself buffered, as is
> the case for Process.getOutputStream. Because neither Channel nor
> WritableByteChannel provide a way to flush (as Channels are expected
> to be "raw" unbuffered IO), data written to the wrapper will not
> propagate to the the other end of the stream until the intermediate
> buffer has been filled. A flush can only be performed if you have
> direct access to the underlying stream, which is generally impossible
> if using this wrapper to interact with a Channel-related API.
>
> I would propose that the default OutputStream Channel wrapper should
> flush() after every non-zero write (or potentially after every write,
> if the underlying stream is not altogether honest about how many bytes
> were written).
>
> Can someone provide a counter example for why the wrapper should *not*
> flush (current behavior)? What would be harmed by making this change?
> I can come up with nothing.
>
> Additional reasons to flush:
>
> * Early propagation of IO errors due to the underlying stream no
> longer being flushable.
> * More responsive, possibly reducing IO stutter for APIs using the wrapper.
>
> That first one could be seen as a negative but I can only see it as a
> positive (raise the error at the time of the bad write, not once the
> buffer is filled many writes later).
>
>

From ralph.goers at dslextreme.com  Tue Apr  6 22:22:16 2021
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Tue, 6 Apr 2021 15:22:16 -0700
Subject: Garbage Free Check
In-Reply-To: <04020c3c-f56d-8488-cd14-0e3b80f124f3@gmail.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
 <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>
 <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>
 <3928DCCA-DDB1-4217-B4EE-08DC11158B60@dslextreme.com>
 <04020c3c-f56d-8488-cd14-0e3b80f124f3@gmail.com>
Message-ID: <B8B4DEE6-9A90-4574-B466-7267266A64FA@dslextreme.com>

I am using 

openjdk version "11.0.10" 2021-01-19 LTS
OpenJDK Runtime Environment Corretto-11.0.10.9.1 (build 11.0.10+9-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.10.9.1 (build 11.0.10+9-LTS, mixed mode)

Our test uses
<dependency>
  <groupId>com.google.code.java-allocation-instrumenter</groupId>
  <artifactId>java-allocation-instrumenter</artifactId>
  <version>3.3.0</version>
</dependency>
to validate that it is not allocating any objects.

If you want to test it yourself you can do

git clone https://github.com/apache/logging-log4j2.git <https://github.com/apache/logging-log4j2.git>
cd logging-log4j2
mvn -DskipTests=true clean install
cd log4j-core
mvn surefire:test -Dtest=GcFreeSynchronousLoggingTest -Dmaven.surefire.debug="-Dlog4j2.usePreciseClock=true?

When it fails you will see a strange message with 

I just allocated the object 2021-04-06T21:55:20.878377Z of type java/time/Instant whose size is 24 ==> expected: <true> but was: <false>

Ralph

> On Apr 6, 2021, at 9:53 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Ralph,
> 
> 
> Which version of JDK did you try running the code. I tried the following benchmark:
> 
> 
> @BenchmarkMode(Mode.AverageTime)
> @Fork(value = 1)
> @Warmup(iterations = 5, time = 1)
> @Measurement(iterations = 10, time = 1)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @State(Scope.Benchmark)
> public class InstantBench {
> 
>     @Benchmark
>     public long epochMilli() {
>         Instant instant = Clock.systemUTC().instant();
>         return instant.toEpochMilli();
>     }
> }
> 
> 
> And didn't get any heap allocation on either JDK 11:
> 
> 
> Benchmark Mode  Cnt   Score    Error   Units
> InstantBench.epochMilli                      avgt   10  34.722 ?  0.328   ns/op
> InstantBench.epochMilli:?gc.alloc.rate       avgt   10  ? 10??           MB/sec
> InstantBench.epochMilli:?gc.alloc.rate.norm  avgt   10  ? 10??             B/op
> InstantBench.epochMilli:?gc.count            avgt   10     ? 0           counts
> 
> 
> ..nor on JDK 16:
> 
> 
> Benchmark Mode  Cnt   Score    Error   Units
> InstantBench.epochMilli                      avgt   10  33.612 ?  0.258   ns/op
> InstantBench.epochMilli:?gc.alloc.rate       avgt   10  ? 10??           MB/sec
> InstantBench.epochMilli:?gc.alloc.rate.norm  avgt   10  ? 10??             B/op
> InstantBench.epochMilli:?gc.count            avgt   10     ? 0           counts
> 
> 
> Regards, Peter
> 
> On 4/6/21 8:17 AM, Ralph Goers wrote:
>> Yes, I am aware that the Instant is constructed from the two values. That is exactly why I was hoping I could pass in an object where the values of those two fields could be injected. This would still allow Instant to be immutable but allow Log4j to update one of the pre-existing Clock instances it is managing. That would require that a new Interface be defined with the two set methods and a new static method in the Clock class.
>> 
>> Getting the value in microseconds would probably be a middle ground that could also work considering that is the best resolution available on most hardware today.
>> 
>> Whichever is implemented I suspect getting it back ported to Java 11 is unlikely? According to the surveys I?ve seen the majority of users are still on Java 8. Given that, I?d be surprised if there is a mad rush to adopt Java 17 very soon. Given where things are I?m not even sure how likely it is this could make it in for Java 17.  The irony here is that the folks who need to run garbage free are also the ones most likely to need a Clock with higher resolution. Right now they can?t have both.
>> 
>> Ralph
>> 
>>> On Apr 5, 2021, at 1:26 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Java does not have a data type with enough resolution to hold a full nanosecond value.
>>> Hence the implementation of Instant holding seconds and nanos.
>>> 
>>> There is an long dormant enhancement request to return micro-seconds as a long.
>>> 8196003 <https://bugs.openjdk.java.net/browse/JDK-8196003> java.time Instant and Duration methods for microseconds
>>> 
>>> That might be useful if the application gets enough resolution from microseconds.
>>> There might be some clever interpolation between System.currentTimeMillis()
>>> and adjusting with System.nanoTime().
>>> Though it would likely not be exactly synchronized with the values from Instant.
>>> 
>>> Regards, Roger
>>> 
>>> 
>>> On 4/5/21 3:56 PM, Brian Goetz wrote:
>>>> Project Valhalla will allow Instant to be migrated to a primitive class, which would address your problem.
>>>> 
>>>> On 4/2/2021 7:47 PM, Ralph Goers wrote:
>>>>> Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.
>>>>> 
>>>>> The code we have simply does
>>>>> 
>>>>> public void init(MutableInstant mutableInstant) {
>>>>>      Instant instant = java.time.Clock.systemUTC().instant();
>>>>> mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
>>>>> }
>>>>> In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
>>>>> Ideally we would really like something like
>>>>> 
>>>>> public void init(MutableInstant mutableInstant) {
>>>>>         java.time.Clock.systemUTC().initInstant(mutableInstant);
>>>>> }
>>>>> 
>>>>> where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.
>>>>> 
>>>>> This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.
>>>>> 
>>>>> Do you know of another way to do this? Am I missing something?
>>>>> 
>>>>> Ralph
>>> 
>> 
> 


From raffaello.giulietti at gmail.com  Tue Apr  6 22:40:40 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 7 Apr 2021 00:40:40 +0200
Subject: Faster double parser?
Message-ID: <db685deb-565e-e16d-da00-4f3923851647@gmail.com>

Hi,

if there's revived interest I would be glad to migrate the code to 
Skara/GitHub for a PR. The last uploaded version is still on Mercurial, 
I assume, under Brian Burkhalter's webrev folder.

But I'd also like to point out that there is a pending CSR as well.

(Sorry for the initiator of this thread: you're speaking about a parser, 
we about the opposite.)


Greetings
Raffaello



> The mailing list mangled formatting. My comments are prefixed below by ?->?.
> 
> On Apr 5, 2021, at 9:52 AM, Brian Burkhalter <brian.burkhalter at oracle.com<mailto:brian.burkhalter at oracle.com>> wrote:
> 
> On Apr 5, 2021, at 4:11 AM, Andrew Haley <aph at redhat.com<mailto:aph at redhat.com><mailto:aph at redhat.com>> wrote:
> 
> On 4/5/21 9:08 AM, Alan Bateman wrote:
> On 04/04/2021 09:53, Andrew Haley wrote:
> :
> We also have a candidate for a String -> toDouble parser from Raffaello
> Giulietti:
> 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
> 
> As far as I can see there's nothing wrong with it, but it got stuck in
> review. This was a bad failure of our review processes, I'm afraid. I
> wonder if we will do any better with this one.
> 
> Yeah, there was a lengthy discussion about this at the OpenJDK Committer
> Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
> both put time into looking at the proposal it but the conclusion was
> that Raffaello's paper "The Schubfach way to render doubles" needed a
> review from from an expert in this area.
> 
> -> I spent some time on it a while back but got bogged down.
> 
> I wonder. The implementation has even been proved correct for floats by
> exhaustion. (Of course that's not possible for doubles.)
> 
> -> I exhaustively verified it for floats. I also ran round-trip tests for doubles which ran for days without error. Of course one can only disprove by counterexample, not prove by anecdote.
> 
> I submit, therefore, that we could at least use the float version without
> reasonable fear of breaking something.
> 
> -> That is a good suggestion.
> 
> We seem to be paralysed by this one.
> 
> Guy Steele was mentioned but I don't know if he was approached about it.
> 
> -> Indirectly.
> 
> -> Another aspect which was raised was supportability: is it sufficiently understood for us to support? On that note I would ask ?Is FloatingDecimal sufficiently understood to support?? I think the answer to both questions is the same.


From brian.burkhalter at oracle.com  Tue Apr  6 22:44:31 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 6 Apr 2021 22:44:31 +0000
Subject: Faster double parser?
In-Reply-To: <db685deb-565e-e16d-da00-4f3923851647@gmail.com>
References: <db685deb-565e-e16d-da00-4f3923851647@gmail.com>
Message-ID: <60A14336-E4A9-440C-96F0-EA47EB34FD7C@oracle.com>


On Apr 6, 2021, at 3:40 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com<mailto:raffaello.giulietti at gmail.com>> wrote:

if there's revived interest I would be glad to migrate the code to Skara/GitHub for a PR. The last uploaded version is still on Mercurial, I assume, under Brian Burkhalter's webrev folder.

Is the Hg version current?

http://cr.openjdk.java.net/~bpb/4511638/webrev.04/

Converting the patch to Git is straightforward.

But I'd also like to point out that there is a pending CSR as well.

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

Thanks,

Brian

From darcy at openjdk.java.net  Tue Apr  6 22:59:31 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 6 Apr 2021 22:59:31 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits
In-Reply-To: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
Message-ID: <GuVfVyp43DBMH5Bx36KivqlL02tdk0JqzMIOJKADHDg=.932a5542-321e-4680-88e8-a73f4c53e11b@github.com>

On Tue, 6 Apr 2021 20:34:52 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

test/jdk/java/util/Formatter/BigDecimalRounding.java line 44:

> 42:     public static void testBigDecimalRounding() {
> 43:         var res1 = String.format("%g", 0.00009999999999999995);
> 44:         var res2 = String.format("%g", 0.00009999999f);

To avoid possible vagaries in decimal -> binary conversion of double values, I suggest also testing against a BigDecimal directly rounded to the precision in question.

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

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

From raffaello.giulietti at gmail.com  Tue Apr  6 23:41:07 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 7 Apr 2021 01:41:07 +0200
Subject: Faster double parser?
In-Reply-To: <60A14336-E4A9-440C-96F0-EA47EB34FD7C@oracle.com>
References: <db685deb-565e-e16d-da00-4f3923851647@gmail.com>
 <60A14336-E4A9-440C-96F0-EA47EB34FD7C@oracle.com>
Message-ID: <7d7a33f8-e6a7-2eb1-e681-688927093382@gmail.com>

Hi,

yes, the code in itself is current.

I would need to adapt it to OpenJDK coding conventions; in particular 
the form of multiline comments is not the usual one. Only cosmetic 
changes, though. Nothing would affect the executable code.

Also, the current patch modifies some existing files, so I need to check 
that nothing has changed in the meantime.

I'll prepare a PR in the next couple of days.




On 2021-04-07 00:44, Brian Burkhalter wrote:
> 
>> On Apr 6, 2021, at 3:40 PM, Raffaello Giulietti 
>> <raffaello.giulietti at gmail.com <mailto:raffaello.giulietti at gmail.com>> 
>> wrote:
>>
>> if there's revived interest I would be glad to migrate the code to 
>> Skara/GitHub for a PR. The last uploaded version is still on 
>> Mercurial, I assume, under Brian Burkhalter's webrev folder.
> 
> Is the Hg version current?
> 
> http://cr.openjdk.java.net/~bpb/4511638/webrev.04/ 
> <http://cr.openjdk.java.net/~bpb/4511638/webrev.04/>
> 
> Converting the patch to Git is straightforward.
> 
>> But I'd also like to point out that there is a pending CSR as well.
> 
> https://bugs.openjdk.java.net/browse/JDK-8202555 
> <https://bugs.openjdk.java.net/browse/JDK-8202555>
> 
> Thanks,
> 
> Brian

From asemenyuk at openjdk.java.net  Wed Apr  7 00:22:14 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 7 Apr 2021 00:22:14 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers [v3]
In-Reply-To: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
Message-ID: <XmZfOOhVpDGC-2bsIpOrtYNWV51Vp2gMy2nWyYibFX8=.2148e520-fc15-4a4c-9025-ff0714d92f75@github.com>

> Use value of `--icon` jpackage CLI option to set icon for exe installers.

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

  Fix AppImagePackageTest.testEmpty(true) failure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3347/files
  - new: https://git.openjdk.java.net/jdk/pull/3347/files/36ec66de..d05753c2

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

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

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

From herrick at openjdk.java.net  Wed Apr  7 00:29:28 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 7 Apr 2021 00:29:28 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers [v3]
In-Reply-To: <XmZfOOhVpDGC-2bsIpOrtYNWV51Vp2gMy2nWyYibFX8=.2148e520-fc15-4a4c-9025-ff0714d92f75@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
 <XmZfOOhVpDGC-2bsIpOrtYNWV51Vp2gMy2nWyYibFX8=.2148e520-fc15-4a4c-9025-ff0714d92f75@github.com>
Message-ID: <C5AqsHR9X8AprF3JBPVg7H31-mGURnxU_Igq8ouJ7g4=.476b2c69-3cbc-4773-8380-9faf8bf02a15@github.com>

On Wed, 7 Apr 2021 00:22:14 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Use value of `--icon` jpackage CLI option to set icon for exe installers.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix AppImagePackageTest.testEmpty(true) failure

Marked as reviewed by herrick (Reviewer).

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

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

From almatvee at openjdk.java.net  Wed Apr  7 00:50:29 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 7 Apr 2021 00:50:29 GMT
Subject: RFR: 8236127: Use value of --icon CLI option to set icon for exe
 installers [v3]
In-Reply-To: <XmZfOOhVpDGC-2bsIpOrtYNWV51Vp2gMy2nWyYibFX8=.2148e520-fc15-4a4c-9025-ff0714d92f75@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
 <XmZfOOhVpDGC-2bsIpOrtYNWV51Vp2gMy2nWyYibFX8=.2148e520-fc15-4a4c-9025-ff0714d92f75@github.com>
Message-ID: <GS5dRBdSjz-k2bui7q2OzBMcNN365VNh2co2GpNIS-c=.3a00aa2d-ffac-4500-bf67-6ac9ba665b61@github.com>

On Wed, 7 Apr 2021 00:22:14 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Use value of `--icon` jpackage CLI option to set icon for exe installers.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix AppImagePackageTest.testEmpty(true) failure

Marked as reviewed by almatvee (Committer).

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

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

From ysuenaga at openjdk.java.net  Wed Apr  7 01:18:43 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 7 Apr 2021 01:18:43 GMT
Subject: RFR: 8264551: Unexpected warning when jpackage creates an exe
Message-ID: <iHhI4gRqU47IB0pL8E7cMIEZyuBAsKYwZyHwZ_jjOF8=.1ebeaa7f-cedf-4708-8028-ac9dcd253067@github.com>

Since fix to [JDK-8263135](https://bugs.openjdk.java.net/browse/JDK-8263135), we've seen following warning message on the console when we run jpackage to create exe.

WARNING: MsiCloseHandle(3174034504) failed with error=6 

It is caused by lack of initializer in `DatabaseRecord(DatabaseView& view)`. We need to add it.

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

Commit messages:
 - Add initializer to DatabaseRecord(DatabaseView& view)

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

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

From igraves at openjdk.java.net  Wed Apr  7 02:48:00 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 7 Apr 2021 02:48:00 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits [v2]
In-Reply-To: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
Message-ID: <O2mswzonqSXwR182cYYrlA7-lRwGnOCUav_bpVD5EjE=.4f6b2e1c-8fdc-4455-b561-1892804e1788@github.com>

> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

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

  Adding BigDecimal equivalents to tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3363/files
  - new: https://git.openjdk.java.net/jdk/pull/3363/files/8ec00f8f..cf40421e

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

  Stats: 10 lines in 1 file changed: 5 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3363.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3363/head:pull/3363

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

From igraves at openjdk.java.net  Wed Apr  7 03:00:36 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 7 Apr 2021 03:00:36 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits [v2]
In-Reply-To: <GuVfVyp43DBMH5Bx36KivqlL02tdk0JqzMIOJKADHDg=.932a5542-321e-4680-88e8-a73f4c53e11b@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <GuVfVyp43DBMH5Bx36KivqlL02tdk0JqzMIOJKADHDg=.932a5542-321e-4680-88e8-a73f4c53e11b@github.com>
Message-ID: <AJFhToPnN24rgn3sPAq_YDPZgnrAv9CMewdrLnJAxIo=.6bd6010e-3764-48b4-9056-e7194136f2b6@github.com>

On Tue, 6 Apr 2021 22:56:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding BigDecimal equivalents to tests
>
> test/jdk/java/util/Formatter/BigDecimalRounding.java line 44:
> 
>> 42:     public static void testBigDecimalRounding() {
>> 43:         var res1 = String.format("%g", 0.00009999999999999995);
>> 44:         var res2 = String.format("%g", 0.00009999999f);
> 
> To avoid possible vagaries in decimal -> binary conversion of double values, I suggest also testing against a BigDecimal directly rounded to the precision in question.

Good thought, thanks.

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

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

From jiefu at openjdk.java.net  Wed Apr  7 03:42:02 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 7 Apr 2021 03:42:02 GMT
Subject: RFR: 8264809: test-lib fails to build due to some warnings in
 ASN1Formatter and jfr
Message-ID: <dQiWHORvae0jKv8kU3fyVaR6uDh1eN5IVy4kpkkGT0w=.b3e76902-788f-44dd-bd51-bff5553642b3@github.com>

Hi all,

test-lib fails to build due to three javac warnings:

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

Commit messages:
 - 8264809: test-lib fails to build due to some warnings in ASN1Formatter and jfr

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

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

From dongbo at openjdk.java.net  Wed Apr  7 05:51:02 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 7 Apr 2021 05:51:02 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

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

  fix misleading annotations

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3228/files
  - new: https://git.openjdk.java.net/jdk/pull/3228/files/faa830cf..a342ad1e

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

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

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

From dongbo at openjdk.java.net  Wed Apr  7 06:00:45 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 7 Apr 2021 06:00:45 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v5]
In-Reply-To: <rqcpOO-iWcmNJ_MQnX-3ZB0q89o5Avx1Iu8WDLOs_lE=.bfed903b-572e-4aff-8430-f5b01302c2b7@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com>
 <rqcpOO-iWcmNJ_MQnX-3ZB0q89o5Avx1Iu8WDLOs_lE=.bfed903b-572e-4aff-8430-f5b01302c2b7@github.com>
Message-ID: <hghsPRtRB2h-VfnV9nSqXwqW7dQF6RlptS1ctf6I1LA=.4be89867-150b-421a-8fbf-4ec0896a6264@github.com>

On Tue, 6 Apr 2021 14:04:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - conflicts resolved
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into aarch64.base64.decode
>>  - resovling conflicts
>>  - load data with one ldrw, add JMH tests for error inputs
>>  - Merge branch 'master' into aarch64.base64.decode
>>  - copyright
>>  - trivial fixes
>>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>>  - Merge branch 'master' into aarch64.base64.decode
>>  - 8256245: AArch64: Implement Base64 decoding intrinsic
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5800:
> 
>> 5798:     __ br(Assembler::LT, Process4B);
>> 5799: 
>> 5800:     // The 1st character of the input can be illegal if the data is MIME encoded.
> 
> Why is this sentence here? It is very misleading.

This sentence was used to describe the worst case observed frequently so that readers can understand more easily why the pre-processing non-SIMD code is necessary.
I apologize for being unclear and misleading. The annotations have been modified as suggested.

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

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

From aph at openjdk.java.net  Wed Apr  7 09:56:21 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Apr 2021 09:56:21 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6]
In-Reply-To: <sGQjaUtyiB5cDch3o5YGyLnf9lG6YoMrwABun7jgbK4=.a0b249ef-2e79-4b56-8eae-e0e2181bd8ec@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>
 <sGQjaUtyiB5cDch3o5YGyLnf9lG6YoMrwABun7jgbK4=.a0b249ef-2e79-4b56-8eae-e0e2181bd8ec@github.com>
Message-ID: <uYrE1TBlkMS4Jlz36xe0CX_v9iucRqkHCM_Sc5F2gnA=.4a85979d-9e73-4a83-981c-ee47faf051ce@github.com>

On Wed, 7 Apr 2021 09:50:45 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix misleading annotations
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5829:
> 
>> 5827:     __ strb(r14, __ post(dst, 1));
>> 5828:     __ strb(r15, __ post(dst, 1));
>> 5829:     __ strb(r13, __ post(dst, 1));
> 
> I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think.

Sorry, that's not quite right, but you get the idea: let's not generate unnecessary memory traffic.

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

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

From aph at openjdk.java.net  Wed Apr  7 09:56:20 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Apr 2021 09:56:20 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6]
In-Reply-To: <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>
Message-ID: <sGQjaUtyiB5cDch3o5YGyLnf9lG6YoMrwABun7jgbK4=.a0b249ef-2e79-4b56-8eae-e0e2181bd8ec@github.com>

On Wed, 7 Apr 2021 05:51:02 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix misleading annotations

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5829:

> 5827:     __ strb(r14, __ post(dst, 1));
> 5828:     __ strb(r15, __ post(dst, 1));
> 5829:     __ strb(r13, __ post(dst, 1));

I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think.

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

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

From Alan.Bateman at oracle.com  Wed Apr  7 11:16:26 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 7 Apr 2021 12:16:26 +0100
Subject: Why doesn't Channels.newChannel(OutputStream) flush?
In-Reply-To: <CAE-f1xQbb4a1W6vyTcQ-9mLy9Hf0+XdNvVbohvsdbQPke-b7bw@mail.gmail.com>
References: <CAE-f1xQbb4a1W6vyTcQ-9mLy9Hf0+XdNvVbohvsdbQPke-b7bw@mail.gmail.com>
Message-ID: <4b6d73d0-c0d0-09c0-1672-c4008f8c95a8@oracle.com>

On 06/04/2021 20:30, Charles Oliver Nutter wrote:
> While debugging some subprocess logic in JRuby today I came to the
> realization that the WritableByteChannel returned by
> Channels.newChannel(OutputStream) is "broken".
>
> https://github.com/jruby/jruby/pull/6649/commits/5a6912caf3adb70fb4c210c73ae02fbf16f404d9
>
> The issue arises when the provided stream is itself buffered, as is
> the case for Process.getOutputStream. Because neither Channel nor
> WritableByteChannel provide a way to flush (as Channels are expected
> to be "raw" unbuffered IO), data written to the wrapper will not
> propagate to the the other end of the stream until the intermediate
> buffer has been filled. A flush can only be performed if you have
> direct access to the underlying stream, which is generally impossible
> if using this wrapper to interact with a Channel-related API.
>
> I would propose that the default OutputStream Channel wrapper should
> flush() after every non-zero write (or potentially after every write,
> if the underlying stream is not altogether honest about how many bytes
> were written).
Channels.newChannel(OutputStream) dates from Java 1.4 and JSR-51 so I 
don't think we can rush into changing it. If a writable channel is 
created on an buffered stream then it will usually be up to the 
underlying stream as to how much to buffer and when to flush when it 
wraps another stream. So I think it will take a bit of exploration and 
maybe there is a case for an overload that configures when if/when it 
flushes. A PrintStream like autoFlush may or may not be enough.

-Alan.

From rriggs at openjdk.java.net  Wed Apr  7 13:52:35 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Apr 2021 13:52:35 GMT
Subject: RFR: 8264809: test-lib fails to build due to some warnings in
 ASN1Formatter and jfr
In-Reply-To: <dQiWHORvae0jKv8kU3fyVaR6uDh1eN5IVy4kpkkGT0w=.b3e76902-788f-44dd-bd51-bff5553642b3@github.com>
References: <dQiWHORvae0jKv8kU3fyVaR6uDh1eN5IVy4kpkkGT0w=.b3e76902-788f-44dd-bd51-bff5553642b3@github.com>
Message-ID: <eFtO98MK6RW_5CKvWAoQ8CUNj8g6_Otyi6_1fKjWeCw=.1dea018c-1b2d-4e07-8313-faa0ad886ebc@github.com>

On Wed, 7 Apr 2021 03:34:15 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> test-lib fails to build due to three javac warnings:

Looks good.
It seems only the build-test-lib make rule has error on warnings set.
When running the tests, the compiles do not fail. (though the warnings are produced).

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

Marked as reviewed by rriggs (Reviewer).

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

From github.com+70726043+rgiulietti at openjdk.java.net  Wed Apr  7 18:41:04 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 7 Apr 2021 18:41:04 GMT
Subject: RFR: 8264514: HexFormat implementation tweaks [v2]
In-Reply-To: <CmAtdEv07AR4bJ9zJ5aAlkHL4zsmyN58_TFDvnqCNwQ=.89102181-0ae7-4294-82b0-4b87b92c4b68@github.com>
References: <CmAtdEv07AR4bJ9zJ5aAlkHL4zsmyN58_TFDvnqCNwQ=.89102181-0ae7-4294-82b0-4b87b92c4b68@github.com>
Message-ID: <ftqmUYvOcdR69RNhpgdDCZV1IGwq2265E8V0SJGcZ7w=.abcdbce1-8598-4bba-b4e8-f9d7b35037ec@github.com>

> Please review these small tweaks.
> 
> For background information see [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)
> 
> Greetings
> Raffaello

Raffaello Giulietti has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3295/files
  - new: https://git.openjdk.java.net/jdk/pull/3295/files/123f3101..21e7402b

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

  Stats: 67 lines in 1 file changed: 26 ins; 10 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3295.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3295/head:pull/3295

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

From github.com+70726043+rgiulietti at openjdk.java.net  Wed Apr  7 18:41:05 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 7 Apr 2021 18:41:05 GMT
Subject: Withdrawn: 8264514: HexFormat implementation tweaks
In-Reply-To: <CmAtdEv07AR4bJ9zJ5aAlkHL4zsmyN58_TFDvnqCNwQ=.89102181-0ae7-4294-82b0-4b87b92c4b68@github.com>
References: <CmAtdEv07AR4bJ9zJ5aAlkHL4zsmyN58_TFDvnqCNwQ=.89102181-0ae7-4294-82b0-4b87b92c4b68@github.com>
Message-ID: <RyH4hsLDgVjfkpJ8pPxOTizBng7MDm-dyO2MtBoLtcI=.f766c579-3a35-4c47-a5ba-887cd37e50bd@github.com>

On Wed, 31 Mar 2021 21:39:46 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

> Please review these small tweaks.
> 
> For background information see [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)
> 
> Greetings
> Raffaello

This pull request has been closed without being integrated.

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

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

From asemenyuk at openjdk.java.net  Wed Apr  7 18:49:08 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 7 Apr 2021 18:49:08 GMT
Subject: RFR: 8264551: Unexpected warning when jpackage creates an exe
In-Reply-To: <iHhI4gRqU47IB0pL8E7cMIEZyuBAsKYwZyHwZ_jjOF8=.1ebeaa7f-cedf-4708-8028-ac9dcd253067@github.com>
References: <iHhI4gRqU47IB0pL8E7cMIEZyuBAsKYwZyHwZ_jjOF8=.1ebeaa7f-cedf-4708-8028-ac9dcd253067@github.com>
Message-ID: <JWBrkYegRdGcWyihlhKht8bhh-lrLnQrQdu8YV5PVsc=.5644852e-a705-4c06-add9-69d72a4fd740@github.com>

On Wed, 7 Apr 2021 01:09:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Since fix to [JDK-8263135](https://bugs.openjdk.java.net/browse/JDK-8263135), we've seen following warning message on the console when we run jpackage to create exe.
> 
> WARNING: MsiCloseHandle(3174034504) failed with error=6 
> 
> It is caused by lack of initializer in `DatabaseRecord(DatabaseView& view)`. We need to add it.

Marked as reviewed by asemenyuk (Reviewer).

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

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

From github.com+70726043+rgiulietti at openjdk.java.net  Wed Apr  7 18:59:01 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 7 Apr 2021 18:59:01 GMT
Subject: RFR: 8264514: HexFormat implementation tweaks
Message-ID: <wV2FdN2pRDkE8M0EEKnvM5En47NyMBfCy9ISZqi0WrA=.83d77737-9b80-4840-a5c7-0409ef1e14ce@github.com>

(Changed to new branch in personal fork)

Please review these small tweaks.
For background information see [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)

Greetings
Raffaello

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

Commit messages:
 - 8264514: HexFormat implementation tweaks

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

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

From herrick at openjdk.java.net  Wed Apr  7 19:11:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 7 Apr 2021 19:11:49 GMT
Subject: RFR: 8264551: Unexpected warning when jpackage creates an exe
In-Reply-To: <iHhI4gRqU47IB0pL8E7cMIEZyuBAsKYwZyHwZ_jjOF8=.1ebeaa7f-cedf-4708-8028-ac9dcd253067@github.com>
References: <iHhI4gRqU47IB0pL8E7cMIEZyuBAsKYwZyHwZ_jjOF8=.1ebeaa7f-cedf-4708-8028-ac9dcd253067@github.com>
Message-ID: <XN2N_Tqd6tIkSIHkwB_lU-nyc06v4jjKn2q7FtlFVc8=.e97136c4-01d7-48ef-8347-170990b1e9b3@github.com>

On Wed, 7 Apr 2021 01:09:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Since fix to [JDK-8263135](https://bugs.openjdk.java.net/browse/JDK-8263135), we've seen following warning message on the console when we run jpackage to create exe.
> 
> WARNING: MsiCloseHandle(3174034504) failed with error=6 
> 
> It is caused by lack of initializer in `DatabaseRecord(DatabaseView& view)`. We need to add it.

Marked as reviewed by herrick (Reviewer).

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

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

From bpb at openjdk.java.net  Wed Apr  7 21:12:46 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 7 Apr 2021 21:12:46 GMT
Subject: RFR: 8261301: StringWriter.flush() is NOOP but documentation does not
 indicate it
Message-ID: <0RH475n7cuVmKrEsDrROhuNshYwHny1ITlHPYlzNg4Q=.952e9c4a-2e62-4426-be0c-5f91ce7dc7b5@github.com>

The specification of the method `flush()` in the `java.io` classes `CharArrayWriter` and `StringWriter` is not explicit about the fact that the method has no effect. This request proposes to add to the specification of each flush() method the sentence
The {@code flush} method of {@code <ClassName/>} does nothing.
The corresponding CSR is JDK-8264867.

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

Commit messages:
 - 8261301: StringWriter.flush() is NOOP but documentation does not indicate it

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

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

From naoto at openjdk.java.net  Wed Apr  7 22:17:00 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 7 Apr 2021 22:17:00 GMT
Subject: RFR: 8261301: StringWriter.flush() is NOOP but documentation does
 not indicate it
In-Reply-To: <0RH475n7cuVmKrEsDrROhuNshYwHny1ITlHPYlzNg4Q=.952e9c4a-2e62-4426-be0c-5f91ce7dc7b5@github.com>
References: <0RH475n7cuVmKrEsDrROhuNshYwHny1ITlHPYlzNg4Q=.952e9c4a-2e62-4426-be0c-5f91ce7dc7b5@github.com>
Message-ID: <aXrb76t3D5xPu1TC8jUdZ63_ulowuVELtpysLF1pkjI=.30cc4eba-c9ad-4620-ad0e-c7d66b96ce97@github.com>

On Wed, 7 Apr 2021 21:01:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The specification of the method `flush()` in the `java.io` classes `CharArrayWriter` and `StringWriter` is not explicit about the fact that the method has no effect. This request proposes to add to the specification of each flush() method the sentence
> The {@code flush} method of {@code <ClassName/>} does nothing.
> The corresponding CSR is JDK-8264867.

Marked as reviewed by naoto (Reviewer).

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

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

From ysuenaga at openjdk.java.net  Wed Apr  7 23:17:15 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 7 Apr 2021 23:17:15 GMT
Subject: Integrated: 8264551: Unexpected warning when jpackage creates an exe
In-Reply-To: <iHhI4gRqU47IB0pL8E7cMIEZyuBAsKYwZyHwZ_jjOF8=.1ebeaa7f-cedf-4708-8028-ac9dcd253067@github.com>
References: <iHhI4gRqU47IB0pL8E7cMIEZyuBAsKYwZyHwZ_jjOF8=.1ebeaa7f-cedf-4708-8028-ac9dcd253067@github.com>
Message-ID: <R1ghgriE1_zBM0YcFuH8fljQ-zckOS7zlkNV3GVxmp4=.b8cd1e31-f1e1-4019-b67d-a365f924c001@github.com>

On Wed, 7 Apr 2021 01:09:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Since fix to [JDK-8263135](https://bugs.openjdk.java.net/browse/JDK-8263135), we've seen following warning message on the console when we run jpackage to create exe.
> 
> WARNING: MsiCloseHandle(3174034504) failed with error=6 
> 
> It is caused by lack of initializer in `DatabaseRecord(DatabaseView& view)`. We need to add it.

This pull request has now been integrated.

Changeset: a863ab69
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a863ab69
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8264551: Unexpected warning when jpackage creates an exe

Reviewed-by: asemenyuk, herrick

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

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

From joehw at openjdk.java.net  Thu Apr  8 00:18:43 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 8 Apr 2021 00:18:43 GMT
Subject: RFR: JDK-8264454 : Jaxp unit test from open jdk needs to be
 improved [v3]
In-Reply-To: <OQ4YPUa1sCmcuRu89j8Iifln8da5QhJwQIOtuXBJrAY=.8d4dcf50-d90e-421e-83e1-7aee3db5e570@github.com>
References: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
 <OQ4YPUa1sCmcuRu89j8Iifln8da5QhJwQIOtuXBJrAY=.8d4dcf50-d90e-421e-83e1-7aee3db5e570@github.com>
Message-ID: <Y5mE_qYfUBJsiQf3qm5MBGNDjosJaamfATMGL-WmQHA=.a4112ed2-ca60-445c-a2f6-65f9b4cdd9dd@github.com>

On Tue, 6 Apr 2021 16:53:03 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> JDK-8264454 : Jaxp unit test from open jdk needs to be improved
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year.

Marked as reviewed by joehw (Reviewer).

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

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

From joehw at openjdk.java.net  Thu Apr  8 00:18:44 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 8 Apr 2021 00:18:44 GMT
Subject: RFR: JDK-8264454 : Jaxp unit test from open jdk needs to be
 improved
In-Reply-To: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
References: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
Message-ID: <jE8SKD9SBALvVuVNLg1YV-cWWkrkvcsB0FSUknfhn6s=.62543fd1-6cef-4b7e-a00d-b849b82650d6@github.com>

On Tue, 30 Mar 2021 16:56:57 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

> JDK-8264454 : Jaxp unit test from open jdk needs to be improved

Ok, this is enough of improvement for now. I created a bug to keep track of the ISE case.

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

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

From jiefu at openjdk.java.net  Thu Apr  8 00:26:48 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 8 Apr 2021 00:26:48 GMT
Subject: RFR: 8264809: test-lib fails to build due to some warnings in
 ASN1Formatter and jfr
In-Reply-To: <eFtO98MK6RW_5CKvWAoQ8CUNj8g6_Otyi6_1fKjWeCw=.1dea018c-1b2d-4e07-8313-faa0ad886ebc@github.com>
References: <dQiWHORvae0jKv8kU3fyVaR6uDh1eN5IVy4kpkkGT0w=.b3e76902-788f-44dd-bd51-bff5553642b3@github.com>
 <eFtO98MK6RW_5CKvWAoQ8CUNj8g6_Otyi6_1fKjWeCw=.1dea018c-1b2d-4e07-8313-faa0ad886ebc@github.com>
Message-ID: <EhAvFT1RlLeI9Y8RlKw26VysPTvUDRFwlXa52MmhBp4=.67249086-d42e-4268-bd27-d4b4911e39dd@github.com>

On Wed, 7 Apr 2021 13:48:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi all,
>> 
>> test-lib fails to build due to three javac warnings:
>
> Looks good.
> It seems only the build-test-lib make rule has error on warnings set.
> When running the tests, the compiles do not fail. (though the warnings are produced).

Thanks @RogerRiggs .

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

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

From jiefu at openjdk.java.net  Thu Apr  8 00:30:34 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 8 Apr 2021 00:30:34 GMT
Subject: Integrated: 8264809: test-lib fails to build due to some warnings in
 ASN1Formatter and jfr
In-Reply-To: <dQiWHORvae0jKv8kU3fyVaR6uDh1eN5IVy4kpkkGT0w=.b3e76902-788f-44dd-bd51-bff5553642b3@github.com>
References: <dQiWHORvae0jKv8kU3fyVaR6uDh1eN5IVy4kpkkGT0w=.b3e76902-788f-44dd-bd51-bff5553642b3@github.com>
Message-ID: <vqR8xpJdXO6zXtPvJBzwPmxaHLvYkUaa4Rn6igel0ps=.d8535cfa-3312-4db8-a246-88dc83d13737@github.com>

On Wed, 7 Apr 2021 03:34:15 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> test-lib fails to build due to three javac warnings:

This pull request has now been integrated.

Changeset: 88eb2919
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/88eb2919
Stats:     5 lines in 3 files changed: 1 ins; 0 del; 4 mod

8264809: test-lib fails to build due to some warnings in ASN1Formatter and jfr

Reviewed-by: rriggs

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

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

From dongbo at openjdk.java.net  Thu Apr  8 06:33:43 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 8 Apr 2021 06:33:43 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

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

  reduce unnecessary memory write traffic in non-SIMD code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3228/files
  - new: https://git.openjdk.java.net/jdk/pull/3228/files/a342ad1e..ab0e405b

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

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

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

From ralph.goers at dslextreme.com  Thu Apr  8 06:33:51 2021
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Wed, 7 Apr 2021 23:33:51 -0700
Subject: Garbage Free Check
In-Reply-To: <B8B4DEE6-9A90-4574-B466-7267266A64FA@dslextreme.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
 <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>
 <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>
 <3928DCCA-DDB1-4217-B4EE-08DC11158B60@dslextreme.com>
 <04020c3c-f56d-8488-cd14-0e3b80f124f3@gmail.com>
 <B8B4DEE6-9A90-4574-B466-7267266A64FA@dslextreme.com>
Message-ID: <E0D57728-CD1C-477E-8DA2-044C9DCD8062@dslextreme.com>

Interesting. I ran the test with

openjdk version "16" 2021-03-16
OpenJDK Runtime Environment (build 16+36-2231)
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)

and it passed. I then ran it with 

openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

and

java version "11.0.9" 2020-10-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.9+7-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.9+7-LTS, mixed mode)

and

java version "11.0.10" 2021-01-19 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.10+8-LTS-162)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode)

and it failed with all of them.

Ralph


> On Apr 6, 2021, at 3:22 PM, Ralph Goers <ralph.goers at dslextreme.com> wrote:
> 
> I am using 
> 
> openjdk version "11.0.10" 2021-01-19 LTS
> OpenJDK Runtime Environment Corretto-11.0.10.9.1 (build 11.0.10+9-LTS)
> OpenJDK 64-Bit Server VM Corretto-11.0.10.9.1 (build 11.0.10+9-LTS, mixed mode)
> 
> Our test uses
> <dependency>
>  <groupId>com.google.code.java-allocation-instrumenter</groupId>
>  <artifactId>java-allocation-instrumenter</artifactId>
>  <version>3.3.0</version>
> </dependency>
> to validate that it is not allocating any objects.
> 
> If you want to test it yourself you can do
> 
> git clone https://github.com/apache/logging-log4j2.git <https://github.com/apache/logging-log4j2.git>
> cd logging-log4j2
> mvn -DskipTests=true clean install
> cd log4j-core
> mvn surefire:test -Dtest=GcFreeSynchronousLoggingTest -Dmaven.surefire.debug="-Dlog4j2.usePreciseClock=true?
> 
> When it fails you will see a strange message with 
> 
> I just allocated the object 2021-04-06T21:55:20.878377Z of type java/time/Instant whose size is 24 ==> expected: <true> but was: <false>
> 
> Ralph
> 
>> On Apr 6, 2021, at 9:53 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> 
>> Hi Ralph,
>> 
>> 
>> Which version of JDK did you try running the code. I tried the following benchmark:
>> 
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Fork(value = 1)
>> @Warmup(iterations = 5, time = 1)
>> @Measurement(iterations = 10, time = 1)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @State(Scope.Benchmark)
>> public class InstantBench {
>> 
>>    @Benchmark
>>    public long epochMilli() {
>>        Instant instant = Clock.systemUTC().instant();
>>        return instant.toEpochMilli();
>>    }
>> }
>> 
>> 
>> And didn't get any heap allocation on either JDK 11:
>> 
>> 
>> Benchmark Mode  Cnt   Score    Error   Units
>> InstantBench.epochMilli                      avgt   10  34.722 ?  0.328   ns/op
>> InstantBench.epochMilli:?gc.alloc.rate       avgt   10  ? 10??           MB/sec
>> InstantBench.epochMilli:?gc.alloc.rate.norm  avgt   10  ? 10??             B/op
>> InstantBench.epochMilli:?gc.count            avgt   10     ? 0           counts
>> 
>> 
>> ..nor on JDK 16:
>> 
>> 
>> Benchmark Mode  Cnt   Score    Error   Units
>> InstantBench.epochMilli                      avgt   10  33.612 ?  0.258   ns/op
>> InstantBench.epochMilli:?gc.alloc.rate       avgt   10  ? 10??           MB/sec
>> InstantBench.epochMilli:?gc.alloc.rate.norm  avgt   10  ? 10??             B/op
>> InstantBench.epochMilli:?gc.count            avgt   10     ? 0           counts
>> 
>> 
>> Regards, Peter
>> 
>> On 4/6/21 8:17 AM, Ralph Goers wrote:
>>> Yes, I am aware that the Instant is constructed from the two values. That is exactly why I was hoping I could pass in an object where the values of those two fields could be injected. This would still allow Instant to be immutable but allow Log4j to update one of the pre-existing Clock instances it is managing. That would require that a new Interface be defined with the two set methods and a new static method in the Clock class.
>>> 
>>> Getting the value in microseconds would probably be a middle ground that could also work considering that is the best resolution available on most hardware today.
>>> 
>>> Whichever is implemented I suspect getting it back ported to Java 11 is unlikely? According to the surveys I?ve seen the majority of users are still on Java 8. Given that, I?d be surprised if there is a mad rush to adopt Java 17 very soon. Given where things are I?m not even sure how likely it is this could make it in for Java 17.  The irony here is that the folks who need to run garbage free are also the ones most likely to need a Clock with higher resolution. Right now they can?t have both.
>>> 
>>> Ralph
>>> 
>>>> On Apr 5, 2021, at 1:26 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Java does not have a data type with enough resolution to hold a full nanosecond value.
>>>> Hence the implementation of Instant holding seconds and nanos.
>>>> 
>>>> There is an long dormant enhancement request to return micro-seconds as a long.
>>>> 8196003 <https://bugs.openjdk.java.net/browse/JDK-8196003> java.time Instant and Duration methods for microseconds
>>>> 
>>>> That might be useful if the application gets enough resolution from microseconds.
>>>> There might be some clever interpolation between System.currentTimeMillis()
>>>> and adjusting with System.nanoTime().
>>>> Though it would likely not be exactly synchronized with the values from Instant.
>>>> 
>>>> Regards, Roger
>>>> 
>>>> 
>>>> On 4/5/21 3:56 PM, Brian Goetz wrote:
>>>>> Project Valhalla will allow Instant to be migrated to a primitive class, which would address your problem.
>>>>> 
>>>>> On 4/2/2021 7:47 PM, Ralph Goers wrote:
>>>>>> Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.
>>>>>> 
>>>>>> The code we have simply does
>>>>>> 
>>>>>> public void init(MutableInstant mutableInstant) {
>>>>>>     Instant instant = java.time.Clock.systemUTC().instant();
>>>>>> mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
>>>>>> }
>>>>>> In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
>>>>>> Ideally we would really like something like
>>>>>> 
>>>>>> public void init(MutableInstant mutableInstant) {
>>>>>>        java.time.Clock.systemUTC().initInstant(mutableInstant);
>>>>>> }
>>>>>> 
>>>>>> where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.
>>>>>> 
>>>>>> This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.
>>>>>> 
>>>>>> Do you know of another way to do this? Am I missing something?
>>>>>> 
>>>>>> Ralph
>>>> 
>>> 
>> 
> 
> 



From dongbo at openjdk.java.net  Thu Apr  8 06:39:11 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 8 Apr 2021 06:39:11 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6]
In-Reply-To: <uYrE1TBlkMS4Jlz36xe0CX_v9iucRqkHCM_Sc5F2gnA=.4a85979d-9e73-4a83-981c-ee47faf051ce@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>
 <sGQjaUtyiB5cDch3o5YGyLnf9lG6YoMrwABun7jgbK4=.a0b249ef-2e79-4b56-8eae-e0e2181bd8ec@github.com>
 <uYrE1TBlkMS4Jlz36xe0CX_v9iucRqkHCM_Sc5F2gnA=.4a85979d-9e73-4a83-981c-ee47faf051ce@github.com>
Message-ID: <M87LnnCUtlf_s6jY3eRaU8IrV_YM-zzEh6jjdPOjGhs=.83ed3f80-8c28-4acd-bee0-13534b1dd656@github.com>

On Wed, 7 Apr 2021 09:53:36 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5829:
>> 
>>> 5827:     __ strb(r14, __ post(dst, 1));
>>> 5828:     __ strb(r15, __ post(dst, 1));
>>> 5829:     __ strb(r13, __ post(dst, 1));
>> 
>> I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think.
>
> Sorry, that's not quite right, but you get the idea: let's not generate unnecessary memory traffic.

Okay, implemented as:
__ lslw(r14, r10, 10);
__ bfiw(r14, r11, 4, 6);
__ bfmw(r14, r12, 2, 5);
__ rev16w(r14, r14);
__ bfiw(r13, r12, 6, 2);
__ strh(r14, __ post(dst, 2));
__ strb(r13, __ post(dst, 1));

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

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

From ralph.goers at dslextreme.com  Thu Apr  8 07:09:21 2021
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Thu, 8 Apr 2021 00:09:21 -0700
Subject: Garbage Free Check
In-Reply-To: <E0D57728-CD1C-477E-8DA2-044C9DCD8062@dslextreme.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
 <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>
 <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>
 <3928DCCA-DDB1-4217-B4EE-08DC11158B60@dslextreme.com>
 <04020c3c-f56d-8488-cd14-0e3b80f124f3@gmail.com>
 <B8B4DEE6-9A90-4574-B466-7267266A64FA@dslextreme.com>
 <E0D57728-CD1C-477E-8DA2-044C9DCD8062@dslextreme.com>
Message-ID: <F7ACC5F4-CDF0-4490-8818-B631589CDAAB@dslextreme.com>

Well, after digging deeper it seems it didn?t really pass on Java 16. The allocation instrumenter was unable to instrument anything so it didn?t generate the errors the test looks for. I tried with Java 12-14 and those all failed. In Java 15 the JVM crashed.

Ralph

> On Apr 7, 2021, at 11:33 PM, Ralph Goers <ralph.goers at dslextreme.com> wrote:
> 
> Interesting. I ran the test with
> 
> openjdk version "16" 2021-03-16
> OpenJDK Runtime Environment (build 16+36-2231)
> OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)
> 
> and it passed. I then ran it with 
> 
> openjdk version "11.0.2" 2019-01-15
> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> 
> and
> 
> java version "11.0.9" 2020-10-20 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.9+7-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.9+7-LTS, mixed mode)
> 
> and
> 
> java version "11.0.10" 2021-01-19 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.10+8-LTS-162)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode)
> 
> and it failed with all of them.
> 
> Ralph
> 
> 
>> On Apr 6, 2021, at 3:22 PM, Ralph Goers <ralph.goers at dslextreme.com <mailto:ralph.goers at dslextreme.com>> wrote:
>> 
>> I am using 
>> 
>> openjdk version "11.0.10" 2021-01-19 LTS
>> OpenJDK Runtime Environment Corretto-11.0.10.9.1 (build 11.0.10+9-LTS)
>> OpenJDK 64-Bit Server VM Corretto-11.0.10.9.1 (build 11.0.10+9-LTS, mixed mode)
>> 
>> Our test uses
>> <dependency>
>> <groupId>com.google.code.java-allocation-instrumenter</groupId>
>> <artifactId>java-allocation-instrumenter</artifactId>
>> <version>3.3.0</version>
>> </dependency>
>> to validate that it is not allocating any objects.
>> 
>> If you want to test it yourself you can do
>> 
>> git clone https://github.com/apache/logging-log4j2.git <https://github.com/apache/logging-log4j2.git> <https://github.com/apache/logging-log4j2.git <https://github.com/apache/logging-log4j2.git>>
>> cd logging-log4j2
>> mvn -DskipTests=true clean install
>> cd log4j-core
>> mvn surefire:test -Dtest=GcFreeSynchronousLoggingTest -Dmaven.surefire.debug="-Dlog4j2.usePreciseClock=true?
>> 
>> When it fails you will see a strange message with 
>> 
>> I just allocated the object 2021-04-06T21:55:20.878377Z of type java/time/Instant whose size is 24 ==> expected: <true> but was: <false>
>> 
>> Ralph
>> 
>>> On Apr 6, 2021, at 9:53 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>> 
>>> Hi Ralph,
>>> 
>>> 
>>> Which version of JDK did you try running the code. I tried the following benchmark:
>>> 
>>> 
>>> @BenchmarkMode(Mode.AverageTime)
>>> @Fork(value = 1)
>>> @Warmup(iterations = 5, time = 1)
>>> @Measurement(iterations = 10, time = 1)
>>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> @State(Scope.Benchmark)
>>> public class InstantBench {
>>> 
>>>   @Benchmark
>>>   public long epochMilli() {
>>>       Instant instant = Clock.systemUTC().instant();
>>>       return instant.toEpochMilli();
>>>   }
>>> }
>>> 
>>> 
>>> And didn't get any heap allocation on either JDK 11:
>>> 
>>> 
>>> Benchmark Mode  Cnt   Score    Error   Units
>>> InstantBench.epochMilli                      avgt   10  34.722 ?  0.328   ns/op
>>> InstantBench.epochMilli:?gc.alloc.rate       avgt   10  ? 10??           MB/sec
>>> InstantBench.epochMilli:?gc.alloc.rate.norm  avgt   10  ? 10??             B/op
>>> InstantBench.epochMilli:?gc.count            avgt   10     ? 0           counts
>>> 
>>> 
>>> ..nor on JDK 16:
>>> 
>>> 
>>> Benchmark Mode  Cnt   Score    Error   Units
>>> InstantBench.epochMilli                      avgt   10  33.612 ?  0.258   ns/op
>>> InstantBench.epochMilli:?gc.alloc.rate       avgt   10  ? 10??           MB/sec
>>> InstantBench.epochMilli:?gc.alloc.rate.norm  avgt   10  ? 10??             B/op
>>> InstantBench.epochMilli:?gc.count            avgt   10     ? 0           counts
>>> 
>>> 
>>> Regards, Peter
>>> 
>>> On 4/6/21 8:17 AM, Ralph Goers wrote:
>>>> Yes, I am aware that the Instant is constructed from the two values. That is exactly why I was hoping I could pass in an object where the values of those two fields could be injected. This would still allow Instant to be immutable but allow Log4j to update one of the pre-existing Clock instances it is managing. That would require that a new Interface be defined with the two set methods and a new static method in the Clock class.
>>>> 
>>>> Getting the value in microseconds would probably be a middle ground that could also work considering that is the best resolution available on most hardware today.
>>>> 
>>>> Whichever is implemented I suspect getting it back ported to Java 11 is unlikely? According to the surveys I?ve seen the majority of users are still on Java 8. Given that, I?d be surprised if there is a mad rush to adopt Java 17 very soon. Given where things are I?m not even sure how likely it is this could make it in for Java 17.  The irony here is that the folks who need to run garbage free are also the ones most likely to need a Clock with higher resolution. Right now they can?t have both.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Apr 5, 2021, at 1:26 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Java does not have a data type with enough resolution to hold a full nanosecond value.
>>>>> Hence the implementation of Instant holding seconds and nanos.
>>>>> 
>>>>> There is an long dormant enhancement request to return micro-seconds as a long.
>>>>> 8196003 <https://bugs.openjdk.java.net/browse/JDK-8196003> java.time Instant and Duration methods for microseconds
>>>>> 
>>>>> That might be useful if the application gets enough resolution from microseconds.
>>>>> There might be some clever interpolation between System.currentTimeMillis()
>>>>> and adjusting with System.nanoTime().
>>>>> Though it would likely not be exactly synchronized with the values from Instant.
>>>>> 
>>>>> Regards, Roger
>>>>> 
>>>>> 
>>>>> On 4/5/21 3:56 PM, Brian Goetz wrote:
>>>>>> Project Valhalla will allow Instant to be migrated to a primitive class, which would address your problem.
>>>>>> 
>>>>>> On 4/2/2021 7:47 PM, Ralph Goers wrote:
>>>>>>> Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.
>>>>>>> 
>>>>>>> The code we have simply does
>>>>>>> 
>>>>>>> public void init(MutableInstant mutableInstant) {
>>>>>>>    Instant instant = java.time.Clock.systemUTC().instant();
>>>>>>> mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
>>>>>>> }
>>>>>>> In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
>>>>>>> Ideally we would really like something like
>>>>>>> 
>>>>>>> public void init(MutableInstant mutableInstant) {
>>>>>>>       java.time.Clock.systemUTC().initInstant(mutableInstant);
>>>>>>> }
>>>>>>> 
>>>>>>> where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.
>>>>>>> 
>>>>>>> This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.
>>>>>>> 
>>>>>>> Do you know of another way to do this? Am I missing something?
>>>>>>> 
>>>>>>> Ralph


From aph at openjdk.java.net  Thu Apr  8 08:32:18 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 8 Apr 2021 08:32:18 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
Message-ID: <jMsubVt8m3Xn_R8ABDVLCzZK3kyvO2EFhnjrc6XX5l0=.198df9f0-4f9a-4660-aa70-9a36612e11d2@github.com>

On Thu, 8 Apr 2021 06:33:43 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce unnecessary memory write traffic in non-SIMD code

Marked as reviewed by aph (Reviewer).

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

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

From lzang at openjdk.java.net  Thu Apr  8 08:32:25 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 8 Apr 2021 08:32:25 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v3]
In-Reply-To: <z-VtWLNFeho201QW1vLymWa3vB-TSkwMElKw_seESeM=.c5d67dac-2543-4bd4-b5d3-dfc15e56d4fa@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
 <z-VtWLNFeho201QW1vLymWa3vB-TSkwMElKw_seESeM=.c5d67dac-2543-4bd4-b5d3-dfc15e56d4fa@github.com>
Message-ID: <BIAT8d0uhmiDK4YwqSHGZSgTh1Ach6qQvgEbark9kdE=.5f053c10-7e37-4a0f-9a37-8a92b7bd5585@github.com>

On Fri, 2 Apr 2021 08:53:20 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi Lin,
>> 
>> On Mar 24, 2021, at 2:51 AM, Lin Zang ***@***.******@***.***>> wrote:
>> 
>> 
>> 
>> Hi Lance?
>> Thanks a lot for your review. I will update the PR ASAP.
>> May I ask your help to also review the CSR?
>> 
>> I believe we need to flush out some of the issues I raised that were not test related as they will result in updates to the javadoc which will require an update to the CSR.
>> 
>> 
>> 
>> Thanks!
>> 
>> BRs,
>> Lin
>> 
>> ?
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/3072#issuecomment-805549600>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABQPFO5R4INTAUFZ3QS6WL3TFGDXHANCNFSM4ZMLU6SA>.
>> 
>> ***@***.***
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> ***@***.******@***.***>
>
> Dear @LanceAndersen,
> Here I added a class `GZIPHeaderData` which is defined to hold all gzip header members, and make it an argument of the GZIPOutputStream constructor.  Would you like to help review and check whether this change looks reasonable?
> 
> BTW, this pr still lack of the negative test cases, I plan to add it when the constructor API is fixed.
> 
> Thanks!
> Lin

Dear All,
May I ask your help to review this change? Thanks!

BRs,
Lin

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Apr  8 08:38:38 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 8 Apr 2021 08:38:38 GMT
Subject: RFR: 8264896: Remove redundant '& 0xFF' from int-to-byte cast
Message-ID: <T9cLs0tk1TmQ9TiHiQSFuFvT2L49j1_rZ-s6Pl6lFQs=.68fb0dea-9045-4401-9d87-5ca59772501b@github.com>

When we do
byte b1 = (byte) (value & 0xFF);
we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below:
public class Main {
  public static void main(String[] args) throws Exception {
    IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> {
      byte b1 = (byte) (value & 0xFF);
      byte b2 = (byte) value;
      if (b1 != b2) {
        throw new RuntimeException("" + value);
      }
    });
}

Also tier1 and tier2 are both OK.

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

Commit messages:
 - Merge branch 'master' into bitwise
 - Remove redundant '& 0xFF' from int-to-byte cast

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Apr  8 08:50:09 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 8 Apr 2021 08:50:09 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <VSPKLm1HjhCkd_WmlFJCikNyedxejJnBZ0JOwUxb87k=.35ea99d2-b3d4-4203-b9f2-2a2548262dcb@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
 <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
 <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>
 <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>
 <VSPKLm1HjhCkd_WmlFJCikNyedxejJnBZ0JOwUxb87k=.35ea99d2-b3d4-4203-b9f2-2a2548262dcb@github.com>
Message-ID: <z_O5Zecq1WILtXpfu3dEG_tJv-XeXKUW1oU9U6rE7yo=.504befcb-9d96-44de-ae1b-a8d5f0f871d8@github.com>

On Mon, 15 Mar 2021 06:56:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here.
>
>> @AlanBateman so is it ok to keep `ArrayLists`?
> 
> One thing to look out for is usages of 2-arg add method that inserts at a specific position. This shouldn't be a concern in URLClassPath.closeLoaders (assuming this is this usage where the question arises).

@AlanBateman looks like `List.add(o, i)` is not used at all in scope of these changes.

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

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

From github.com+1204330+overheadhunter at openjdk.java.net  Thu Apr  8 08:57:17 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Thu, 8 Apr 2021 08:57:17 GMT
Subject: RFR: 8264896: Remove redundant '& 0xFF' from int-to-byte cast
In-Reply-To: <T9cLs0tk1TmQ9TiHiQSFuFvT2L49j1_rZ-s6Pl6lFQs=.68fb0dea-9045-4401-9d87-5ca59772501b@github.com>
References: <T9cLs0tk1TmQ9TiHiQSFuFvT2L49j1_rZ-s6Pl6lFQs=.68fb0dea-9045-4401-9d87-5ca59772501b@github.com>
Message-ID: <vFic_EPGM_JbsjsHk8ZbTqFFeHA5AHpMqeEd9HZ6X_o=.069ccba6-25d6-44bc-8252-ebda302b4abe@github.com>

On Thu, 4 Mar 2021 12:16:29 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> When we do
> byte b1 = (byte) (value & 0xFF);
> we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below:
> public class Main {
>   public static void main(String[] args) throws Exception {
>     IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> {
>       byte b1 = (byte) (value & 0xFF);
>       byte b2 = (byte) value;
>       if (b1 != b2) {
>         throw new RuntimeException("" + value);
>       }
>     });
> }
> 
> Also tier1 and tier2 are both OK.

I don't think these masks have been added because they are _required_ but rather because they explicitly show the intention: You can immediately see that losing the MSBs of an int during the cast is _not_ just an error.

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

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

From alanb at openjdk.java.net  Thu Apr  8 08:58:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 8 Apr 2021 08:58:08 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v3]
In-Reply-To: <BIAT8d0uhmiDK4YwqSHGZSgTh1Ach6qQvgEbark9kdE=.5f053c10-7e37-4a0f-9a37-8a92b7bd5585@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
 <z-VtWLNFeho201QW1vLymWa3vB-TSkwMElKw_seESeM=.c5d67dac-2543-4bd4-b5d3-dfc15e56d4fa@github.com>
 <BIAT8d0uhmiDK4YwqSHGZSgTh1Ach6qQvgEbark9kdE=.5f053c10-7e37-4a0f-9a37-8a92b7bd5585@github.com>
Message-ID: <3NgvnAImIrOF6eaXJSim4TCHPruhp6yD2tVqBm-RMHM=.1bc66bec-53fb-4840-b0ef-c03a7cc111d1@github.com>

On Thu, 8 Apr 2021 08:29:36 GMT, Lin Zang <lzang at openjdk.org> wrote:

> Dear All,
> May I ask your help to review this change? Thanks!

@LanceAndersen Do you have cycles to help Lin? This proposal will require discussion, they may be case for the header to be a record for example. My personal view is that the PR should be set aside until there is at least at least some agreement on the API.

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

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

From dongbo at openjdk.java.net  Thu Apr  8 09:08:17 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 8 Apr 2021 09:08:17 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <jMsubVt8m3Xn_R8ABDVLCzZK3kyvO2EFhnjrc6XX5l0=.198df9f0-4f9a-4660-aa70-9a36612e11d2@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
 <jMsubVt8m3Xn_R8ABDVLCzZK3kyvO2EFhnjrc6XX5l0=.198df9f0-4f9a-4660-aa70-9a36612e11d2@github.com>
Message-ID: <ihe1BY1gSa4LAWNjnF0GGh-3R56YYhLAOWtM7-sGHGQ=.fc0a4abe-908a-4582-86a6-8d56193015b0@github.com>

On Thu, 8 Apr 2021 08:28:53 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce unnecessary memory write traffic in non-SIMD code
>
> Marked as reviewed by aph (Reviewer).

@theRealAph Thanks for the review.

Hi @nick-arm, are you also ok with the newest commit?

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

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

From dfuchs at openjdk.java.net  Thu Apr  8 09:11:18 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 8 Apr 2021 09:11:18 GMT
Subject: RFR: 8264896: Remove redundant '& 0xFF' from int-to-byte cast
In-Reply-To: <vFic_EPGM_JbsjsHk8ZbTqFFeHA5AHpMqeEd9HZ6X_o=.069ccba6-25d6-44bc-8252-ebda302b4abe@github.com>
References: <T9cLs0tk1TmQ9TiHiQSFuFvT2L49j1_rZ-s6Pl6lFQs=.68fb0dea-9045-4401-9d87-5ca59772501b@github.com>
 <vFic_EPGM_JbsjsHk8ZbTqFFeHA5AHpMqeEd9HZ6X_o=.069ccba6-25d6-44bc-8252-ebda302b4abe@github.com>
Message-ID: <PzxaShiKuvAABtjwY5kHNDZXSGbdKWTICgnJkySn11U=.db83f51f-1d1f-4efc-8d40-ee4a6ff2a185@github.com>

On Thu, 8 Apr 2021 08:54:35 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

>> When we do
>> byte b1 = (byte) (value & 0xFF);
>> we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below:
>> public class Main {
>>   public static void main(String[] args) throws Exception {
>>     IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> {
>>       byte b1 = (byte) (value & 0xFF);
>>       byte b2 = (byte) value;
>>       if (b1 != b2) {
>>         throw new RuntimeException("" + value);
>>       }
>>     });
>> }
>> 
>> Also tier1 and tier2 are both OK.
>
> I don't think these masks have been added because they are _required_ but rather because they explicitly show the intention: You can immediately see that losing the MSBs of an int during the cast is _not_ just an error.

I agree with Sebastian. I believe the original code was clearer.

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

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

From ngasson at openjdk.java.net  Thu Apr  8 09:13:09 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 8 Apr 2021 09:13:09 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
Message-ID: <FiqGN4RkG8w_gL11WWWjFf6YpLUlIeU_QU0Ko3neuy4=.97207cfe-cfeb-4dc7-ad36-c13f55796064@github.com>

On Thu, 8 Apr 2021 06:33:43 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce unnecessary memory write traffic in non-SIMD code

Marked as reviewed by ngasson (Committer).

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

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

From ngasson at openjdk.java.net  Thu Apr  8 09:13:09 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 8 Apr 2021 09:13:09 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <ihe1BY1gSa4LAWNjnF0GGh-3R56YYhLAOWtM7-sGHGQ=.fc0a4abe-908a-4582-86a6-8d56193015b0@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
 <jMsubVt8m3Xn_R8ABDVLCzZK3kyvO2EFhnjrc6XX5l0=.198df9f0-4f9a-4660-aa70-9a36612e11d2@github.com>
 <ihe1BY1gSa4LAWNjnF0GGh-3R56YYhLAOWtM7-sGHGQ=.fc0a4abe-908a-4582-86a6-8d56193015b0@github.com>
Message-ID: <nYOZzRGbJTFTZqnIswMZNfi3e25V1CxlGJaB022RWug=.92d1ecab-9bf8-40a9-a830-86afbcc8f083@github.com>

On Thu, 8 Apr 2021 09:05:43 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> Hi @nick-arm, are you also ok with the newest commit?

It looks ok to me but I'm not a Reviewer.

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

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

From adinn at redhat.com  Thu Apr  8 09:15:29 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 8 Apr 2021 10:15:29 +0100
Subject: RFR: 8264896: Remove redundant '& 0xFF' from int-to-byte cast
In-Reply-To: <PzxaShiKuvAABtjwY5kHNDZXSGbdKWTICgnJkySn11U=.db83f51f-1d1f-4efc-8d40-ee4a6ff2a185@github.com>
References: <T9cLs0tk1TmQ9TiHiQSFuFvT2L49j1_rZ-s6Pl6lFQs=.68fb0dea-9045-4401-9d87-5ca59772501b@github.com>
 <vFic_EPGM_JbsjsHk8ZbTqFFeHA5AHpMqeEd9HZ6X_o=.069ccba6-25d6-44bc-8252-ebda302b4abe@github.com>
 <PzxaShiKuvAABtjwY5kHNDZXSGbdKWTICgnJkySn11U=.db83f51f-1d1f-4efc-8d40-ee4a6ff2a185@github.com>
Message-ID: <bcec5ca7-e62b-b36c-c3b6-fe1e86e06de0@redhat.com>

On 08/04/2021 10:11, Daniel Fuchs wrote:
> On Thu, 8 Apr 2021 08:54:35 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:
> 
>>> When we do
>>> byte b1 = (byte) (value & 0xFF);
>>> we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below:
>>> public class Main {
>>>    public static void main(String[] args) throws Exception {
>>>      IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> {
>>>        byte b1 = (byte) (value & 0xFF);
>>>        byte b2 = (byte) value;
>>>        if (b1 != b2) {
>>>          throw new RuntimeException("" + value);
>>>        }
>>>      });
>>> }
>>>
>>> Also tier1 and tier2 are both OK.
>>
>> I don't think these masks have been added because they are _required_ but rather because they explicitly show the intention: You can immediately see that losing the MSBs of an int during the cast is _not_ just an error.
> 
> I agree with Sebastian. I believe the original code was clearer.
The same applies for the (value >>> 0) expressions that this patch also 
removes. The reason for keeping them is to emphasize the continuity with 
the (value >>> 24), (value >>> 16), etc cases that precede them.

Since none of this will make any difference to performance I think it is 
better to keep this code as is.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From rriggs at openjdk.java.net  Thu Apr  8 13:49:22 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 8 Apr 2021 13:49:22 GMT
Subject: RFR: 8261301: StringWriter.flush() is NOOP but documentation does
 not indicate it
In-Reply-To: <0RH475n7cuVmKrEsDrROhuNshYwHny1ITlHPYlzNg4Q=.952e9c4a-2e62-4426-be0c-5f91ce7dc7b5@github.com>
References: <0RH475n7cuVmKrEsDrROhuNshYwHny1ITlHPYlzNg4Q=.952e9c4a-2e62-4426-be0c-5f91ce7dc7b5@github.com>
Message-ID: <c9aYMne-uFk5N0fr5lL65MwTs8P8SoKSkckP_gcCRQI=.cf43d04c-f2e8-4ecd-a3f3-56f2f562b27a@github.com>

On Wed, 7 Apr 2021 21:01:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The specification of the method `flush()` in the `java.io` classes `CharArrayWriter` and `StringWriter` is not explicit about the fact that the method has no effect. This request proposes to add to the specification of each flush() method the sentence
> The {@code flush} method of {@code <ClassName/>} does nothing.
> The corresponding CSR is JDK-8264867.

In the CSR, the first sentence of the Summary should be context free.
It is used standalone in other contexts to describe the change.  Perhaps change to:
"Clarify the `flush` methods in java.io classes CharArrayWriter and StringWriter do nothing."

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

Marked as reviewed by rriggs (Reviewer).

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

From lance.andersen at oracle.com  Thu Apr  8 14:29:14 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 8 Apr 2021 10:29:14 -0400
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v3]
In-Reply-To: <BIAT8d0uhmiDK4YwqSHGZSgTh1Ach6qQvgEbark9kdE=.5f053c10-7e37-4a0f-9a37-8a92b7bd5585@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
 <z-VtWLNFeho201QW1vLymWa3vB-TSkwMElKw_seESeM=.c5d67dac-2543-4bd4-b5d3-dfc15e56d4fa@github.com>
 <BIAT8d0uhmiDK4YwqSHGZSgTh1Ach6qQvgEbark9kdE=.5f053c10-7e37-4a0f-9a37-8a92b7bd5585@github.com>
Message-ID: <11ED65B7-1E7F-48A8-B773-549235A6524E@oracle.com>

Hi Lin,

First thank you for your efforts on this feature.  As Alan suggested on March 26, we should take a step back and flush out the overall changes to the API before moving forward with additional PR reviews.   

We should look to see if it makes sense to use some of the more recent java features such as Record.

If we are adding a specific class to hold the header fields,  perhaps using the builder pattern should be considered vs  constructors.

If we are writing out these additional fields, what should we do with them when reading  a gzip file back?

Have you looked at other gzip api implementations to see what they provide in this area?    

Is there anyone who relies on this additional header info?  As I mentioned in an earlier comment, we should validate the changes against another implementation to ensure that we can read the data back correctly and that the additional header data that we write can be read by other tools.

Once we reach a consensus on the overall API changes and/or additions, then we can look to move forward with the next PR review.

Alan,  Yes I am happy to help Lin on moving this forward.

> On Apr 8, 2021, at 4:32 AM, Lin Zang <lzang at openjdk.java.net> wrote:
> 
> On Fri, 2 Apr 2021 08:53:20 GMT, Lin Zang <lzang at openjdk.org <mailto:lzang at openjdk.org>> wrote:
> 
>>> Hi Lin,
>>> 
>>> On Mar 24, 2021, at 2:51 AM, Lin Zang ***@***.******@***.***>> wrote:
>>> 
>>> 
>>> 
>>> Hi Lance?
>>> Thanks a lot for your review. I will update the PR ASAP.
>>> May I ask your help to also review the CSR?
>>> 
>>> I believe we need to flush out some of the issues I raised that were not test related as they will result in updates to the javadoc which will require an update to the CSR.
>>> 
>>> 
>>> 
>>> Thanks!
>>> 
>>> BRs,
>>> Lin
>>> 
>>> ?
>>> You are receiving this because you commented.
>>> Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/3072#issuecomment-805549600>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABQPFO5R4INTAUFZ3QS6WL3TFGDXHANCNFSM4ZMLU6SA>.
>>> 
>>> ***@***.***
>>> 
>>> 
>>> 
>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> ***@***.******@***.***>
>> 
>> Dear @LanceAndersen,
>> Here I added a class `GZIPHeaderData` which is defined to hold all gzip header members, and make it an argument of the GZIPOutputStream constructor.  Would you like to help review and check whether this change looks reasonable?
>> 
>> BTW, this pr still lack of the negative test cases, I plan to add it when the constructor API is fixed.
>> 
>> Thanks!
>> Lin
> 
> Dear All,
> May I ask your help to review this change? Thanks!
> 
> BRs,
> Lin
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3072 <https://git.openjdk.java.net/jdk/pull/3072>


From kvn at openjdk.java.net  Thu Apr  8 15:32:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 15:32:40 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler
Message-ID: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>

As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 

- `jdk.aot` module ? the `jaotc` tool 
- `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
- related HotSpot code guarded by `#if INCLUDE_AOT` 

Additionally, remove tests as well as code in makefiles related to AoT compilation.

Tested hs-tier1-4

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

Commit messages:
 - 8264805: Remove the experimental Ahead-of-Time Compiler

Changes: https://git.openjdk.java.net/jdk/pull/3398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264805
  Stats: 26903 lines in 375 files changed: 4 ins; 26703 del; 196 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

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

From github.com+471021+marschall at openjdk.java.net  Thu Apr  8 15:47:23 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Thu, 8 Apr 2021 15:47:23 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <P8SvYYoQHyWbRw20r-0kJO0eJtMy5pL7zhmpgqj5HZw=.ebef09a9-a705-4e91-9e07-148c62bc1442@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
 <Wi1oVqQQU2X7y_jCkhKBgiU9b41jTIHyimz5YFUntgw=.f66745a3-95a8-4986-b1df-dd873a829427@github.com>
 <P8SvYYoQHyWbRw20r-0kJO0eJtMy5pL7zhmpgqj5HZw=.ebef09a9-a705-4e91-9e07-148c62bc1442@github.com>
Message-ID: <3eBOFD1ZTTIxEA7Pgd1c2T8-Gwb1M1_4bnZQerTjTXY=.a9593b4f-1556-40ff-a4a9-404a0da4297c@github.com>

On Sat, 13 Mar 2021 14:40:14 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> I think the implementation changes here look good. I don't know however whether there is enough coverage in the tests. These should verify that the `Reader`, `CharArrayReader`, and `InputStreamReader` implementations of `read(CharBuffer)` are accurate. If there is already sufficient coverage in the tests in `test/jdk/java/io` then that is good enough and nothing need be added.
>
>> I think the implementation changes here look good. I don't know however whether there is enough coverage in the tests. These should verify that the `Reader`, `CharArrayReader`, and `InputStreamReader` implementations of `read(CharBuffer)` are accurate. If there is already sufficient coverage in the tests in `test/jdk/java/io` then that is good enough and nothing need be added.
> 
> `CharArrayReader` was lacking a test. I added a test which found a bug and fixed the bug. The PR also contains new tests for `Reader` and `InputStreamReader`. They cover on-heap and off-heap cases.
> 
> Is there a way to get test coverage with JTReg tests? I only found [1] which seems out of date and points to an Oracle internal wiki.
> 
>  [1] https://wiki.openjdk.java.net/display/CodeTools/JCov+FAQ#JCovFAQ-HowdoIuseJCovwithjtreg?

How do we proceed here? Are there additional changes that you would like me to perform or undo?

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

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

From asemenyuk at openjdk.java.net  Thu Apr  8 15:47:28 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 8 Apr 2021 15:47:28 GMT
Subject: Integrated: 8236127: Use value of --icon CLI option to set icon for
 exe installers
In-Reply-To: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
References: <qj7zDwi7_Tjk6Ees6OvvNfPzP6mDtq-cfVSnxbUycj0=.ae70928f-498c-43a9-9aff-a1af21109cca@github.com>
Message-ID: <VoEzBJKXCIFacfJKe2ZBQz02gOzpgZaQ_f_ACvWZ_tQ=.6c49e150-ebad-4ee4-83e6-a0ff6ea83aba@github.com>

On Mon, 5 Apr 2021 19:46:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Use value of `--icon` jpackage CLI option to set icon for exe installers.

This pull request has now been integrated.

Changeset: 5bd6c745
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5bd6c745
Stats:     243 lines in 8 files changed: 209 ins; 18 del; 16 mod

8236127: Use value of --icon CLI option to set icon for exe installers

Reviewed-by: almatvee, herrick

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

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

From kvn at openjdk.java.net  Thu Apr  8 15:58:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 15:58:39 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v2]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <fx4j96R0QPbRe0vxfo8psKinNZeKEu-alqxyKTgrJqc=.0b17062e-345e-446c-9c51-c2711eb17441@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

Vladimir Kozlov 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-8264805
 - 8264805: Remove the experimental Ahead-of-Time Compiler

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

Changes: https://git.openjdk.java.net/jdk/pull/3398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=01
  Stats: 26906 lines in 375 files changed: 4 ins; 26709 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

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

From pconcannon at openjdk.java.net  Thu Apr  8 16:01:41 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 8 Apr 2021 16:01:41 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v3]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <pCGsyKhNdxDp6439M6Oc6vbEKvueLqgylxxKCzeMFFU=.978deb3a-f32d-4a06-bbbc-5049fc25cdd2@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

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

 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 8263668: Update java.time to use instanceof pattern variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/b72e658e..d7355049

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

  Stats: 37636 lines in 887 files changed: 29080 ins; 4064 del; 4492 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170

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

From kvn at openjdk.java.net  Thu Apr  8 16:17:33 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 16:17:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v3]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <BlpY5DxuvNwVzjeD5tsKKsGrBMRiF44IpNQTFM8-PDk=.a24899bc-1bf4-4bd1-b3fe-014dfa1f1c23@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8264805
 - Merge branch 'master' into JDK-8264805
 - 8264805: Remove the experimental Ahead-of-Time Compiler

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

Changes: https://git.openjdk.java.net/jdk/pull/3398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=02
  Stats: 26906 lines in 375 files changed: 4 ins; 26709 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

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

From kvn at openjdk.java.net  Thu Apr  8 17:24:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 17:24:38 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

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

  Remove exports from Graal module to jdk.aot

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3398/files
  - new: https://git.openjdk.java.net/jdk/pull/3398/files/3dbc6210..6cce0f6c

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

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

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

From coleenp at openjdk.java.net  Thu Apr  8 19:35:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 8 Apr 2021 19:35:06 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <nWH5uT6GOy39SQ5N0i0_ebq68fxuz51usnggz0_Zo6k=.948353ee-179b-497c-becf-e959995ae130@github.com>

On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) {
This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want.

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

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

From coleenp at openjdk.java.net  Thu Apr  8 19:42:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 8 Apr 2021 19:42:06 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <oP7swTV0ldoNBfWnHMamOyfNybhTuK-iKaHUy2x1E_g=.82aa1f26-0653-4784-bba3-3253af0958ab@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

I looked at the changes in oops, runtime, classfile and code directories.

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

Marked as reviewed by coleenp (Reviewer).

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

From erikj at openjdk.java.net  Thu Apr  8 19:54:07 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 8 Apr 2021 19:54:07 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <fqV6HvSPDuUiTGTAOxfZ7YpMrNmn0tLPFlPCSjf9zJc=.19110c8b-c210-463e-860d-8ec13d0160f0@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From stefank at openjdk.java.net  Thu Apr  8 20:04:07 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 8 Apr 2021 20:04:07 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <qAqfbw9odHV4Our9-TXmABErJnJwQqmCH1j4XJLV2yk=.733aa4d6-7710-4c6f-8db2-6300d399d492@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

GC changes look good.

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

Marked as reviewed by stefank (Reviewer).

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

From kvn at openjdk.java.net  Thu Apr  8 20:04:08 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 20:04:08 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <qAqfbw9odHV4Our9-TXmABErJnJwQqmCH1j4XJLV2yk=.733aa4d6-7710-4c6f-8db2-6300d399d492@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <qAqfbw9odHV4Our9-TXmABErJnJwQqmCH1j4XJLV2yk=.733aa4d6-7710-4c6f-8db2-6300d399d492@github.com>
Message-ID: <P7MB60v5xlZO4-xDgE9EzCJfWSDVF36aahOe4R0RK4o=.b205b33f-d376-46ba-a8c7-b2790a91fc25@github.com>

On Thu, 8 Apr 2021 19:58:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> GC changes look good.

> void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) {
> This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want.

Thank you, Coleen, for review. I will wait other comments and will remove this code.

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

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

From kvn at openjdk.java.net  Thu Apr  8 20:04:08 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 20:04:08 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <P7MB60v5xlZO4-xDgE9EzCJfWSDVF36aahOe4R0RK4o=.b205b33f-d376-46ba-a8c7-b2790a91fc25@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <qAqfbw9odHV4Our9-TXmABErJnJwQqmCH1j4XJLV2yk=.733aa4d6-7710-4c6f-8db2-6300d399d492@github.com>
 <P7MB60v5xlZO4-xDgE9EzCJfWSDVF36aahOe4R0RK4o=.b205b33f-d376-46ba-a8c7-b2790a91fc25@github.com>
Message-ID: <ev8mgaenIy2OM_DWsdaeWXqfA9n_mTGHNCqBDLVHvNk=.00135a1c-ac22-4f99-b00a-ce060169037c@github.com>

On Thu, 8 Apr 2021 20:00:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> GC changes look good.
>
>> void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) {
>> This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want.
> 
> Thank you, Coleen, for review. I will wait other comments and will remove this code.

Thank you, Erik and Stefan.

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

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

From iignatyev at openjdk.java.net  Thu Apr  8 20:31:11 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Apr 2021 20:31:11 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <dLbTg3Hf84jb3Sr9JRqByhd0_nh4vMSqp_33XJeikaM=.ce9e08d7-6516-4009-9a0b-0013ed9a12a1@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

Test changes look good to me.

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

Marked as reviewed by iignatyev (Reviewer).

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

From coleenp at openjdk.java.net  Thu Apr  8 21:03:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 8 Apr 2021 21:03:07 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <dLbTg3Hf84jb3Sr9JRqByhd0_nh4vMSqp_33XJeikaM=.ce9e08d7-6516-4009-9a0b-0013ed9a12a1@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <dLbTg3Hf84jb3Sr9JRqByhd0_nh4vMSqp_33XJeikaM=.ce9e08d7-6516-4009-9a0b-0013ed9a12a1@github.com>
Message-ID: <qjBKlSG7kBRP8akJ5LQx0jixIS3nYCGETetypfUb2rY=.3ef64c46-3518-44e1-83cf-c17bd64db662@github.com>

On Thu, 8 Apr 2021 20:28:27 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> Test changes look good to me.

There's a comment above
void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) {
that should be rewritten, so I think we should just file an RFE to remove it afterwards.

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

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

From github.com+70726043+rgiulietti at openjdk.java.net  Thu Apr  8 21:19:14 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 8 Apr 2021 21:19:14 GMT
Subject: RFR: 8264514: HexFormat implementation tweaks
In-Reply-To: <wV2FdN2pRDkE8M0EEKnvM5En47NyMBfCy9ISZqi0WrA=.83d77737-9b80-4840-a5c7-0409ef1e14ce@github.com>
References: <wV2FdN2pRDkE8M0EEKnvM5En47NyMBfCy9ISZqi0WrA=.83d77737-9b80-4840-a5c7-0409ef1e14ce@github.com>
Message-ID: <T4yYFir1RKxiR3HwoiuEauMbfSSs-2pXxo8Iba9L6PY=.d81b1d40-d3f4-4231-9089-805ad4d50af2@github.com>

On Wed, 7 Apr 2021 18:49:36 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

> (Changed to new branch in personal fork)
> 
> Please review these small tweaks.
> For background information see [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)
> 
> Greetings
> Raffaello

Automatically started Windows x64 tier1 tests are still running after more than 24 hours...

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Thu Apr  8 21:25:12 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Thu, 8 Apr 2021 21:25:12 GMT
Subject: Integrated: JDK-8264454 : Jaxp unit test from open jdk needs to be
 improved
In-Reply-To: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
References: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
Message-ID: <5-Myh9eqXj3Pn3hJhAP8Zw5diKZK2jIi7_iflPO_H7c=.be632e77-6787-4ff1-bf6e-65a6ecd4b335@github.com>

On Tue, 30 Mar 2021 16:56:57 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

> JDK-8264454 : Jaxp unit test from open jdk needs to be improved

This pull request has now been integrated.

Changeset: 308f6796
Author:    Mahendra Chhipa <mahendra.chhipa at oracle.com>
Committer: Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/308f6796
Stats:     757 lines in 8 files changed: 71 ins; 606 del; 80 mod

8264454: Jaxp unit test from open jdk needs to be improved

Reviewed-by: joehw

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

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

From naoto at openjdk.java.net  Thu Apr  8 21:27:20 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 8 Apr 2021 21:27:20 GMT
Subject: RFR: 8264765: BreakIterator sees bogus sentence boundary in
 parenthesized =?UTF-8?B?4oCcaS5lLuKAnQ==?= phrase
Message-ID: <RWM--Xx47tXkDwysIImFsvNCqU6H9chw-cqPEzYR9TI=.e70ab795-bac0-4580-bac4-52abe8a61c85@github.com>

Please review the fix to the subject issue. It is not actually related to "parenthesized", but period-comma sequence was regarded as a break on a backward traverse.

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

Commit messages:
 - 8264765: BreakIterator sees bogus sentence boundary in parenthesized ?i.e.? phrase

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

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

From github.com+70726043+rgiulietti at openjdk.java.net  Thu Apr  8 21:27:59 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 8 Apr 2021 21:27:59 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results
Message-ID: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>

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

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

Commit messages:
 - 4511638: Double.toString(double) sometimes produces incorrect results

Changes: https://git.openjdk.java.net/jdk/pull/3402/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-4511638
  Stats: 4237 lines in 15 files changed: 4116 ins; 54 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402

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

From github.com+70726043+rgiulietti at openjdk.java.net  Thu Apr  8 21:27:59 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 8 Apr 2021 21:27:59 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <ZZ5yFa5Yp9pn-EQQ4LbKskpOde1vxotwI_ZNh_q5q5k=.94794852-4b82-479a-ac4d-43b3cd3d903b@github.com>

On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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

Forgot to add that other changes in the code are the use of switch expressions and the use of instanceof patterns.

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

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

From kvn at openjdk.java.net  Thu Apr  8 21:57:07 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 21:57:07 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <qjBKlSG7kBRP8akJ5LQx0jixIS3nYCGETetypfUb2rY=.3ef64c46-3518-44e1-83cf-c17bd64db662@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <dLbTg3Hf84jb3Sr9JRqByhd0_nh4vMSqp_33XJeikaM=.ce9e08d7-6516-4009-9a0b-0013ed9a12a1@github.com>
 <qjBKlSG7kBRP8akJ5LQx0jixIS3nYCGETetypfUb2rY=.3ef64c46-3518-44e1-83cf-c17bd64db662@github.com>
Message-ID: <UB5Y0bV48eM9xCNqaxfdSEHa1ROJyGKAABlAs0Uu2io=.6cd68e34-d190-4580-be4a-cfb0c669a327@github.com>

On Thu, 8 Apr 2021 20:59:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There's a comment above
> void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) {
> that should be rewritten, so I think we should just file an RFE to remove it afterwards.

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

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

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

From joehw at openjdk.java.net  Thu Apr  8 23:50:14 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 8 Apr 2021 23:50:14 GMT
Subject: RFR: 8264765: BreakIterator sees bogus sentence boundary in
 parenthesized =?UTF-8?B?4oCcaS5lLuKAnQ==?= phrase
In-Reply-To: <RWM--Xx47tXkDwysIImFsvNCqU6H9chw-cqPEzYR9TI=.e70ab795-bac0-4580-bac4-52abe8a61c85@github.com>
References: <RWM--Xx47tXkDwysIImFsvNCqU6H9chw-cqPEzYR9TI=.e70ab795-bac0-4580-bac4-52abe8a61c85@github.com>
Message-ID: <H0I9I1R415L_EdtIqnHFaet2yx0zq-18S1RBQBPdMRM=.13fa0af8-1e51-4fce-9a57-0a8baf33bbbc@github.com>

On Thu, 8 Apr 2021 18:19:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. It is not actually related to "parenthesized", but period-comma sequence was regarded as a break on a backward traverse.

Marked as reviewed by joehw (Reviewer).

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

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

From dongbo at openjdk.java.net  Fri Apr  9 01:31:21 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 9 Apr 2021 01:31:21 GMT
Subject: Integrated: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <uKMipGivuWdeMN-7Zc-CYY3OehrZMV2X0b18N2wOKcM=.2509357d-110b-4e2c-b833-531343251db8@github.com>

On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

This pull request has now been integrated.

Changeset: 77b16739
Author:    Dong Bo <dongbo at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77b16739
Stats:     436 lines in 3 files changed: 436 ins; 0 del; 0 mod

8256245: AArch64: Implement Base64 decoding intrinsic

Reviewed-by: aph, ngasson

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

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

From dholmes at openjdk.java.net  Fri Apr  9 04:35:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 9 Apr 2021 04:35:15 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

Hi Vladimir,

This looks good to me - I went through all the files.

It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??

I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.

Thanks,
David

src/hotspot/cpu/x86/compiledIC_x86.cpp line 134:

> 132: #ifdef ASSERT
> 133:   CodeBlob *cb = CodeCache::find_blob_unsafe((address) _call);
> 134:   assert(cb, "sanity");

Nit: implied boolean - use "cb != NULL"

src/hotspot/share/memory/heap.hpp line 174:

> 172:   bool contains(const void* p) const             { return low() <= p && p < high(); }
> 173:   bool contains_blob(const CodeBlob* blob) const {
> 174:     const void* start = (void*)blob;

start seems redundant now

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

Marked as reviewed by dholmes (Reviewer).

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

From aph at openjdk.java.net  Fri Apr  9 08:18:18 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 9 Apr 2021 08:18:18 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <7ioJ2_GFIK53zxpqFcYLt9LYDd8WS7ronekRuo6O5Ac=.572d87d5-2f1f-41cf-8c9b-6d018926f0cf@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

AArch64 looks fine.

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

Marked as reviewed by aph (Reviewer).

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

From shade at openjdk.java.net  Fri Apr  9 08:54:18 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Apr 2021 08:54:18 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

Shenandoah parts look good. I have a few minor comments after reading the rest.

src/hotspot/cpu/x86/globalDefinitions_x86.hpp line 73:

> 71: 
> 72: #if INCLUDE_JVMCI
> 73: #define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS (EnableJVMCI)

Minor nit: can probably drop parentheses here.

src/hotspot/share/code/compiledIC.cpp line 715:

> 713:     tty->print("interpreted");
> 714:   } else {
> 715:     tty->print("unknown");

We can probably split this cleanup into the minor issue, your call. The benefit of separate issue: backportability.

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

Marked as reviewed by shade (Reviewer).

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

From chegar at openjdk.java.net  Fri Apr  9 09:30:49 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 9 Apr 2021 09:30:49 GMT
Subject: RFR: 8264827: Large mapped buffer/segment crash the VM when calling
 isLoaded
Message-ID: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>

Avoid overflow when calculating the number of pages for large mapped segment sizes.

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

Commit messages:
 - Test update
 - Initial changes

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

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

From shade at openjdk.java.net  Fri Apr  9 09:48:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Apr 2021 09:48:36 GMT
Subject: RFR: 8264976: Minor numeric bug in
 AbstractSplittableWithBrineGenerator.makeSplitsSpliterator
Message-ID: <qzQKVrErONUrofcWd5FuIztqiIaA9_SYBeJRIwZxLxs=.a5232bfa-db14-486f-8940-74b2707b1265@github.com>

SonarCloud reports:
  Cast one of the operands of this subtraction operation to a "long".

Here:
        Spliterator<SplittableGenerator> makeSplitsSpliterator(long index, long fence, SplittableGenerator source) {
            ...
            long multiplier = (1 << SALT_SHIFT) - 1; // <---- here

The shift is integer, and the cast to long is too late. `SALT_SHIFT` is currently 4, so this is not the problem. But it would become a problem if `SALT_SHIFT` ever becomes 32 or larger. The shift operand should be `1L` for safety. Observe:

jshell> Long.toHexString((1 << 31) - 1)
$2 ==> "7fffffff"

jshell> Long.toHexString((1 << 32) - 1)
$3 ==> "0"

jshell> Long.toHexString((1L << 32) - 1)
$4 ==> "ffffffff"

Additional testing: 
 - [x] Linux x86_64 fastdebug, `jdk/utils/Random`

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

Commit messages:
 - 8264976: Minor numeric bug in AbstractSplittableWithBrineGenerator.makeSplitsSpliterator

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

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

From chegar at openjdk.java.net  Fri Apr  9 10:19:21 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 9 Apr 2021 10:19:21 GMT
Subject: RFR: 8264827: Large mapped buffer/segment crash the VM when
 calling isLoaded
In-Reply-To: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>
References: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>
Message-ID: <duKrsHD0fkzxHS7shaMYafpcoBASlj9thYwNFYsbuCg=.acd5d807-868d-4fac-81a9-568b30d71022@github.com>

On Wed, 7 Apr 2021 15:45:30 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Avoid overflow when calculating the number of pages for large mapped segment sizes.

Note for reviewers on the test. A 3GB file is sufficient to demonstrate the issue in the old code, as follows (with a 4K page size, since the narrowing cast of size is the significant issue):

jshell> int pageSize() { return 4 * 1024; }
|  created method pageSize()

jshell> int pageCount(long size) { return (int)(size + (long)pageSize() - 1L) / pageSize(); }
|  created method pageCount(long)

jshell> pageCount(3L * 1024L * 1024L * 1024L)
$3 ==> -262143

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

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

From jvernee at openjdk.java.net  Fri Apr  9 10:51:53 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 9 Apr 2021 10:51:53 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a set
 of MethodHandles
Message-ID: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>

This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode.

The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case?

Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch.

The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant.

Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining.

Some numbers from the added benchmarks:
Benchmark                                        (numCases)  (offset)  (sorted)  Mode  Cnt   Score   Error  Units
MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A  avgt   30   4.186 ? 0.054  ms/op
MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A  avgt   30   4.164 ? 0.057  ms/op
MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A  avgt   30   4.124 ? 0.023  ms/op
MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A  avgt   30   4.126 ? 0.025  ms/op
MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A  avgt   30   4.137 ? 0.042  ms/op
MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A  avgt   30   4.113 ? 0.016  ms/op
MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A  avgt   30   4.118 ? 0.028  ms/op
MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A  avgt   30   4.127 ? 0.019  ms/op
MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A  avgt   30   4.116 ? 0.013  ms/op
MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A  avgt   30   4.121 ? 0.020  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A  avgt   30   4.113 ? 0.009  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A  avgt   30   4.149 ? 0.041  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A  avgt   30   4.121 ? 0.026  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A  avgt   30   4.113 ? 0.021  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A  avgt   30   4.129 ? 0.028  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A  avgt   30   4.105 ? 0.019  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A  avgt   30   4.097 ? 0.021  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A  avgt   30   4.131 ? 0.037  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A  avgt   30   4.135 ? 0.025  ms/op
MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A  avgt   30   4.139 ? 0.145  ms/op
MethodHandlesTableSwitchRandom.testSwitch                 5         0      true  avgt   30   4.894 ? 0.028  ms/op
MethodHandlesTableSwitchRandom.testSwitch                 5         0     false  avgt   30  11.526 ? 0.194  ms/op
MethodHandlesTableSwitchRandom.testSwitch                 5       150      true  avgt   30   4.882 ? 0.025  ms/op
MethodHandlesTableSwitchRandom.testSwitch                 5       150     false  avgt   30  11.532 ? 0.034  ms/op
MethodHandlesTableSwitchRandom.testSwitch                10         0      true  avgt   30   5.065 ? 0.076  ms/op
MethodHandlesTableSwitchRandom.testSwitch                10         0     false  avgt   30  13.016 ? 0.020  ms/op
MethodHandlesTableSwitchRandom.testSwitch                10       150      true  avgt   30   5.103 ? 0.051  ms/op
MethodHandlesTableSwitchRandom.testSwitch                10       150     false  avgt   30  12.984 ? 0.102  ms/op
MethodHandlesTableSwitchRandom.testSwitch                25         0      true  avgt   30   8.441 ? 0.165  ms/op
MethodHandlesTableSwitchRandom.testSwitch                25         0     false  avgt   30  13.371 ? 0.060  ms/op
MethodHandlesTableSwitchRandom.testSwitch                25       150      true  avgt   30   8.628 ? 0.032  ms/op
MethodHandlesTableSwitchRandom.testSwitch                25       150     false  avgt   30  13.542 ? 0.020  ms/op
MethodHandlesTableSwitchRandom.testSwitch                50         0      true  avgt   30   4.701 ? 0.015  ms/op
MethodHandlesTableSwitchRandom.testSwitch                50         0     false  avgt   30  13.562 ? 0.063  ms/op
MethodHandlesTableSwitchRandom.testSwitch                50       150      true  avgt   30   7.991 ? 3.111  ms/op
MethodHandlesTableSwitchRandom.testSwitch                50       150     false  avgt   30  13.543 ? 0.088  ms/op
MethodHandlesTableSwitchRandom.testSwitch               100         0      true  avgt   30   4.712 ? 0.020  ms/op
MethodHandlesTableSwitchRandom.testSwitch               100         0     false  avgt   30  13.600 ? 0.085  ms/op
MethodHandlesTableSwitchRandom.testSwitch               100       150      true  avgt   30   4.676 ? 0.011  ms/op
MethodHandlesTableSwitchRandom.testSwitch               100       150     false  avgt   30  13.476 ? 0.043  ms/op

Testing:
- [x] Running of included benchmarks
- [x] Inspecting inlining trace and verifying method handle targets are inlined
- [x] Running TestTableSwitch test (currently the only user of the new code)
- [x] Running java/lang/invoke tests (just in case)
- [x] Some manual testing

Thanks,
Jorn

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

Commit messages:
 - Improve test
 - Touchup
 - Use cases array + holder
 - WIP - implement tableSwitch combinator in lambda form interpreter

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

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

From alanb at openjdk.java.net  Fri Apr  9 11:55:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 9 Apr 2021 11:55:14 GMT
Subject: RFR: 8264827: Large mapped buffer/segment crash the VM when
 calling isLoaded
In-Reply-To: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>
References: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>
Message-ID: <QDv_dMIWuDAdkeouCHg-ejm46sDt9nhBgMxkGDGD-tA=.dacd3e05-9291-42ad-8892-463291227e0f@github.com>

On Wed, 7 Apr 2021 15:45:30 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Avoid overflow when calculating the number of pages for large mapped segment sizes.

Looks okay to me.

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

Marked as reviewed by alanb (Reviewer).

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

From ccleary at openjdk.java.net  Fri Apr  9 13:22:38 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 9 Apr 2021 13:22:38 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
Message-ID: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>

### Description
This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.

- AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.

### Fixes
- Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.

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

Commit messages:
 - 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI

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

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

From alanb at openjdk.java.net  Fri Apr  9 13:33:25 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 9 Apr 2021 13:33:25 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
In-Reply-To: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
Message-ID: <YkEe7dreyHP8-9mls649wwEN7EC_wKLwRtcGKnYSe6c=.701aae38-6a2e-4552-9f5e-75c020faa938@github.com>

On Fri, 9 Apr 2021 13:15:16 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> ### Description
> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
> 
> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
> 
> ### Fixes
> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 401:

> 399:         return AccessController.doPrivileged(
> 400:                 (PrivilegedAction<String>) () -> System.getProperty(propName, defVal)
> 401:         );

If you want to avoid the cast then you could create the PrivilegedAction explicitly, e.g.

PrivilegedAction<String> pa = () -> System.getProperty(propName, defVal);
return AccessController.doPrivileged(pa);

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

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

From rriggs at openjdk.java.net  Fri Apr  9 13:55:25 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 9 Apr 2021 13:55:25 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
In-Reply-To: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
Message-ID: <so-JHo-zCJLzP1A-f6PyAQmMGeDd1SEHlWXWkgTHGIw=.5249d1d2-a236-4081-956e-f45414c9cfad@github.com>

On Fri, 9 Apr 2021 13:15:16 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> ### Description
> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
> 
> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
> 
> ### Fixes
> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.

Looks good.

A general reminder about one important difference between an anonymous inner class and a lambda.
An anonymous has *identity* but a lambda does not; or only accidentally.
None of the uses here require identity.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 413:

> 411:         return AccessController.doPrivileged(
> 412:                 (PrivilegedAction<Long>) () -> Long.getLong(propName, defVal).longValue()
> 413:         );

And GetIntegerAction here. Though it only supports an int value.

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

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

From rriggs at openjdk.java.net  Fri Apr  9 13:55:26 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 9 Apr 2021 13:55:26 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
In-Reply-To: <YkEe7dreyHP8-9mls649wwEN7EC_wKLwRtcGKnYSe6c=.701aae38-6a2e-4552-9f5e-75c020faa938@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <YkEe7dreyHP8-9mls649wwEN7EC_wKLwRtcGKnYSe6c=.701aae38-6a2e-4552-9f5e-75c020faa938@github.com>
Message-ID: <WrL54cbMBIH9MVKDjR_b8GaaNDjUy7KLg_l5Wt3relo=.5fc37927-5e2e-4f4e-b25a-b005a5982723@github.com>

On Fri, 9 Apr 2021 13:30:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
>> 
>> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
>> 
>> ### Fixes
>> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.
>
> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 401:
> 
>> 399:         return AccessController.doPrivileged(
>> 400:                 (PrivilegedAction<String>) () -> System.getProperty(propName, defVal)
>> 401:         );
> 
> If you want to avoid the cast then you could create the PrivilegedAction explicitly, e.g.
> 
> PrivilegedAction<String> pa = () -> System.getProperty(propName, defVal);
> return AccessController.doPrivileged(pa);

An alternative here would be to use sun.security.action.privilegedGetProperty(prop, default).
The package is already exported from java.base to java.desktop, etc.

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

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

From ccleary at openjdk.java.net  Fri Apr  9 13:55:26 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 9 Apr 2021 13:55:26 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
In-Reply-To: <WrL54cbMBIH9MVKDjR_b8GaaNDjUy7KLg_l5Wt3relo=.5fc37927-5e2e-4f4e-b25a-b005a5982723@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <YkEe7dreyHP8-9mls649wwEN7EC_wKLwRtcGKnYSe6c=.701aae38-6a2e-4552-9f5e-75c020faa938@github.com>
 <WrL54cbMBIH9MVKDjR_b8GaaNDjUy7KLg_l5Wt3relo=.5fc37927-5e2e-4f4e-b25a-b005a5982723@github.com>
Message-ID: <ZX6X4R6XoMSzXDq1EboV4YfCdn2u23g4T6im8hofJ0M=.b4969ffc-76d3-44e2-8698-04cf7d378d21@github.com>

On Fri, 9 Apr 2021 13:45:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 401:
>> 
>>> 399:         return AccessController.doPrivileged(
>>> 400:                 (PrivilegedAction<String>) () -> System.getProperty(propName, defVal)
>>> 401:         );
>> 
>> If you want to avoid the cast then you could create the PrivilegedAction explicitly, e.g.
>> 
>> PrivilegedAction<String> pa = () -> System.getProperty(propName, defVal);
>> return AccessController.doPrivileged(pa);
>
> An alternative here would be to use sun.security.action.privilegedGetProperty(prop, default).
> The package is already exported from java.base to java.desktop, etc.

That is a very neat alternative yes. Approaching the problem like that especially improves the readability [JdkLDAP.java](https://github.com/openjdk/jdk/pull/3416/files#diff-bf4c67da93cf2b9196508db2d57f7e01bc884f2268f5bfd43a9f01dfd55e4955) in my opinion. 
I don't think casting has any major performance hits for these fixes, so is your suggestion mostly for readability's sake?

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

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

From rriggs at openjdk.java.net  Fri Apr  9 14:04:27 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 9 Apr 2021 14:04:27 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
In-Reply-To: <ZX6X4R6XoMSzXDq1EboV4YfCdn2u23g4T6im8hofJ0M=.b4969ffc-76d3-44e2-8698-04cf7d378d21@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <YkEe7dreyHP8-9mls649wwEN7EC_wKLwRtcGKnYSe6c=.701aae38-6a2e-4552-9f5e-75c020faa938@github.com>
 <WrL54cbMBIH9MVKDjR_b8GaaNDjUy7KLg_l5Wt3relo=.5fc37927-5e2e-4f4e-b25a-b005a5982723@github.com>
 <ZX6X4R6XoMSzXDq1EboV4YfCdn2u23g4T6im8hofJ0M=.b4969ffc-76d3-44e2-8698-04cf7d378d21@github.com>
Message-ID: <S92o3Wl2IkxOK2eC6SkbSIHICXcvrMt3DPAuqbUrLt4=.d66ba502-3601-4f2a-8767-b53ce33f457e@github.com>

On Fri, 9 Apr 2021 13:51:30 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> An alternative here would be to use sun.security.action.privilegedGetProperty(prop, default).
>> The package is already exported from java.base to java.desktop, etc.
>
> That is a very neat alternative yes. Approaching the problem like that especially improves the readability [JdkLDAP.java](https://github.com/openjdk/jdk/pull/3416/files#diff-bf4c67da93cf2b9196508db2d57f7e01bc884f2268f5bfd43a9f01dfd55e4955) in my opinion. 
> I don't think casting has any major performance hits for these fixes, so is your suggestion mostly for readability's sake?

Right, not a performance problem.  Just simpler to use an existing method to read a privileged property.
And there will be one less doPriv.

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

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

From mgrzejszczak at vmware.com  Fri Apr  9 14:29:32 2021
From: mgrzejszczak at vmware.com (Marcin Grzejszczak)
Date: Fri, 9 Apr 2021 14:29:32 +0000
Subject: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16
Message-ID: <DS7PR05MB7336C87120CE63D1072BC12AB8739@DS7PR05MB7336.namprd05.prod.outlook.com>

Hi!

I'm the lead of Spring Cloud Sleuth [1], a project dedicated to working with distributed tracing. We're propagating the tracing context e.g. through threads. That means that when a user spawns a new thread we need to pass the context from the old thread to the new one. Example - if the user uses an Executor or an ExecutorService (e.g. via calling the execute(Runnable r)? method) then we need to wrap the Runnable? in its trace representation. That means that we retrieve the context from Thread A , pass it in the constructor of the TraceRunnable? and then restore it once the run? method is called in Thread B.

The problem in Sleuth that we have with JDK16 is that we can't use reflection to ensure that we're wrapping all methods of any Executors [2]. In other words we want to create a proxy around an existing Executor and wrap all methods. Currently, we're using reflection cause Executor implementations such as `ScheduledThreadPoolExecutor` have quite a few protected methods that we can't access. What we would like to achieve is a delegation mechanism that we can wrap all objects that the given Executor is using within their API (such as Runnables, Callables, other Executors) in their trace representation and then delegate calls for all methods to the wrapped object. That would also mean the delegation to currently protected methods.

If there's another way to achieve this other than opening the java.util.concurrent API then I would very much like to use it. Currently with JDK16 it's not possible to instrument that code so context propagation might be buggy when dealing with executors.

[1] - https://spring.io/projects/spring-cloud-sleuth
Spring Cloud Sleuth<https://spring.io/projects/spring-cloud-sleuth>
Adds trace and span ids to the Slf4J MDC, so you can extract all the logs from a given trace or span in a log aggregator. Instruments common ingress and egress points from Spring applications (servlet filter, rest template, scheduled actions, message channels, feign client).
spring.io
?
?

[2] - https://github.com/spring-cloud/spring-cloud-sleuth/issues/1897
[https://avatars.githubusercontent.com/u/7815877?s=400&v=4]<https://github.com/spring-cloud/spring-cloud-sleuth/issues/1897>
InaccessibleObjectException when calling getScheduledThreadPoolExecutor ? Issue #1897 ? spring-cloud/spring-cloud-sleuth<https://github.com/spring-cloud/spring-cloud-sleuth/issues/1897>
Describe the bug When calling the method LazyTraceThreadPoolTaskScheduler.getScheduledThreadPoolExecutor(), a new LazyTraceScheduledThreadPoolExecutor is created. The constructor of the pool execut...
github.com
?
?



Marcin Grzejszczak
Staff Engineer, Spring Cloud


From bpb at openjdk.java.net  Fri Apr  9 14:52:21 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 9 Apr 2021 14:52:21 GMT
Subject: RFR: 8261301: StringWriter.flush() is NOOP but documentation does
 not indicate it
In-Reply-To: <c9aYMne-uFk5N0fr5lL65MwTs8P8SoKSkckP_gcCRQI=.cf43d04c-f2e8-4ecd-a3f3-56f2f562b27a@github.com>
References: <0RH475n7cuVmKrEsDrROhuNshYwHny1ITlHPYlzNg4Q=.952e9c4a-2e62-4426-be0c-5f91ce7dc7b5@github.com>
 <c9aYMne-uFk5N0fr5lL65MwTs8P8SoKSkckP_gcCRQI=.cf43d04c-f2e8-4ecd-a3f3-56f2f562b27a@github.com>
Message-ID: <XsTYk_xzBKecl7_l2gP1bFILmRvT_AwvQtdsAzwTjhU=.59d9b6bf-3aef-45c5-87d8-8fde38c8078c@github.com>

On Thu, 8 Apr 2021 13:46:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The specification of the method `flush()` in the `java.io` classes `CharArrayWriter` and `StringWriter` is not explicit about the fact that the method has no effect. This request proposes to add to the specification of each flush() method the sentence
>> The {@code flush} method of {@code <ClassName/>} does nothing.
>> The corresponding CSR is JDK-8264867.
>
> In the CSR, the first sentence of the Summary should be context free.
> It is used standalone in other contexts to describe the change.  Perhaps change to:
> "Clarify the `flush` methods in java.io classes CharArrayWriter and StringWriter do nothing."

@RogerRiggs I updated the CSR as you suggested, thanks!

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

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

From forax at univ-mlv.fr  Fri Apr  9 15:18:11 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 9 Apr 2021 17:18:11 +0200 (CEST)
Subject: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16
In-Reply-To: <DS7PR05MB7336C87120CE63D1072BC12AB8739@DS7PR05MB7336.namprd05.prod.outlook.com>
References: <DS7PR05MB7336C87120CE63D1072BC12AB8739@DS7PR05MB7336.namprd05.prod.outlook.com>
Message-ID: <376687683.1441983.1617981491321.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Marcin Grzejszczak" <mgrzejszczak at vmware.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 9 Avril 2021 16:29:32
> Objet: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

> Hi!
> 
> I'm the lead of Spring Cloud Sleuth [1], a project dedicated to working with
> distributed tracing. We're propagating the tracing context e.g. through
> threads. That means that when a user spawns a new thread we need to pass the
> context from the old thread to the new one. Example - if the user uses an
> Executor or an ExecutorService (e.g. via calling the execute(Runnable r)
> method) then we need to wrap the Runnable in its trace representation. That
> means that we retrieve the context from Thread A , pass it in the constructor
> of the TraceRunnable and then restore it once the run method is called in
> Thread B.
> 
> The problem in Sleuth that we have with JDK16 is that we can't use reflection to
> ensure that we're wrapping all methods of any Executors [2]. In other words we
> want to create a proxy around an existing Executor and wrap all methods.
> Currently, we're using reflection cause Executor implementations such as
> `ScheduledThreadPoolExecutor` have quite a few protected methods that we can't
> access. What we would like to achieve is a delegation mechanism that we can
> wrap all objects that the given Executor is using within their API (such as
> Runnables, Callables, other Executors) in their trace representation and then
> delegate calls for all methods to the wrapped object. That would also mean the
> delegation to currently protected methods.
> 
> If there's another way to achieve this other than opening the
> java.util.concurrent API then I would very much like to use it. Currently with
> JDK16 it's not possible to instrument that code so context propagation might be
> buggy when dealing with executors.

I'm not sure if you are using an agent or not, if you are using an agent, you can redefine a module
https://docs.oracle.com/en/java/javase/16/docs/api/java.instrument/java/lang/instrument/Instrumentation.html#redefineModule(java.lang.Module,java.util.Set,java.util.Map,java.util.Map,java.util.Set,java.util.Map)

regards,
R?mi

> 
> Marcin Grzejszczak
> Staff Engineer, Spring Cloud

From mgrzejszczak at vmware.com  Fri Apr  9 15:41:28 2021
From: mgrzejszczak at vmware.com (Marcin Grzejszczak)
Date: Fri, 9 Apr 2021 15:41:28 +0000
Subject: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16
In-Reply-To: <376687683.1441983.1617981491321.JavaMail.zimbra@u-pem.fr>
References: <DS7PR05MB7336C87120CE63D1072BC12AB8739@DS7PR05MB7336.namprd05.prod.outlook.com>,
 <376687683.1441983.1617981491321.JavaMail.zimbra@u-pem.fr>
Message-ID: <DS7PR05MB733638DD6AB73E39E0E95742B8739@DS7PR05MB7336.namprd05.prod.outlook.com>

That's the thing, I'm not using an agent. We're doing the wrapping at runtime by instrumenting spring beans.

Pobierz aplikacj? Outlook dla systemu iOS<https://aka.ms/o0ukef>
________________________________
Od: Remi Forax <forax at univ-mlv.fr>
Wys?ane: Friday, April 9, 2021 5:18:11 PM
Do: Marcin Grzejszczak <mgrzejszczak at vmware.com>
DW: core-libs-dev <core-libs-dev at openjdk.java.net>
Temat: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

----- Mail original -----
> De: "Marcin Grzejszczak" <mgrzejszczak at vmware.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 9 Avril 2021 16:29:32
> Objet: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

> Hi!
>
> I'm the lead of Spring Cloud Sleuth [1], a project dedicated to working with
> distributed tracing. We're propagating the tracing context e.g. through
> threads. That means that when a user spawns a new thread we need to pass the
> context from the old thread to the new one. Example - if the user uses an
> Executor or an ExecutorService (e.g. via calling the execute(Runnable r)
> method) then we need to wrap the Runnable in its trace representation. That
> means that we retrieve the context from Thread A , pass it in the constructor
> of the TraceRunnable and then restore it once the run method is called in
> Thread B.
>
> The problem in Sleuth that we have with JDK16 is that we can't use reflection to
> ensure that we're wrapping all methods of any Executors [2]. In other words we
> want to create a proxy around an existing Executor and wrap all methods.
> Currently, we're using reflection cause Executor implementations such as
> `ScheduledThreadPoolExecutor` have quite a few protected methods that we can't
> access. What we would like to achieve is a delegation mechanism that we can
> wrap all objects that the given Executor is using within their API (such as
> Runnables, Callables, other Executors) in their trace representation and then
> delegate calls for all methods to the wrapped object. That would also mean the
> delegation to currently protected methods.
>
> If there's another way to achieve this other than opening the
> java.util.concurrent API then I would very much like to use it. Currently with
> JDK16 it's not possible to instrument that code so context propagation might be
> buggy when dealing with executors.

I'm not sure if you are using an agent or not, if you are using an agent, you can redefine a module
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fjava%2Fjavase%2F16%2Fdocs%2Fapi%2Fjava.instrument%2Fjava%2Flang%2Finstrument%2FInstrumentation.html%23redefineModule&amp;data=04%7C01%7Cmgrzejszczak%40vmware.com%7Cc45688f3edb8423b9cae08d8fb6ab28a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637535782975891768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=RHHLZTpU5RMNx7JHwkgG79%2FHWlXsXYOG8bBw9WaYQCU%3D&amp;reserved=0(java.lang.Module,java.util.Set,java.util.Map,java.util.Map,java.util.Set,java.util.Map)

regards,
R?mi

>
> Marcin Grzejszczak
> Staff Engineer, Spring Cloud

From ccleary at openjdk.java.net  Fri Apr  9 15:44:18 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 9 Apr 2021 15:44:18 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
In-Reply-To: <S92o3Wl2IkxOK2eC6SkbSIHICXcvrMt3DPAuqbUrLt4=.d66ba502-3601-4f2a-8767-b53ce33f457e@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <YkEe7dreyHP8-9mls649wwEN7EC_wKLwRtcGKnYSe6c=.701aae38-6a2e-4552-9f5e-75c020faa938@github.com>
 <WrL54cbMBIH9MVKDjR_b8GaaNDjUy7KLg_l5Wt3relo=.5fc37927-5e2e-4f4e-b25a-b005a5982723@github.com>
 <ZX6X4R6XoMSzXDq1EboV4YfCdn2u23g4T6im8hofJ0M=.b4969ffc-76d3-44e2-8698-04cf7d378d21@github.com>
 <S92o3Wl2IkxOK2eC6SkbSIHICXcvrMt3DPAuqbUrLt4=.d66ba502-3601-4f2a-8767-b53ce33f457e@github.com>
Message-ID: <2Gxd3r3g-ZHlCtLt2dCrqCiJPuERgJCRO4umyyHR1pc=.387bd392-ca48-4ff6-b0fc-efd5b81148dc@github.com>

On Fri, 9 Apr 2021 14:01:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> That is a very neat alternative yes. Approaching the problem like that especially improves the readability [JdkLDAP.java](https://github.com/openjdk/jdk/pull/3416/files#diff-bf4c67da93cf2b9196508db2d57f7e01bc884f2268f5bfd43a9f01dfd55e4955) in my opinion. 
>> I don't think casting has any major performance hits for these fixes, so is your suggestion mostly for readability's sake?
>
> Right, not a performance problem.  Just simpler to use an existing method to read a privileged property.
> And there will be one less doPriv.

I think I may change the PR to reflect what Alan suggested. Its more readable than the lambda-with-cast solution in that an action is created _and then_ an action is carried out as supposed to fitting it all into one call. Its also as concise.

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

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

From ccleary at openjdk.java.net  Fri Apr  9 15:51:36 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 9 Apr 2021 15:51:36 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
In-Reply-To: <so-JHo-zCJLzP1A-f6PyAQmMGeDd1SEHlWXWkgTHGIw=.5249d1d2-a236-4081-956e-f45414c9cfad@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <so-JHo-zCJLzP1A-f6PyAQmMGeDd1SEHlWXWkgTHGIw=.5249d1d2-a236-4081-956e-f45414c9cfad@github.com>
Message-ID: <1sJidHe6B9avCln-Fqqklfv4TKrXL64_utx21MprrYk=.817a96d0-71db-4dec-9dfa-8d66b5854452@github.com>

On Fri, 9 Apr 2021 13:46:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
>> 
>> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
>> 
>> ### Fixes
>> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.
>
> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 413:
> 
>> 411:         return AccessController.doPrivileged(
>> 412:                 (PrivilegedAction<Long>) () -> Long.getLong(propName, defVal).longValue()
>> 413:         );
> 
> And GetIntegerAction here. Though it only supports an int value.

Thanks for the suggestion Roger, I think the `privilegedGetProperty(prop, default)` for the `getProperty()` method looks great. 

WRT to using it for `getInt()` and `getLong()`, I think its reasonable to use other means for these methods in the interest of consistency due to, as you pointed out, only `int` being supported. Would you think? Or would it be better to use the same means in all 3 methods?

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

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

From forax at univ-mlv.fr  Fri Apr  9 16:33:10 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 9 Apr 2021 18:33:10 +0200 (CEST)
Subject: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16
In-Reply-To: <DS7PR05MB733638DD6AB73E39E0E95742B8739@DS7PR05MB7336.namprd05.prod.outlook.com>
References: <DS7PR05MB7336C87120CE63D1072BC12AB8739@DS7PR05MB7336.namprd05.prod.outlook.com>
 <376687683.1441983.1617981491321.JavaMail.zimbra@u-pem.fr>
 <DS7PR05MB733638DD6AB73E39E0E95742B8739@DS7PR05MB7336.namprd05.prod.outlook.com>
Message-ID: <1155571019.1500171.1617985990552.JavaMail.zimbra@u-pem.fr>

> De: "Marcin Grzejszczak" <mgrzejszczak at vmware.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 9 Avril 2021 17:41:28
> Objet: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

> That's the thing, I'm not using an agent. We're doing the wrapping at runtime by
> instrumenting spring beans.

Apart the fact that decorateTask is a good example of why it's better to use delegation than using the template method pattern. 
Why do you need to call decorateTask() directly, and not execute/submit/invoke with your wrapped Runnable ? 

R?mi 

> Pobierz aplikacj? [ https://aka.ms/o0ukef |
> Outlook dla systemu iOS ]

> Od: Remi Forax <forax at univ-mlv.fr>
> Wys?ane: Friday, April 9, 2021 5:18:11 PM
> Do: Marcin Grzejszczak <mgrzejszczak at vmware.com>
> DW: core-libs-dev <core-libs-dev at openjdk.java.net>
> Temat: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16
> ----- Mail original -----
> > De: "Marcin Grzejszczak" <mgrzejszczak at vmware.com>
> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Vendredi 9 Avril 2021 16:29:32
> > Objet: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

> > Hi!

> > I'm the lead of Spring Cloud Sleuth [1], a project dedicated to working with
> > distributed tracing. We're propagating the tracing context e.g. through
> > threads. That means that when a user spawns a new thread we need to pass the
> > context from the old thread to the new one. Example - if the user uses an
> > Executor or an ExecutorService (e.g. via calling the execute(Runnable r)
> > method) then we need to wrap the Runnable in its trace representation. That
> > means that we retrieve the context from Thread A , pass it in the constructor
> > of the TraceRunnable and then restore it once the run method is called in
> > Thread B.

> > The problem in Sleuth that we have with JDK16 is that we can't use reflection to
> > ensure that we're wrapping all methods of any Executors [2]. In other words we
> > want to create a proxy around an existing Executor and wrap all methods.
> > Currently, we're using reflection cause Executor implementations such as
> > `ScheduledThreadPoolExecutor` have quite a few protected methods that we can't
> > access. What we would like to achieve is a delegation mechanism that we can
> > wrap all objects that the given Executor is using within their API (such as
> > Runnables, Callables, other Executors) in their trace representation and then
> > delegate calls for all methods to the wrapped object. That would also mean the
> > delegation to currently protected methods.

> > If there's another way to achieve this other than opening the
> > java.util.concurrent API then I would very much like to use it. Currently with
> > JDK16 it's not possible to instrument that code so context propagation might be
> > buggy when dealing with executors.

> I'm not sure if you are using an agent or not, if you are using an agent, you
> can redefine a module
> [
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fjava%2Fjavase%2F16%2Fdocs%2Fapi%2Fjava.instrument%2Fjava%2Flang%2Finstrument%2FInstrumentation.html%23redefineModule&data=04%7C01%7Cmgrzejszczak%40vmware.com%7Cc45688f3edb8423b9cae08d8fb6ab28a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637535782975891768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=RHHLZTpU5RMNx7JHwkgG79%2FHWlXsXYOG8bBw9WaYQCU%3D&reserved=0(java.lang.Module,java.util.Set,java.util.Map,java.util.Map,java.util.Set,java.util.Map
> |
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fjava%2Fjavase%2F16%2Fdocs%2Fapi%2Fjava.instrument%2Fjava%2Flang%2Finstrument%2FInstrumentation.html%23redefineModule&amp;data=04%7C01%7Cmgrzejszczak%40vmware.com%7Cc45688f3edb8423b9cae08d8fb6ab28a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637535782975891768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=RHHLZTpU5RMNx7JHwkgG79%2FHWlXsXYOG8bBw9WaYQCU%3D&amp;reserved=0(java.lang.Module,java.util.Set,java.util.Map,java.util.Map,java.util.Set,java.util.Map
> ] )

> regards,
> R?mi


> > Marcin Grzejszczak
> > Staff Engineer, Spring Cloud

From rriggs at openjdk.java.net  Fri Apr  9 16:33:10 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 9 Apr 2021 16:33:10 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
In-Reply-To: <1sJidHe6B9avCln-Fqqklfv4TKrXL64_utx21MprrYk=.817a96d0-71db-4dec-9dfa-8d66b5854452@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <so-JHo-zCJLzP1A-f6PyAQmMGeDd1SEHlWXWkgTHGIw=.5249d1d2-a236-4081-956e-f45414c9cfad@github.com>
 <1sJidHe6B9avCln-Fqqklfv4TKrXL64_utx21MprrYk=.817a96d0-71db-4dec-9dfa-8d66b5854452@github.com>
Message-ID: <aQ2Xcg-PwlYCTma5o-F1e2sZ_n7aM2Lva_8RVzbKmq8=.e0236973-77af-47f7-8049-244db469dce5@github.com>

On Fri, 9 Apr 2021 15:47:35 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 413:
>> 
>>> 411:         return AccessController.doPrivileged(
>>> 412:                 (PrivilegedAction<Long>) () -> Long.getLong(propName, defVal).longValue()
>>> 413:         );
>> 
>> And GetIntegerAction here. Though it only supports an int value.
>
> Thanks for the suggestion Roger, I think the `privilegedGetProperty(prop, default)` for the `getProperty()` method looks great. 
> 
> WRT to using it for `getInt()` and `getLong()`, I think its reasonable to use other means for these methods in the interest of consistency due to, as you pointed out, only `int` being supported. Would you think? Or would it be better to use the same means in all 3 methods?

Its a slippery slope that might require a bit more investigation to check the expected value sizes to see if a change to the number of bits in the value for each property might break something.  Technical debt can take you down a rabbit hole. Quickest to just convert to the lamba as you proposed.

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

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

From github.com+70726043+rgiulietti at openjdk.java.net  Fri Apr  9 16:36:08 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 9 Apr 2021 16:36:08 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <ZZ5yFa5Yp9pn-EQQ4LbKskpOde1vxotwI_ZNh_q5q5k=.94794852-4b82-479a-ac4d-43b3cd3d903b@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <ZZ5yFa5Yp9pn-EQQ4LbKskpOde1vxotwI_ZNh_q5q5k=.94794852-4b82-479a-ac4d-43b3cd3d903b@github.com>
Message-ID: <aGafaAZyfJ-IXdw7or9nUlJn7BrRqxmN3ZhhudzuIyY=.1c9b951a-75f8-4289-8358-0d3c2a7da33a@github.com>

On Thu, 8 Apr 2021 21:20:34 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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
>
> Forgot to add that other changes in the code are the use of switch expressions and the use of instanceof patterns.

Hello,

here's some background information for those that didn't follow the mailing list for the last couple of years.

Some enjoyable properties of the novel algorithm:
* No intermediate objects are instantiated.
* Loop-free core algorithm.
* Only int and long arithmetic.
* No divisions at all.
* 17.7x speedup (jmh) [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065921.html).
* Randomized, yet reproducible deep diving tests (jtreg).
* Clear, unambiguous spec.
* All floats have been tested to fully meet the spec.
* Fully documented in [2](https://drive.google.com/file/d/1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN/view) and/or in comments.

See [3](https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062580.html) for some (invented) Q&A. The last Q&A deals with your investment in time for an informed review.


Greetings
Raffaello

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

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

From iveresov at openjdk.java.net  Fri Apr  9 16:41:20 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 9 Apr 2021 16:41:20 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1184:

> 1182:       }
> 1183:     } else if (jvmci_env()->isa_HotSpotMetaspaceConstantImpl(constant)) {
> 1184:       if (!_immutable_pic_compilation) {

All _immutable_pic_compilation mentions can be removed as well. It is true only for AOT compiles produced by Graal. It's never going to be used without AOT.

src/hotspot/share/oops/instanceKlass.hpp line 257:

> 255:     _misc_declares_nonstatic_concrete_methods = 1 << 6,  // directly declares non-static, concrete methods
> 256:     _misc_has_been_redefined                  = 1 << 7,  // class has been redefined
> 257:     _unused                                   = 1 << 8,  //

Any particular reason we don't want to remove this gap?

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

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

From bpb at openjdk.java.net  Fri Apr  9 16:42:16 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 9 Apr 2021 16:42:16 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <aGafaAZyfJ-IXdw7or9nUlJn7BrRqxmN3ZhhudzuIyY=.1c9b951a-75f8-4289-8358-0d3c2a7da33a@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <ZZ5yFa5Yp9pn-EQQ4LbKskpOde1vxotwI_ZNh_q5q5k=.94794852-4b82-479a-ac4d-43b3cd3d903b@github.com>
 <aGafaAZyfJ-IXdw7or9nUlJn7BrRqxmN3ZhhudzuIyY=.1c9b951a-75f8-4289-8358-0d3c2a7da33a@github.com>
Message-ID: <xeXaW0biu37nz7Bjfcfy72K9FoEkn3gEwjUiK2IqmR0=.7f4fd1d0-e713-49d4-85e9-8db7a2adad20@github.com>

On Fri, 9 Apr 2021 16:33:43 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

>> Forgot to add that other changes in the code are the use of switch expressions and the use of instanceof patterns.
>
> Hello,
> 
> here's some background information for those that didn't follow the mailing list for the last couple of years.
> 
> Some enjoyable properties of the novel algorithm:
> * No intermediate objects are instantiated.
> * Loop-free core algorithm.
> * Only int and long arithmetic.
> * No divisions at all.
> * 17.7x speedup (jmh) [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065921.html).
> * Randomized, yet reproducible deep diving tests (jtreg).
> * Clear, unambiguous spec.
> * All floats have been tested to fully meet the spec.
> * Fully documented in [2](https://drive.google.com/file/d/1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN/view) and/or in comments.
> 
> See [3](https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062580.html) for some (invented) Q&A. The last Q&A deals with your investment in time for an informed review.
> 
> 
> Greetings
> Raffaello

@rgiulietti Please issue the `/csr/` command here [1]. Speaking of which, does the CSR [2] need to be updated?

[1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/csr
[2] https://bugs.openjdk.java.net/browse/JDK-8202555

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

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

From github.com+70726043+rgiulietti at openjdk.java.net  Fri Apr  9 16:47:06 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 9 Apr 2021 16:47:06 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <xeXaW0biu37nz7Bjfcfy72K9FoEkn3gEwjUiK2IqmR0=.7f4fd1d0-e713-49d4-85e9-8db7a2adad20@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <ZZ5yFa5Yp9pn-EQQ4LbKskpOde1vxotwI_ZNh_q5q5k=.94794852-4b82-479a-ac4d-43b3cd3d903b@github.com>
 <aGafaAZyfJ-IXdw7or9nUlJn7BrRqxmN3ZhhudzuIyY=.1c9b951a-75f8-4289-8358-0d3c2a7da33a@github.com>
 <xeXaW0biu37nz7Bjfcfy72K9FoEkn3gEwjUiK2IqmR0=.7f4fd1d0-e713-49d4-85e9-8db7a2adad20@github.com>
Message-ID: <QuPJ3jQVdUFJ4X54BPrOVnoub74Ez5HDygkPmQ6MN_M=.8ad5e97f-6de6-42a3-96d7-4cb9defa0b89@github.com>

On Fri, 9 Apr 2021 16:39:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hello,
>> 
>> here's some background information for those that didn't follow the mailing list for the last couple of years.
>> 
>> Some enjoyable properties of the novel algorithm:
>> * No intermediate objects are instantiated.
>> * Loop-free core algorithm.
>> * Only int and long arithmetic.
>> * No divisions at all.
>> * 17.7x speedup (jmh) [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065921.html).
>> * Randomized, yet reproducible deep diving tests (jtreg).
>> * Clear, unambiguous spec.
>> * All floats have been tested to fully meet the spec.
>> * Fully documented in [2](https://drive.google.com/file/d/1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN/view) and/or in comments.
>> 
>> See [3](https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062580.html) for some (invented) Q&A. The last Q&A deals with your investment in time for an informed review.
>> 
>> 
>> Greetings
>> Raffaello
>
> @rgiulietti Please issue the `/csr/` command here [1]. Speaking of which, does the CSR [2] need to be updated?
> 
> [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/csr
> [2] https://bugs.openjdk.java.net/browse/JDK-8202555

@bplb No, the CSR [1] (https://bugs.openjdk.java.net/browse/JDK-8202555) needs no updates.

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

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

From github.com+70726043+rgiulietti at openjdk.java.net  Fri Apr  9 16:50:20 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 9 Apr 2021 16:50:20 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <QuPJ3jQVdUFJ4X54BPrOVnoub74Ez5HDygkPmQ6MN_M=.8ad5e97f-6de6-42a3-96d7-4cb9defa0b89@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <ZZ5yFa5Yp9pn-EQQ4LbKskpOde1vxotwI_ZNh_q5q5k=.94794852-4b82-479a-ac4d-43b3cd3d903b@github.com>
 <aGafaAZyfJ-IXdw7or9nUlJn7BrRqxmN3ZhhudzuIyY=.1c9b951a-75f8-4289-8358-0d3c2a7da33a@github.com>
 <xeXaW0biu37nz7Bjfcfy72K9FoEkn3gEwjUiK2IqmR0=.7f4fd1d0-e713-49d4-85e9-8db7a2adad20@github.com>
 <QuPJ3jQVdUFJ4X54BPrOVnoub74Ez5HDygkPmQ6MN_M=.8ad5e97f-6de6-42a3-96d7-4cb9defa0b89@github.com>
Message-ID: <4Y1I2tOubakn1P0R4aSgGovSzXuitsoTIgApHZGvoto=.4fcf2594-5f5d-4324-b150-c3b8b634dcae@github.com>

On Fri, 9 Apr 2021 16:44:18 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

>> @rgiulietti Please issue the `/csr/` command here [1]. Speaking of which, does the CSR [2] need to be updated?
>> 
>> [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/csr
>> [2] https://bugs.openjdk.java.net/browse/JDK-8202555
>
> @bplb No, the CSR [1] (https://bugs.openjdk.java.net/browse/JDK-8202555) needs no updates.

The langtools/tier1 test tools/javac/sym/ElementStructureTest.java fails on all 4 platforms supported by the automatic GH actions.
Does anybody have a clue? Is this something I should be worried about?

Thanks

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

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

From forax at univ-mlv.fr  Fri Apr  9 16:54:44 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 9 Apr 2021 18:54:44 +0200 (CEST)
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over
 a set of MethodHandles
In-Reply-To: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
References: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
Message-ID: <1039463632.1515198.1617987284725.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Jorn Vernee" <jvernee at openjdk.java.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 9 Avril 2021 12:51:53
> Objet: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

> This patch adds a `tableSwitch` combinator that can be used to switch over a set
> of method handles given an index, with a fallback in case the index is out of
> bounds, much like the `tableswitch` bytecode.
> 
> The combinator does not support specifying the starting index, so the switch
> cases always run from 0 to however many target handles are specified. A
> starting index can be added manually with another combination step that filters
> the input index by adding or subtracting a constant from it, which does not
> affect performance. One of the reasons for not supporting a starting index is
> that it allows for more lambda form sharing, but also simplifies the
> implementation somewhat. I guess an open question is if a convenience overload
> should be added for that case?

I think the combinator should be lookupswitch which is more general than tableswitch with a special case when generating the bytecode to generate a tableswitch instead of a lookupswitch if the indexes are subsequent.

> 
> Lookup switch can also be simulated by filtering the input through an injection
> function that translates it into a case index, which has also proven to have
> the ability to have comparable performance to, or even better performance than,
> a bytecode-native `lookupswitch` instruction. I plan to add such an injection
> function to the runtime libraries in the future as well. Maybe at that point it
> could be evaluated if it's worth it to add a lookup switch combinator as well,
> but I don't see an immediate need to include it in this patch.
> 

As i said in the bug when we discuss about that the filtering function,
i believe that the filtering function for emulating lookupswitch is lookupswitch itself.

> The current bytecode intrinsification generates a call for each switch case,
> which guarantees full inlining of the target method handles. Alternatively we
> could only have 1 callsite at the end of the switch, where each case just loads
> the target method handle, but currently this does not allow for inlining of the
> handles, since they are not constant.

This scheme also allows to never JIT compile a branch which is never used.

> 
> Maybe a future C2 optimization could look at the receiver input for invokeBasic
> call sites, and if the input is a phi node, clone the call for each constant
> input of the phi. I believe that would allow simplifying the bytecode without
> giving up on inlining.
> 
> Some numbers from the added benchmarks:
> Benchmark                                        (numCases)  (offset)  (sorted)
> Mode  Cnt   Score   Error  Units
> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A
> avgt   30   4.186 ? 0.054  ms/op
> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A
> avgt   30   4.164 ? 0.057  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A
> avgt   30   4.124 ? 0.023  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A
> avgt   30   4.126 ? 0.025  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A
> avgt   30   4.137 ? 0.042  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A
> avgt   30   4.113 ? 0.016  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A
> avgt   30   4.118 ? 0.028  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A
> avgt   30   4.127 ? 0.019  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A
> avgt   30   4.116 ? 0.013  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A
> avgt   30   4.121 ? 0.020  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A
> avgt   30   4.113 ? 0.009  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A
> avgt   30   4.149 ? 0.041  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A
> avgt   30   4.121 ? 0.026  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A
> avgt   30   4.113 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A
> avgt   30   4.129 ? 0.028  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A
> avgt   30   4.105 ? 0.019  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A
> avgt   30   4.097 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A
> avgt   30   4.131 ? 0.037  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A
> avgt   30   4.135 ? 0.025  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A
> avgt   30   4.139 ? 0.145  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true
> avgt   30   4.894 ? 0.028  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false
> avgt   30  11.526 ? 0.194  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true
> avgt   30   4.882 ? 0.025  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false
> avgt   30  11.532 ? 0.034  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0      true
> avgt   30   5.065 ? 0.076  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0     false
> avgt   30  13.016 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150      true
> avgt   30   5.103 ? 0.051  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150     false
> avgt   30  12.984 ? 0.102  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0      true
> avgt   30   8.441 ? 0.165  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0     false
> avgt   30  13.371 ? 0.060  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150      true
> avgt   30   8.628 ? 0.032  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150     false
> avgt   30  13.542 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0      true
> avgt   30   4.701 ? 0.015  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0     false
> avgt   30  13.562 ? 0.063  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150      true
> avgt   30   7.991 ? 3.111  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150     false
> avgt   30  13.543 ? 0.088  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0      true
> avgt   30   4.712 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0     false
> avgt   30  13.600 ? 0.085  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150      true
> avgt   30   4.676 ? 0.011  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150     false
> avgt   30  13.476 ? 0.043  ms/op
> 
> Testing:
> - [x] Running of included benchmarks
> - [x] Inspecting inlining trace and verifying method handle targets are inlined
> - [x] Running TestTableSwitch test (currently the only user of the new code)
> - [x] Running java/lang/invoke tests (just in case)
> - [x] Some manual testing
> 
> Thanks,
> Jorn
> 
> -------------
> 
> Commit messages:
> - Improve test
> - Touchup
> - Use cases array + holder
> - WIP - implement tableSwitch combinator in lambda form interpreter
> 
> Changes: https://git.openjdk.java.net/jdk/pull/3401/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3401&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8263087
>  Stats: 959 lines in 8 files changed: 955 ins; 0 del; 4 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/3401.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3401/head:pull/3401
> 
> PR: https://git.openjdk.java.net/jdk/pull/3401

From iklam at openjdk.java.net  Fri Apr  9 16:58:23 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 9 Apr 2021 16:58:23 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

LGTM. Just a small nit.

src/hotspot/share/oops/methodCounters.cpp line 77:

> 75: }
> 76: 
> 77: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) {

MethodCounters::metaspace_pointers_do can be removed altogether (also need to remove the declaration in methodCounter.hpp).

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

Marked as reviewed by iklam (Reviewer).

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

From naoto at openjdk.java.net  Fri Apr  9 16:58:49 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 9 Apr 2021 16:58:49 GMT
Subject: RFR: 8264208: Console charset API
Message-ID: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>

Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

Commit messages:
 - 8264208: Console charset API

Changes: https://git.openjdk.java.net/jdk/pull/3419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264208
  Stats: 202 lines in 9 files changed: 174 ins; 17 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

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

From bpb at openjdk.java.net  Fri Apr  9 16:55:27 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 9 Apr 2021 16:55:27 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <xeXaW0biu37nz7Bjfcfy72K9FoEkn3gEwjUiK2IqmR0=.7f4fd1d0-e713-49d4-85e9-8db7a2adad20@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <ZZ5yFa5Yp9pn-EQQ4LbKskpOde1vxotwI_ZNh_q5q5k=.94794852-4b82-479a-ac4d-43b3cd3d903b@github.com>
 <aGafaAZyfJ-IXdw7or9nUlJn7BrRqxmN3ZhhudzuIyY=.1c9b951a-75f8-4289-8358-0d3c2a7da33a@github.com>
 <xeXaW0biu37nz7Bjfcfy72K9FoEkn3gEwjUiK2IqmR0=.7f4fd1d0-e713-49d4-85e9-8db7a2adad20@github.com>
Message-ID: <i9iWzSjH-2-KhUIeetkkeDRGojtCfCXoK0k0PYS6rIE=.92ad4ff6-de4b-4615-a296-4eb3f868880d@github.com>

On Fri, 9 Apr 2021 16:39:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hello,
>> 
>> here's some background information for those that didn't follow the mailing list for the last couple of years.
>> 
>> Some enjoyable properties of the novel algorithm:
>> * No intermediate objects are instantiated.
>> * Loop-free core algorithm.
>> * Only int and long arithmetic.
>> * No divisions at all.
>> * 17.7x speedup (jmh) [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065921.html).
>> * Randomized, yet reproducible deep diving tests (jtreg).
>> * Clear, unambiguous spec.
>> * All floats have been tested to fully meet the spec.
>> * Fully documented in [2](https://drive.google.com/file/d/1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN/view) and/or in comments.
>> 
>> See [3](https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062580.html) for some (invented) Q&A. The last Q&A deals with your investment in time for an informed review.
>> 
>> 
>> Greetings
>> Raffaello
>
> @rgiulietti Please issue the `/csr/` command here [1]. Speaking of which, does the CSR [2] need to be updated?
> 
> [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/csr
> [2] https://bugs.openjdk.java.net/browse/JDK-8202555

> @bplb No, the CSR [1] (https://bugs.openjdk.java.net/browse/JDK-8202555) needs no updates.

OK, good. I wonder whether it should be moved back to `Draft` until someone else other than me has reviewed it?

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

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

From mgrzejszczak at vmware.com  Fri Apr  9 17:08:14 2021
From: mgrzejszczak at vmware.com (Marcin Grzejszczak)
Date: Fri, 9 Apr 2021 17:08:14 +0000
Subject: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16
In-Reply-To: <1155571019.1500171.1617985990552.JavaMail.zimbra@u-pem.fr>
References: <DS7PR05MB7336C87120CE63D1072BC12AB8739@DS7PR05MB7336.namprd05.prod.outlook.com>
 <376687683.1441983.1617981491321.JavaMail.zimbra@u-pem.fr>
 <DS7PR05MB733638DD6AB73E39E0E95742B8739@DS7PR05MB7336.namprd05.prod.outlook.com>,
 <1155571019.1500171.1617985990552.JavaMail.zimbra@u-pem.fr>
Message-ID: <DS7PR05MB73369B341790943A86F3EC00B8739@DS7PR05MB7336.namprd05.prod.outlook.com>

I'm decorating existing user or framework code. If they have custom behavior, i want to respect that instead of override it.

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Friday, April 9, 2021 6:33:10 PM
To: Marcin Grzejszczak <mgrzejszczak at vmware.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16



________________________________
De: "Marcin Grzejszczak" <mgrzejszczak at vmware.com>
?: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
Envoy?: Vendredi 9 Avril 2021 17:41:28
Objet: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16
That's the thing, I'm not using an agent. We're doing the wrapping at runtime by instrumenting spring beans.

Apart the fact that decorateTask is a good example of why it's better to use delegation than using the template method pattern.
Why do you need to call decorateTask() directly, and not execute/submit/invoke with your wrapped Runnable ?

R?mi


Pobierz aplikacj? Outlook dla systemu iOS<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fo0ukef&data=04%7C01%7Cmgrzejszczak%40vmware.com%7C945386adac8e497074c408d8fb752d00%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637535827988392448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BHiUJZH2bfIaGb30vvz%2BxrA%2B1IObAnEKLqIbwBBjl%2BM%3D&reserved=0>
________________________________
Od: Remi Forax <forax at univ-mlv.fr>
Wys?ane: Friday, April 9, 2021 5:18:11 PM
Do: Marcin Grzejszczak <mgrzejszczak at vmware.com>
DW: core-libs-dev <core-libs-dev at openjdk.java.net>
Temat: Re: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

----- Mail original -----
> De: "Marcin Grzejszczak" <mgrzejszczak at vmware.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 9 Avril 2021 16:29:32
> Objet: Instrumenting Executors - issues in Spring Cloud Sleuth and JDK16

> Hi!
>
> I'm the lead of Spring Cloud Sleuth [1], a project dedicated to working with
> distributed tracing. We're propagating the tracing context e.g. through
> threads. That means that when a user spawns a new thread we need to pass the
> context from the old thread to the new one. Example - if the user uses an
> Executor or an ExecutorService (e.g. via calling the execute(Runnable r)
> method) then we need to wrap the Runnable in its trace representation. That
> means that we retrieve the context from Thread A , pass it in the constructor
> of the TraceRunnable and then restore it once the run method is called in
> Thread B.
>
> The problem in Sleuth that we have with JDK16 is that we can't use reflection to
> ensure that we're wrapping all methods of any Executors [2]. In other words we
> want to create a proxy around an existing Executor and wrap all methods.
> Currently, we're using reflection cause Executor implementations such as
> `ScheduledThreadPoolExecutor` have quite a few protected methods that we can't
> access. What we would like to achieve is a delegation mechanism that we can
> wrap all objects that the given Executor is using within their API (such as
> Runnables, Callables, other Executors) in their trace representation and then
> delegate calls for all methods to the wrapped object. That would also mean the
> delegation to currently protected methods.
>
> If there's another way to achieve this other than opening the
> java.util.concurrent API then I would very much like to use it. Currently with
> JDK16 it's not possible to instrument that code so context propagation might be
> buggy when dealing with executors.

I'm not sure if you are using an agent or not, if you are using an agent, you can redefine a module
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fjava%2Fjavase%2F16%2Fdocs%2Fapi%2Fjava.instrument%2Fjava%2Flang%2Finstrument%2FInstrumentation.html%23redefineModule&amp;data=04%7C01%7Cmgrzejszczak%40vmware.com%7Cc45688f3edb8423b9cae08d8fb6ab28a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637535782975891768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=RHHLZTpU5RMNx7JHwkgG79%2FHWlXsXYOG8bBw9WaYQCU%3D&amp;reserved=0(java.lang.Module,java.util.Set,java.util.Map,java.util.Map,java.util.Set,java.util.Map<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fjava%2Fjavase%2F16%2Fdocs%2Fapi%2Fjava.instrument%2Fjava%2Flang%2Finstrument%2FInstrumentation.html%23redefineModule&data=04%7C01%7Cmgrzejszczak%40vmware.com%7C945386adac8e497074c408d8fb752d00%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637535827988397428%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OdUeAdV0it0JJfr%2FFQB4fc02EYlAfVXQkCX8vdgTx2Y%3D&reserved=0>)

regards,
R?mi

>
> Marcin Grzejszczak
> Staff Engineer, Spring Cloud


From kvn at openjdk.java.net  Fri Apr  9 17:13:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:13:17 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
Message-ID: <FkHY159OY-BZJOj3EpameQ-wQhLgiMyMrrjxu2JZQ8k=.f879e3aa-cdb7-40af-8826-3484a299e914@github.com>

On Fri, 9 Apr 2021 04:32:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Vladimir,
> 
> This looks good to me - I went through all the files.
> 
> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??
> 
> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.
> 
> Thanks,
> David

Thank you, David.
We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`.
I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000

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

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

From jorn.vernee at oracle.com  Fri Apr  9 17:39:32 2021
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Fri, 9 Apr 2021 19:39:32 +0200
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: <1039463632.1515198.1617987284725.JavaMail.zimbra@u-pem.fr>
References: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
 <1039463632.1515198.1617987284725.JavaMail.zimbra@u-pem.fr>
Message-ID: <6004728c-f129-ab41-9ac2-260723ac5108@oracle.com>

On 09/04/2021 18:54, Remi Forax wrote:
> ----- Mail original -----
>> De: "Jorn Vernee" <jvernee at openjdk.java.net>
>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Vendredi 9 Avril 2021 12:51:53
>> Objet: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles
>> This patch adds a `tableSwitch` combinator that can be used to switch over a set
>> of method handles given an index, with a fallback in case the index is out of
>> bounds, much like the `tableswitch` bytecode.
>>
>> The combinator does not support specifying the starting index, so the switch
>> cases always run from 0 to however many target handles are specified. A
>> starting index can be added manually with another combination step that filters
>> the input index by adding or subtracting a constant from it, which does not
>> affect performance. One of the reasons for not supporting a starting index is
>> that it allows for more lambda form sharing, but also simplifies the
>> implementation somewhat. I guess an open question is if a convenience overload
>> should be added for that case?
> I think the combinator should be lookupswitch which is more general than tableswitch with a special case when generating the bytecode to generate a tableswitch instead of a lookupswitch if the indexes are subsequent.
One of the bigger downsides I see in supporting lookupswitch directly is 
that the lambda form and intrinsified bytecode become dependent on the 
key set, which allows for less sharing. Something that is not/less of a 
problem with tableswitch + filter function, because the filter function 
could potentially be the same for any key set (where the key set is 
bound to the filter function instead).
>
>> Lookup switch can also be simulated by filtering the input through an injection
>> function that translates it into a case index, which has also proven to have
>> the ability to have comparable performance to, or even better performance than,
>> a bytecode-native `lookupswitch` instruction. I plan to add such an injection
>> function to the runtime libraries in the future as well. Maybe at that point it
>> could be evaluated if it's worth it to add a lookup switch combinator as well,
>> but I don't see an immediate need to include it in this patch.
>>
> As i said in the bug when we discuss about that the filtering function,
> i believe that the filtering function for emulating lookupswitch is lookupswitch itself.
Right, but lookupswitch also ties us into C2's optimization strategy for 
lookupswitch. Having the ability to specify the filter function allows 
picking a better one for the particular use-case. For instance for 
switches with a large-ish number of cases (15+) it's faster to use a 
HashMap lookup as a filtering function (according to my benchmarking), 
with comparinble results to native lookupswitch if the filter function 
uses a tree of if/else.

Though, I'm not saying that it's not worth it to add a lookupswitch 
combinator as well, to me it seems like tableswitch is the more 
flexible/minimal primitive, because it doesn't force the use of a 
particular lookup strategy.

WRT picking the translation strategy based on the set of keys; I'm note 
super keen on that. Since the MethodHandle combinators are a low-level 
API, I ended up adopting a simple 'what you see is what you get' 
philosophy as much as possible, with the possibility of building other 
use-cases on top. i.e. a tableSwitch combinator that reliably translates 
into the tableswitch bytecode, a lookupSwitch combinator that reliably 
translates into the lookupswitch bytecode, and an exception if I get the 
key set wrong, rather than silently switching strategies to one or the 
other.
>
>> The current bytecode intrinsification generates a call for each switch case,
>> which guarantees full inlining of the target method handles. Alternatively we
>> could only have 1 callsite at the end of the switch, where each case just loads
>> the target method handle, but currently this does not allow for inlining of the
>> handles, since they are not constant.
> This scheme also allows to never JIT compile a branch which is never used.

Yes, that's a good point, thanks.

Thanks for the input,
Jorn

>
>> Maybe a future C2 optimization could look at the receiver input for invokeBasic
>> call sites, and if the input is a phi node, clone the call for each constant
>> input of the phi. I believe that would allow simplifying the bytecode without
>> giving up on inlining.
>>
>> Some numbers from the added benchmarks:
>> Benchmark                                        (numCases)  (offset)  (sorted)
>> Mode  Cnt   Score   Error  Units
>> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A
>> avgt   30   4.186 ? 0.054  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A
>> avgt   30   4.164 ? 0.057  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A
>> avgt   30   4.124 ? 0.023  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A
>> avgt   30   4.126 ? 0.025  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A
>> avgt   30   4.137 ? 0.042  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A
>> avgt   30   4.113 ? 0.016  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A
>> avgt   30   4.118 ? 0.028  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A
>> avgt   30   4.127 ? 0.019  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A
>> avgt   30   4.116 ? 0.013  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A
>> avgt   30   4.121 ? 0.020  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A
>> avgt   30   4.113 ? 0.009  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A
>> avgt   30   4.149 ? 0.041  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A
>> avgt   30   4.121 ? 0.026  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A
>> avgt   30   4.113 ? 0.021  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A
>> avgt   30   4.129 ? 0.028  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A
>> avgt   30   4.105 ? 0.019  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A
>> avgt   30   4.097 ? 0.021  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A
>> avgt   30   4.131 ? 0.037  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A
>> avgt   30   4.135 ? 0.025  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A
>> avgt   30   4.139 ? 0.145  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true
>> avgt   30   4.894 ? 0.028  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false
>> avgt   30  11.526 ? 0.194  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true
>> avgt   30   4.882 ? 0.025  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false
>> avgt   30  11.532 ? 0.034  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10         0      true
>> avgt   30   5.065 ? 0.076  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10         0     false
>> avgt   30  13.016 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10       150      true
>> avgt   30   5.103 ? 0.051  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10       150     false
>> avgt   30  12.984 ? 0.102  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25         0      true
>> avgt   30   8.441 ? 0.165  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25         0     false
>> avgt   30  13.371 ? 0.060  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25       150      true
>> avgt   30   8.628 ? 0.032  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25       150     false
>> avgt   30  13.542 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50         0      true
>> avgt   30   4.701 ? 0.015  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50         0     false
>> avgt   30  13.562 ? 0.063  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50       150      true
>> avgt   30   7.991 ? 3.111  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50       150     false
>> avgt   30  13.543 ? 0.088  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100         0      true
>> avgt   30   4.712 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100         0     false
>> avgt   30  13.600 ? 0.085  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100       150      true
>> avgt   30   4.676 ? 0.011  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100       150     false
>> avgt   30  13.476 ? 0.043  ms/op
>>
>> Testing:
>> - [x] Running of included benchmarks
>> - [x] Inspecting inlining trace and verifying method handle targets are inlined
>> - [x] Running TestTableSwitch test (currently the only user of the new code)
>> - [x] Running java/lang/invoke tests (just in case)
>> - [x] Some manual testing
>>
>> Thanks,
>> Jorn
>>
>> -------------
>>
>> Commit messages:
>> - Improve test
>> - Touchup
>> - Use cases array + holder
>> - WIP - implement tableSwitch combinator in lambda form interpreter
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/3401/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3401&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8263087
>>   Stats: 959 lines in 8 files changed: 955 ins; 0 del; 4 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/3401.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/3401/head:pull/3401
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3401

From kvn at openjdk.java.net  Fri Apr  9 17:42:27 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:42:27 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <FkHY159OY-BZJOj3EpameQ-wQhLgiMyMrrjxu2JZQ8k=.f879e3aa-cdb7-40af-8826-3484a299e914@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
 <FkHY159OY-BZJOj3EpameQ-wQhLgiMyMrrjxu2JZQ8k=.f879e3aa-cdb7-40af-8826-3484a299e914@github.com>
Message-ID: <lC8kkzacpStLbNr77SkZMBiGX6j3frs3zFkSq2OdAXA=.92744f14-5afc-4458-814d-6d61e8644af7@github.com>

On Fri, 9 Apr 2021 17:09:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi Vladimir,
>> 
>> This looks good to me - I went through all the files.
>> 
>> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??
>> 
>> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.
>> 
>> Thanks,
>> David
>
>> Hi Vladimir,
>> 
>> This looks good to me - I went through all the files.
>> 
>> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??
>> 
>> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.
>> 
>> Thanks,
>> David
> 
> Thank you, David.
> We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`.
> I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000

Thank you, Igor Ignatyev, Igor Veresov, Ioi, Aleksey and Andrew for reviews.
I will update changes based on your comments.

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

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

From kvn at openjdk.java.net  Fri Apr  9 17:43:22 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:43:22 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler
Message-ID: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>

As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:

- `jdk.internal.vm.compiler` ? the Graal compiler 
- `jdk.internal.vm.compiler.management` ? Graal's `MBean`
- `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests

Remove Graal related code in makefiles.

Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
src/jdk.internal.vm.compiler/share/classes/module-info.java
src/jdk.internal.vm.compiler.management/share/classes/module-info.java

@AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.

Tested hs-tier1-4

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

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

Commit messages:
 - 8264806: Remove the experimental JIT compiler

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

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

From kvn at openjdk.java.net  Fri Apr  9 17:45:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:45:20 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
Message-ID: <VtF7FHuoaEtc_asbPszw_UIshxBWd7F2CQp0DdzKcZ4=.5f06acbb-7de3-4a23-8602-92a8c31dd8ac@github.com>

On Fri, 9 Apr 2021 02:44:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/compiledIC_x86.cpp line 134:
> 
>> 132: #ifdef ASSERT
>> 133:   CodeBlob *cb = CodeCache::find_blob_unsafe((address) _call);
>> 134:   assert(cb, "sanity");
> 
> Nit: implied boolean - use "cb != NULL"

done

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

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

From john.r.rose at oracle.com  Fri Apr  9 18:01:18 2021
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 9 Apr 2021 11:01:18 -0700
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: <1039463632.1515198.1617987284725.JavaMail.zimbra@u-pem.fr>
References: <1039463632.1515198.1617987284725.JavaMail.zimbra@u-pem.fr>
Message-ID: <2D79F7CF-8A3E-482A-A5F3-BEBF83AD75D3@oracle.com>

On Apr 9, 2021, at 9:55 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> I think the combinator should be lookupswitch which is more general than tableswitch with a special case when generating the bytecode to generate a tableswitch instead of a lookupswitch if the indexes are subsequent.

We can get there in the simpler steps Jorn has outlined.

The combinator is much simpler if the case numbers are implicit in [0,N). Then it?s natural to filter on the [0,N) input as a separately factored choice. That also scales to pattern-switch. 

I agree with the choice to have N call sites. It?s possible to build the one call site version on top using constant combinators but not vice versa. 

From naoto at openjdk.java.net  Fri Apr  9 18:15:26 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 9 Apr 2021 18:15:26 GMT
Subject: Integrated: 8264765: BreakIterator sees bogus sentence boundary in
 parenthesized =?UTF-8?B?4oCcaS5lLuKAnQ==?= phrase
In-Reply-To: <RWM--Xx47tXkDwysIImFsvNCqU6H9chw-cqPEzYR9TI=.e70ab795-bac0-4580-bac4-52abe8a61c85@github.com>
References: <RWM--Xx47tXkDwysIImFsvNCqU6H9chw-cqPEzYR9TI=.e70ab795-bac0-4580-bac4-52abe8a61c85@github.com>
Message-ID: <eL-vLLfPXjwo_Wf1B0fWhqPOTby_W2x7raT0gUpbVNU=.58d04cfa-5609-46f3-9313-a3596bee129c@github.com>

On Thu, 8 Apr 2021 18:19:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. It is not actually related to "parenthesized", but period-comma sequence was regarded as a break on a backward traverse.

This pull request has now been integrated.

Changeset: 9ebc497b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9ebc497b
Stats:     19 lines in 2 files changed: 14 ins; 0 del; 5 mod

8264765: BreakIterator sees bogus sentence boundary in parenthesized ?i.e.? phrase

Reviewed-by: joehw

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

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

From forax at univ-mlv.fr  Fri Apr  9 18:15:24 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 9 Apr 2021 20:15:24 +0200 (CEST)
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over
 a set of MethodHandles
In-Reply-To: <2D79F7CF-8A3E-482A-A5F3-BEBF83AD75D3@oracle.com>
References: <1039463632.1515198.1617987284725.JavaMail.zimbra@u-pem.fr>
 <2D79F7CF-8A3E-482A-A5F3-BEBF83AD75D3@oracle.com>
Message-ID: <1676065058.1536496.1617992124966.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jorn Vernee" <jvernee at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 9 Avril 2021 20:01:18
> Objet: Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

Hi John,

> On Apr 9, 2021, at 9:55 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> I think the combinator should be lookupswitch which is more general than
>> tableswitch with a special case when generating the bytecode to generate a
>> tableswitch instead of a lookupswitch if the indexes are subsequent.
> 
> We can get there in the simpler steps Jorn has outlined.

I fail to see how it can work.

> 
> The combinator is much simpler if the case numbers are implicit in [0,N). Then
> it?s natural to filter on the [0,N) input as a separately factored choice.

An array of MethodHandles + a default method handle is simpler than an array of sorted ints + an array of MethodHandles + a default method, but not much simpler.

> That also scales to pattern-switch.

yes, for all the switches, pattern-switch, enum-switch but not for the string switch which requires a lookup switch.
Can you outline how to use the tableswitch combinator in the case of a switch on strings ?

> 
> I agree with the choice to have N call sites. It?s possible to build the one
> call site version on top using constant combinators but not vice versa.

yes,
R?mi

From kvn at openjdk.java.net  Fri Apr  9 18:23:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:23:26 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
Message-ID: <obMOiA-1TtLCLVF4QQ8u16sMgzCJuhb1h_HpwerXte0=.5f118e88-ab6a-4105-86ab-70d87d2fa439@github.com>

On Fri, 9 Apr 2021 03:03:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/memory/heap.hpp line 174:
> 
>> 172:   bool contains(const void* p) const             { return low() <= p && p < high(); }
>> 173:   bool contains_blob(const CodeBlob* blob) const {
>> 174:     const void* start = (void*)blob;
> 
> start seems redundant now

Done:
   bool contains_blob(const CodeBlob* blob) const {
-    const void* start = (void*)blob;
-    return contains(start);
+    return contains((void*)blob);
   }

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

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

From kvn at openjdk.java.net  Fri Apr  9 18:23:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:23:25 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
Message-ID: <ofskald98fzMljX0LHBVGFyKrGey-skK1S_4gpd07r8=.33f3109a-b923-44a5-bdf1-d99dfbf341fd@github.com>

On Fri, 9 Apr 2021 08:29:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/globalDefinitions_x86.hpp line 73:
> 
>> 71: 
>> 72: #if INCLUDE_JVMCI
>> 73: #define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS (EnableJVMCI)
> 
> Minor nit: can probably drop parentheses here.

done

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

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

From jvernee at openjdk.java.net  Fri Apr  9 18:30:28 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 9 Apr 2021 18:30:28 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
References: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
Message-ID: <DEXbC3bYjT4JjGSjYgljIFz6sc3Vpi2cq83q8hsr2CI=.e6ae2e97-b13c-4cea-9a09-3fbe504cf68f@github.com>

On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc):
> 
>      Creates a table switch method handle, which can be used to switch over a set of target
>      method handles, based on a given target index, called selector.
> 
>      For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)},
>      and where {@code N} is the number of target method handles, the table switch method
>      handle will invoke the n-th target method handle from the list of target method handles.
> 
>      For a selector value that does not fall in the range {@code [0, N)}, the table switch
>      method handle will invoke the given fallback method handle.
> 
>      All method handles passed to this method must have the same type, with the additional
>      requirement that the leading parameter be of type {@code int}. The leading parameter
>      represents the selector.
> 
>      Any trailing parameters present in the type will appear on the returned table switch
>      method handle as well. Any arguments assigned to these parameters will be forwarded,
>      together with the selector value, to the selected method handle when invoking it.
> 
> The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case?
> 
> Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch.
> 
> The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant.
> 
> Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining.
> 
> Some numbers from the added benchmarks:
> Benchmark                                        (numCases)  (offset)  (sorted)  Mode  Cnt   Score   Error  Units
> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A  avgt   30   4.186 ? 0.054  ms/op
> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A  avgt   30   4.164 ? 0.057  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A  avgt   30   4.124 ? 0.023  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A  avgt   30   4.126 ? 0.025  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A  avgt   30   4.137 ? 0.042  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A  avgt   30   4.113 ? 0.016  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A  avgt   30   4.118 ? 0.028  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A  avgt   30   4.127 ? 0.019  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A  avgt   30   4.116 ? 0.013  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A  avgt   30   4.121 ? 0.020  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A  avgt   30   4.113 ? 0.009  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A  avgt   30   4.149 ? 0.041  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A  avgt   30   4.121 ? 0.026  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A  avgt   30   4.113 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A  avgt   30   4.129 ? 0.028  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A  avgt   30   4.105 ? 0.019  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A  avgt   30   4.097 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A  avgt   30   4.131 ? 0.037  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A  avgt   30   4.135 ? 0.025  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A  avgt   30   4.139 ? 0.145  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true  avgt   30   4.894 ? 0.028  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false  avgt   30  11.526 ? 0.194  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true  avgt   30   4.882 ? 0.025  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false  avgt   30  11.532 ? 0.034  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0      true  avgt   30   5.065 ? 0.076  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0     false  avgt   30  13.016 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150      true  avgt   30   5.103 ? 0.051  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150     false  avgt   30  12.984 ? 0.102  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0      true  avgt   30   8.441 ? 0.165  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0     false  avgt   30  13.371 ? 0.060  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150      true  avgt   30   8.628 ? 0.032  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150     false  avgt   30  13.542 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0      true  avgt   30   4.701 ? 0.015  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0     false  avgt   30  13.562 ? 0.063  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150      true  avgt   30   7.991 ? 3.111  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150     false  avgt   30  13.543 ? 0.088  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0      true  avgt   30   4.712 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0     false  avgt   30  13.600 ? 0.085  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150      true  avgt   30   4.676 ? 0.011  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150     false  avgt   30  13.476 ? 0.043  ms/op
> 
> Testing:
> - [x] Running of included benchmarks
> - [x] Inspecting inlining trace and verifying method handle targets are inlined
> - [x] Running TestTableSwitch test (currently the only user of the new code)
> - [x] Running java/lang/invoke tests (just in case)
> - [x] Some manual testing
> 
> Thanks,
> Jorn

> yes, for all the switches, pattern-switch, enum-switch but not for the string switch which requires a lookup switch.
Can you outline how to use the tableswitch combinator in the case of a switch on strings ?

Jan Lahoda has made several good examples of that: https://github.com/lahodaj/jdk/blob/switch-bootstrap/src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java

I ran some benchmarks:

![results](http://cr.openjdk.java.net/~jvernee/StringSwitch_10.svg)

Here, 'legacy' is what C2 does.

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

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

From kvn at openjdk.java.net  Fri Apr  9 18:32:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:32:26 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
Message-ID: <Cv3I8B_-bwT0M-Ft2JqNPkxYk-PP46aqJKN23mKYblY=.c94b7bfc-cc2a-4a76-87bd-58a7a24d4fba@github.com>

On Fri, 9 Apr 2021 08:32:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/code/compiledIC.cpp line 715:
> 
>> 713:     tty->print("interpreted");
>> 714:   } else {
>> 715:     tty->print("unknown");
> 
> We can probably split this cleanup into the minor issue, your call. The benefit of separate issue: backportability.

Reverted and filed https://bugs.openjdk.java.net/browse/JDK-8265013

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

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

From kvn at openjdk.java.net  Fri Apr  9 18:36:24 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:36:24 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
Message-ID: <8rFTTlGuCqN9XzBEbaAAf9R-YhTTqe45jv9Gh7F506w=.67e92697-68c4-4657-abb4-803231a9d1a9@github.com>

On Fri, 9 Apr 2021 16:30:41 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/instanceKlass.hpp line 257:
> 
>> 255:     _misc_declares_nonstatic_concrete_methods = 1 << 6,  // directly declares non-static, concrete methods
>> 256:     _misc_has_been_redefined                  = 1 << 7,  // class has been redefined
>> 257:     _unused                                   = 1 << 8,  //
> 
> Any particular reason we don't want to remove this gap?

Less changes. We don't get any benefits from removing it. It is opposite - if we need a new value we will use it without changing following values again.

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

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

From kvn at openjdk.java.net  Fri Apr  9 19:09:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 19:09:25 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
Message-ID: <qc4oegjT9GB5i8kHO9od5ygICGV2g5kv2RP0wUEoW0w=.69e16fc3-aa93-4cd6-9419-91b83914dfd1@github.com>

On Fri, 9 Apr 2021 16:34:58 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1184:
> 
>> 1182:       }
>> 1183:     } else if (jvmci_env()->isa_HotSpotMetaspaceConstantImpl(constant)) {
>> 1184:       if (!_immutable_pic_compilation) {
> 
> All _immutable_pic_compilation mentions can be removed as well. It is true only for AOT compiles produced by Graal. It's never going to be used without AOT.

Done. I removed _immutable_pic_compilation in JVMCI in Hotspot.

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

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

From kvn at openjdk.java.net  Fri Apr  9 19:26:22 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 19:26:22 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
Message-ID: <9RiwxlBLMiREzNvRHU14RQBW33nieUT8-Pmkod_GvtA=.ad51b2f9-f244-4346-8844-9fee39c9aa5b@github.com>

On Fri, 9 Apr 2021 16:54:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/methodCounters.cpp line 77:
> 
>> 75: }
>> 76: 
>> 77: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) {
> 
> MethodCounters::metaspace_pointers_do can be removed altogether (also need to remove the declaration in methodCounter.hpp).

Done.

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

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

From erikj at openjdk.java.net  Fri Apr  9 19:33:34 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 9 Apr 2021 19:33:34 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <9YQ-kwVWOO0OzJO1YcfP9nnzUInhLOJ9yiecsYWBIp4=.22504511-4d72-4a41-8092-820501c1ca35@github.com>

On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

make/GraalBuilderImage.gmk line 1:

> 1: #

This file should not be removed. This outout image is this makefile produces is used as input to the separate GraalVM build.

make/Main.gmk line 444:

> 442: ))
> 443: 
> 444: $(eval $(call SetupTarget, graal-builder-image, \

Same as above, this needs to stay.

make/autoconf/spec.gmk.in line 895:

> 893: STATIC_LIBS_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(STATIC_LIBS_IMAGE_SUBDIR)
> 894: 
> 895: # Graal builder image

Like above, this needs to stay.

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

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

From joehw at openjdk.java.net  Fri Apr  9 19:34:21 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 9 Apr 2021 19:34:21 GMT
Subject: RFR: 8264208: Console charset API
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <__ihL9ryNtSo-eJ_qsADX-CYWLkU9MyJreehabFPu6o=.181ffcb4-1d8b-4172-aaae-c103c0156f9c@github.com>

On Fri, 9 Apr 2021 16:47:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Marked as reviewed by joehw (Reviewer).

src/java.base/share/classes/java/io/Console.java line 404:

> 402:      *
> 403:      * @return A {@code Charset} object used in this {@code Console}.
> 404:      * @since 17

A couple of minor comments: 
May replace {@code Charset} with @link;
Add "the" to the sentence: The returned charset corresponds to "the" input...
@return: javadoc guide suggests "do not capitalize and do not end with a period" when writing a phrase. But I guess for consistency in this class, it's okay to capitalize.

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

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

From dalibor.topic at oracle.com  Fri Apr  9 19:49:52 2021
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 9 Apr 2021 21:49:52 +0200
Subject: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <CAEQxcvF8Y5rsnaXYaKbs3+1hBEtFFvEhT-kNz3DKTO-mbVr0Xw@mail.gmail.com>
References: <BLAPR20MB4177F862D3DEBFE859D533B7AE659@BLAPR20MB4177.namprd20.prod.outlook.com>
 <BLAPR20MB41773DC6EF41338328CA0104AE799@BLAPR20MB4177.namprd20.prod.outlook.com>
 <692862AD-6F1C-4171-9764-6F92E2590570@oracle.com>
 <CAEQxcvF8Y5rsnaXYaKbs3+1hBEtFFvEhT-kNz3DKTO-mbVr0Xw@mail.gmail.com>
Message-ID: <fa75580b-b4de-f348-b65c-3e9baa55d531@oracle.com>

Hi Anirvan,

You can contact contact Oracle?s open-source administrators at 
opensource_ww_grp at oracle.com, who run the OCA app.

We don't use the github usernames from the OCA app for OpenJDK pull 
requests, so you should not be running into issues with that for 
contributions to OpenJDK. If you do, please let me know off-list which 
pull request is involved.

cheers,
dalibor topic

On 03.04.2021 22:11, Anirvan Sarkar wrote:
> Hi Pavel,
> 
> I think I have the same issue as Chris.
> 
> The new OCA contributors list [1] is incorrectly linking the user names to
> GitHub as compared to the old contributors list [2].
> It seems the new OCA contributors list is assuming that the GitHub username
> of past contributors is the same as the username of the project, when they
> had signed the OCA in the past.
> 
> When I had signed OCA a few years back for the OpenJFX project, I had
> provided my username as *anirvan.sarkar*.
> This was my username on java.net / javafx-jira.kenai.com (the old JIRA for
> JavaFX project).
> But my GitHub username is *AnirvanSarkar*, not *anirvan.sarkar* which user
> does not exist on GitHub.
> 
> [1] : https://oca.opensource.oracle.com/?ojr=contrib-list
> [2] : https://oca.opensource.oracle.com/?ojr=old-contrib-list
> 
> 
> On Sun, 4 Apr 2021 at 03:35, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
>> Hey Chris,
>>
>> I don't know exactly what triggers removal of the "oca" and "oca-verify"
>> labels. The only OCA entry for Chris Dennis I could find [1] had a
>> different GitHub username. Did you mistype it or it belongs to another
>> person? Mind you, that person's GitHub page is 404.
>>
>> -Pavel
>>
>> [1] https://oca.opensource.oracle.com/?ojr=contrib-list
>>
>>> On 3 Apr 2021, at 16:12, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>>
>>> A gentle prod. Am I misunderstanding procedure here?
>>>
>>> From: Chris Dennis <chris.w.dennis at gmail.com>
>>> Date: Monday, March 22, 2021 at 2:28 PM
>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>> Subject: 8214761: Bug in parallel Kahan summation implementation
>>> I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 -
>> but have been stuck waiting on OCA signatory status to be confirmed. Did
>> something get lost in the shuffle or do I just need to be more patient.
>>>
>>> Thanks,
>>>
>>> Chris
>>
>>
> 

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>, Video: dalibor.topic at oracle.com
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From jvernee at openjdk.java.net  Fri Apr  9 20:05:23 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 9 Apr 2021 20:05:23 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: <DEXbC3bYjT4JjGSjYgljIFz6sc3Vpi2cq83q8hsr2CI=.e6ae2e97-b13c-4cea-9a09-3fbe504cf68f@github.com>
References: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
 <DEXbC3bYjT4JjGSjYgljIFz6sc3Vpi2cq83q8hsr2CI=.e6ae2e97-b13c-4cea-9a09-3fbe504cf68f@github.com>
Message-ID: <ccIS-p2Cz9JzdNUVjjb3m8dhAjIZ17VcSpJodoxFW6Q=.4d13b919-4735-491b-9c47-c19b3808dd23@github.com>

On Fri, 9 Apr 2021 18:27:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc):
>> 
>>      Creates a table switch method handle, which can be used to switch over a set of target
>>      method handles, based on a given target index, called selector.
>> 
>>      For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)},
>>      and where {@code N} is the number of target method handles, the table switch method
>>      handle will invoke the n-th target method handle from the list of target method handles.
>> 
>>      For a selector value that does not fall in the range {@code [0, N)}, the table switch
>>      method handle will invoke the given fallback method handle.
>> 
>>      All method handles passed to this method must have the same type, with the additional
>>      requirement that the leading parameter be of type {@code int}. The leading parameter
>>      represents the selector.
>> 
>>      Any trailing parameters present in the type will appear on the returned table switch
>>      method handle as well. Any arguments assigned to these parameters will be forwarded,
>>      together with the selector value, to the selected method handle when invoking it.
>> 
>> The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case?
>> 
>> Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch.
>> 
>> The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant.
>> 
>> Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining.
>> 
>> Some numbers from the added benchmarks:
>> Benchmark                                        (numCases)  (offset)  (sorted)  Mode  Cnt   Score   Error  Units
>> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A  avgt   30   4.186 ? 0.054  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A  avgt   30   4.164 ? 0.057  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A  avgt   30   4.124 ? 0.023  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A  avgt   30   4.126 ? 0.025  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A  avgt   30   4.137 ? 0.042  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A  avgt   30   4.113 ? 0.016  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A  avgt   30   4.118 ? 0.028  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A  avgt   30   4.127 ? 0.019  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A  avgt   30   4.116 ? 0.013  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A  avgt   30   4.121 ? 0.020  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A  avgt   30   4.113 ? 0.009  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A  avgt   30   4.149 ? 0.041  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A  avgt   30   4.121 ? 0.026  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A  avgt   30   4.113 ? 0.021  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A  avgt   30   4.129 ? 0.028  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A  avgt   30   4.105 ? 0.019  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A  avgt   30   4.097 ? 0.021  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A  avgt   30   4.131 ? 0.037  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A  avgt   30   4.135 ? 0.025  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A  avgt   30   4.139 ? 0.145  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true  avgt   30   4.894 ? 0.028  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false  avgt   30  11.526 ? 0.194  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true  avgt   30   4.882 ? 0.025  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false  avgt   30  11.532 ? 0.034  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10         0      true  avgt   30   5.065 ? 0.076  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10         0     false  avgt   30  13.016 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10       150      true  avgt   30   5.103 ? 0.051  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10       150     false  avgt   30  12.984 ? 0.102  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25         0      true  avgt   30   8.441 ? 0.165  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25         0     false  avgt   30  13.371 ? 0.060  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25       150      true  avgt   30   8.628 ? 0.032  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25       150     false  avgt   30  13.542 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50         0      true  avgt   30   4.701 ? 0.015  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50         0     false  avgt   30  13.562 ? 0.063  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50       150      true  avgt   30   7.991 ? 3.111  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50       150     false  avgt   30  13.543 ? 0.088  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100         0      true  avgt   30   4.712 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100         0     false  avgt   30  13.600 ? 0.085  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100       150      true  avgt   30   4.676 ? 0.011  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100       150     false  avgt   30  13.476 ? 0.043  ms/op
>> 
>> Testing:
>> - [x] Running of included benchmarks
>> - [x] Inspecting inlining trace and verifying method handle targets are inlined
>> - [x] Running TestTableSwitch test (currently the only user of the new code)
>> - [x] Running java/lang/invoke tests (just in case)
>> - [x] Some manual testing
>> 
>> Thanks,
>> Jorn
>
>> yes, for all the switches, pattern-switch, enum-switch but not for the string switch which requires a lookup switch.
> Can you outline how to use the tableswitch combinator in the case of a switch on strings ?
> 
> Jan Lahoda has made several good examples of that: https://github.com/lahodaj/jdk/blob/switch-bootstrap/src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java i.e. several filtering strategies for translating a String into a table index (which can then be fed to `tableswitch`)
> 
> I ran some benchmarks:
> 
> ![results](http://cr.openjdk.java.net/~jvernee/StringSwitch_10.svg)
> 
> Here, 'legacy' is what C2 does with `lookupswitch`.
> 
> Maybe it's worth it to include such an example & benchmark in this patch as well (show off how to emulate `lookupswitch`)

I've uploaded a benchmark that simulates a lookup switch using the tableSwitch combinator as well, using a HashMap lookup as a filter: https://github.com/openjdk/jdk/commit/a7157eb0ef1b7190aabfb2689539801c6692bbae

For that particular key set (the same as from the graph above), HashMap is faster:

Benchmark                                              Mode  Cnt   Score   Error  Units
MethodHandlesEmulateLookupSwitch.emulatedLookupSwitch  avgt   30  19.450 ? 0.079  ms/op
MethodHandlesEmulateLookupSwitch.nativeLookupSwitch    avgt   30  25.370 ? 0.159  ms/op

But, I've found it really depends on the key set. However, this is mostly to demonstrate that emulation can have competitive performance with native `lookupswitch`. e.g. to get constant folding for constant inputs another filter has to be used, since C2 can not see through the HashMap lookups.

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

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

From github.com+828220+forax at openjdk.java.net  Fri Apr  9 20:05:24 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 9 Apr 2021 20:05:24 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: <ccIS-p2Cz9JzdNUVjjb3m8dhAjIZ17VcSpJodoxFW6Q=.4d13b919-4735-491b-9c47-c19b3808dd23@github.com>
References: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
 <DEXbC3bYjT4JjGSjYgljIFz6sc3Vpi2cq83q8hsr2CI=.e6ae2e97-b13c-4cea-9a09-3fbe504cf68f@github.com>
 <ccIS-p2Cz9JzdNUVjjb3m8dhAjIZ17VcSpJodoxFW6Q=.4d13b919-4735-491b-9c47-c19b3808dd23@github.com>
Message-ID: <QHEJNH7QNBRv5nV90IN7AyosipYglY-6q3p3kvaBkP8=.90ebc662-df92-4130-9be0-a1e47e0e8511@github.com>

On Fri, 9 Apr 2021 19:57:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> yes, for all the switches, pattern-switch, enum-switch but not for the string switch which requires a lookup switch.
>> Can you outline how to use the tableswitch combinator in the case of a switch on strings ?
>> 
>> Jan Lahoda has made several good examples of that: https://github.com/lahodaj/jdk/blob/switch-bootstrap/src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java i.e. several filtering strategies for translating a String into a table index (which can then be fed to `tableswitch`)
>> 
>> I ran some benchmarks:
>> 
>> ![results](http://cr.openjdk.java.net/~jvernee/StringSwitch_10.svg)
>> 
>> Here, 'legacy' is what C2 does with `lookupswitch`.
>> 
>> Maybe it's worth it to include such an example & benchmark in this patch as well (show off how to emulate `lookupswitch`)
>
> I've uploaded a benchmark that simulates a lookup switch using the tableSwitch combinator as well, using a HashMap lookup as a filter: https://github.com/openjdk/jdk/commit/a7157eb0ef1b7190aabfb2689539801c6692bbae
> 
> For that particular key set (the same as from the graph above), HashMap is faster:
> 
> Benchmark                                              Mode  Cnt   Score   Error  Units
> MethodHandlesEmulateLookupSwitch.emulatedLookupSwitch  avgt   30  19.450 ? 0.079  ms/op
> MethodHandlesEmulateLookupSwitch.nativeLookupSwitch    avgt   30  25.370 ? 0.159  ms/op
> 
> But, I've found it really depends on the key set. However, this is mostly to demonstrate that emulation can have competitive performance with native `lookupswitch`. e.g. to get constant folding for constant inputs another filter has to be used, since C2 can not see through the HashMap lookups.

Ok, let restart from the beginning,
you have two strategy to de-sugar a switch,
- if what you do after the case do not mutate any variables, you can desugar each case to a method more or less like a lambda (it's not exactly like a lambda because there is no capture) and you have an indy in front that will call the right method handles
- you have a front end, with an indy that associate the object to an int and a backend which is tableswitch in the bytecode

The first strategy is an optimization, it will get you good performance by example if you compare a switch on a hirerachy on types and the equivalent method call. But you can not use that strategy for all switch, it's more an optimization.
The second strategy let you encode any switches.

The tests above are using the first strategy, which I think is not what we should implement by default given that it doesn't work will all cases. In the particular case of a switch on string, javac generates two switches, the front one and the back one, if we want to compare, we should implement the second strategy, so indy or the equivalent constant handle should take a String as parameter and return an int.

On the test themselves, for the hash, the Map should be directly bound, it will be more efficient, the asm version doesn't not appear in the graphics and there is a missing strategy that is using a MutableCallSite to switch from the a cascade of guards using the real values (store the String value even if it goes to `default`) and then switch to a lookup switch which i've found is the optimal strategy in real code (it works a lot like a bi-morphic cache but on string values instead of on classes).

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

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

From mchung at openjdk.java.net  Fri Apr  9 20:53:33 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 9 Apr 2021 20:53:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <FhGLyUe8AL5wDoKma5NIDtKP8Rmq2c5a9e4uFF5rRWM=.0aca481d-4791-4021-b9ae-b868ea42f11e@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

I reviewed the module-loader-map and non-hotspot non-AOT tests.

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

Marked as reviewed by mchung (Reviewer).

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

From naoto at openjdk.java.net  Fri Apr  9 21:06:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 9 Apr 2021 21:06:03 GMT
Subject: RFR: 8264208: Console charset API [v2]
In-Reply-To: <__ihL9ryNtSo-eJ_qsADX-CYWLkU9MyJreehabFPu6o=.181ffcb4-1d8b-4172-aaae-c103c0156f9c@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <__ihL9ryNtSo-eJ_qsADX-CYWLkU9MyJreehabFPu6o=.181ffcb4-1d8b-4172-aaae-c103c0156f9c@github.com>
Message-ID: <4k7yjIhZ_ZaZ7o617B5Ijmf0osdKHppduwmZpVFWeAA=.63b03ee3-ea9c-4c7b-aec9-13ca8c675fa1@github.com>

On Fri, 9 Apr 2021 19:25:02 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflected the review comments.
>
> src/java.base/share/classes/java/io/Console.java line 404:
> 
>> 402:      *
>> 403:      * @return A {@code Charset} object used in this {@code Console}.
>> 404:      * @since 17
> 
> A couple of minor comments: 
> May replace {@code Charset} with @link;
> Add "the" to the sentence: The returned charset corresponds to "the" input...
> @return: javadoc guide suggests "do not capitalize and do not end with a period" when writing a phrase. But I guess for consistency in this class, it's okay to capitalize.

Thanks, Joe. Modified as suggested.

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

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

From naoto at openjdk.java.net  Fri Apr  9 21:06:00 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 9 Apr 2021 21:06:00 GMT
Subject: RFR: 8264208: Console charset API [v2]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Reflected the review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/d6db04bb..8fd8f6e6

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

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

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

From darcy at openjdk.java.net  Fri Apr  9 21:35:32 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 9 Apr 2021 21:35:32 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices [v2]
In-Reply-To: <wkvUYUR9nw4dCBh0TKp2pOyIM1XEQAX3_E1EU3rgIys=.7309e577-1157-4cb4-987c-04c69aa15545@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
 <wkvUYUR9nw4dCBh0TKp2pOyIM1XEQAX3_E1EU3rgIys=.7309e577-1157-4cb4-987c-04c69aa15545@github.com>
Message-ID: <-YAV5sGQbTCq27m3Ke2NQQFr-zIOO-0LIUb9e5ZVoRk=.9d7c03fa-356c-47c3-90e7-d74609becb5b@github.com>

On Fri, 19 Mar 2021 15:20:00 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by darcy (Reviewer).

src/java.base/share/classes/java/lang/reflect/Constructor.java line 612:

> 610:         Class<?> declaringClass = getDeclaringClass();
> 611:         if (
> 612:             declaringClass.isEnum()

Please format as
if (declaringClass.isEnum()) {
...

test/jdk/java/lang/annotation/EnumConstructorAnnotation.java line 39:

> 37:     public static void main(String[] args) {
> 38:         Constructor<?> c = SampleEnum.class.getDeclaredConstructors()[0];
> 39:         Annotation[] a = c.getParameters()[2].getAnnotations();

The value of c.getParameters().getAnnotations() can be checked for consistency against c.getParameterAnnotations(). (The type java.lang.reflect.Parameter was added several releases after annotations were added.)

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

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

From kvn at openjdk.java.net  Fri Apr  9 21:59:04 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 21:59:04 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <wJ_aASXqtzMg6Fb3Ag8Ia6bjvAzdMIHH_GF5U8OuNEE=.574c044a-9fa1-46a9-8a0d-d1a89ce3fcc3@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3398/files
  - new: https://git.openjdk.java.net/jdk/pull/3398/files/6cce0f6c..71a166c1

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

  Stats: 36 lines in 9 files changed: 0 ins; 27 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

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

From iveresov at openjdk.java.net  Fri Apr  9 22:02:33 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 9 Apr 2021 22:02:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5]
In-Reply-To: <wJ_aASXqtzMg6Fb3Ag8Ia6bjvAzdMIHH_GF5U8OuNEE=.574c044a-9fa1-46a9-8a0d-d1a89ce3fcc3@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <wJ_aASXqtzMg6Fb3Ag8Ia6bjvAzdMIHH_GF5U8OuNEE=.574c044a-9fa1-46a9-8a0d-d1a89ce3fcc3@github.com>
Message-ID: <qEoLNtb0E3sj735OChUsZUqhMxWzOslXVpFmPslveQ4=.913b5cdb-e9ca-48c8-8246-371e5d881879@github.com>

On Fri, 9 Apr 2021 21:59:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by iveresov (Reviewer).

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

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

From joehw at openjdk.java.net  Fri Apr  9 22:21:25 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 9 Apr 2021 22:21:25 GMT
Subject: RFR: 8264208: Console charset API [v2]
In-Reply-To: <4k7yjIhZ_ZaZ7o617B5Ijmf0osdKHppduwmZpVFWeAA=.63b03ee3-ea9c-4c7b-aec9-13ca8c675fa1@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <__ihL9ryNtSo-eJ_qsADX-CYWLkU9MyJreehabFPu6o=.181ffcb4-1d8b-4172-aaae-c103c0156f9c@github.com>
 <4k7yjIhZ_ZaZ7o617B5Ijmf0osdKHppduwmZpVFWeAA=.63b03ee3-ea9c-4c7b-aec9-13ca8c675fa1@github.com>
Message-ID: <rtu34hMQMcm79_XKTdXevhsPb7DJPLPOeCDNnABU0oI=.c0b21a31-7918-4479-a743-c101a0576c0f@github.com>

On Fri, 9 Apr 2021 21:02:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 404:
>> 
>>> 402:      *
>>> 403:      * @return A {@code Charset} object used in this {@code Console}.
>>> 404:      * @since 17
>> 
>> A couple of minor comments: 
>> May replace {@code Charset} with @link;
>> Add "the" to the sentence: The returned charset corresponds to "the" input...
>> @return: javadoc guide suggests "do not capitalize and do not end with a period" when writing a phrase. But I guess for consistency in this class, it's okay to capitalize.
>
> Thanks, Joe. Modified as suggested.

Thanks. Looks good to me.

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

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

From joehw at openjdk.java.net  Fri Apr  9 22:21:24 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 9 Apr 2021 22:21:24 GMT
Subject: RFR: 8264208: Console charset API [v2]
In-Reply-To: <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>
Message-ID: <ZqXKknTtwSK4wd4dO87qFDEcA7CKzbHyOsd3tS4KmrE=.f88aada9-9e87-4286-8aa4-c502bcf2686b@github.com>

On Fri, 9 Apr 2021 21:06:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflected the review comments.

Marked as reviewed by joehw (Reviewer).

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

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

From kvn at openjdk.java.net  Fri Apr  9 22:26:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 22:26:40 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

Vladimir Kozlov 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:

 - Restore Graal Builder image makefile
 - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
 - 8264806: Remove the experimental JIT compiler

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3421/files
  - new: https://git.openjdk.java.net/jdk/pull/3421/files/8ff9b599..a246aaa6

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

  Stats: 102 lines in 12 files changed: 66 ins; 27 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3421.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421

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

From kvn at openjdk.java.net  Fri Apr  9 22:33:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 22:33:36 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <esTJIrmWXvkRNa7I79JjO0sB4EGlXlVPDhkihL8n-tw=.c996f1e8-8012-41c6-918b-de2b5abc8867@github.com>

On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

Thankyou, @erikj79, for review. I restored code as you asked.
For some reasons incremental webrev shows update only in Cdiffs.

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

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

From john.r.rose at oracle.com  Fri Apr  9 23:00:09 2021
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 9 Apr 2021 23:00:09 +0000
Subject: [External] : Re: RFR: 8263087: Add a MethodHandle combinator that
 switches over a set of MethodHandles
In-Reply-To: <1676065058.1536496.1617992124966.JavaMail.zimbra@u-pem.fr>
References: <1039463632.1515198.1617987284725.JavaMail.zimbra@u-pem.fr>
 <2D79F7CF-8A3E-482A-A5F3-BEBF83AD75D3@oracle.com>
 <1676065058.1536496.1617992124966.JavaMail.zimbra@u-pem.fr>
Message-ID: <3C42C8CE-19B0-4DEA-906B-9065C21FC468@oracle.com>

On Apr 9, 2021, at 11:15 AM, forax at univ-mlv.fr wrote:
> 
> ----- Mail original -----
>> De: "John Rose" <john.r.rose at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "Jorn Vernee" <jvernee at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Vendredi 9 Avril 2021 20:01:18
>> Objet: Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles
> 
> Hi John,
> 
>> On Apr 9, 2021, at 9:55 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>> I think the combinator should be lookupswitch which is more general than
>>> tableswitch with a special case when generating the bytecode to generate a
>>> tableswitch instead of a lookupswitch if the indexes are subsequent.
>> 
>> We can get there in the simpler steps Jorn has outlined.
> 
> I fail to see how it can work.

If you have a fixed set of N cases it is always valid
to number them compactly in [0,N).  If there is
another association of keys in some set K to cases,
then you simply build a mapping K ? [0,N).  That
works for enums, lookupswitch, strings, and patterns.
The mapping functions would be:
  - Enum::ordinal
  - a lookupswitch of cases `case i: return n`, n in [0,N]
  - some perfect hash, composed with lookupswitch
  - some decision tree that outputs compact case numbers

In the second case, C2 will inline the lookupswitch and
tableswitch together and do branch-to-branch tensioning.
The result will be the same as if the intermediate tableswitch
had not been used.

The MH combinator for lookupswitch can use a data-driven
reverse lookup in a (frozen/stable) int[] array, using binary
search.  The bytecode emitter can render such a thing as
an internal lookupswitch, if that seems desirable.  But
the stable array with binary search scales to other types
besides int, so it?s the right primitive.

The SwitchBootstraps class is the place to match a
static decision tree or decision chain (of N cases) of
an arbitrary shape to compact case labels in [0,N).
Then they all feed to Jorn?s primitive.

> 
>> 
>> The combinator is much simpler if the case numbers are implicit in [0,N). Then
>> it?s natural to filter on the [0,N) input as a separately factored choice.
> 
> An array of MethodHandles + a default method handle is simpler than an array of sorted ints + an array of MethodHandles + a default method, but not much simpler.

Simpler by the complexity of the sorting, which is a sharp edge.
The type ?sorted int array without duplicates and unaliased
or frozen? is pretty involved.  Easy to make mistakes with it.

> 
>> That also scales to pattern-switch.
> 
> yes, for all the switches, pattern-switch, enum-switch but not for the string switch which requires a lookup switch.

Nope; see above.

> Can you outline how to use the tableswitch combinator in the case of a switch on strings ?

Above; reduce to perfect hash plus lookupswitch
producing compact int values to feed to a tableswitch.

Summary:  Switches only need one case label domain:  [0,N).
Everything else is case label mappings.

? John

From john.r.rose at oracle.com  Fri Apr  9 23:43:49 2021
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 9 Apr 2021 23:43:49 +0000
Subject: [External] : Re: RFR: 8263087: Add a MethodHandle combinator that
 switches over a set of MethodHandles
In-Reply-To: <3C42C8CE-19B0-4DEA-906B-9065C21FC468@oracle.com>
References: <1039463632.1515198.1617987284725.JavaMail.zimbra@u-pem.fr>
 <2D79F7CF-8A3E-482A-A5F3-BEBF83AD75D3@oracle.com>
 <1676065058.1536496.1617992124966.JavaMail.zimbra@u-pem.fr>
 <3C42C8CE-19B0-4DEA-906B-9065C21FC468@oracle.com>
Message-ID: <45B89776-037B-43A3-92C8-4FDC0486F25F@oracle.com>

On Apr 9, 2021, at 4:00 PM, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>> wrote:

The MH combinator for lookupswitch can use a data-driven
reverse lookup in a (frozen/stable) int[] array, using binary
search.  The bytecode emitter can render such a thing as
an internal lookupswitch, if that seems desirable.  But
the stable array with binary search scales to other types
besides int, so it?s the right primitive.

This may be confusing on a couple of points.
First, the mapping function I?m talking about is not
a MH combinator, but rather a MH factory, which takes
a non-MH argument, probably an unsorted array or List
of items of any type.  It then DTRT (internal hash map
or tree map or flat binary search or flat table lookup or
lookupswitch or any combination thereof) to get
an algorithm to classify the array or List elements
into a compact enumeration [0,N).

Second, when the input array or List is of int (or
Integer) then it *might* be a lookupswitch internally,
and I?m abusing the terminology to call this particular
case a lookupswitch.  But it?s really just a classifier
factory, whose output is a MH of type K ? [0,N) for
some K.  The output might also be ToIntFunction<K>
for all I care; that can be inter-converted with a MH.





From mik3hall at gmail.com  Fri Apr  9 23:59:21 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 9 Apr 2021 18:59:21 -0500
Subject: jpackage ea-17 --mac-entitlements 
Message-ID: <46999285-AB16-4C02-B891-1CEFF804C58E@gmail.com>

Should bug reports be written against this yet?

I codesign generated a entitlements file and then tried adding?

    <key>com.apple.private.tcc.allow-prompting</key>
    <true/>

I added this to my invocation?

--mac-entitlements ?entitlements.xml"

And the app crashed?

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (Code Signature Invalid)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 0x1

This is new to me and user error is very possible. It does seem to possibly be necessary for something I am trying to do.  If this is still new work in progress and you would prefer bug reports to be deferred until later that?s fine. If you would like the bug reports written now I can do that.




From mik3hall at gmail.com  Sat Apr 10 00:08:51 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 9 Apr 2021 19:08:51 -0500
Subject: jpackage ea-17 --mac-entitlements 
In-Reply-To: <46999285-AB16-4C02-B891-1CEFF804C58E@gmail.com>
References: <46999285-AB16-4C02-B891-1CEFF804C58E@gmail.com>
Message-ID: <5E9852DD-B066-4EFD-8D74-3D17C5CFA807@gmail.com>



> On Apr 9, 2021, at 6:59 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Should bug reports be written against this yet?
> 
> I codesign generated a entitlements file and then tried adding?
> 
>    <key>com.apple.private.tcc.allow-prompting</key>
>    <true/>
> 
> I added this to my invocation?
> 
> --mac-entitlements ?entitlements.xml"
> 
> And the app crashed?
> 
> System Integrity Protection: enabled
> 
> Crashed Thread:        0
> 
> Exception Type:        EXC_CRASH (Code Signature Invalid)
> Exception Codes:       0x0000000000000000, 0x0000000000000000
> Exception Note:        EXC_CORPSE_NOTIFY
> 
> Termination Reason:    Namespace CODESIGNING, Code 0x1
> 
> This is new to me and user error is very possible. It does seem to possibly be necessary for something I am trying to do.  If this is still new work in progress and you would prefer bug reports to be deferred until later that?s fine. If you would like the bug reports written now I can do that.

OK, probable user error. I eliminated my entitlement changes and it worked.


From ecki at zusammenkunft.net  Sat Apr 10 00:21:48 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 10 Apr 2021 00:21:48 +0000
Subject: RFR: 8264208: Console charset API [v2]
In-Reply-To: <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>,
 <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>
Message-ID: <AM0PR03MB4145819B0E63C7299CD2BF28FF729@AM0PR03MB4145.eurprd03.prod.outlook.com>

Hello,

I like the API, it is useful, however not enough to replace the defaultCharset once the Change to UTF8 is done. You still need a way to query the platforms file encoding (especially on Windows).

Also I wonder if the Javadoc needs to discuss platform aspects of console, especially System.out and LANG on unix vs. windows.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Naoto Sato <naoto at openjdk.java.net>
Gesendet: Friday, April 9, 2021 11:06:00 PM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Re: RFR: 8264208: Console charset API [v2]

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Reflected the review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/d6db04bb..8fd8f6e6

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

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

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

From amenkov at openjdk.java.net  Sat Apr 10 01:22:46 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Sat, 10 Apr 2021 01:22:46 GMT
Subject: RFR: 8262002:
 java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with
 "TestCaseScaffoldException: DummyClassWithLVT did not match .class file"
In-Reply-To: <zKkhC_I6U5M179m6g4pm2Aal447M11lt8FGrQ154i6c=.7028424c-7779-46bf-9eee-3f0b1b95d98d@github.com>
References: <zKkhC_I6U5M179m6g4pm2Aal447M11lt8FGrQ154i6c=.7028424c-7779-46bf-9eee-3f0b1b95d98d@github.com>
Message-ID: <3C-yT6xsCeRk7U96EHpt2NuALsf2h3VqauXRGMENE80=.c8fa44d0-0ee0-4db4-8572-516b38586575@github.com>

On Sat, 10 Apr 2021 01:10:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution)
> The fix:
> - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does
> - makes the test java instead of shell
> - added workaround for JDK-8264667
> - test code is ready to ignore order of attributes

label remove core-libs

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

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

From amenkov at openjdk.java.net  Sat Apr 10 01:22:45 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Sat, 10 Apr 2021 01:22:45 GMT
Subject: RFR: 8262002:
 java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with
 "TestCaseScaffoldException: DummyClassWithLVT did not match .class file"
Message-ID: <zKkhC_I6U5M179m6g4pm2Aal447M11lt8FGrQ154i6c=.7028424c-7779-46bf-9eee-3f0b1b95d98d@github.com>

The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution)
The fix:
- updates JvmtiClassFileReconstituter to add attributes in the same order as javac does
- makes the test java instead of shell
- added workaround for JDK-8264667
- test code is ready to ignore order of attributes

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

Commit messages:
 - fixed spaces
 - JDK-8262002

Changes: https://git.openjdk.java.net/jdk/pull/3426/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3426&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262002
  Stats: 220 lines in 4 files changed: 113 ins; 96 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3426.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3426/head:pull/3426

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

From mik3hall at gmail.com  Sat Apr 10 02:27:36 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 9 Apr 2021 21:27:36 -0500
Subject: jpackage ea-17 --mac-entitlements 
In-Reply-To: <5E9852DD-B066-4EFD-8D74-3D17C5CFA807@gmail.com>
References: <46999285-AB16-4C02-B891-1CEFF804C58E@gmail.com>
 <5E9852DD-B066-4EFD-8D74-3D17C5CFA807@gmail.com>
Message-ID: <BBB99242-DCDC-4045-A1A1-9FE43F1FE1B9@gmail.com>

> 
> OK, probable user error. I eliminated my entitlement changes and it worked.
> 
Related to the same functionality that I am trying to add, I should, or have to, make changes to my Info.plist
This being the addition of NSAppleEventsUsageDescription. 
If I remember correctly in prior discussion concerning application specific environment variables provision was made for the user to include their own custom Info.plist in the Resources directory? Is that correct? Does the file name stay the same?
 
If of interest what I am trying to do is pretty much as described here?
Authorization by AEDeterminePermissionToAutomateTarget waits infinit time
https://developer.apple.com/forums/thread/666528 <https://developer.apple.com/forums/thread/666528>
Except that hangs intermittently and rarely while mine always hangs.

I want to authorize automation AppleEvents for my own application. This consistently hangs on the above call (AEDeterminePermissionToAutomateTarget) done in JNI.

2442 AEDeterminePermissionToAutomateTarget  (in AE) + 1313  [0x7fff3a2d8f2c]
    +                                                               2442 _dispatch_semaphore_wait_slow  (in libdispatch.dylib) + 98  [0x7fff72fb4fbf]
    +                                                                 2442 _dispatch_sema4_wait  (in libdispatch.dylib) + 16  [0x7fff72fb4aed]
    +                                                                   2442 semaphore_wait_trap  (in libsystem_kernel.dylib) + 10  [0x7fff7314ee36]

I have succeeded in getting the same native code to run command line from Terminal. I got it to run once from my application when the application was launched command line, it showed a dialog, and granted permission. However, the dialog application showed as Terminal and not mine.. So now the functionality actually works if command line launched but doesn?t if double click launched. With the problem that it hangs if I try the permit double click launched.

So it seems Terminal must be doing something different or have different authorization than I do. One difference was the entitlement that I originally was crashing with on this list thread.

Also if of interest I determined that difference by using the Taccy application. 
https://eclecticlight.co/tag/taccy/ <https://eclecticlight.co/tag/taccy/>
For Terminal this shows 

App signature check:
/System/Applications/Utilities/Terminal.app: accepted
source=Apple System
origin=Software Signing

For my application?

App signature check:
?? spctl error 1
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app: a sealed resource is missing or invalid

I believe this relates to?
JDK-8263156 : [macos]: OS X application signing concerns - a sealed resource is missing or invalid
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156>

Although I believe 
codesign -v --verbose=4 outputdir/HalfPipe.app 
This verify would be sufficient to reproduce that error for any(?) jpackage Developer signed application.

I?m not sure what your policies are for using 3rd party tools but Taccy seems to give you a nice graphical view of application signing/entitlement related.

Sorry for the length,
Thanks



From dlong at openjdk.java.net  Sat Apr 10 04:05:27 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 10 Apr 2021 04:05:27 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
Message-ID: <R3JbyZHH6VUO_p8svNqSG992mHxBRJhObXokst2aIjM=.f4c8ec54-c2e8-443f-8ace-f58080234fd4@github.com>

On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> LGTM. Just a small nit.

@iklam
I thought the fingerprint code was also used by CDS.

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

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

From iklam at openjdk.java.net  Sat Apr 10 06:08:33 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 10 Apr 2021 06:08:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
Message-ID: <GNwoVCz0KZNh5hN9Fiz9iLgzj1zjMfEXzxqKQP0MOpo=.95df12c1-172e-4465-bc9f-c580a6129147@github.com>

On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> LGTM. Just a small nit.

> @iklam
> I thought the fingerprint code was also used by CDS.

CDS actually uses a different mechanism (CRC of the classfile bytes) to validate that a class has not changed between archive dumping time and runtime. See

https://github.com/openjdk/jdk/blob/5784f6b7f74d0b8081ac107fea172539d57d6020/src/hotspot/share/classfile/systemDictionaryShared.cpp#L1126-L1130

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

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

From tvaleev at openjdk.java.net  Sat Apr 10 06:44:58 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sat, 10 Apr 2021 06:44:58 GMT
Subject: RFR: JDK-8265029: Preserve SIZED characteristics on slice operations
 (skip, limit)
Message-ID: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>

With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.

Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op

After patch:
ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op

Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.

Before patch:
Benchmark                         (size)   Mode  Cnt      Score     Error  Units
ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s

After patch:
Benchmark                         (size)   Mode  Cnt      Score      Error  Units
ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s

I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

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

Commit messages:
 - Convert line endings
 - JDK-8265029: Preserve SIZED characteristics on slice operations (skip, limit)

Changes: https://git.openjdk.java.net/jdk/pull/3427/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265029
  Stats: 377 lines in 9 files changed: 312 ins; 7 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3427.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427

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

From github.com+5455181+rouxantoine at openjdk.java.net  Sat Apr 10 11:00:29 2021
From: github.com+5455181+rouxantoine at openjdk.java.net (Antoine)
Date: Sat, 10 Apr 2021 11:00:29 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit)
In-Reply-To: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
Message-ID: <SkzCY4XDaJozLLnH5mjh_6EdrN3c7o7HGwrv1GTmhxE=.1446a1bb-f02a-488e-9a91-7a8c20a3be58@github.com>

On Sat, 10 Apr 2021 06:30:33 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
> 
> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
> 
> After patch:
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
> 
> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
> 
> Before patch:
> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
> 
> After patch:
> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
> 
> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 469:

> 467:     @Override
> 468:     final <P_IN> long exactOutputSizeIfKnown(Spliterator<P_IN> spliterator) {
> 469:         long size = StreamOpFlag.SIZED.isKnown(getStreamAndOpFlags()) ? spliterator.getExactSizeIfKnown() : -1;

hey, 

small detail but maybe :

return StreamOpFlag.SIZED.isKnown(getStreamAndOpFlags()) ? adjustSize(spliterator.getExactSizeIfKnown()) : -1
this prevent local long `size` variable creation and obvious second ternary `size == -1` return -1

otherwise everything else good job ??

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

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

From vsitnikov at openjdk.java.net  Sat Apr 10 14:13:28 2021
From: vsitnikov at openjdk.java.net (Vladimir Sitnikov)
Date: Sat, 10 Apr 2021 14:13:28 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit)
In-Reply-To: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
Message-ID: <nalDZnXMS-fO5rLnNkDrAUPN-P9CIkmA0rtyw_4pNdQ=.4f958180-3c3e-4842-802e-5df49a2571d5@github.com>

On Sat, 10 Apr 2021 06:30:33 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
> 
> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
> 
> After patch:
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
> 
> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
> 
> Before patch:
> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
> 
> After patch:
> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
> 
> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

src/java.base/share/classes/java/util/stream/SliceOps.java line 238:

> 236:             long adjustSize(long size) {
> 237:                 return isParallel() ? super.adjustSize(size)
> 238:                     : calcSize(super.adjustSize(size), skip, adjustedLimit);

Do you think it is worth adding a comment that clarifies why serial and parallel cases are different?

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

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

From vsitnikov at openjdk.java.net  Sat Apr 10 14:22:36 2021
From: vsitnikov at openjdk.java.net (Vladimir Sitnikov)
Date: Sat, 10 Apr 2021 14:22:36 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit)
In-Reply-To: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
Message-ID: <V3WjYkS-e7otps8mtKtK_RudpWPIsRIcAws1lR2qIlw=.0728d0c9-72b1-41e7-952c-170899e37486@github.com>

On Sat, 10 Apr 2021 06:30:33 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
> 
> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
> 
> After patch:
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
> 
> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
> 
> Before patch:
> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
> 
> After patch:
> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
> 
> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java line 195:

> 193:             assertEquals(Stream.of(1, 2, 3, 4).peek(e -> ai.getAndIncrement())
> 194:                 .parallel().skip(1).limit(2).skip(1).count(), 1);
> 195:             assertEquals(ai.get(), 0);

Does it make sense to extract the method here and launch it with different input streams?

test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java line 370:

> 368:         assertNotNull(prefix);
> 369:         assertTrue(parSpliterator.hasCharacteristics(Spliterator.SIZED));
> 370:         assertTrue(parSpliterator.hasCharacteristics(Spliterator.SUBSIZED));

It would be great to integrate the code comment to the assertion message. Then test failure would print the message making it easier to understand the failure.

It would be great to extract `assertHasCharacteristics` method so the failure printed the actual characteristics rather than "expected true got false"

test/micro/org/openjdk/bench/java/util/stream/ops/ref/SliceToList.java line 50:

> 48:     @Benchmark
> 49:     public List<String> seq_baseline() {
> 50:         return IntStream.range(0, size)

Typically you want to move all the constants to state fields to avoid constant folding by the compiler.
The compiler might accidentally use the fact that range start is always 0 and produce a dedicated optimized code for it. 

See https://shipilev.net/blog/2014/java-scala-divided-we-fail/

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

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

From iignatyev at openjdk.java.net  Sat Apr 10 15:28:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 10 Apr 2021 15:28:35 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler
In-Reply-To: <esTJIrmWXvkRNa7I79JjO0sB4EGlXlVPDhkihL8n-tw=.c996f1e8-8012-41c6-918b-de2b5abc8867@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <esTJIrmWXvkRNa7I79JjO0sB4EGlXlVPDhkihL8n-tw=.c996f1e8-8012-41c6-918b-de2b5abc8867@github.com>
Message-ID: <xgOd5n66UzgCkCKWjyJm36Iny0IgrHhasvw414josho=.59b61cf1-deaa-4e8e-abac-416b72f96b44@github.com>

On Fri, 9 Apr 2021 22:30:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Thankyou, @erikj79, for review. I restored code as you asked.
> For some reasons incremental webrev shows update only in Cdiffs.

none of the full webrevs seem to render even the list of changed files? is it just me?

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

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

From iignatyev at openjdk.java.net  Sat Apr 10 15:41:44 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 10 Apr 2021 15:41:44 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
Message-ID: <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>

On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov 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:
> 
>  - Restore Graal Builder image makefile
>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>  - 8264806: Remove the experimental JIT compiler

should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
what about `vm.graal.enabled` `@requires` property?

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

Changes requested by iignatyev (Reviewer).

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

From kvn at openjdk.java.net  Sat Apr 10 16:35:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 10 Apr 2021 16:35:40 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
Message-ID: <NzvHUjqTGTOLJ62arAOL48geIgrsPKOz8JIPgxRU7p8=.148828ec-a76e-448d-ab4c-7b8c68e6e54b@github.com>

On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
> what about `vm.graal.enabled` `@requires` property?

Thank you, @iignatev for looking on changes.

I forgot to mention that `Compiler::isGraalEnabled()` returns always false now. Because 94 tests uses `@requires !vm.graal.enabled` I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests.

Unfortunately changes in `Compiler.java` are listed the last on `Files changed` tab and GitHub has trouble to load these big changes - it takes time to see them. Here `Compiler.java` chnges for review:
diff --git a/test/lib/sun/hotspot/code/Compiler.java b/test/lib/sun/hotspot/code/Compiler.java
index 99122bd93b8..71288ae4482 100644
--- a/test/lib/sun/hotspot/code/Compiler.java
+++ b/test/lib/sun/hotspot/code/Compiler.java
@@ -60,33 +60,10 @@ public class Compiler {
     /**
      * Check if Graal is used as JIT compiler.
      *
-     * Graal is enabled if following conditions are true:
-     * - we are not in Interpreter mode
-     * - UseJVMCICompiler flag is true
-     * - jvmci.Compiler variable is equal to 'graal'
-     * - TieredCompilation is not used or TieredStopAtLevel is greater than 3
-     * No need to check client mode because it set UseJVMCICompiler to false.
-     *
-     * @return true if Graal is used as JIT compiler.
+     * @return false because Graal is removed from JDK.
      */
     public static boolean isGraalEnabled() {
-        Boolean useCompiler = WB.getBooleanVMFlag("UseCompiler");
-        if (useCompiler == null || !useCompiler) {
-            return false;
-        }
-        Boolean useJvmciComp = WB.getBooleanVMFlag("UseJVMCICompiler");
-        if (useJvmciComp == null || !useJvmciComp) {
-            return false;
-        }
-
-        Boolean tieredCompilation = WB.getBooleanVMFlag("TieredCompilation");
-        Long compLevel = WB.getIntxVMFlag("TieredStopAtLevel");
-        // if TieredCompilation is enabled and compilation level is <= 3 then no Graal is used
-        if (tieredCompilation != null && tieredCompilation &&
-            compLevel != null && compLevel <= 3) {
-            return false;
-        }
-        return true;
+        return false;
     }
 ```

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

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

From kvn at openjdk.java.net  Sat Apr 10 16:40:48 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 10 Apr 2021 16:40:48 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
Message-ID: <CJmqOz4xt_BJW73qbUCZU_XnBafv4DRs6M2Yq1MQunQ=.72f19d3a-e2a5-4abe-a2fc-05ec4cd0f774@github.com>

On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Vladimir Kozlov 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:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
> what about `vm.graal.enabled` `@requires` property?

@iignatev  If you think that I should clean tests anyway I will file follow up RFE to do that.

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

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

From iignatyev at openjdk.java.net  Sat Apr 10 16:50:46 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 10 Apr 2021 16:50:46 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <CJmqOz4xt_BJW73qbUCZU_XnBafv4DRs6M2Yq1MQunQ=.72f19d3a-e2a5-4abe-a2fc-05ec4cd0f774@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
 <CJmqOz4xt_BJW73qbUCZU_XnBafv4DRs6M2Yq1MQunQ=.72f19d3a-e2a5-4abe-a2fc-05ec4cd0f774@github.com>
Message-ID: <mLnVgoSLUnIg2T8JXKoBMIysR3WFMUrwfqb99Qlrjt4=.9b96d02a-9f49-42f6-b8aa-83f71c5010f0@github.com>

On Sat, 10 Apr 2021 16:36:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
>> what about `vm.graal.enabled` `@requires` property?
>
> @iignatev  If you think that I should clean tests anyway I will file follow up RFE to do that.

> > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
> > what about `vm.graal.enabled` `@requires` property?
> 
> Thank you, @iignatev for looking on changes.
> 
> I forgot to mention that `Compiler::isGraalEnabled()` returns always false now. Because 94 tests uses `@requires !vm.graal.enabled` I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests.

> If you think that I should clean tests anyway I will file follow up RFE to do that.

changing  `Compiler::isGraalEnabled()` to always return false effectively makes these tests unrunnable for GraalVM group (unless they are keep the modified `sun/hotspot/code/Compiler` and/or `requires/VMProps` in their forks). on top of that, I foresee that there will be more tests incompatible w/ Graal yet given it won't be run/tested in OpenJDK, these tests won't be marked and hence will fail when run w/ Graal. so Graal people will have to either do marking themselves (I guess in both upstream and their fork) or maintain a list of inapplicable tests in a format that works best for their setup.

that's to say, I think we should clean up the tests, yet I totally agree there is no need to do it as part of this PR. we can discuss how to do it better for both OpenJDK and GraalVM folks in the follow-up RFE.

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

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

From iignatyev at openjdk.java.net  Sat Apr 10 16:50:46 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 10 Apr 2021 16:50:46 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
Message-ID: <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>

On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov 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:
> 
>  - Restore Graal Builder image makefile
>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>  - 8264806: Remove the experimental JIT compiler

Marked as reviewed by iignatyev (Reviewer).

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

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

From mik3hall at gmail.com  Sat Apr 10 17:06:33 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 10 Apr 2021 12:06:33 -0500
Subject: jpackage ea-17 --mac-entitlements 
In-Reply-To: <BBB99242-DCDC-4045-A1A1-9FE43F1FE1B9@gmail.com>
References: <46999285-AB16-4C02-B891-1CEFF804C58E@gmail.com>
 <5E9852DD-B066-4EFD-8D74-3D17C5CFA807@gmail.com>
 <BBB99242-DCDC-4045-A1A1-9FE43F1FE1B9@gmail.com>
Message-ID: <F72FE21E-3B16-461D-AD13-EC46D23E9992@gmail.com>



> On Apr 9, 2021, at 9:27 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Although I believe 
> codesign -v --verbose=4 outputdir/HalfPipe.app 
> This verify would be sufficient to reproduce that error for any(?) jpackage Developer signed application.

An additional thought on this might be that it would be an idea to include a codesign verify as part of the build. From my java command line app.

exec codesign -v /Applications/BBEdit.app
exec codesign -v /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: a sealed resource is missing or invalid
exec codesign -v /Applications/BBEdit.app | wc
wc: chars - 0
wc: words - 0
wc: lines - 0
exec codesign -v /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app | wc
wc: chars - 97
wc: words - 8
wc: lines - 1

Verify appears to return nothing if it succeeds and an error message if it doesn?t. From java it might have to check on that?

I could RFE if wanted.

From kvn at openjdk.java.net  Sat Apr 10 17:44:34 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 10 Apr 2021 17:44:34 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
Message-ID: <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>

On Sat, 10 Apr 2021 16:47:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Vladimir Kozlov 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:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> Marked as reviewed by iignatyev (Reviewer).

Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032

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

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

From winterhalter at openjdk.java.net  Sat Apr 10 20:22:56 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sat, 10 Apr 2021 20:22:56 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices [v3]
In-Reply-To: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
Message-ID: <LJiE5efTG4CwqcSbpXeFsYcuLDd2e3JXArhax993k2c=.66ac49d1-1b4f-4eb9-8aa9-ff7fb022222d@github.com>

> 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.

Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3082/files
  - new: https://git.openjdk.java.net/jdk/pull/3082/files/d50d5f4c..0302611f

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

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

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

From winterhalter at openjdk.java.net  Sat Apr 10 20:23:01 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sat, 10 Apr 2021 20:23:01 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices [v2]
In-Reply-To: <-YAV5sGQbTCq27m3Ke2NQQFr-zIOO-0LIUb9e5ZVoRk=.9d7c03fa-356c-47c3-90e7-d74609becb5b@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
 <wkvUYUR9nw4dCBh0TKp2pOyIM1XEQAX3_E1EU3rgIys=.7309e577-1157-4cb4-987c-04c69aa15545@github.com>
 <-YAV5sGQbTCq27m3Ke2NQQFr-zIOO-0LIUb9e5ZVoRk=.9d7c03fa-356c-47c3-90e7-d74609becb5b@github.com>
Message-ID: <puANtXn27YIS9lk1e5w9_XdO9bl5zIWzQJ7apfhzrKs=.6fea9fe2-091d-4ed4-b549-b55f7cef03e1@github.com>

On Fri, 9 Apr 2021 21:27:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.base/share/classes/java/lang/reflect/Constructor.java line 612:
> 
>> 610:         Class<?> declaringClass = getDeclaringClass();
>> 611:         if (
>> 612:             declaringClass.isEnum()
> 
> Please format as
> if (declaringClass.isEnum()) {
> ...

Changed the formatting.

> test/jdk/java/lang/annotation/EnumConstructorAnnotation.java line 39:
> 
>> 37:     public static void main(String[] args) {
>> 38:         Constructor<?> c = SampleEnum.class.getDeclaredConstructors()[0];
>> 39:         Annotation[] a = c.getParameters()[2].getAnnotations();
> 
> The value of c.getParameters().getAnnotations() can be checked for consistency against c.getParameterAnnotations(). (The type java.lang.reflect.Parameter was added several releases after annotations were added.)

I added a test for both approaches.

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

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

From lzang at openjdk.java.net  Sun Apr 11 03:16:31 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sun, 11 Apr 2021 03:16:31 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v3]
In-Reply-To: <3NgvnAImIrOF6eaXJSim4TCHPruhp6yD2tVqBm-RMHM=.1bc66bec-53fb-4840-b0ef-c03a7cc111d1@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
 <z-VtWLNFeho201QW1vLymWa3vB-TSkwMElKw_seESeM=.c5d67dac-2543-4bd4-b5d3-dfc15e56d4fa@github.com>
 <BIAT8d0uhmiDK4YwqSHGZSgTh1Ach6qQvgEbark9kdE=.5f053c10-7e37-4a0f-9a37-8a92b7bd5585@github.com>
 <3NgvnAImIrOF6eaXJSim4TCHPruhp6yD2tVqBm-RMHM=.1bc66bec-53fb-4840-b0ef-c03a7cc111d1@github.com>
Message-ID: <nC8k5DtDjXIWcdbnT4sm__-c11ZPFNkM79YFUTWK894=.635fea29-1c8a-46ee-af24-3bafc90052eb@github.com>

On Thu, 8 Apr 2021 08:54:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Dear All,
>> May I ask your help to review this change? Thanks!
>> 
>> BRs,
>> Lin
>
>> Dear All,
>> May I ask your help to review this change? Thanks!
> 
> @LanceAndersen Do you have cycles to help Lin? This proposal will require discussion, they may be case for the header to be a record for example. My personal view is that the PR should be set aside until there is at least at least some agreement on the API.

Dear @AlanBateman  and @LanceAndersen,

Thanks a lot for your review and comments!

> 
> We should look to see if it makes sense to use some of the more recent java features such as Record.
> 
> If we are adding a specific class to hold the header fields, perhaps using the builder pattern should be considered vs constructors.

I agree, we should finalize the API before moving forward. I am not quite fimilar with Record, I will do some investigation, trying to use it in this PR and discuss with you later. 

> If we are writing out these additional fields, what should we do with them when reading a gzip file back?

IMO, generally there should be check of header crc, and some other checks like the header format, magic number etc. May be we could implement it like the gnu gzip tool, which ingore contents of most header fields but verified the general header info.

> Have you looked at other gzip api implementations to see what they provide in this area?

I have looked at the gzip implementation at https://github.com/linzang/gzip/blob/distrotech-gzip/gzip.c#L1281, this method is use to generate header crc value for check. And there is some legal header check in this method.  And `file name` is used to save original file name in gzip when it is truncated. refer to https://github.com/linzang/gzip/blob/distrotech-gzip/zip.c#L37

In JDK, there is a usage of `file comment` in the gzip heap dump file generated by jcmd `jmap -dump` command.  at https://github.com/openjdk/jdk/blob/ff52f2989fd60ec8251eaf76f4c4b78f10d3e048/src/hotspot/share/services/heapDumperCompression.cpp#L127 , and this info is used in testing like an hint for uncompression, please refer https://github.com/openjdk/jdk/blob/ff52f2989fd60ec8251eaf76f4c4b78f10d3e048/test/lib/jdk/test/lib/hprof/parser/GzipRandomAccess.java#L280.

And IMHO the behavior of adding information in `file comments` seems like  a general way to transfer extra information between compressor and uncompressor. 


> Is there anyone who relies on this additional header info? As I mentioned in an earlier comment, we should validate the changes against another implementation to ensure that we can read the data back correctly and that the additional header data that we write can be read by other tools.

May be we could have similar behavior? which just do some general header info check, calculate CRC of the header and ignore the real contents of most header fields. Do you think it is reasonable? 


Thanks!
Lin

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

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

From tvaleev at openjdk.java.net  Sun Apr 11 05:53:52 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sun, 11 Apr 2021 05:53:52 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit)
In-Reply-To: <nalDZnXMS-fO5rLnNkDrAUPN-P9CIkmA0rtyw_4pNdQ=.4f958180-3c3e-4842-802e-5df49a2571d5@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
 <nalDZnXMS-fO5rLnNkDrAUPN-P9CIkmA0rtyw_4pNdQ=.4f958180-3c3e-4842-802e-5df49a2571d5@github.com>
Message-ID: <1umG10UtTpdZpp1O3xc5LZ5_ZwUfbr5AJ1NXcKLHMqM=.f2eca0d9-a485-4e19-abc5-c9aff09fc6c6@github.com>

On Sat, 10 Apr 2021 14:10:21 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
>> 
>> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
>> 
>> After patch:
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
>> 
>> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
>> 
>> Before patch:
>> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
>> 
>> After patch:
>> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
>> 
>> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.
>
> src/java.base/share/classes/java/util/stream/SliceOps.java line 238:
> 
>> 236:             long adjustSize(long size) {
>> 237:                 return isParallel() ? super.adjustSize(size)
>> 238:                     : calcSize(super.adjustSize(size), skip, adjustedLimit);
> 
> Do you think it is worth adding a comment that clarifies why serial and parallel cases are different?

Ok

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

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

From tvaleev at openjdk.java.net  Sun Apr 11 06:58:06 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sun, 11 Apr 2021 06:58:06 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit)
In-Reply-To: <V3WjYkS-e7otps8mtKtK_RudpWPIsRIcAws1lR2qIlw=.0728d0c9-72b1-41e7-952c-170899e37486@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
 <V3WjYkS-e7otps8mtKtK_RudpWPIsRIcAws1lR2qIlw=.0728d0c9-72b1-41e7-952c-170899e37486@github.com>
Message-ID: <xJj8vvxyAQd3iQs___SNxXrpDXoNujbbFd2yv5O-XPY=.9b787c49-1187-4f5a-bcf0-d15f3614b406@github.com>

On Sat, 10 Apr 2021 14:13:55 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
>> 
>> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
>> 
>> After patch:
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
>> 
>> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
>> 
>> Before patch:
>> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
>> 
>> After patch:
>> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
>> 
>> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.
>
> test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java line 195:
> 
>> 193:             assertEquals(Stream.of(1, 2, 3, 4).peek(e -> ai.getAndIncrement())
>> 194:                 .parallel().skip(1).limit(2).skip(1).count(), 1);
>> 195:             assertEquals(ai.get(), 0);
> 
> Does it make sense to extract the method here and launch it with different input streams?

Well, it's not that easy as there are tests for IntStream, LongStream, DoubleStream and object Stream, so they cannot be generalized under the same method. Still extracting four methods reduces some amount of repetition, so I'll do this.

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

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

From tvaleev at openjdk.java.net  Sun Apr 11 07:03:37 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sun, 11 Apr 2021 07:03:37 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit)
In-Reply-To: <V3WjYkS-e7otps8mtKtK_RudpWPIsRIcAws1lR2qIlw=.0728d0c9-72b1-41e7-952c-170899e37486@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
 <V3WjYkS-e7otps8mtKtK_RudpWPIsRIcAws1lR2qIlw=.0728d0c9-72b1-41e7-952c-170899e37486@github.com>
Message-ID: <gO-dfHbEPrbMZJpuQOqEj7Ys6gmZ1NmVwy0QDZWUKy4=.394004a1-90ac-4a43-ae55-6a6fa5001b89@github.com>

On Sat, 10 Apr 2021 14:16:40 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
>> 
>> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
>> 
>> After patch:
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
>> 
>> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
>> 
>> Before patch:
>> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
>> 
>> After patch:
>> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
>> 
>> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.
>
> test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java line 370:
> 
>> 368:         assertNotNull(prefix);
>> 369:         assertTrue(parSpliterator.hasCharacteristics(Spliterator.SIZED));
>> 370:         assertTrue(parSpliterator.hasCharacteristics(Spliterator.SUBSIZED));
> 
> It would be great to integrate the code comment to the assertion message. Then test failure would print the message making it easier to understand the failure.
> 
> It would be great to extract `assertHasCharacteristics` method so the failure printed the actual characteristics rather than "expected true got false"

assertTrue/False(spltr.hasCharacteristics(...)) pattern appears in Stream API tests quite often. I can see dozens of occurrences. If extracting such kind of method, then it would be better to replace all of them. At the same time, this will make the patch bigger complicating its review and drifting from the original task. You can contribute such a change separately. In fact, the line number in the report points exactly to the problematic spliterator and characteristics, and dedicated method would not provide you with more information. Anyway, you'll need to take a look at the test source code to see how the spliterator was created, so you won't save much time with a better message.

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

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

From tvaleev at openjdk.java.net  Sun Apr 11 07:14:07 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sun, 11 Apr 2021 07:14:07 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v2]
In-Reply-To: <V3WjYkS-e7otps8mtKtK_RudpWPIsRIcAws1lR2qIlw=.0728d0c9-72b1-41e7-952c-170899e37486@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
 <V3WjYkS-e7otps8mtKtK_RudpWPIsRIcAws1lR2qIlw=.0728d0c9-72b1-41e7-952c-170899e37486@github.com>
Message-ID: <6EaN570C2sujSUuzYBu2NsYFBqzp8ZqrMbnlT33YaVU=.571d96d0-37ea-4cd9-ba52-32de421346c4@github.com>

On Sat, 10 Apr 2021 14:18:57 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes according to review:
>>   
>>   1. Comments in adjustSize
>>   2. repeating code extracted from testNoEvaluationForSizedStream
>
> test/micro/org/openjdk/bench/java/util/stream/ops/ref/SliceToList.java line 50:
> 
>> 48:     @Benchmark
>> 49:     public List<String> seq_baseline() {
>> 50:         return IntStream.range(0, size)
> 
> Typically you want to move all the constants to state fields to avoid constant folding by the compiler.
> The compiler might accidentally use the fact that range start is always 0 and produce a dedicated optimized code for it. 
> 
> See https://shipilev.net/blog/2014/java-scala-divided-we-fail/

I know this article. Here, the upper bound is a state field, so the whole range cannot be optimized. And even if the compiler optimizes at the loop start, it's pretty common to have ranges starting with the constant 0 in the production, so I would not say that having 0 as an iteration starting point makes the benchmark more artificial. The same approach is used in neighbor benchmarks, and in fact, this is not the biggest problem with these benchmarks. Clean type profile makes them much more artificial than starting with zero. So I'd prefer keeping zero as is.

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

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

From tvaleev at openjdk.java.net  Sun Apr 11 07:14:07 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sun, 11 Apr 2021 07:14:07 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v2]
In-Reply-To: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
Message-ID: <ZHLRs8mqnELs41aVUMzXzNKdZMqE8JkiqQ1X07k0uaQ=.fe4eb48c-8b84-4fbf-ba2b-b9e4588b53a5@github.com>

> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
> 
> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
> 
> After patch:
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
> 
> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
> 
> Before patch:
> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
> 
> After patch:
> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
> 
> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Fixes according to review:
  
  1. Comments in adjustSize
  2. repeating code extracted from testNoEvaluationForSizedStream

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3427/files
  - new: https://git.openjdk.java.net/jdk/pull/3427/files/036ea4f9..25755e14

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

  Stats: 73 lines in 2 files changed: 6 ins; 23 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3427.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427

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

From dnsimon at openjdk.java.net  Sun Apr 11 10:28:36 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Sun, 11 Apr 2021 10:28:36 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
Message-ID: <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>

On Sat, 10 Apr 2021 17:41:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Marked as reviewed by iignatyev (Reviewer).
>
> Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032

We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important.

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

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

From lance.andersen at oracle.com  Sun Apr 11 11:10:01 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 11 Apr 2021 11:10:01 +0000
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v3]
In-Reply-To: <nC8k5DtDjXIWcdbnT4sm__-c11ZPFNkM79YFUTWK894=.635fea29-1c8a-46ee-af24-3bafc90052eb@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
 <z-VtWLNFeho201QW1vLymWa3vB-TSkwMElKw_seESeM=.c5d67dac-2543-4bd4-b5d3-dfc15e56d4fa@github.com>
 <BIAT8d0uhmiDK4YwqSHGZSgTh1Ach6qQvgEbark9kdE=.5f053c10-7e37-4a0f-9a37-8a92b7bd5585@github.com>
 <3NgvnAImIrOF6eaXJSim4TCHPruhp6yD2tVqBm-RMHM=.1bc66bec-53fb-4840-b0ef-c03a7cc111d1@github.com>
 <nC8k5DtDjXIWcdbnT4sm__-c11ZPFNkM79YFUTWK894=.635fea29-1c8a-46ee-af24-3bafc90052eb@github.com>
Message-ID: <98127E73-8F14-4858-A965-85C0FF053EC2@oracle.com>


Hi Lin
On Apr 10, 2021, at 11:16 PM, Lin Zang <lzang at openjdk.java.net<mailto:lzang at openjdk.java.net>> wrote:


Dear @AlanBateman  and @LanceAndersen,

Thanks a lot for your review and comments!


We should look to see if it makes sense to use some of the more recent java features such as Record.

If we are adding a specific class to hold the header fields, perhaps using the builder pattern should be considered vs constructors.

I agree, we should finalize the API before moving forward. I am not quite fimilar with Record, I will do some investigation, trying to use it in this PR and discuss with you later.

Please look at:

The Jep https://openjdk.java.net/jeps/395

A simple tutorial

https://oracle.github.io/learning-library/oci-library/oci-hol/oci-java-app/workshops/freetier/?customTrackingParam=:ow:lp:pt:::RC_WWMK200728P00009:OCIJava_HOL&elqTrackId=7e168170255b485a917a5e6602097868&elqaid=100601&elqat=2&source=:ow:lp:cpo:::RC_WWMK200728P00012:LPD400088742+:ow:lp:cpo::&lab=lab-6-records#STEP1:AsimpleRecord

Chris and Julia?s video is also very good:

https://www.youtube.com/watch?v=pxiHwrEMEtI

Between the use of Record and/or the Builder pattern, assembling the header values can be done quite nicely without constructor overload.

If we are writing out these additional fields, what should we do with them when reading a gzip file back?

IMO, generally there should be check of header crc, and some other checks like the header format, magic number etc. May be we could implement it like the gnu gzip tool, which ingore contents of most header fields but verified the general header info.

Sorry, that what not my point  Your current proposal provides no wayto access these fields similar to for example ZipEntry.  If we are going to set these additional fields then we should we should provided a means to access the fields

Have you looked at other gzip api implementations to see what they provide in this area?

Please look at api?s such as commons-compress.  They provide access to these fields via the API in addition to being able to set the fields.  This is what I was referring to above.


I have looked at the gzip implementation at https://github.com/linzang/gzip/blob/distrotech-gzip/gzip.c#L1281, this method is use to generate header crc value for check. And there is some legal header check in this method.  And `file name` is used to save original file name in gzip when it is truncated. refer to https://github.com/linzang/gzip/blob/distrotech-gzip/zip.c#L37

In JDK, there is a usage of `file comment` in the gzip heap dump file generated by jcmd `jmap -dump` command.  at https://github.com/openjdk/jdk/blob/ff52f2989fd60ec8251eaf76f4c4b78f10d3e048/src/hotspot/share/services/heapDumperCompression.cpp#L127 , and this info is used in testing like an hint for uncompression, please refer https://github.com/openjdk/jdk/blob/ff52f2989fd60ec8251eaf76f4c4b78f10d3e048/test/lib/jdk/test/lib/hprof/parser/GzipRandomAccess.java#L280.

And IMHO the behavior of adding information in `file comments` seems like  a general way to transfer extra information between compressor and uncompressor.


Is there anyone who relies on this additional header info? As I mentioned in an earlier comment, we should validate the changes against another implementation to ensure that we can read the data back correctly and that the additional header data that we write can be read by other tools.

May be we could have similar behavior? which just do some general header info check, calculate CRC of the header and ignore the real contents of most header fields. Do you think it is reasonable?

Adding additional support for these fields is fine, we just need to agree on the API changes to move forward prior to updating the PR

Thanks!
Lin

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

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

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From alanb at openjdk.java.net  Sun Apr 11 13:47:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 11 Apr 2021 13:47:43 GMT
Subject: RFR: 8264208: Console charset API [v2]
In-Reply-To: <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>
Message-ID: <PK6d-sJpo6TFL_Sg-nseVHg8JHqlAVUPOYCZRgKeJck=.29662da4-ffb6-4cd4-8ba0-8c55fa1782d7@github.com>

On Fri, 9 Apr 2021 21:06:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflected the review comments.

src/java.base/share/classes/java/io/Console.java line 397:

> 395:     /**
> 396:      * Returns the {@link java.nio.charset.Charset Charset} object used in
> 397:      * this {@code Console}.

The Console is a singleton and the existing methods use "the console" so I think we should do the same here.

We'll need to add to the description of the System.{in,out,err} fields, I don't mind if we do it as part of this PR or another issue.

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

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

From mik3hall at gmail.com  Sun Apr 11 15:46:53 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 11 Apr 2021 10:46:53 -0500
Subject: jpackage ea-17 --mac-entitlements 
In-Reply-To: <BBB99242-DCDC-4045-A1A1-9FE43F1FE1B9@gmail.com>
References: <46999285-AB16-4C02-B891-1CEFF804C58E@gmail.com>
 <5E9852DD-B066-4EFD-8D74-3D17C5CFA807@gmail.com>
 <BBB99242-DCDC-4045-A1A1-9FE43F1FE1B9@gmail.com>
Message-ID: <A256DF43-ACEA-4CCD-B4F5-816D01CD6822@gmail.com>



> On Apr 9, 2021, at 9:27 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> 
>> OK, probable user error. I eliminated my entitlement changes and it worked.
>> 
> Related to the same functionality that I am trying to add, I should, or have to, make changes to my Info.plist
> This being the addition of NSAppleEventsUsageDescription. 
> If I remember correctly in prior discussion concerning application specific environment variables provision was made for the user to include their own custom Info.plist in the Resources directory? Is that correct? Does the file name stay the same?
>  

I apparently remembered this correctly. I added the above NSAppleEventsUsageDescription to a copied Info.plist and it worked from the resources dir.

On the AppleEvent permission issue it was my misunderstanding on that. I thought I should pass my application bundle id for the user to give permission to. 
But it should be passed the ?other? bundle id of what I want to send events to.
So in this case with the permission request?
		System.out.println(aePerm("com.apple.systemevents",true));

You can then?

exec open "/System/Library/CoreServices/System Events.app?.       [The target app must be running or -600 error]
us.hall.osx.AEPermit                                                                          [This got the dialog requesting permission without hanging]
0

And an AppleScript against System Events can be run?

mps
376	Finder		com.apple.finder	/System/Library/CoreServices/Finder.app	MACS
836	Mail		com.apple.mail	/System/Applications/Mail.app	emal
1338	AdobeReader	com.adobe.Reader	/Applications/Adobe Acrobat Reader DC.app	CARO
2225	Terminal		com.apple.Terminal	/System/Applications/Utilities/Terminal.app	????
2398	HalfPipe		us.hall.HalfPipe	/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app	????
2834	System Preferences	com.apple.systempreferences	/System/Applications/System Preferences.app	sprf
2855	eclipse		org.eclipse.platform.ide	/Users/mjh/java-2019-06/Eclipse.app	????

Old AppleScript based command to get Apple specific information about running processes from System Events, which is an application itself I just found out.

Requesting permission for your own bundle id hangs. Otherwise no problem, and nothing jpackage/Java related for that matter.
But to indicate resolved.


From jiefu at tencent.com  Mon Apr 12 06:51:27 2021
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Mon, 12 Apr 2021 06:51:27 +0000
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}
Message-ID: <F8E82625-69A8-44BD-8BA8-CE77377895C2@tencent.com>

Hi all,

I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
```
Math.pow(-0.0, 0.5) = 0.0
Math.sqrt(-0.0) = -0.0

Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
```

The reason is that both of pow and sqrt have special rules for these computations.
For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.

I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).

So why Java creates conflict special rules for them?
Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?

I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L644
[2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L385
[3] https://github.com/openjdk/jdk/pull/3404/

From github.com+10835776+stsypanov at openjdk.java.net  Mon Apr 12 08:28:04 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 12 Apr 2021 08:28:04 GMT
Subject: RFR: 8265039: Adjust javadoc for ByteArray*Stream and InputStream
Message-ID: <4gCHtNBg4xI0Sfz81z5-iViKyF1z7BEVPpTGsWmuRek=.270a9f3e-c52e-404c-8290-5a2f0bab3855@github.com>

Hello,

to avoid cases detected in [https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pull/2992) I propose to modify JavaDoc of  `ByteArray*Stream` to explicitly mention redundancy of wrapping with `BufferedInputStream`.

As of `InputStream` I think in notation `It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream.` the word 'never' should be replaced with 'usually': apart from `ByteArrayInputStream` e.g. `FileInputStream.available()` often returns the count of remaining bytes (the only exclusion I'm aware of is the files located under `/proc/`) and indeed this count can be used to allocate a buffer to read all the bytes in one call.

Consider benchmark


@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class ByteArrayInputStreamBenchmark {

  @Benchmark
  public void read(Data data, Blackhole bh) {
    int value;
    var in = data.bais;
    while ((value = in.read()) != -1) {
      bh.consume(value);
    }
  }

  @Benchmark
  public void readBuffered(Data data, Blackhole bh) throws IOException {
    int value;
    var in = new BufferedInputStream(data.bais);
    while ((value = in.read()) != -1) {
      bh.consume(value);
    }
  }

  @Benchmark
  public Object readAllBytes(Data data) {
    var in = data.bais;
    return in.readAllBytes();
  }

  @Benchmark
  public Object readAllBytesBuffered(Data data) throws IOException {
    var in = data.bais;
    return new BufferedInputStream(in).readAllBytes();
  }

  @State(Scope.Thread)
  public static class Data {

    @Param({"8", "128", "512", "1024"})
    private int length;

    private byte[] bytes;
    private ByteArrayInputStream bais;

    @Setup(Level.Iteration)
    public void setUp() {
      bytes = new byte[length];
      ThreadLocalRandom.current().nextBytes(bytes);
    }

    @Setup(Level.Invocation)
    public void setUpBais() {
      bais = new ByteArrayInputStream(bytes);
    }
  }
}


giving


                                         (length)       Score     Error   Units
read                                            8      55.737 ?   0.431   ns/op
read                                          128     533.172 ?   1.613   ns/op
read                                          512    2066.238 ?  23.989   ns/op
read                                         1024    4335.570 ?  20.137   ns/op

readBuffered                                    8     521.936 ?   2.454   ns/op
readBuffered                                  128     971.617 ? 100.469   ns/op
readBuffered                                  512    2284.472 ? 251.390   ns/op
readBuffered                                 1024    4168.598 ?  77.980   ns/op

readAllBytes                                    8      34.850 ?   0.072   ns/op
readAllBytes                                  128      36.751 ?   0.133   ns/op
readAllBytes                                  512      45.304 ?   0.699   ns/op
readAllBytes                                 1024      61.790 ?   0.386   ns/op

readAllBytesBuffered                            8     870.454 ?   4.406   ns/op
readAllBytesBuffered                          128     910.176 ?  32.258   ns/op
readAllBytesBuffered                          512     896.155 ?   6.005   ns/op
readAllBytesBuffered                         1024     965.596 ?  29.225   ns/op

read:?gc.alloc.rate.norm                        8      32.006 ?   0.001    B/op
read:?gc.alloc.rate.norm                      128      32.007 ?   0.004    B/op
read:?gc.alloc.rate.norm                      512      32.010 ?   0.010    B/op
read:?gc.alloc.rate.norm                     1024      32.011 ?   0.008    B/op

readBuffered:?gc.alloc.rate.norm                8    8280.354 ?   0.016    B/op
readBuffered:?gc.alloc.rate.norm              128    8240.484 ?   0.015    B/op
readBuffered:?gc.alloc.rate.norm              512    8240.599 ?   0.056    B/op
readBuffered:?gc.alloc.rate.norm             1024    8280.978 ?   0.024    B/op

readAllBytes:?gc.alloc.rate.norm                8      56.008 ?   0.001    B/op
readAllBytes:?gc.alloc.rate.norm              128     176.017 ?   0.001    B/op
readAllBytes:?gc.alloc.rate.norm              512     560.035 ?   0.002    B/op
readAllBytes:?gc.alloc.rate.norm             1024    1072.057 ?   0.002    B/op

readAllBytesBuffered:?gc.alloc.rate.norm        8   16512.660 ?   0.026    B/op
readAllBytesBuffered:?gc.alloc.rate.norm      128   16632.684 ?   0.008    B/op
readAllBytesBuffered:?gc.alloc.rate.norm      512   17016.694 ?   0.017    B/op
readAllBytesBuffered:?gc.alloc.rate.norm     1024   17528.748 ?   0.012    B/op

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

Commit messages:
 - Adjust javadoc for ByteArray*Stream

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

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

From yyang at openjdk.java.net  Mon Apr 12 08:28:08 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 12 Apr 2021 08:28:08 GMT
Subject: RFR: 8265039: Adjust javadoc for ByteArray*Stream and InputStream
In-Reply-To: <4gCHtNBg4xI0Sfz81z5-iViKyF1z7BEVPpTGsWmuRek=.270a9f3e-c52e-404c-8290-5a2f0bab3855@github.com>
References: <4gCHtNBg4xI0Sfz81z5-iViKyF1z7BEVPpTGsWmuRek=.270a9f3e-c52e-404c-8290-5a2f0bab3855@github.com>
Message-ID: <Qb254NwfMc8Y8LbAEZA87VOs-E0M1xEGVWF6BlBpHDI=.2aa6abcf-f269-4fce-9a78-2cbe29a01cf6@github.com>

On Mon, 5 Apr 2021 08:37:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Hello,
> 
> to avoid cases detected in [https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pull/2992) I propose to modify JavaDoc of  `ByteArray*Stream` to explicitly mention redundancy of wrapping with `BufferedInputStream`.
> 
> As of `InputStream` I think in notation `It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream.` the word 'never' should be replaced with 'usually': apart from `ByteArrayInputStream` e.g. `FileInputStream.available()` often returns the count of remaining bytes (the only exclusion I'm aware of is the files located under `/proc/`) and indeed this count can be used to allocate a buffer to read all the bytes in one call.
> 
> Consider benchmark
> 
> 
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class ByteArrayInputStreamBenchmark {
> 
>   @Benchmark
>   public void read(Data data, Blackhole bh) {
>     int value;
>     var in = data.bais;
>     while ((value = in.read()) != -1) {
>       bh.consume(value);
>     }
>   }
> 
>   @Benchmark
>   public void readBuffered(Data data, Blackhole bh) throws IOException {
>     int value;
>     var in = new BufferedInputStream(data.bais);
>     while ((value = in.read()) != -1) {
>       bh.consume(value);
>     }
>   }
> 
>   @Benchmark
>   public Object readAllBytes(Data data) {
>     var in = data.bais;
>     return in.readAllBytes();
>   }
> 
>   @Benchmark
>   public Object readAllBytesBuffered(Data data) throws IOException {
>     var in = data.bais;
>     return new BufferedInputStream(in).readAllBytes();
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
> 
>     @Param({"8", "128", "512", "1024"})
>     private int length;
> 
>     private byte[] bytes;
>     private ByteArrayInputStream bais;
> 
>     @Setup(Level.Iteration)
>     public void setUp() {
>       bytes = new byte[length];
>       ThreadLocalRandom.current().nextBytes(bytes);
>     }
> 
>     @Setup(Level.Invocation)
>     public void setUpBais() {
>       bais = new ByteArrayInputStream(bytes);
>     }
>   }
> }
> 
> 
> giving
> 
> 
>                                          (length)       Score     Error   Units
> read                                            8      55.737 ?   0.431   ns/op
> read                                          128     533.172 ?   1.613   ns/op
> read                                          512    2066.238 ?  23.989   ns/op
> read                                         1024    4335.570 ?  20.137   ns/op
> 
> readBuffered                                    8     521.936 ?   2.454   ns/op
> readBuffered                                  128     971.617 ? 100.469   ns/op
> readBuffered                                  512    2284.472 ? 251.390   ns/op
> readBuffered                                 1024    4168.598 ?  77.980   ns/op
> 
> readAllBytes                                    8      34.850 ?   0.072   ns/op
> readAllBytes                                  128      36.751 ?   0.133   ns/op
> readAllBytes                                  512      45.304 ?   0.699   ns/op
> readAllBytes                                 1024      61.790 ?   0.386   ns/op
> 
> readAllBytesBuffered                            8     870.454 ?   4.406   ns/op
> readAllBytesBuffered                          128     910.176 ?  32.258   ns/op
> readAllBytesBuffered                          512     896.155 ?   6.005   ns/op
> readAllBytesBuffered                         1024     965.596 ?  29.225   ns/op
> 
> read:?gc.alloc.rate.norm                        8      32.006 ?   0.001    B/op
> read:?gc.alloc.rate.norm                      128      32.007 ?   0.004    B/op
> read:?gc.alloc.rate.norm                      512      32.010 ?   0.010    B/op
> read:?gc.alloc.rate.norm                     1024      32.011 ?   0.008    B/op
> 
> readBuffered:?gc.alloc.rate.norm                8    8280.354 ?   0.016    B/op
> readBuffered:?gc.alloc.rate.norm              128    8240.484 ?   0.015    B/op
> readBuffered:?gc.alloc.rate.norm              512    8240.599 ?   0.056    B/op
> readBuffered:?gc.alloc.rate.norm             1024    8280.978 ?   0.024    B/op
> 
> readAllBytes:?gc.alloc.rate.norm                8      56.008 ?   0.001    B/op
> readAllBytes:?gc.alloc.rate.norm              128     176.017 ?   0.001    B/op
> readAllBytes:?gc.alloc.rate.norm              512     560.035 ?   0.002    B/op
> readAllBytes:?gc.alloc.rate.norm             1024    1072.057 ?   0.002    B/op
> 
> readAllBytesBuffered:?gc.alloc.rate.norm        8   16512.660 ?   0.026    B/op
> readAllBytesBuffered:?gc.alloc.rate.norm      128   16632.684 ?   0.008    B/op
> readAllBytesBuffered:?gc.alloc.rate.norm      512   17016.694 ?   0.017    B/op
> readAllBytesBuffered:?gc.alloc.rate.norm     1024   17528.748 ?   0.012    B/op

Hi, I create the issue https://bugs.openjdk.java.net/browse/JDK-8265039 for this PR??.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Apr 12 08:28:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 12 Apr 2021 08:28:11 GMT
Subject: RFR: 8265039: Adjust javadoc for ByteArray*Stream and InputStream
In-Reply-To: <Qb254NwfMc8Y8LbAEZA87VOs-E0M1xEGVWF6BlBpHDI=.2aa6abcf-f269-4fce-9a78-2cbe29a01cf6@github.com>
References: <4gCHtNBg4xI0Sfz81z5-iViKyF1z7BEVPpTGsWmuRek=.270a9f3e-c52e-404c-8290-5a2f0bab3855@github.com>
 <Qb254NwfMc8Y8LbAEZA87VOs-E0M1xEGVWF6BlBpHDI=.2aa6abcf-f269-4fce-9a78-2cbe29a01cf6@github.com>
Message-ID: <9wVjxrcx9QmeTgMAgMRMMydW5kiOTAkEtIuLthO86Ws=.d36c60ef-68b2-4672-9162-339f7372a40a@github.com>

On Mon, 12 Apr 2021 02:40:27 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Hello,
>> 
>> to avoid cases detected in [https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pull/2992) I propose to modify JavaDoc of  `ByteArray*Stream` to explicitly mention redundancy of wrapping with `BufferedInputStream`.
>> 
>> As of `InputStream` I think in notation `It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream.` the word 'never' should be replaced with 'usually': apart from `ByteArrayInputStream` e.g. `FileInputStream.available()` often returns the count of remaining bytes (the only exclusion I'm aware of is the files located under `/proc/`) and indeed this count can be used to allocate a buffer to read all the bytes in one call.
>> 
>> Consider benchmark
>> 
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class ByteArrayInputStreamBenchmark {
>> 
>>   @Benchmark
>>   public void read(Data data, Blackhole bh) {
>>     int value;
>>     var in = data.bais;
>>     while ((value = in.read()) != -1) {
>>       bh.consume(value);
>>     }
>>   }
>> 
>>   @Benchmark
>>   public void readBuffered(Data data, Blackhole bh) throws IOException {
>>     int value;
>>     var in = new BufferedInputStream(data.bais);
>>     while ((value = in.read()) != -1) {
>>       bh.consume(value);
>>     }
>>   }
>> 
>>   @Benchmark
>>   public Object readAllBytes(Data data) {
>>     var in = data.bais;
>>     return in.readAllBytes();
>>   }
>> 
>>   @Benchmark
>>   public Object readAllBytesBuffered(Data data) throws IOException {
>>     var in = data.bais;
>>     return new BufferedInputStream(in).readAllBytes();
>>   }
>> 
>>   @State(Scope.Thread)
>>   public static class Data {
>> 
>>     @Param({"8", "128", "512", "1024"})
>>     private int length;
>> 
>>     private byte[] bytes;
>>     private ByteArrayInputStream bais;
>> 
>>     @Setup(Level.Iteration)
>>     public void setUp() {
>>       bytes = new byte[length];
>>       ThreadLocalRandom.current().nextBytes(bytes);
>>     }
>> 
>>     @Setup(Level.Invocation)
>>     public void setUpBais() {
>>       bais = new ByteArrayInputStream(bytes);
>>     }
>>   }
>> }
>> 
>> 
>> giving
>> 
>> 
>>                                          (length)       Score     Error   Units
>> read                                            8      55.737 ?   0.431   ns/op
>> read                                          128     533.172 ?   1.613   ns/op
>> read                                          512    2066.238 ?  23.989   ns/op
>> read                                         1024    4335.570 ?  20.137   ns/op
>> 
>> readBuffered                                    8     521.936 ?   2.454   ns/op
>> readBuffered                                  128     971.617 ? 100.469   ns/op
>> readBuffered                                  512    2284.472 ? 251.390   ns/op
>> readBuffered                                 1024    4168.598 ?  77.980   ns/op
>> 
>> readAllBytes                                    8      34.850 ?   0.072   ns/op
>> readAllBytes                                  128      36.751 ?   0.133   ns/op
>> readAllBytes                                  512      45.304 ?   0.699   ns/op
>> readAllBytes                                 1024      61.790 ?   0.386   ns/op
>> 
>> readAllBytesBuffered                            8     870.454 ?   4.406   ns/op
>> readAllBytesBuffered                          128     910.176 ?  32.258   ns/op
>> readAllBytesBuffered                          512     896.155 ?   6.005   ns/op
>> readAllBytesBuffered                         1024     965.596 ?  29.225   ns/op
>> 
>> read:?gc.alloc.rate.norm                        8      32.006 ?   0.001    B/op
>> read:?gc.alloc.rate.norm                      128      32.007 ?   0.004    B/op
>> read:?gc.alloc.rate.norm                      512      32.010 ?   0.010    B/op
>> read:?gc.alloc.rate.norm                     1024      32.011 ?   0.008    B/op
>> 
>> readBuffered:?gc.alloc.rate.norm                8    8280.354 ?   0.016    B/op
>> readBuffered:?gc.alloc.rate.norm              128    8240.484 ?   0.015    B/op
>> readBuffered:?gc.alloc.rate.norm              512    8240.599 ?   0.056    B/op
>> readBuffered:?gc.alloc.rate.norm             1024    8280.978 ?   0.024    B/op
>> 
>> readAllBytes:?gc.alloc.rate.norm                8      56.008 ?   0.001    B/op
>> readAllBytes:?gc.alloc.rate.norm              128     176.017 ?   0.001    B/op
>> readAllBytes:?gc.alloc.rate.norm              512     560.035 ?   0.002    B/op
>> readAllBytes:?gc.alloc.rate.norm             1024    1072.057 ?   0.002    B/op
>> 
>> readAllBytesBuffered:?gc.alloc.rate.norm        8   16512.660 ?   0.026    B/op
>> readAllBytesBuffered:?gc.alloc.rate.norm      128   16632.684 ?   0.008    B/op
>> readAllBytesBuffered:?gc.alloc.rate.norm      512   17016.694 ?   0.017    B/op
>> readAllBytesBuffered:?gc.alloc.rate.norm     1024   17528.748 ?   0.012    B/op
>
> Hi, I create the issue https://bugs.openjdk.java.net/browse/JDK-8265039 for this PR??.

@kelthuzadx thanks!

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

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

From chegar at openjdk.java.net  Mon Apr 12 08:31:51 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 12 Apr 2021 08:31:51 GMT
Subject: RFR: 8264827: Large mapped buffer/segment crash the VM when
 calling isLoaded [v2]
In-Reply-To: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>
References: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>
Message-ID: <O20h2DZFozpGOS8rJyK66m5bCTJilMF180tn5NwAtVY=.6623e956-aa53-4cd7-9f24-d7883b831058@github.com>

> Avoid overflow when calculating the number of pages for large mapped segment sizes.

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

  Skip testing on 32-bit systems

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3378/files
  - new: https://git.openjdk.java.net/jdk/pull/3378/files/1816b200..1dbe4a63

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

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

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

From adinn at redhat.com  Mon Apr 12 09:23:24 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 12 Apr 2021 10:23:24 +0100
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}
In-Reply-To: <F8E82625-69A8-44BD-8BA8-CE77377895C2@tencent.com>
References: <F8E82625-69A8-44BD-8BA8-CE77377895C2@tencent.com>
Message-ID: <e1cf592d-b883-a4e5-63c2-bcaceb00f675@redhat.com>

On 12/04/2021 07:51, jiefu(??) wrote:

> I think most people will be confused by these rules because from the
> view of mathematics, Math.pow(x, 0.5) should be equal to
> Math.sqrt(x).

This is already a confused situation from the point of view of 
mathematics. Consider these two expressions:

Math.sqrt(-0.0) * Math.sqrt(-0.0)

Math.pow(-0.0, 0.5) * Math.pow(-0.0, 0.5)

It doesn't matter whether the functions sqrt and pow compute -0.0 or 0.0 
as the value here. Either result will fail to satisfy the equality

   f(x) * f(x) == x

The problem is that computation has already diverged from mathematical 
expectation by introducing the value -0.0. So, Java (and other 
languages) have to make up a rule here.

> So why Java creates conflict special rules for them? Is it possible
> to let Math.pow(-0.0, 0.5) = -0.0 and
> Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?

It might well match expectations better if both functions were to 
generate the same value here. However, expectations have already been 
set by libc:

$ cat > sqrt.c << END
#include <stdio.h>
#include <math.h>
int main(int argc, char **argv) {
     printf("sqrt(-0.F) = %f\n", sqrt(-0.F));
     printf("pow(-0.F, 0.5) = %f\n", pow(-0.F, 0.5));
}
END
$ make sqrt
cc     sqrt.c   -o sqrt
$ ./sqrt
sqrt(-0.F) = -0.000000
pow(-0.F, 0.5) = 0.000000

I have no idea why these specific results were made up for C but Java 
really ought to follow them.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From mcimadamore at openjdk.java.net  Mon Apr 12 10:07:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 12 Apr 2021 10:07:55 GMT
Subject: RFR: 8264827: Large mapped buffer/segment crash the VM when
 calling isLoaded [v2]
In-Reply-To: <O20h2DZFozpGOS8rJyK66m5bCTJilMF180tn5NwAtVY=.6623e956-aa53-4cd7-9f24-d7883b831058@github.com>
References: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>
 <O20h2DZFozpGOS8rJyK66m5bCTJilMF180tn5NwAtVY=.6623e956-aa53-4cd7-9f24-d7883b831058@github.com>
Message-ID: <o92S9JcsAzNmDJ5-BSXqvp8ybmduAVKDgJbrICwzDIs=.5bcff298-c769-4944-a421-6ac17f9d5d9d@github.com>

On Mon, 12 Apr 2021 08:31:51 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Avoid overflow when calculating the number of pages for large mapped segment sizes.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Skip testing on 32-bit systems

Looks good - thanks for fixing.

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

Marked as reviewed by mcimadamore (Reviewer).

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

From raffaello.giulietti at gmail.com  Mon Apr 12 10:40:02 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 12 Apr 2021 12:40:02 +0200
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}
Message-ID: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>

Hi Jie,

the behavior you report is the one specified by the standard IEEE 754. 
Java follows this standard as closely as it can.

The standard says that
* squareRoot(-0) = -0
* squareRoot(-?) = NaN

Also, the standard has a long lists of special cases for pow(x, y), 
among them:
* pow(?0, y) is +0 for finite y > 0 and not an odd integer
* pow(-?, y) is +? for finite y > 0 and not an odd integer

Thus, the conflicts you observe originate in following the standard, not 
by special Java rules.

Unfortunately, the IEEE standard does not explain the reasons for the 
special rules. Some are obvious, some are not.


HTH
Raffaello


> Hi all,
> 
> I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
> ```
> Math.pow(-0.0, 0.5) = 0.0
> Math.sqrt(-0.0) = -0.0
> 
> Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
> Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
> ```
> 
> The reason is that both of pow and sqrt have special rules for these computations.
> For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
> And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
> And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
> 
> I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
> 
> So why Java creates conflict special rules for them?
> Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
> 
> I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
> If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
> 
> Thanks.
> Best regards,
> Jie

From redestad at openjdk.java.net  Mon Apr 12 10:53:14 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 12 Apr 2021 10:53:14 GMT
Subject: RFR: 8265061: Simplify MethodHandleNatives::canBeCalledVirtual
Message-ID: <F1BFRA3SUXt26I6rF7d2ttmCbPGtLXJuk8miIzB9DIA=.2ed3675d-005e-48d0-9ad3-5878d9928b93@github.com>

Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual is a cleanup and minimal startup improvement on apps spinning up MethodHandles.

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

Commit messages:
 - Remove switch in canBeCalledVirtual

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

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

From chegar at openjdk.java.net  Mon Apr 12 11:25:54 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 12 Apr 2021 11:25:54 GMT
Subject: Integrated: 8264827: Large mapped buffer/segment crash the VM when
 calling isLoaded
In-Reply-To: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>
References: <DdpnMcD0fHQcOxoX3CxfMD-e91jh-Wq6ygGts4jj-TA=.0f54915c-9ec1-4497-a7f2-ec2228b7bf62@github.com>
Message-ID: <rDcEwW_Cp8lzok9R7vnGSbNiLZD-jz5UWRyvtapMbdE=.5160bffe-53b8-41ad-9550-522b52bcb788@github.com>

On Wed, 7 Apr 2021 15:45:30 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Avoid overflow when calculating the number of pages for large mapped segment sizes.

This pull request has now been integrated.

Changeset: 3c9858dd
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3c9858dd
Stats:     36 lines in 5 files changed: 23 ins; 0 del; 13 mod

8264827: Large mapped buffer/segment crash the VM when calling isLoaded

Reviewed-by: alanb, mcimadamore

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

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

From jiefu at tencent.com  Mon Apr 12 11:44:05 2021
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Mon, 12 Apr 2021 11:44:05 +0000
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}(Internet mail)
In-Reply-To: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
Message-ID: <72184DF4-C63B-488F-8490-074247292022@tencent.com>

Hi Andrew H, Andrew D, and Raffaello,

Thank you all for your kind reply and helpful comments.

Now I got where the rules come from.
But I don't think the IEEE standars are reasonable to specify conflits rules.
Maybe, these computations should be open to be implementation dependent.

(If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java.
We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right?
And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.

Thanks.
Best regards,
Jie


?On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:

    Hi Jie,
    
    the behavior you report is the one specified by the standard IEEE 754. 
    Java follows this standard as closely as it can.
    
    The standard says that
    * squareRoot(-0) = -0
    * squareRoot(-?) = NaN
    
    Also, the standard has a long lists of special cases for pow(x, y), 
    among them:
    * pow(?0, y) is +0 for finite y > 0 and not an odd integer
    * pow(-?, y) is +? for finite y > 0 and not an odd integer
    
    Thus, the conflicts you observe originate in following the standard, not 
    by special Java rules.
    
    Unfortunately, the IEEE standard does not explain the reasons for the 
    special rules. Some are obvious, some are not.
    
    
    HTH
    Raffaello
    
    
    > Hi all,
    > 
    > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
    > ```
    > Math.pow(-0.0, 0.5) = 0.0
    > Math.sqrt(-0.0) = -0.0
    > 
    > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
    > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
    > ```
    > 
    > The reason is that both of pow and sqrt have special rules for these computations.
    > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
    > And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
    > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
    > 
    > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
    > 
    > So why Java creates conflict special rules for them?
    > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
    > 
    > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
    > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
    > 
    > Thanks.
    > Best regards,
    > Jie
    
    


From jvernee at openjdk.java.net  Mon Apr 12 11:50:55 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 12 Apr 2021 11:50:55 GMT
Subject: RFR: 8265061: Simplify MethodHandleNatives::canBeCalledVirtual
In-Reply-To: <F1BFRA3SUXt26I6rF7d2ttmCbPGtLXJuk8miIzB9DIA=.2ed3675d-005e-48d0-9ad3-5878d9928b93@github.com>
References: <F1BFRA3SUXt26I6rF7d2ttmCbPGtLXJuk8miIzB9DIA=.2ed3675d-005e-48d0-9ad3-5878d9928b93@github.com>
Message-ID: <3dkA-W1oDe3xQ5bHIx83PzHVcO76smzpPg8T-goDbjE=.04ba28bc-a9c4-4603-b641-4943823807d1@github.com>

On Mon, 12 Apr 2021 10:45:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual is a cleanup and minimal startup improvement on apps spinning up MethodHandles.

Marked as reviewed by jvernee (Committer).

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

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

From jfranck at openjdk.java.net  Mon Apr 12 11:53:48 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 12 Apr 2021 11:53:48 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices [v3]
In-Reply-To: <LJiE5efTG4CwqcSbpXeFsYcuLDd2e3JXArhax993k2c=.66ac49d1-1b4f-4eb9-8aa9-ff7fb022222d@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
 <LJiE5efTG4CwqcSbpXeFsYcuLDd2e3JXArhax993k2c=.66ac49d1-1b4f-4eb9-8aa9-ff7fb022222d@github.com>
Message-ID: <2ZehSCiNqik-zxVHZVjDYtNta0DRymcX5iAMeu-wXec=.5fb68e0f-5357-40ab-a9c5-4ebf8cd83da0@github.com>

On Sat, 10 Apr 2021 20:22:56 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.

Marked as reviewed by jfranck (Reviewer).

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

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

From raffaello.giulietti at gmail.com  Mon Apr 12 13:05:58 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 12 Apr 2021 15:05:58 +0200
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}(Internet mail)
In-Reply-To: <72184DF4-C63B-488F-8490-074247292022@tencent.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
 <72184DF4-C63B-488F-8490-074247292022@tencent.com>
Message-ID: <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>

Hi Jie,

I don't think that changing the spec of Math.pow() to be misaligned with 
IEEE 754 would be a wise option. IEEE is much more pervasive than Java. 
There are many aspects in IEEE that might be seen as questionable, but 
at least it is a widely adopted standard.

AFAIU, the only reason you would like to "optimize" the special case of 
y = 0.5 in pow(x, y) to return sqrt(x) is for performance, more accuracy 
and some kind of consistency.

But then, why not a special case for y = 0.25 as sqrt(sqrt(x))?
And what about y = 0.75? Should this be translated to sqrt(sqrt(pow(x, 3)))?
What about y = 1.0 / 3.0? Should this become cbrt(x)?
And why not consider y = 2.0 / 3.0 in a special rule: cbrt(x * x)?

You see, the special cases can quickly become unmanageable. Also, 
special rules would produce results which are "discontinuous" with 
nearby exponents, like y = 0.5000000000000001.

That's probably why IEEE doesn't propose translation rules for finite 
numerical exponents that are not integers, except when x is a special value.


Greetings
Raffaello



On 2021-04-12 13:44, jiefu(??) wrote:
> Hi Andrew H, Andrew D, and Raffaello,
> 
> Thank you all for your kind reply and helpful comments.
> 
> Now I got where the rules come from.
> But I don't think the IEEE standars are reasonable to specify conflits rules.
> Maybe, these computations should be open to be implementation dependent.
> 
> (If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java.
> We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right?
> And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> ?On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
> 
>      Hi Jie,
>      
>      the behavior you report is the one specified by the standard IEEE 754.
>      Java follows this standard as closely as it can.
>      
>      The standard says that
>      * squareRoot(-0) = -0
>      * squareRoot(-?) = NaN
>      
>      Also, the standard has a long lists of special cases for pow(x, y),
>      among them:
>      * pow(?0, y) is +0 for finite y > 0 and not an odd integer
>      * pow(-?, y) is +? for finite y > 0 and not an odd integer
>      
>      Thus, the conflicts you observe originate in following the standard, not
>      by special Java rules.
>      
>      Unfortunately, the IEEE standard does not explain the reasons for the
>      special rules. Some are obvious, some are not.
>      
>      
>      HTH
>      Raffaello
>      
>      
>      > Hi all,
>      >
>      > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
>      > ```
>      > Math.pow(-0.0, 0.5) = 0.0
>      > Math.sqrt(-0.0) = -0.0
>      >
>      > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
>      > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
>      > ```
>      >
>      > The reason is that both of pow and sqrt have special rules for these computations.
>      > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
>      > And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
>      > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
>      >
>      > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
>      >
>      > So why Java creates conflict special rules for them?
>      > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
>      >
>      > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
>      > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
>      >
>      > Thanks.
>      > Best regards,
>      > Jie
>      
>      
> 

From jiefu at tencent.com  Mon Apr 12 13:39:16 2021
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Mon, 12 Apr 2021 13:39:16 +0000
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}(Internet mail)
In-Reply-To: <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
 <72184DF4-C63B-488F-8490-074247292022@tencent.com>
 <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>
Message-ID: <F7BB9A3B-454F-48A4-A8EB-83200E0C50CF@tencent.com>

Hi Raffaello,

Thanks for your execllent analysis.
I agree with you now.
And I'll close the optimization PR [1] tomorrow if there is no objections.

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/pull/3404/


?On 2021/4/12, 9:06 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:

    Hi Jie,
    
    I don't think that changing the spec of Math.pow() to be misaligned with 
    IEEE 754 would be a wise option. IEEE is much more pervasive than Java. 
    There are many aspects in IEEE that might be seen as questionable, but 
    at least it is a widely adopted standard.
    
    AFAIU, the only reason you would like to "optimize" the special case of 
    y = 0.5 in pow(x, y) to return sqrt(x) is for performance, more accuracy 
    and some kind of consistency.
    
    But then, why not a special case for y = 0.25 as sqrt(sqrt(x))?
    And what about y = 0.75? Should this be translated to sqrt(sqrt(pow(x, 3)))?
    What about y = 1.0 / 3.0? Should this become cbrt(x)?
    And why not consider y = 2.0 / 3.0 in a special rule: cbrt(x * x)?
    
    You see, the special cases can quickly become unmanageable. Also, 
    special rules would produce results which are "discontinuous" with 
    nearby exponents, like y = 0.5000000000000001.
    
    That's probably why IEEE doesn't propose translation rules for finite 
    numerical exponents that are not integers, except when x is a special value.
    
    
    Greetings
    Raffaello
    
    
    
    On 2021-04-12 13:44, jiefu(??) wrote:
    > Hi Andrew H, Andrew D, and Raffaello,
    > 
    > Thank you all for your kind reply and helpful comments.
    > 
    > Now I got where the rules come from.
    > But I don't think the IEEE standars are reasonable to specify conflits rules.
    > Maybe, these computations should be open to be implementation dependent.
    > 
    > (If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java.
    > We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right?
    > And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.
    > 
    > Thanks.
    > Best regards,
    > Jie
    > 
    > 
    > On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
    > 
    >      Hi Jie,
    >      
    >      the behavior you report is the one specified by the standard IEEE 754.
    >      Java follows this standard as closely as it can.
    >      
    >      The standard says that
    >      * squareRoot(-0) = -0
    >      * squareRoot(-?) = NaN
    >      
    >      Also, the standard has a long lists of special cases for pow(x, y),
    >      among them:
    >      * pow(?0, y) is +0 for finite y > 0 and not an odd integer
    >      * pow(-?, y) is +? for finite y > 0 and not an odd integer
    >      
    >      Thus, the conflicts you observe originate in following the standard, not
    >      by special Java rules.
    >      
    >      Unfortunately, the IEEE standard does not explain the reasons for the
    >      special rules. Some are obvious, some are not.
    >      
    >      
    >      HTH
    >      Raffaello
    >      
    >      
    >      > Hi all,
    >      >
    >      > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
    >      > ```
    >      > Math.pow(-0.0, 0.5) = 0.0
    >      > Math.sqrt(-0.0) = -0.0
    >      >
    >      > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
    >      > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
    >      > ```
    >      >
    >      > The reason is that both of pow and sqrt have special rules for these computations.
    >      > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
    >      > And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
    >      > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
    >      >
    >      > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
    >      >
    >      > So why Java creates conflict special rules for them?
    >      > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
    >      >
    >      > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
    >      > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
    >      >
    >      > Thanks.
    >      > Best regards,
    >      > Jie
    >      
    >      
    > 
    
    


From ccleary at openjdk.java.net  Mon Apr 12 14:09:55 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 12 Apr 2021 14:09:55 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
Message-ID: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>

> ### Description
> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
> 
> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
> 
> ### Fixes
> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.

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

 - Update copyright headers
 - Tidied up lambdas

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3416/files
  - new: https://git.openjdk.java.net/jdk/pull/3416/files/f0c2238a..840ea35c

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

  Stats: 29 lines in 5 files changed: 1 ins; 7 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3416.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3416/head:pull/3416

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

From ccleary at openjdk.java.net  Mon Apr 12 14:09:56 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 12 Apr 2021 14:09:56 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <aQ2Xcg-PwlYCTma5o-F1e2sZ_n7aM2Lva_8RVzbKmq8=.e0236973-77af-47f7-8049-244db469dce5@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <so-JHo-zCJLzP1A-f6PyAQmMGeDd1SEHlWXWkgTHGIw=.5249d1d2-a236-4081-956e-f45414c9cfad@github.com>
 <1sJidHe6B9avCln-Fqqklfv4TKrXL64_utx21MprrYk=.817a96d0-71db-4dec-9dfa-8d66b5854452@github.com>
 <aQ2Xcg-PwlYCTma5o-F1e2sZ_n7aM2Lva_8RVzbKmq8=.e0236973-77af-47f7-8049-244db469dce5@github.com>
Message-ID: <Mh9r3zNrfJcLdriMb0Y9j5W9ebTr_70fRF1s30IgDvU=.457940bc-2388-454d-bd97-d9e81fe488cf@github.com>

On Fri, 9 Apr 2021 16:30:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thanks for the suggestion Roger, I think the `privilegedGetProperty(prop, default)` for the `getProperty()` method looks great. 
>> 
>> WRT to using it for `getInt()` and `getLong()`, I think its reasonable to use other means for these methods in the interest of consistency due to, as you pointed out, only `int` being supported. Would you think? Or would it be better to use the same means in all 3 methods?
>
> Its a slippery slope that might require a bit more investigation to check the expected value sizes to see if a change to the number of bits in the value for each property might break something.  Technical debt can take you down a rabbit hole. Quickest to just convert to the lamba as you proposed.

I have stuck with the lambda conversion solution in the [current changes](https://github.com/openjdk/jdk/pull/3416/commits/1746840eaa9a8de34d89d73d993e2f86aa0d0ed3), however WRT to Alan's previous feedback on creating a PrivilegedAction explicitly as it makes everything a bit more readable.

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

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

From raffaello.giulietti at gmail.com  Mon Apr 12 15:37:46 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 12 Apr 2021 17:37:46 +0200
Subject: What is the status of JEP draft: "Predictable regex performance"?
Message-ID: <5c4e932c-42cb-33d2-d5cc-e9d07243a728@gmail.com>

Hello,

I'm just curious about the status of the important project described by 
"JEP draft: Predictable regex performance" [1].

Afaiu, there are mentions about:
* Using the native re2 library [2] via JNI, with the cons that usage 
becomes kind of unnatural, like "closing" the pattern to release native 
resources.
* Possibly porting re2 to Java, but it seems rather big, several kLOC.
* Adopting/adapting the incomplete and unmaintained re2j [3] Java 
implementation of re2.
* Using the sregex project [4], but it's unclear to me what makes it 
substantially different from re2.

Less clear is whether the project is still exploring various 
alternatives in addition to the above ones or has started to converge 
towards a preferred choice.


Greetings
Raffaello

----

[1] https://openjdk.java.net/jeps/8260688
[2] https://github.com/google/re2
[3] https://github.com/rapid7/re2-java
[4] https://github.com/openresty/sregex

From mchung at openjdk.java.net  Mon Apr 12 16:14:38 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Apr 2021 16:14:38 GMT
Subject: RFR: 8265061: Simplify MethodHandleNatives::canBeCalledVirtual
In-Reply-To: <F1BFRA3SUXt26I6rF7d2ttmCbPGtLXJuk8miIzB9DIA=.2ed3675d-005e-48d0-9ad3-5878d9928b93@github.com>
References: <F1BFRA3SUXt26I6rF7d2ttmCbPGtLXJuk8miIzB9DIA=.2ed3675d-005e-48d0-9ad3-5878d9928b93@github.com>
Message-ID: <0ZjUSczymCgdg3X2z_foCmnHPTm6NIQGnW3boALzu-I=.6eb77c86-a324-4e05-8b20-435a2272d937@github.com>

On Mon, 12 Apr 2021 10:45:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual is a cleanup and minimal startup improvement on apps spinning up MethodHandles.

Marked as reviewed by mchung (Reviewer).

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

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

From dfuchs at openjdk.java.net  Mon Apr 12 16:16:39 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 12 Apr 2021 16:16:39 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
Message-ID: <DAqlNN1EEtZq1tY493jw2XeA27e7NOL350g-3FMrfi4=.ae5327d7-8eb5-4d67-ae66-faf86c0c06b0@github.com>

On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
>> 
>> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
>> 
>> ### Fixes
>> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.
>
> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright headers
>  - Tidied up lambdas

LGTM

src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 400:

> 398:     private static final String getProperty(final String propName, final String defVal) {
> 399:         PrivilegedAction<String> pa = () -> System.getProperty(propName, defVal);
> 400:         return AccessController.doPrivileged(pa);

Hmmm... This is not strictly equivalent but will work because java.naming is loaded by the boot loader and has the permission to read all system properties. I guess the code on the left-hand side was written at a time where JNDI was still in a stand-alone library?

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

Marked as reviewed by dfuchs (Reviewer).

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

From erikj at openjdk.java.net  Mon Apr 12 16:21:50 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 12 Apr 2021 16:21:50 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
Message-ID: <kVdFvMb_xK3q3FCB94V8aJbUpoEVsH3mjZFPP6JFy_0=.6bdcc9ec-33d4-4492-83bf-b728a0fce482@github.com>

On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> 
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov 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:
> 
>  - Restore Graal Builder image makefile
>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>  - 8264806: Remove the experimental JIT compiler

make/common/Modules.gmk line 68:

> 66: 
> 67: # Filter out Graal specific modules
> 68: MODULES_FILTER += jdk.internal.vm.compiler

If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all?

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

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

From naoto.sato at oracle.com  Mon Apr 12 16:41:36 2021
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 12 Apr 2021 09:41:36 -0700
Subject: RFR: 8264208: Console charset API [v2]
In-Reply-To: <AM0PR03MB4145819B0E63C7299CD2BF28FF729@AM0PR03MB4145.eurprd03.prod.outlook.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>
 <AM0PR03MB4145819B0E63C7299CD2BF28FF729@AM0PR03MB4145.eurprd03.prod.outlook.com>
Message-ID: <8acc3ff0-e460-6240-fdf4-d5c3e75be4dc@oracle.com>

Hi Bernd,

On 4/9/21 5:21 PM, Bernd Eckenfels wrote:
> Hello,
> 
> I like the API, it is useful, however not enough to replace the defaultCharset once the Change to UTF8 is done. You still need a way to query the platforms file encoding (especially on Windows).

Initially I thought it would be beneficial to provide the method that 
returns so-called `platform` charset, but I am not so sure introducing 
it. The reason is that once JEP 400 is enabled, that method only serves 
to migrate the old apps in the new environment. And that's where the 
`COMPAT` system property would be utilized. If those apps have luxury to 
make source code changes, I would recommend migrating the code by giving 
the charset argument to the failing FileReader or alike.

> 
> Also I wonder if the Javadoc needs to discuss platform aspects of console, especially System.out and LANG on unix vs. windows.

I will add some descriptions to System.out/err in relation to Console, 
but how they map to platform's settings (LANG on Unix/System locale on 
Windows) is an implementation detail, and I don't think it should be be 
described in the spec.

Naoto

> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Naoto Sato <naoto at openjdk.java.net>
> Gesendet: Friday, April 9, 2021 11:06:00 PM
> An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Betreff: Re: RFR: 8264208: Console charset API [v2]
> 
>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
> 
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Reflected the review comments.
> 
> -------------
> 
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/3419/files
>    - new: https://git.openjdk.java.net/jdk/pull/3419/files/d6db04bb..8fd8f6e6
> 
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=01
>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=00-01
> 
>    Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419
> 
> PR: https://git.openjdk.java.net/jdk/pull/3419
> 

From aefimov at openjdk.java.net  Mon Apr 12 16:56:42 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 12 Apr 2021 16:56:42 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
Message-ID: <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com>

On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
>> 
>> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
>> 
>> ### Fixes
>> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.
>
> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright headers
>  - Tidied up lambdas

The change looks good to me with one small suggestion:

src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java line 223:

> 221:      */
> 222:     private final ClassLoader getContextClassLoader() {
> 223:         PrivilegedAction<ClassLoader> pa = () -> Thread.currentThread().getContextClassLoader();

We can use here an instance method reference to beautify code a little bit more:
```PrivilegedAction<ClassLoader> pa = Thread.currentThread()::getContextClassLoader;```

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

Marked as reviewed by aefimov (Committer).

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

From kvn at openjdk.java.net  Mon Apr 12 17:22:00 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 12 Apr 2021 17:22:00 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <kVdFvMb_xK3q3FCB94V8aJbUpoEVsH3mjZFPP6JFy_0=.6bdcc9ec-33d4-4492-83bf-b728a0fce482@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <kVdFvMb_xK3q3FCB94V8aJbUpoEVsH3mjZFPP6JFy_0=.6bdcc9ec-33d4-4492-83bf-b728a0fce482@github.com>
Message-ID: <z8uXpkbdA-wiwrLpejc7CDO-er7i6IH3bxJ_xD-Ayl0=.f7d147c2-f0e1-4228-aed0-83023551afd9@github.com>

On Mon, 12 Apr 2021 16:18:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Vladimir Kozlov 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:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> make/common/Modules.gmk line 68:
> 
>> 66: 
>> 67: # Filter out Graal specific modules
>> 68: MODULES_FILTER += jdk.internal.vm.compiler
> 
> If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all?

We filter out because we can't build Graal anymore. But we need these module-info.java files because JVMCI's module-info.java references them:
https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java#L26

Otherwise we can't build JVMCI which we continue to support.

I filed followup RFE to implement Alan's suggestion to use Module  API which will allow to remove these files later:
https://bugs.openjdk.java.net/browse/JDK-8265091

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

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

From rriggs at openjdk.java.net  Mon Apr 12 17:37:28 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 12 Apr 2021 17:37:28 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
Message-ID: <KMMQsX9FLcV0x5dadY9TUKXPEzBeazAXAgqyMMjIO4Q=.3e47f06f-b4b5-45d2-84aa-9545187c6817@github.com>

On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
>> 
>> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
>> 
>> ### Fixes
>> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.
>
> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright headers
>  - Tidied up lambdas

Marked as reviewed by rriggs (Reviewer).

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

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

From joe.darcy at oracle.com  Mon Apr 12 18:20:28 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 12 Apr 2021 11:20:28 -0700
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}(Internet mail)
In-Reply-To: <F7BB9A3B-454F-48A4-A8EB-83200E0C50CF@tencent.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
 <72184DF4-C63B-488F-8490-074247292022@tencent.com>
 <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>
 <F7BB9A3B-454F-48A4-A8EB-83200E0C50CF@tencent.com>
Message-ID: <e093136a-78ff-06f4-46ce-3b46c764ee03@oracle.com>

Hello,

Adding some additional context, more recent versions of the IEEE 754 
standard have given explicit recommendations for math library function 
definitions, including pow. The Java definitions of those methods long 
predate the IEEE 754 coverage and there are a small number of 
differences, including in the pow special cases. These differences are 
now described more explicitly in the JDK 17 specs as of

JDK-8240632: Note differences between IEEE 754-2019 math lib special 
cases and java.lang.Math

The difference in question for pow is:

> ???? * @apiNote
> ???? * The special cases definitions of this method differ from the
> ???? * special case definitions of the IEEE 754 recommended {@code
> ???? * pow} operation for &plusmn;{@code 1.0} raised to an infinite
> ???? * power. This method treats such cases as indeterminate and
> ???? * specifies a NaN is returned. The IEEE 754 specification treats
> ???? * the infinite power as a large integer (large-magnitude
> ???? * floating-point numbers are numerically integers, specifically
> ???? * even integers) and therefore specifies {@code 1.0} be returned.

There are no plans to align the Java definition of pow with the IEEE 754 
definition in these few cases.

Note that the Java library implementation of pow does delegate to sqrt 
while respecting the relevant special cases:

> ??????????? } else if (y == 0.5) {
> ??????????????? if (x >= -Double.MAX_VALUE) // Handle x == -infinity later
> ??????????????????? return Math.sqrt(x + 0.0); // Add 0.0 to properly 
> handle x == -0.0
https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L366

Mathematically, the sqrt function is about as pleasant a function as you 
can be asked to approximate in floating-point arithmetic. The function 
is smooth, doesn't overflow or underflow, and has a simple 
Newton-iteration that can be expressed in basic arithmetic operations. 
The pow function doesn't enjoy these properties and has a larger design 
space for what a reasonable floating-point approximation could be.

HTH,

-Joe

On 4/12/2021 6:39 AM, jiefu(??) wrote:
> Hi Raffaello,
>
> Thanks for your execllent analysis.
> I agree with you now.
> And I'll close the optimization PR [1] tomorrow if there is no objections.
>
> Thanks.
> Best regards,
> Jie
>
> [1] https://github.com/openjdk/jdk/pull/3404/
>
>
> ?On 2021/4/12, 9:06 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
>
>      Hi Jie,
>      
>      I don't think that changing the spec of Math.pow() to be misaligned with
>      IEEE 754 would be a wise option. IEEE is much more pervasive than Java.
>      There are many aspects in IEEE that might be seen as questionable, but
>      at least it is a widely adopted standard.
>      
>      AFAIU, the only reason you would like to "optimize" the special case of
>      y = 0.5 in pow(x, y) to return sqrt(x) is for performance, more accuracy
>      and some kind of consistency.
>      
>      But then, why not a special case for y = 0.25 as sqrt(sqrt(x))?
>      And what about y = 0.75? Should this be translated to sqrt(sqrt(pow(x, 3)))?
>      What about y = 1.0 / 3.0? Should this become cbrt(x)?
>      And why not consider y = 2.0 / 3.0 in a special rule: cbrt(x * x)?
>      
>      You see, the special cases can quickly become unmanageable. Also,
>      special rules would produce results which are "discontinuous" with
>      nearby exponents, like y = 0.5000000000000001.
>      
>      That's probably why IEEE doesn't propose translation rules for finite
>      numerical exponents that are not integers, except when x is a special value.
>      
>      
>      Greetings
>      Raffaello
>      
>      
>      
>      On 2021-04-12 13:44, jiefu(??) wrote:
>      > Hi Andrew H, Andrew D, and Raffaello,
>      >
>      > Thank you all for your kind reply and helpful comments.
>      >
>      > Now I got where the rules come from.
>      > But I don't think the IEEE standars are reasonable to specify conflits rules.
>      > Maybe, these computations should be open to be implementation dependent.
>      >
>      > (If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java.
>      > We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right?
>      > And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.
>      >
>      > Thanks.
>      > Best regards,
>      > Jie
>      >
>      >
>      > On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
>      >
>      >      Hi Jie,
>      >
>      >      the behavior you report is the one specified by the standard IEEE 754.
>      >      Java follows this standard as closely as it can.
>      >
>      >      The standard says that
>      >      * squareRoot(-0) = -0
>      >      * squareRoot(-?) = NaN
>      >
>      >      Also, the standard has a long lists of special cases for pow(x, y),
>      >      among them:
>      >      * pow(?0, y) is +0 for finite y > 0 and not an odd integer
>      >      * pow(-?, y) is +? for finite y > 0 and not an odd integer
>      >
>      >      Thus, the conflicts you observe originate in following the standard, not
>      >      by special Java rules.
>      >
>      >      Unfortunately, the IEEE standard does not explain the reasons for the
>      >      special rules. Some are obvious, some are not.
>      >
>      >
>      >      HTH
>      >      Raffaello
>      >
>      >
>      >      > Hi all,
>      >      >
>      >      > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
>      >      > ```
>      >      > Math.pow(-0.0, 0.5) = 0.0
>      >      > Math.sqrt(-0.0) = -0.0
>      >      >
>      >      > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
>      >      > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
>      >      > ```
>      >      >
>      >      > The reason is that both of pow and sqrt have special rules for these computations.
>      >      > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
>      >      > And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
>      >      > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
>      >      >
>      >      > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
>      >      >
>      >      > So why Java creates conflict special rules for them?
>      >      > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
>      >      >
>      >      > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
>      >      > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
>      >      >
>      >      > Thanks.
>      >      > Best regards,
>      >      > Jie
>      >
>      >
>      >
>      
>      
>

From chegar at openjdk.java.net  Mon Apr 12 18:41:30 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 12 Apr 2021 18:41:30 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
Message-ID: <_GNd3qUOe-dSf-ZjSVe0SieHKlaJys9Ue8kbLl9Ai0Q=.430a49bc-b581-46c4-9290-47d3596c73f2@github.com>

On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
>> 
>> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
>> 
>> ### Fixes
>> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.
>
> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright headers
>  - Tidied up lambdas

Marked as reviewed by chegar (Reviewer).

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

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

From egahlin at openjdk.java.net  Mon Apr 12 20:53:09 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 12 Apr 2021 20:53:09 GMT
Subject: RFR: 8203359: Container level resources events [v7]
In-Reply-To: <VfQQscAw_gy6to6NS4kUlABJ_ErFH4_9denWYtB9zE0=.ff5ad719-110a-46c2-97d2-b2641b065949@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <VfQQscAw_gy6to6NS4kUlABJ_ErFH4_9denWYtB9zE0=.ff5ad719-110a-46c2-97d2-b2641b065949@github.com>
Message-ID: <ejPb-pIuXnItPJfNsuEqQ3u54Nu38GeN7RYf4ftrapo=.5b71e65c-399f-4933-8490-b897564aa325@github.com>

On Fri, 2 Apr 2021 12:33:03 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
>> 
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
>> * CPU related metrics
>> * Memory related metrics
>> * I/O related metrics
>> 
>> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
>> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove trailing spaces

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 163:

> 161:     private static void initializeContainerEvents() {
> 162:         containerMetrics = Container.metrics();
> 163:         if (containerMetrics != null) {

I understand this will reduce startup time, but it's contrary to how we treat other events. 

We register events, even if they can't be used. We want users to see what events are available (and their metadata) and use JMC recording wizard or other means to configure a .jfc file without actually being connected to a containerized process. We want the same events to minimize (subtle) platform dependent bugs.

I think we should try to find other means to reduce the startup time. It's better to have consistent behaviour, but an initial implementation than isn't as performant, than inconsistent behavior and somewhat faster implementation.

At some point we will need to address the startup cost of registering Java events anyway. For example, we could generate metadata at build time in a binary format, similar to what we already do with native events. Could even be the same file. Then we can have hundreds of Java events without the cost of reflection and unnecessary class loading at startup. We could add a simple check so that bytecode for the container events (commit() etc) are not generated unless in a container environment. A couple of (cached) checks in JVMUpcalls may be sufficient to prevent instrumentation cost.

src/jdk.jfr/share/conf/jfr/default.jfc line 1051:

> 1049:       <flag name="class-loading-enabled" label="Class Loading">false</flag>
> 1050: 
> 1051:       <flag name="container-events-enabled" label="Container Events">true</flag>

I don't think we should create "flag" for "Container Events". Instead we should treat them like CPU and other OS events, always on. Since JFR can be used outside a container, it seems wrong to have this as an option.

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

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

From winterhalter at openjdk.java.net  Mon Apr 12 20:54:47 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 12 Apr 2021 20:54:47 GMT
Subject: RFR: 8228988: AnnotationParser throws NullPointerException on
 incompatible member type
In-Reply-To: <Zylg9nIkBHVXyHvMWMr6OI2LcX0OY8RZ_9YVcx61DJE=.17aa18df-62d9-4009-9f23-fe3aabe9d990@github.com>
References: <Zylg9nIkBHVXyHvMWMr6OI2LcX0OY8RZ_9YVcx61DJE=.17aa18df-62d9-4009-9f23-fe3aabe9d990@github.com>
Message-ID: <rMRU9XUY9e3Hjnf3ApThfDJJUCyHOAvRo4Kx9pMXXN0=.572f6f7d-712e-4215-a1ff-01f54349d449@github.com>

On Fri, 5 Feb 2021 21:24:34 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> When a class is compiled against a version of an annotation that is later loaded in an incompatible manner where an enum-typed member is changed into an annotation or vice versa, the reflection API currently throws a `NullPointerException` upon accessing the member. Instead an `AnnotationTypeMismatchException` should be thrown.
> 
> This change adjusts the parsing to trigger the correct exception.

Sure, I created a [CSR for the change](https://bugs.openjdk.java.net/browse/JDK-8265097). Are those picked up automatically or is there something more I should do to have it reviewed?

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

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

From erikj at openjdk.java.net  Mon Apr 12 20:58:35 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 12 Apr 2021 20:58:35 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <z8uXpkbdA-wiwrLpejc7CDO-er7i6IH3bxJ_xD-Ayl0=.f7d147c2-f0e1-4228-aed0-83023551afd9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <kVdFvMb_xK3q3FCB94V8aJbUpoEVsH3mjZFPP6JFy_0=.6bdcc9ec-33d4-4492-83bf-b728a0fce482@github.com>
 <z8uXpkbdA-wiwrLpejc7CDO-er7i6IH3bxJ_xD-Ayl0=.f7d147c2-f0e1-4228-aed0-83023551afd9@github.com>
Message-ID: <7HS0ES8bIxSFNXrIiGQRIgm5w30UQqGIHP7TmfWNDAg=.3a2af723-79ee-4ce8-9e1c-3873b09ed9c0@github.com>

On Mon, 12 Apr 2021 17:18:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> make/common/Modules.gmk line 68:
>> 
>>> 66: 
>>> 67: # Filter out Graal specific modules
>>> 68: MODULES_FILTER += jdk.internal.vm.compiler
>> 
>> If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all?
>
> We filter out because we can't build Graal anymore. But we need these module-info.java files because JVMCI's module-info.java references them:
> https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java#L26
> 
> Otherwise we can't build JVMCI which we continue to support.
> 
> I filed followup RFE to implement Alan's suggestion to use Module  API which will allow to remove these files later:
> https://bugs.openjdk.java.net/browse/JDK-8265091

Right, I thought I saw something about modules that Alan commented on, but couldn't find it. All good then.

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

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

From erikj at openjdk.java.net  Mon Apr 12 20:58:32 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 12 Apr 2021 20:58:32 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
Message-ID: <eA8Jvy2UDmoHFmXXl7iKHf1Rpye4jcGbcC_itITSyYI=.959320fc-e89a-4b74-b0ad-131fc2d962e6@github.com>

On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> 
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov 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:
> 
>  - Restore Graal Builder image makefile
>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>  - 8264806: Remove the experimental JIT compiler

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From winterhalter at openjdk.java.net  Mon Apr 12 21:05:10 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 12 Apr 2021 21:05:10 GMT
Subject: Integrated: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices
In-Reply-To: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
Message-ID: <M3axLM_FvQCaRtFl5Yk-0fV22AYR_oqdKih3oseT9b0=.73d4072f-bf09-465a-8454-5bba0ec1b531@github.com>

On Thu, 18 Mar 2021 21:03:20 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.

This pull request has now been integrated.

Changeset: 9dd96257
Author:    Rafael Winterhalter <winterhalter at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9dd96257
Stats:     73 lines in 4 files changed: 64 ins; 0 del; 9 mod

8263763: Synthetic constructor parameters of enum are not considered for annotation indices

Reviewed-by: darcy, jfranck

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

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

From almatvee at openjdk.java.net  Mon Apr 12 21:05:23 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 12 Apr 2021 21:05:23 GMT
Subject: RFR: 8263157: [macos]: java.library.path is being set incorrectly
Message-ID: <v7NMd4LY3RreLut_ZvMF-uieaeAmeyXC4yzNRS4A0TY=.fbb2eae4-9c39-46ff-b4a4-a62d0096ed03@github.com>

This is regression from JDK-8242302. Fixed by setting java.library.path to same values as it was before JDK-8242302.

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

Commit messages:
 - 8263157: [macos]: java.library.path is being set incorrectly

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

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

From igraves at openjdk.java.net  Mon Apr 12 21:06:02 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 12 Apr 2021 21:06:02 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation
Message-ID: <17pJwHuMSE84yctm26ka--BCKYk_PDensjFdYqx9f_I=.94b25ba9-c244-4870-b620-7fc54199bc51@github.com>

Fixes a bug where the compensated sum should be negated when added together in the merge step of a given collector. This impacts accuracy of parallel summations with Double streams and creates larger deviations from a standard sequential (ie non-parallel) compensated summation.

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

Commit messages:
 - Fixing a compensated/Kahan summation bug that increase error

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

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

From naoto at openjdk.java.net  Mon Apr 12 21:15:18 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 12 Apr 2021 21:15:18 GMT
Subject: RFR: 8264208: Console charset API [v3]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <cXxF8OzB-ii-jmJmo6nNP-Sj_2KYbfmt7NZPDALDVT8=.00ccc11e-9ac5-42aa-9616-f3b63d120c8c@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Reflecting the review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/8fd8f6e6..c172d0a1

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

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

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

From naoto at openjdk.java.net  Mon Apr 12 21:15:19 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 12 Apr 2021 21:15:19 GMT
Subject: RFR: 8264208: Console charset API [v2]
In-Reply-To: <PK6d-sJpo6TFL_Sg-nseVHg8JHqlAVUPOYCZRgKeJck=.29662da4-ffb6-4cd4-8ba0-8c55fa1782d7@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>
 <PK6d-sJpo6TFL_Sg-nseVHg8JHqlAVUPOYCZRgKeJck=.29662da4-ffb6-4cd4-8ba0-8c55fa1782d7@github.com>
Message-ID: <kxV55hr3g5mDXwJaxIp5q5E3jmW5LjrhMiiounhtmZg=.30a2acfb-c827-4d91-8830-9aad85686ed0@github.com>

On Sun, 11 Apr 2021 13:44:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflected the review comments.
>
> src/java.base/share/classes/java/io/Console.java line 397:
> 
>> 395:     /**
>> 396:      * Returns the {@link java.nio.charset.Charset Charset} object used in
>> 397:      * this {@code Console}.
> 
> The Console is a singleton and the existing methods use "the console" so I think we should do the same here.
> 
> We'll need to add to the description of the System.{in,out,err} fields, I don't mind if we do it as part of this PR or another issue.

Javadoc updated. Instead of modifying System.out/err (System.in is not affected, as it does not convert b2c), I modified PrintStream javadoc.

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

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

From igraves at openjdk.java.net  Mon Apr 12 21:27:58 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 12 Apr 2021 21:27:58 GMT
Subject: Withdrawn: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <17pJwHuMSE84yctm26ka--BCKYk_PDensjFdYqx9f_I=.94b25ba9-c244-4870-b620-7fc54199bc51@github.com>
References: <17pJwHuMSE84yctm26ka--BCKYk_PDensjFdYqx9f_I=.94b25ba9-c244-4870-b620-7fc54199bc51@github.com>
Message-ID: <Z1SzduVXb70r6y8DCj69e7-OSJsfu_nWBZfjxQLDJPc=.8b4b6811-4793-4d12-88f5-e0b6494abcb9@github.com>

On Mon, 12 Apr 2021 19:45:24 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Fixes a bug where the compensated sum should be negated when added together in the merge step of a given collector. This impacts accuracy of parallel summations with Double streams and creates larger deviations from a standard sequential (ie non-parallel) compensated summation.

This pull request has been closed without being integrated.

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

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

From igraves at openjdk.java.net  Mon Apr 12 21:31:57 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 12 Apr 2021 21:31:57 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <17pJwHuMSE84yctm26ka--BCKYk_PDensjFdYqx9f_I=.94b25ba9-c244-4870-b620-7fc54199bc51@github.com>
References: <17pJwHuMSE84yctm26ka--BCKYk_PDensjFdYqx9f_I=.94b25ba9-c244-4870-b620-7fc54199bc51@github.com>
Message-ID: <ehoR1CPZCR_T_KgzmAmVTjCWBZgnmujWCjkdLeBsVCc=.e9d6e289-e1f4-4a0f-b284-3c97629247c8@github.com>

On Mon, 12 Apr 2021 19:45:24 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Fixes a bug where the compensated sum should be negated when added together in the merge step of a given collector. This impacts accuracy of parallel summations with Double streams and creates larger deviations from a standard sequential (ie non-parallel) compensated summation.

Duplicate of https://github.com/openjdk/jdk/pull/2988

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

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

From asemenyuk at openjdk.java.net  Mon Apr 12 22:06:57 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 12 Apr 2021 22:06:57 GMT
Subject: RFR: 8263157: [macos]: java.library.path is being set incorrectly
In-Reply-To: <v7NMd4LY3RreLut_ZvMF-uieaeAmeyXC4yzNRS4A0TY=.fbb2eae4-9c39-46ff-b4a4-a62d0096ed03@github.com>
References: <v7NMd4LY3RreLut_ZvMF-uieaeAmeyXC4yzNRS4A0TY=.fbb2eae4-9c39-46ff-b4a4-a62d0096ed03@github.com>
Message-ID: <9qv18DMZ31JEZiukb5FhS_BBQY0sbmEZSOH_FLyIgaY=.388361f0-4fab-4423-8bf6-fc7dc6bb5843@github.com>

On Mon, 12 Apr 2021 20:18:46 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8242302. Fixed by setting java.library.path to same values as it was before JDK-8242302.

Marked as reviewed by asemenyuk (Reviewer).

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

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

From kvn at openjdk.java.net  Mon Apr 12 22:10:06 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 12 Apr 2021 22:10:06 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v3]
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <tXz08rqVPR_leQJMDGrYd4-Z-CrN8vIX105a8Z-GFho=.4b53feba-294e-4a9d-8b6a-d5cdcfaa1367@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> 
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

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

  Restore Compiler::isGraalEnabled()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3421/files
  - new: https://git.openjdk.java.net/jdk/pull/3421/files/a246aaa6..9d6bd42c

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

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

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

From kvn at openjdk.java.net  Mon Apr 12 22:26:09 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 12 Apr 2021 22:26:09 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
Message-ID: <PgueLCQ0HYg5vnvL4zYYrWZbPJbH78CtDkWEr41dBDM=.34bbd71a-990d-47eb-9b1c-10868501c12d@github.com>

On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Vladimir Kozlov 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:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important.

@dougxc  I restored Compiler::isGraalEnabled().

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

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

From naoto at openjdk.java.net  Mon Apr 12 23:01:24 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 12 Apr 2021 23:01:24 GMT
Subject: RFR: 8264208: Console charset API [v4]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Reverted PrintStream changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/c172d0a1..68db1a79

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

  Stats: 50 lines in 2 files changed: 8 ins; 9 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

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

From naoto at openjdk.java.net  Mon Apr 12 23:01:25 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 12 Apr 2021 23:01:25 GMT
Subject: RFR: 8264208: Console charset API [v2]
In-Reply-To: <kxV55hr3g5mDXwJaxIp5q5E3jmW5LjrhMiiounhtmZg=.30a2acfb-c827-4d91-8830-9aad85686ed0@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com>
 <PK6d-sJpo6TFL_Sg-nseVHg8JHqlAVUPOYCZRgKeJck=.29662da4-ffb6-4cd4-8ba0-8c55fa1782d7@github.com>
 <kxV55hr3g5mDXwJaxIp5q5E3jmW5LjrhMiiounhtmZg=.30a2acfb-c827-4d91-8830-9aad85686ed0@github.com>
Message-ID: <2OM-k59QZOx9ankM6iryhlGwX7Y3YfAIUpQux3gPuWs=.c94fc3f6-2256-4e98-9820-95dffb05244d@github.com>

On Mon, 12 Apr 2021 21:12:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 397:
>> 
>>> 395:     /**
>>> 396:      * Returns the {@link java.nio.charset.Charset Charset} object used in
>>> 397:      * this {@code Console}.
>> 
>> The Console is a singleton and the existing methods use "the console" so I think we should do the same here.
>> 
>> We'll need to add to the description of the System.{in,out,err} fields, I don't mind if we do it as part of this PR or another issue.
>
> Javadoc updated. Instead of modifying System.out/err (System.in is not affected, as it does not convert b2c), I modified PrintStream javadoc.

Reverted the changes to PrintStream, as it defaults to Charset.defaultCharset(). Added descriptions to System.out/err instead (and modified the impl).

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

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

From psandoz at openjdk.java.net  Mon Apr 12 23:21:01 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 12 Apr 2021 23:21:01 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v2]
In-Reply-To: <ZHLRs8mqnELs41aVUMzXzNKdZMqE8JkiqQ1X07k0uaQ=.fe4eb48c-8b84-4fbf-ba2b-b9e4588b53a5@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
 <ZHLRs8mqnELs41aVUMzXzNKdZMqE8JkiqQ1X07k0uaQ=.fe4eb48c-8b84-4fbf-ba2b-b9e4588b53a5@github.com>
Message-ID: <mCRvFxSzBxp7-9zapodRxMLc0-1xj_UeZWNbXQjkoXI=.0805102a-a61b-47e0-8d80-a4731dd0d62a@github.com>

On Sun, 11 Apr 2021 07:14:07 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
>> 
>> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
>> 
>> 
>> After patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
>> 
>> 
>> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
>> 
>> Before patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
>> 
>> 
>> After patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
>> 
>> 
>> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes according to review:
>   
>   1. Comments in adjustSize
>   2. repeating code extracted from testNoEvaluationForSizedStream

Even though there are not many changes this cuts deep into how streams work. 

I suspect there is some, possibly minor, impact for sized streams without limit/skip because of the increased cost to compute the exact size. Further, that cost is also incurred for `AbstractWrappingSpliterator`, where we might need to cache the exact size result.

I made some suggestions, mostly around naming, but I admit to being a little uncomfortable with the proposed change and need to think a little more about it. I am wondering if we need another stream flag indicating the size is known and has to be computed?

src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 481:

> 479:     long adjustSize(long size) {
> 480:         return previousStage == null ? size : previousStage.adjustSize(size);
> 481:     }

Suggestion:

    /**
     * Returns the exact output size of the pipeline given the exact size reported by the source spliterator.
     *
     * @param sourceSize the exact size reported by the source spliterator
     * @return the exact output size
     */
    long exactOutputSize(long sourceSize) {
        return previousStage == null ? sourceSize : previousStage.exactOutputSize(sourceSize);
    }


Sticking with the `exactOutput` name i think complements the two methods.

src/java.base/share/classes/java/util/stream/SliceOps.java line 232:

> 230:         if (skip < 0)
> 231:             throw new IllegalArgumentException("Skip must be non-negative: " + skip);
> 232:         long adjustedLimit = limit >= 0 ? limit : Long.MAX_VALUE;

Suggestion:

        long normalizedLimit = limit >= 0 ? limit : Long.MAX_VALUE;


The name `adjustedLimit` implies the limit value is changed, rather than changing the no-limit value.

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

Changes requested by psandoz (Reviewer).

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

From psandoz at openjdk.java.net  Mon Apr 12 23:23:59 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 12 Apr 2021 23:23:59 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v2]
In-Reply-To: <ZHLRs8mqnELs41aVUMzXzNKdZMqE8JkiqQ1X07k0uaQ=.fe4eb48c-8b84-4fbf-ba2b-b9e4588b53a5@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
 <ZHLRs8mqnELs41aVUMzXzNKdZMqE8JkiqQ1X07k0uaQ=.fe4eb48c-8b84-4fbf-ba2b-b9e4588b53a5@github.com>
Message-ID: <nuqd7zNJq36aAGP4HBFTi5jWpc0QQE9Xjxv-TKQu8oo=.640c32de-23b9-43da-b3ae-92648d2751ca@github.com>

On Sun, 11 Apr 2021 07:14:07 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
>> 
>> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
>> 
>> 
>> After patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
>> 
>> 
>> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
>> 
>> Before patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
>> 
>> 
>> After patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
>> 
>> 
>> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes according to review:
>   
>   1. Comments in adjustSize
>   2. repeating code extracted from testNoEvaluationForSizedStream

src/java.base/share/classes/java/util/stream/SliceOps.java line 118:

> 116:                     : calcSize(super.adjustSize(size), skip, adjustedLimit);
> 117:             }
> 118: 

Suggestion:

            @Override
            long exactOutputSize(long sourceSize) {
                // For parallel streams, the exact output size is that reported by the slice op's spliterator,
                // since a slice op is a stateful op whose spliterator is the source spliterator
                // (see AbstractPipeline.sourceSpliterator).
                // Otherwise, for sequential streams the extract output size that of the prior pipeline stage reduced
                // by the skip and limit
                return isParallel() ? sourceSize
                    : calcSize(super.exactOutputSize(sourceSize), skip, normalizedLimit);
            }

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

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

From jiefu at tencent.com  Tue Apr 13 01:26:02 2021
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Tue, 13 Apr 2021 01:26:02 +0000
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}(Internet mail)
In-Reply-To: <e093136a-78ff-06f4-46ce-3b46c764ee03@oracle.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
 <72184DF4-C63B-488F-8490-074247292022@tencent.com>
 <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>
 <F7BB9A3B-454F-48A4-A8EB-83200E0C50CF@tencent.com>
 <e093136a-78ff-06f4-46ce-3b46c764ee03@oracle.com>
Message-ID: <0545E3C5-7216-4F39-AF95-D8854CA6B84E@tencent.com>

Hi Joe,

Thanks for your nice sharing.

Very glad to know that the Java library implementation of pow does delegate to sqrt while respecting the relevant special cases.
This implementation [1] has set a good example for us which means it's safe to replace pow(x, 0.5) with sqrt(x) for all x > 0.0.

Thanks
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L366


?On 2021/4/13, 2:21 AM, "Joe Darcy" <joe.darcy at oracle.com> wrote:

    Hello,
    
    Adding some additional context, more recent versions of the IEEE 754 
    standard have given explicit recommendations for math library function 
    definitions, including pow. The Java definitions of those methods long 
    predate the IEEE 754 coverage and there are a small number of 
    differences, including in the pow special cases. These differences are 
    now described more explicitly in the JDK 17 specs as of
    
    JDK-8240632: Note differences between IEEE 754-2019 math lib special 
    cases and java.lang.Math
    
    The difference in question for pow is:
    
    >      * @apiNote
    >      * The special cases definitions of this method differ from the
    >      * special case definitions of the IEEE 754 recommended {@code
    >      * pow} operation for &plusmn;{@code 1.0} raised to an infinite
    >      * power. This method treats such cases as indeterminate and
    >      * specifies a NaN is returned. The IEEE 754 specification treats
    >      * the infinite power as a large integer (large-magnitude
    >      * floating-point numbers are numerically integers, specifically
    >      * even integers) and therefore specifies {@code 1.0} be returned.
    
    There are no plans to align the Java definition of pow with the IEEE 754 
    definition in these few cases.
    
    Note that the Java library implementation of pow does delegate to sqrt 
    while respecting the relevant special cases:
    
    >             } else if (y == 0.5) {
    >                 if (x >= -Double.MAX_VALUE) // Handle x == -infinity later
    >                     return Math.sqrt(x + 0.0); // Add 0.0 to properly 
    > handle x == -0.0
    https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L366
    
    Mathematically, the sqrt function is about as pleasant a function as you 
    can be asked to approximate in floating-point arithmetic. The function 
    is smooth, doesn't overflow or underflow, and has a simple 
    Newton-iteration that can be expressed in basic arithmetic operations. 
    The pow function doesn't enjoy these properties and has a larger design 
    space for what a reasonable floating-point approximation could be.
    
    HTH,
    
    -Joe
    
    On 4/12/2021 6:39 AM, jiefu(??) wrote:
    > Hi Raffaello,
    >
    > Thanks for your execllent analysis.
    > I agree with you now.
    > And I'll close the optimization PR [1] tomorrow if there is no objections.
    >
    > Thanks.
    > Best regards,
    > Jie
    >
    > [1] https://github.com/openjdk/jdk/pull/3404/
    >
    >
    > On 2021/4/12, 9:06 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
    >
    >      Hi Jie,
    >      
    >      I don't think that changing the spec of Math.pow() to be misaligned with
    >      IEEE 754 would be a wise option. IEEE is much more pervasive than Java.
    >      There are many aspects in IEEE that might be seen as questionable, but
    >      at least it is a widely adopted standard.
    >      
    >      AFAIU, the only reason you would like to "optimize" the special case of
    >      y = 0.5 in pow(x, y) to return sqrt(x) is for performance, more accuracy
    >      and some kind of consistency.
    >      
    >      But then, why not a special case for y = 0.25 as sqrt(sqrt(x))?
    >      And what about y = 0.75? Should this be translated to sqrt(sqrt(pow(x, 3)))?
    >      What about y = 1.0 / 3.0? Should this become cbrt(x)?
    >      And why not consider y = 2.0 / 3.0 in a special rule: cbrt(x * x)?
    >      
    >      You see, the special cases can quickly become unmanageable. Also,
    >      special rules would produce results which are "discontinuous" with
    >      nearby exponents, like y = 0.5000000000000001.
    >      
    >      That's probably why IEEE doesn't propose translation rules for finite
    >      numerical exponents that are not integers, except when x is a special value.
    >      
    >      
    >      Greetings
    >      Raffaello
    >      
    >      
    >      
    >      On 2021-04-12 13:44, jiefu(??) wrote:
    >      > Hi Andrew H, Andrew D, and Raffaello,
    >      >
    >      > Thank you all for your kind reply and helpful comments.
    >      >
    >      > Now I got where the rules come from.
    >      > But I don't think the IEEE standars are reasonable to specify conflits rules.
    >      > Maybe, these computations should be open to be implementation dependent.
    >      >
    >      > (If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java.
    >      > We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right?
    >      > And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.
    >      >
    >      > Thanks.
    >      > Best regards,
    >      > Jie
    >      >
    >      >
    >      > On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
    >      >
    >      >      Hi Jie,
    >      >
    >      >      the behavior you report is the one specified by the standard IEEE 754.
    >      >      Java follows this standard as closely as it can.
    >      >
    >      >      The standard says that
    >      >      * squareRoot(-0) = -0
    >      >      * squareRoot(-?) = NaN
    >      >
    >      >      Also, the standard has a long lists of special cases for pow(x, y),
    >      >      among them:
    >      >      * pow(?0, y) is +0 for finite y > 0 and not an odd integer
    >      >      * pow(-?, y) is +? for finite y > 0 and not an odd integer
    >      >
    >      >      Thus, the conflicts you observe originate in following the standard, not
    >      >      by special Java rules.
    >      >
    >      >      Unfortunately, the IEEE standard does not explain the reasons for the
    >      >      special rules. Some are obvious, some are not.
    >      >
    >      >
    >      >      HTH
    >      >      Raffaello
    >      >
    >      >
    >      >      > Hi all,
    >      >      >
    >      >      > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
    >      >      > ```
    >      >      > Math.pow(-0.0, 0.5) = 0.0
    >      >      > Math.sqrt(-0.0) = -0.0
    >      >      >
    >      >      > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
    >      >      > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
    >      >      > ```
    >      >      >
    >      >      > The reason is that both of pow and sqrt have special rules for these computations.
    >      >      > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
    >      >      > And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
    >      >      > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
    >      >      >
    >      >      > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
    >      >      >
    >      >      > So why Java creates conflict special rules for them?
    >      >      > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
    >      >      >
    >      >      > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
    >      >      > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
    >      >      >
    >      >      > Thanks.
    >      >      > Best regards,
    >      >      > Jie
    >      >
    >      >
    >      >
    >      
    >      
    >
    
    
    


From joehw at openjdk.java.net  Tue Apr 13 02:37:59 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 13 Apr 2021 02:37:59 GMT
Subject: RFR: 8264208: Console charset API [v4]
In-Reply-To: <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>
Message-ID: <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com>

On Mon, 12 Apr 2021 23:01:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted PrintStream changes

src/java.base/share/classes/java/lang/System.java line 2020:

> 2018:         setIn0(new BufferedInputStream(fdIn));
> 2019:         setOut0(newPrintStream(fdOut, cs));
> 2020:         setErr0(newPrintStream(fdErr, cs));

It was getting from sun.stdout.encoding or sun.stderr.encoding. After the change, when there is no console, it would be set with Charset.defaultCharset(). Would that be an incompatible change?

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

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

From mikael at openjdk.java.net  Tue Apr 13 07:12:07 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Tue, 13 Apr 2021 07:12:07 GMT
Subject: RFR: 8265111: ProblemList
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64
Message-ID: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com>

Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a tier1 test) until JDK-8262897 is fixed.

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

Commit messages:
 - 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64

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

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

From dnsimon at openjdk.java.net  Tue Apr 13 09:33:11 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 13 Apr 2021 09:33:11 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
Message-ID: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>

On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Vladimir Kozlov 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:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important.

> @dougxc I restored Compiler::isGraalEnabled().

Thanks. I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later).

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

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

From ccleary at openjdk.java.net  Tue Apr 13 09:36:58 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 13 Apr 2021 09:36:58 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
 <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com>
Message-ID: <Pf2u9S9Cqh7U6E9z8ORmDnZ0PwWjF8VgV4cHyKedCE4=.b33eb0ed-75d7-4655-95be-819514157f20@github.com>

On Mon, 12 Apr 2021 16:44:16 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright headers
>>  - Tidied up lambdas
>
> src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java line 223:
> 
>> 221:      */
>> 222:     private final ClassLoader getContextClassLoader() {
>> 223:         PrivilegedAction<ClassLoader> pa = () -> Thread.currentThread().getContextClassLoader();
> 
> We can use here an instance method reference to beautify code a little bit more:
> ```PrivilegedAction<ClassLoader> pa = Thread.currentThread()::getContextClassLoader;```

Good idea, also would fit in with the style of the method just after, `priviligedHasNext()` as that also uses a functional interface.

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

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

From ccleary at openjdk.java.net  Tue Apr 13 10:04:20 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 13 Apr 2021 10:04:20 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <Pf2u9S9Cqh7U6E9z8ORmDnZ0PwWjF8VgV4cHyKedCE4=.b33eb0ed-75d7-4655-95be-819514157f20@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
 <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com>
 <Pf2u9S9Cqh7U6E9z8ORmDnZ0PwWjF8VgV4cHyKedCE4=.b33eb0ed-75d7-4655-95be-819514157f20@github.com>
Message-ID: <4F7WdUagEWET1dKexsG-tW7MIhIwVPeYGW9u2w_kArE=.e7bd2f51-37f2-4542-bfdd-bcdd7cee6218@github.com>

On Tue, 13 Apr 2021 09:34:15 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java line 223:
>> 
>>> 221:      */
>>> 222:     private final ClassLoader getContextClassLoader() {
>>> 223:         PrivilegedAction<ClassLoader> pa = () -> Thread.currentThread().getContextClassLoader();
>> 
>> We can use here an instance method reference to beautify code a little bit more:
>> ```PrivilegedAction<ClassLoader> pa = Thread.currentThread()::getContextClassLoader;```
>
> Good idea, also would fit in with the style of the method just after, `priviligedHasNext()` as that also uses a functional interface.

Changes included as described in commit [5d6ecd3](https://github.com/openjdk/jdk/pull/3416/commits/5d6ecd31eb6ed2a63f17b2e798e83b91cb720075)

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

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

From ccleary at openjdk.java.net  Tue Apr 13 10:04:19 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 13 Apr 2021 10:04:19 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v3]
In-Reply-To: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
Message-ID: <ZrFeEgGlY7jEL6qlmvwCKL9XrXZrPPvcFHIGNjh50mA=.c1982633-80b6-4e29-a99b-8609b092e05f@github.com>

> ### Description
> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
> 
> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
> 
> ### Fixes
> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.

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

  8048199: Cleaner syntak in getContextClassLoader

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3416/files
  - new: https://git.openjdk.java.net/jdk/pull/3416/files/840ea35c..5d6ecd31

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

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

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

From dfuchs at openjdk.java.net  Tue Apr 13 10:11:57 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 13 Apr 2021 10:11:57 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <4F7WdUagEWET1dKexsG-tW7MIhIwVPeYGW9u2w_kArE=.e7bd2f51-37f2-4542-bfdd-bcdd7cee6218@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
 <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com>
 <Pf2u9S9Cqh7U6E9z8ORmDnZ0PwWjF8VgV4cHyKedCE4=.b33eb0ed-75d7-4655-95be-819514157f20@github.com>
 <4F7WdUagEWET1dKexsG-tW7MIhIwVPeYGW9u2w_kArE=.e7bd2f51-37f2-4542-bfdd-bcdd7cee6218@github.com>
Message-ID: <Ry5wmAnM_USqbfWrTDeSWEQxXm2djaal-RKM75wC45I=.f2c9ad90-d711-4996-9db5-8d386c46762c@github.com>

On Tue, 13 Apr 2021 10:00:51 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Good idea, also would fit in with the style of the method just after, `priviligedHasNext()` as that also uses a functional interface.
>
> Changes included as described in commit [5d6ecd3](https://github.com/openjdk/jdk/pull/3416/commits/5d6ecd31eb6ed2a63f17b2e798e83b91cb720075)

Here again this is not strictly equivalent but AFAIK `Thread::currentThread` doesn't require any permission, so this should be OK.

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

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

From jvernee at openjdk.java.net  Tue Apr 13 10:13:18 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Apr 2021 10:13:18 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching
Message-ID: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>

This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).

This piggybacks on the existing mechanism for method handle invoker caching.

Testing: Local testing `java/lang/invoke` tests. Tier 1-3

Thanks,
Jorn

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

Commit messages:
 - Add VarHandle invoker handle caching

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

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

From redestad at openjdk.java.net  Tue Apr 13 10:32:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 13 Apr 2021 10:32:57 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching
In-Reply-To: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
Message-ID: <68gu-tMmcpDf0xbf7kSMfS_8WHsvvmMnLgNDkFHQRNw=.2a7ea0a7-e029-47ac-bbe1-453c720f6bb8@github.com>

On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
> 
> This piggybacks on the existing mechanism for method handle invoker caching.
> 
> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
> 
> Thanks,
> Jorn

LGTM

`MethodHandles.varHandle(Exact)Invoker` might be somewhat obscure, but caching them like this is straightforward and basically free.

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

Marked as reviewed by redestad (Reviewer).

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

From aefimov at openjdk.java.net  Tue Apr 13 10:33:58 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 13 Apr 2021 10:33:58 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v3]
In-Reply-To: <ZrFeEgGlY7jEL6qlmvwCKL9XrXZrPPvcFHIGNjh50mA=.c1982633-80b6-4e29-a99b-8609b092e05f@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <ZrFeEgGlY7jEL6qlmvwCKL9XrXZrPPvcFHIGNjh50mA=.c1982633-80b6-4e29-a99b-8609b092e05f@github.com>
Message-ID: <t0mtplvz_-sGVbkyzUJsM1T-8frTM9bdgVmf_TCJXjc=.64cb741a-769f-4956-b27f-643b1a0ac608@github.com>

On Tue, 13 Apr 2021 10:04:19 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
>> 
>> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
>> 
>> ### Fixes
>> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8048199: Cleaner syntak in getContextClassLoader

Marked as reviewed by aefimov (Committer).

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

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

From redestad at openjdk.java.net  Tue Apr 13 10:41:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 13 Apr 2021 10:41:57 GMT
Subject: RFR: 8265061: Simplify MethodHandleNatives::canBeCalledVirtual
In-Reply-To: <3dkA-W1oDe3xQ5bHIx83PzHVcO76smzpPg8T-goDbjE=.04ba28bc-a9c4-4603-b641-4943823807d1@github.com>
References: <F1BFRA3SUXt26I6rF7d2ttmCbPGtLXJuk8miIzB9DIA=.2ed3675d-005e-48d0-9ad3-5878d9928b93@github.com>
 <3dkA-W1oDe3xQ5bHIx83PzHVcO76smzpPg8T-goDbjE=.04ba28bc-a9c4-4603-b641-4943823807d1@github.com>
Message-ID: <EO4YMpNkl5MoHdLs4BMTiv_bWUu_sAhFjvZoa4v8qyA=.d9e7513e-b360-4e91-b932-99da6cd96a76@github.com>

On Mon, 12 Apr 2021 11:47:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual is a cleanup and minimal startup improvement on apps spinning up MethodHandles.
>
> Marked as reviewed by jvernee (Committer).

@JornVernee @mlchung - thanks for reviewing!

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

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

From redestad at openjdk.java.net  Tue Apr 13 10:41:58 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 13 Apr 2021 10:41:58 GMT
Subject: Integrated: 8265061: Simplify MethodHandleNatives::canBeCalledVirtual
In-Reply-To: <F1BFRA3SUXt26I6rF7d2ttmCbPGtLXJuk8miIzB9DIA=.2ed3675d-005e-48d0-9ad3-5878d9928b93@github.com>
References: <F1BFRA3SUXt26I6rF7d2ttmCbPGtLXJuk8miIzB9DIA=.2ed3675d-005e-48d0-9ad3-5878d9928b93@github.com>
Message-ID: <clo2HM_tbVshV3gTBvQdFOfNhraEcKo5_kU_nhE0Nks=.697a9864-015a-4fe4-b4a1-74ea487b6ed0@github.com>

On Mon, 12 Apr 2021 10:45:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual is a cleanup and minimal startup improvement on apps spinning up MethodHandles.

This pull request has now been integrated.

Changeset: 7006070f
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7006070f
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8265061: Simplify MethodHandleNatives::canBeCalledVirtual

Reviewed-by: jvernee, mchung

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

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

From akozlov at openjdk.java.net  Tue Apr 13 11:06:00 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 13 Apr 2021 11:06:00 GMT
Subject: RFR: 8265111: ProblemList
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64
In-Reply-To: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com>
References: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com>
Message-ID: <wdp8vrEawc4bLQhZm7OnRZRekbVaK219ij9SM5Fh5CQ=.8cbe8bc0-041a-437b-8524-048a7124a7bf@github.com>

On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a tier1 test) until JDK-8262897 is fixed.

Marked as reviewed by akozlov (no project role).

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

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

From dfuchs at openjdk.java.net  Tue Apr 13 11:09:58 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 13 Apr 2021 11:09:58 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v3]
In-Reply-To: <ZrFeEgGlY7jEL6qlmvwCKL9XrXZrPPvcFHIGNjh50mA=.c1982633-80b6-4e29-a99b-8609b092e05f@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <ZrFeEgGlY7jEL6qlmvwCKL9XrXZrPPvcFHIGNjh50mA=.c1982633-80b6-4e29-a99b-8609b092e05f@github.com>
Message-ID: <M33pBcOhtKjM6rpvBXG0KBwxaNJeGZsXTKnS9Q79p6o=.a4ebe9d5-f205-4823-a47f-871c02a76201@github.com>

On Tue, 13 Apr 2021 10:04:19 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
>> 
>> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
>> 
>> ### Fixes
>> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8048199: Cleaner syntak in getContextClassLoader

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3416

From vlivanov at openjdk.java.net  Tue Apr 13 11:36:58 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 13 Apr 2021 11:36:58 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching
In-Reply-To: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
Message-ID: <CyLBoMFP1tgzprAkLTYPAvTrUSTBJMH_xTgKHcOGuCY=.f6521db4-df07-4c63-af2f-2d88f59dc0a8@github.com>

On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
> 
> This piggybacks on the existing mechanism for method handle invoker caching.
> 
> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
> 
> Thanks,
> Jorn

Looks good.

src/java.base/share/classes/java/lang/invoke/Invokers.java line 131:

> 129:     }
> 130: 
> 131:     private MethodHandle cachedVHInvoker(int idx, VarHandle.AccessMode ak) {

You can turn `int idx` parameter into `boolean isExact` and choose base index depending on its value.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3439

From jpai at openjdk.java.net  Tue Apr 13 11:50:17 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 13 Apr 2021 11:50:17 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <XgB0BT7zwM3BD39h0-BWlxjVpPG2hAfXqGSMEG-dVCM=.e963a637-1499-4f08-8af9-0af1fee96008@github.com>

On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

While we are at this, the `Calendar.getDisplayNames(...)` states this:

> ....
> @throws    IllegalArgumentException
     *        if {@code field} or {@code style} is invalid,
     *        or if this {@code Calendar} is non-lenient and any
     *        of the calendar fields have invalid values

If I understand this correctly, if the `Calendar` instance was non-lenient and this method returned invalid values for the `AM_PM` field, it should have thrown an `IllegalArgumentException` (which is a strange exception to throw for an invalid result, but that's a different matter). However, with the current code in upstream master, I saw no such exception being thrown (nor do I see any such validating code in the `Calendar` implementation) when the calendar instance was non-lenient. Is that expected?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From jpai at openjdk.java.net  Tue Apr 13 11:50:17 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 13 Apr 2021 11:50:17 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
Message-ID: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>

Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?

As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.

The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.

The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.

After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

-------------

Commit messages:
 - Fix test that now fails after fixing 8262108
 - 8262108: SimpleDateFormat formatting broken for sq_MK Locale

Changes: https://git.openjdk.java.net/jdk/pull/3463/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262108
  Stats: 117 lines in 3 files changed: 97 ins; 1 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3463/head:pull/3463

PR: https://git.openjdk.java.net/jdk/pull/3463

From jpai at openjdk.java.net  Tue Apr 13 11:55:59 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 13 Apr 2021 11:55:59 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <N2UFimWEQR8kObGXJqSmVZkbIq95VdyfsaXtno1kHhE=.c5ff4887-5646-4c7d-b8e4-41605b2eda77@github.com>

On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java line 201:

> 199:                                 switch (i) {
> 200:                                     case 0, 2, 3, 4, 5 -> map.put(name, AM);
> 201:                                     case 1, 6, 7, 8, 9, 10, 11 -> map.put(name, PM);

One part where I need input here, is the "midnight" and the "noon" types. I haven't found anything in the JDK code which I can use as a reference to classify "midnight" and "noon" as `AM` (which is what this code is doing). The doc here https://unicode.org/reports/tr35/tr35-dates.html#Day_Period_Rules speaks about these 2 types but I don't think it's something that I can use to translate those types into a field value for Calendar, to represent `AM` or `PM`. As such, right now, I've just guessed that `AM` is probably the right value for these types, but there's no technical reason or reference backing it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From jvernee at openjdk.java.net  Tue Apr 13 12:25:20 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Apr 2021 12:25:20 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching [v2]
In-Reply-To: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
Message-ID: <faOru3LOMx0Cx0AvZvw6kwt_lQ2hcEmfYZFquQhJwWI=.425f41d6-e904-45e2-aa7f-6ca65ac8f526@github.com>

> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
> 
> This piggybacks on the existing mechanism for method handle invoker caching.
> 
> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Review comments:
  - Use boolean instead of index for var handle cache

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3439/files
  - new: https://git.openjdk.java.net/jdk/pull/3439/files/df10dbdd..93681f77

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3439&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3439&range=00-01

  Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3439/head:pull/3439

PR: https://git.openjdk.java.net/jdk/pull/3439

From jvernee at openjdk.java.net  Tue Apr 13 12:25:21 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Apr 2021 12:25:21 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching
In-Reply-To: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
Message-ID: <3JiSVW5I5-4jBIOuaPuXfRfcI3SBGdXzHhzA5Y3Gcz4=.566eec42-8349-49e0-9629-6e6d93914f3f@github.com>

On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
> 
> This piggybacks on the existing mechanism for method handle invoker caching.
> 
> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
> 
> Thanks,
> Jorn

Thanks for the reviews. Comment addressed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3439

From herrick at openjdk.java.net  Tue Apr 13 12:32:05 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Apr 2021 12:32:05 GMT
Subject: RFR: 8263157: [macos]: java.library.path is being set incorrectly
In-Reply-To: <v7NMd4LY3RreLut_ZvMF-uieaeAmeyXC4yzNRS4A0TY=.fbb2eae4-9c39-46ff-b4a4-a62d0096ed03@github.com>
References: <v7NMd4LY3RreLut_ZvMF-uieaeAmeyXC4yzNRS4A0TY=.fbb2eae4-9c39-46ff-b4a4-a62d0096ed03@github.com>
Message-ID: <vX_gD3o5_8bKSiNw8q--00ogpFUhK_4NchEix4oewrI=.53ada36f-a77a-44cf-aba7-9b88f90ee511@github.com>

On Mon, 12 Apr 2021 20:18:46 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8242302. Fixed by setting java.library.path to same values as it was before JDK-8242302.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3443

From github.com+10835776+stsypanov at openjdk.java.net  Tue Apr 13 12:55:36 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 13 Apr 2021 12:55:36 GMT
Subject: RFR: 8265075: Improve and simplify Class.resolveName()
Message-ID: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>

In mentioned method this code snippet

int len = baseName.length() + 1 + name.length();
StringBuilder sb = new StringBuilder(len);
name = sb.append(baseName.replace('.', '/'))
        .append('/')
        .append(name)
        .toString();


can be simplified with performance improvement as

name = baseName.replace('.', '/') + '/' + name;

Also null check of `baseName` can be removed as Class.getPackageName() never returns null.

This benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
public class ResolveNameBenchmark {

  private final Class<? extends ResolveNameBenchmark> klazz = getClass();

  @Benchmark
  public Object original() {
    return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
  }

  @Benchmark
  public Object patched() {
    return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
  }

  private String original(String name) {
    if (!name.startsWith("/")) {
      String baseName = getPackageName();
      if (baseName != null && !baseName.isEmpty()) {
        int len = baseName.length() + 1 + name.length();
        StringBuilder sb = new StringBuilder(len);
        name = sb.append(baseName.replace('.', '/'))
                .append('/')
                .append(name)
                .toString();
      }
    } else {
      name = name.substring(1);
    }
    return name;
  }

  private String patched(String name) {
      if (!name.startsWith("/")) {
          String baseName = getPackageName();
          if (!baseName.isEmpty()) {
              return baseName.replace('.', '/') + '/' + name;
          }
          return name;
      }
      return name.substring(1);
  }

  private String getPackageName() {
    return klazz.getPackageName();
  }
}

demonstrates good improvement, especially as of memory consumption:

                                            Mode  Cnt     Score     Error   Units

original                                    avgt   50    57.974 ?   0.365   ns/op
original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
original:?gc.count                          avgt   50   208.000            counts
original:?gc.time                           avgt   50   224.000                ms

patched                                     avgt   50    44.367 ?   0.162   ns/op
patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
patched:?gc.count                           avgt   50   167.000            counts
patched:?gc.time                            avgt   50   181.000                ms

-------------

Commit messages:
 - 8265075: Improve and simplify Class.resolveName()

Changes: https://git.openjdk.java.net/jdk/pull/3464/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3464&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265075
  Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3464.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3464/head:pull/3464

PR: https://git.openjdk.java.net/jdk/pull/3464

From hseigel at openjdk.java.net  Tue Apr 13 12:57:06 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 13 Apr 2021 12:57:06 GMT
Subject: RFR: 8265111: ProblemList
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64
In-Reply-To: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com>
References: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com>
Message-ID: <qjSRbFh2QmdPkTRv_W8IKvKvrisaTe41Z27ZC2u3klk=.5f796628-0ecc-46c0-bb29-d258f3655b56@github.com>

On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a tier1 test) until JDK-8262897 is fixed.

Looks good and trivial.
Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3452

From itakiguchi at openjdk.java.net  Tue Apr 13 12:58:00 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 13 Apr 2021 12:58:00 GMT
Subject: RFR: 8264208: Console charset API [v4]
In-Reply-To: <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>
Message-ID: <uypgTi0B0VjpQTYYDl0vml47d4h1axGvD3W6TU5M0Ls=.8cfc4081-da3c-4a5e-b671-bb483ee10327@github.com>

On Mon, 12 Apr 2021 23:01:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted PrintStream changes

I have 2 concerns:
1. I think method name "charset()" is too short. It's not called frequently. This method name should explain functionality.
2. Sometimes stderr may be redirected to stdout by shell. Why do we need to set different encodings for these two (sun.stdout.encoding and sun.stderr.encoding) ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From alanb at openjdk.java.net  Tue Apr 13 13:07:11 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 13 Apr 2021 13:07:11 GMT
Subject: RFR: 8264208: Console charset API [v4]
In-Reply-To: <uypgTi0B0VjpQTYYDl0vml47d4h1axGvD3W6TU5M0Ls=.8cfc4081-da3c-4a5e-b671-bb483ee10327@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>
 <uypgTi0B0VjpQTYYDl0vml47d4h1axGvD3W6TU5M0Ls=.8cfc4081-da3c-4a5e-b671-bb483ee10327@github.com>
Message-ID: <u9qboLV9vbNGCr-trYWN-9IgemAWegG4VrlkCtPJj2s=.7a4b5cce-4612-4877-abfc-42d0e28a857b@github.com>

On Tue, 13 Apr 2021 12:54:51 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> 1. I think method name "charset()" is too short. It's not called frequently. This method name should explain functionality.
> 2. Sometimes stderr may be redirected to stdout by shell. Why do we need to set different encodings for these two (sun.stdout.encoding and sun.stderr.encoding) ?

Console's class description already covers this "If the virtual machine is started from an interactive command line without redirecting the standard input and output streams then ...". The existing reader and writer methods use the same charset.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From alanb at openjdk.java.net  Tue Apr 13 14:40:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 13 Apr 2021 14:40:08 GMT
Subject: RFR: 8265075: Improve and simplify Class.resolveName()
In-Reply-To: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
References: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
Message-ID: <oMuAh68jwHr1vwFUFwcwZxSLwR3CmHn8PYB4GxOIoLw=.8eb928a0-6305-414a-89d4-bab5265533cb@github.com>

On Tue, 13 Apr 2021 12:47:50 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In mentioned method this code snippet
> 
> int len = baseName.length() + 1 + name.length();
> StringBuilder sb = new StringBuilder(len);
> name = sb.append(baseName.replace('.', '/'))
>         .append('/')
>         .append(name)
>         .toString();
> 
> 
> can be simplified with performance improvement as
> 
> name = baseName.replace('.', '/') + '/' + name;
> 
> Also null check of `baseName` can be removed as Class.getPackageName() never returns null.
> 
> This benchmark
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ResolveNameBenchmark {
> 
>   private final Class<? extends ResolveNameBenchmark> klazz = getClass();
> 
>   @Benchmark
>   public Object original() {
>     return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   @Benchmark
>   public Object patched() {
>     return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   private String original(String name) {
>     if (!name.startsWith("/")) {
>       String baseName = getPackageName();
>       if (baseName != null && !baseName.isEmpty()) {
>         int len = baseName.length() + 1 + name.length();
>         StringBuilder sb = new StringBuilder(len);
>         name = sb.append(baseName.replace('.', '/'))
>                 .append('/')
>                 .append(name)
>                 .toString();
>       }
>     } else {
>       name = name.substring(1);
>     }
>     return name;
>   }
> 
>   private String patched(String name) {
>       if (!name.startsWith("/")) {
>           String baseName = getPackageName();
>           if (!baseName.isEmpty()) {
>               return baseName.replace('.', '/') + '/' + name;
>           }
>           return name;
>       }
>       return name.substring(1);
>   }
> 
>   private String getPackageName() {
>     return klazz.getPackageName();
>   }
> }
> 
> demonstrates good improvement, especially as of memory consumption:
> 
>                                             Mode  Cnt     Score     Error   Units
> 
> original                                    avgt   50    57.974 ?   0.365   ns/op
> original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
> original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
> original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
> original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
> original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
> original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
> original:?gc.count                          avgt   50   208.000            counts
> original:?gc.time                           avgt   50   224.000                ms
> 
> patched                                     avgt   50    44.367 ?   0.162   ns/op
> patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
> patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
> patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
> patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
> patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
> patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
> patched:?gc.count                           avgt   50   167.000            counts
> patched:?gc.time                            avgt   50   181.000                ms

src/java.base/share/classes/java/lang/Class.java line 3067:

> 3065:      */
> 3066:     private String resolveName(String name) {
> 3067:         if (!name.startsWith("/")) {

I expect this would be more more readable if you invert it, i.e. "if (name.startsWith("/") { return name.substring(1); } else { ... }.

Note that the baseName == null check was needed when it was originally created because getPackageName could return null in the initial version.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3464

From jvernee at openjdk.java.net  Tue Apr 13 14:59:58 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Apr 2021 14:59:58 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
References: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
Message-ID: <MyoY0peEKPsYkB8LE-habtVh4QzSdu3f5gxCFw5TTYQ=.ab28222c-783b-4f41-9081-6a2c31a7e1a5@github.com>

On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. Here is a description of how it works (copied from the javadoc):
> 
>      Creates a table switch method handle, which can be used to switch over a set of target
>      method handles, based on a given target index, called selector.
> 
>      For a selector value of {@code n}, where {@code n} falls in the range {@code [0, N)},
>      and where {@code N} is the number of target method handles, the table switch method
>      handle will invoke the n-th target method handle from the list of target method handles.
> 
>      For a selector value that does not fall in the range {@code [0, N)}, the table switch
>      method handle will invoke the given fallback method handle.
> 
>      All method handles passed to this method must have the same type, with the additional
>      requirement that the leading parameter be of type {@code int}. The leading parameter
>      represents the selector.
> 
>      Any trailing parameters present in the type will appear on the returned table switch
>      method handle as well. Any arguments assigned to these parameters will be forwarded,
>      together with the selector value, to the selected method handle when invoking it.
> 
> The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case?
> 
> Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch.
> 
> The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant.
> 
> Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining.
> 
> Some numbers from the added benchmarks:
> 
> Benchmark                                        (numCases)  (offset)  (sorted)  Mode  Cnt   Score   Error  Units
> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A  avgt   30   4.186 ? 0.054  ms/op
> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A  avgt   30   4.164 ? 0.057  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A  avgt   30   4.124 ? 0.023  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A  avgt   30   4.126 ? 0.025  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A  avgt   30   4.137 ? 0.042  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A  avgt   30   4.113 ? 0.016  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A  avgt   30   4.118 ? 0.028  ms/op
> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A  avgt   30   4.127 ? 0.019  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A  avgt   30   4.116 ? 0.013  ms/op
> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A  avgt   30   4.121 ? 0.020  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A  avgt   30   4.113 ? 0.009  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A  avgt   30   4.149 ? 0.041  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A  avgt   30   4.121 ? 0.026  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A  avgt   30   4.113 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A  avgt   30   4.129 ? 0.028  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A  avgt   30   4.105 ? 0.019  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A  avgt   30   4.097 ? 0.021  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A  avgt   30   4.131 ? 0.037  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A  avgt   30   4.135 ? 0.025  ms/op
> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A  avgt   30   4.139 ? 0.145  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true  avgt   30   4.894 ? 0.028  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false  avgt   30  11.526 ? 0.194  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true  avgt   30   4.882 ? 0.025  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false  avgt   30  11.532 ? 0.034  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0      true  avgt   30   5.065 ? 0.076  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10         0     false  avgt   30  13.016 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150      true  avgt   30   5.103 ? 0.051  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                10       150     false  avgt   30  12.984 ? 0.102  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0      true  avgt   30   8.441 ? 0.165  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25         0     false  avgt   30  13.371 ? 0.060  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150      true  avgt   30   8.628 ? 0.032  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                25       150     false  avgt   30  13.542 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0      true  avgt   30   4.701 ? 0.015  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50         0     false  avgt   30  13.562 ? 0.063  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150      true  avgt   30   7.991 ? 3.111  ms/op
> MethodHandlesTableSwitchRandom.testSwitch                50       150     false  avgt   30  13.543 ? 0.088  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0      true  avgt   30   4.712 ? 0.020  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100         0     false  avgt   30  13.600 ? 0.085  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150      true  avgt   30   4.676 ? 0.011  ms/op
> MethodHandlesTableSwitchRandom.testSwitch               100       150     false  avgt   30  13.476 ? 0.043  ms/op
> 
> 
> Testing:
> - [x] Running of included benchmarks
> - [x] Inspecting inlining trace and verifying method handle targets are inlined
> - [x] Running TestTableSwitch test (currently the only user of the new code)
> - [x] Running java/lang/invoke tests (just in case)
> - [x] Some manual testing
> 
> Thanks,
> Jorn

> you have two strategy to de-sugar a switch,
> 
> * if what you do after the case do not mutate any variables, you can desugar each case to a method more or less like a lambda (it's not exactly like a lambda because there is no capture) and you have an indy in front that will call the right method handles
> 
> * you have a front end, with an indy that associate the object to an int and a backend which is tableswitch in the bytecode
> 
> ...
>
> The tests above are using the first strategy

No, they are using the second strategy. The SwitchBootstraps patch I linked to replaces the front end `lookupswitch` of a String switch with an `invokedynamic` that computes an index for the back end jump table, which is still a `tableswitch` in the bytecode.

As John also described, a hypothetical lookupSwitch combinator can be emulated by using a `k -> [0, N)` projection that feeds into the tableSwitch combinator that is proposed by this PR. The point of the examples I linked to was to show several flavors of projection functions as an example of how this could be implemented, and to show that they have competitive performance with a native `lookupswitch` instruction (the 'legacy' case). i.e. the benchmarks show the difference between `lookupswitch` implemented in bytecode, and a `k -> [0, N)` projection function built by an `invokedynamic`. (sorry, I should have offered more explanation in the first place)

The combinator added by _this_ PR is not meant to replace any part of the String switch translation. For pattern switch the `tableSwitch` combinator _could_ be used to implement the front end `k -> [0, N)` projection, but it is not strictly required. Either way, that seems orthogonal to this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3401

From jpai at openjdk.java.net  Tue Apr 13 15:03:28 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 13 Apr 2021 15:03:28 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v2]
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - copyright year and @bug id reference in existing test
 - copyright year on source

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3463/files
  - new: https://git.openjdk.java.net/jdk/pull/3463/files/812d54f2..84b11879

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3463/head:pull/3463

PR: https://git.openjdk.java.net/jdk/pull/3463

From mikael at openjdk.java.net  Tue Apr 13 15:11:57 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Tue, 13 Apr 2021 15:11:57 GMT
Subject: Integrated: 8265111: ProblemList
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64
In-Reply-To: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com>
References: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com>
Message-ID: <RVp_xOdY8xWKexQrCvnxowLkD9vcCpV7EZsgqBLEw5A=.c1e2cf8e-f83a-4e1a-bc60-d0875bfe898d@github.com>

On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a tier1 test) until JDK-8262897 is fixed.

This pull request has now been integrated.

Changeset: 2aae29c9
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2aae29c9
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64

Reviewed-by: akozlov, hseigel

-------------

PR: https://git.openjdk.java.net/jdk/pull/3452

From psandoz at openjdk.java.net  Tue Apr 13 15:26:59 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 13 Apr 2021 15:26:59 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching [v2]
In-Reply-To: <faOru3LOMx0Cx0AvZvw6kwt_lQ2hcEmfYZFquQhJwWI=.425f41d6-e904-45e2-aa7f-6ca65ac8f526@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
 <faOru3LOMx0Cx0AvZvw6kwt_lQ2hcEmfYZFquQhJwWI=.425f41d6-e904-45e2-aa7f-6ca65ac8f526@github.com>
Message-ID: <_-phSure3gT_HTsELSnIMeUZyJjaYQCBYzwqB1qk6IA=.5ce197a6-e17d-43af-9654-aeaa96c4235d@github.com>

On Tue, 13 Apr 2021 12:25:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
>> 
>> This piggybacks on the existing mechanism for method handle invoker caching.
>> 
>> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments:
>   - Use boolean instead of index for var handle cache

test/jdk/java/lang/invoke/TestVHInvokerCaching.java line 88:

> 86:         MethodHandles.Lookup lookup = lookup();
> 87: 
> 88:         for (Class<?> type : TEST_TYPES) {

A simpler approach would be to iterate over the fields of `Holder` and use `unreflectVarHandle`, then you can remove `TEST_TYPES`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3439

From peter.levart at gmail.com  Tue Apr 13 15:27:21 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 13 Apr 2021 17:27:21 +0200
Subject: RFR: 8265075: Improve and simplify Class.resolveName()
In-Reply-To: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
References: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
Message-ID: <2d99b3b8-5ccd-5d21-fbc6-fadbdd045d14@gmail.com>

Hi, Sergey!


Have you measured the code change in the java.lang.Class itself or just 
equivalent code in the JMH test as you show us?


The JMH test may show better results as it is compiled to bytecode that 
uses special invokedynamic-based string concatenation with optimal MH 
based underlying strategy. The code in java.lang.Class can't be compiled 
to use this kind of concatenation because of bootstraping issues and is 
therefore compiled to bytecode that uses StringBuilder directly (much 
like the existing code of the patched method). So I'm wondering whether 
the improvement in speed is actually there...


Regards, Peter


On 4/13/21 2:55 PM, ?????? ??????? wrote:
> In mentioned method this code snippet
>
> int len = baseName.length() + 1 + name.length();
> StringBuilder sb = new StringBuilder(len);
> name = sb.append(baseName.replace('.', '/'))
>          .append('/')
>          .append(name)
>          .toString();
>
>
> can be simplified with performance improvement as
>
> name = baseName.replace('.', '/') + '/' + name;
>
> Also null check of `baseName` can be removed as Class.getPackageName() never returns null.
>
> This benchmark
>
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ResolveNameBenchmark {
>
>    private final Class<? extends ResolveNameBenchmark> klazz = getClass();
>
>    @Benchmark
>    public Object original() {
>      return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
>    }
>
>    @Benchmark
>    public Object patched() {
>      return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
>    }
>
>    private String original(String name) {
>      if (!name.startsWith("/")) {
>        String baseName = getPackageName();
>        if (baseName != null && !baseName.isEmpty()) {
>          int len = baseName.length() + 1 + name.length();
>          StringBuilder sb = new StringBuilder(len);
>          name = sb.append(baseName.replace('.', '/'))
>                  .append('/')
>                  .append(name)
>                  .toString();
>        }
>      } else {
>        name = name.substring(1);
>      }
>      return name;
>    }
>
>    private String patched(String name) {
>        if (!name.startsWith("/")) {
>            String baseName = getPackageName();
>            if (!baseName.isEmpty()) {
>                return baseName.replace('.', '/') + '/' + name;
>            }
>            return name;
>        }
>        return name.substring(1);
>    }
>
>    private String getPackageName() {
>      return klazz.getPackageName();
>    }
> }
>
> demonstrates good improvement, especially as of memory consumption:
>
>                                              Mode  Cnt     Score     Error   Units
>
> original                                    avgt   50    57.974 ?   0.365   ns/op
> original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
> original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
> original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
> original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
> original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
> original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
> original:?gc.count                          avgt   50   208.000            counts
> original:?gc.time                           avgt   50   224.000                ms
>
> patched                                     avgt   50    44.367 ?   0.162   ns/op
> patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
> patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
> patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
> patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
> patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
> patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
> patched:?gc.count                           avgt   50   167.000            counts
> patched:?gc.time                            avgt   50   181.000                ms
>
> -------------
>
> Commit messages:
>   - 8265075: Improve and simplify Class.resolveName()
>
> Changes: https://git.openjdk.java.net/jdk/pull/3464/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3464&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8265075
>    Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/3464.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/3464/head:pull/3464
>
> PR: https://git.openjdk.java.net/jdk/pull/3464

From jlaskey at openjdk.java.net  Tue Apr 13 16:39:17 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 13 Apr 2021 16:39:17 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented
Message-ID: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>

Move makeXXXSpilterator from public (@hidden) to protected. No API ch

-------------

Commit messages:
 - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

Changes: https://git.openjdk.java.net/jdk/pull/3469/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265137
  Stats: 107 lines in 4 files changed: 0 ins; 91 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3469.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469

PR: https://git.openjdk.java.net/jdk/pull/3469

From uschindler at openjdk.java.net  Tue Apr 13 17:33:04 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 13 Apr 2021 17:33:04 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented
In-Reply-To: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
Message-ID: <qUqSkdWWZcLkAWGVf6rxpQ9-KHPHGcolgrheIY0AW6c=.733be0c4-93bf-4a71-96ee-24060ee5b442@github.com>

On Tue, 13 Apr 2021 16:33:21 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Move makeXXXSpilterator from public (@hidden) to protected. No API ch

This looks exactly like my proposed solution!

+1 Thanks!

Just my question: Is `@hidden` not needed to remove the documentation from protected method? Or is this automatically hidden by javadoc?

-------------

Marked as reviewed by uschindler (Author).

PR: https://git.openjdk.java.net/jdk/pull/3469

From kvn at openjdk.java.net  Tue Apr 13 17:55:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 13 Apr 2021 17:55:20 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
 <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
Message-ID: <TuPyGyrUBp_XcAKrstUIJjz1TGwnoFQ3V-HnXfP7laI=.bd845394-edfb-4ef3-9ed3-ac6dbdcbae3b@github.com>

On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important.
>
>> @dougxc I restored Compiler::isGraalEnabled().
> 
> Thanks. I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later).

@dougxc
Renaming should be done separately. May be use RFE I filed: https://bugs.openjdk.java.net/browse/JDK-8265032

Do you approve these Graal removal changes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3421

From naoto at openjdk.java.net  Tue Apr 13 17:58:57 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 13 Apr 2021 17:58:57 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v2]
In-Reply-To: <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
Message-ID: <vQfvLgmYok7-v_7bt-8T7BtJkZB0Fh4pJnjT7heAzCE=.beb892e4-5d16-41d3-85f6-2a7209753f9f@github.com>

On Tue, 13 Apr 2021 15:03:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year and @bug id reference in existing test
>  - copyright year on source

Have you run regression tests in java.time? If I am not mistaken, your changes simply seem to nullify the day period support.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From naoto at openjdk.java.net  Tue Apr 13 18:13:29 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 13 Apr 2021 18:13:29 GMT
Subject: RFR: 8264208: Console charset API [v5]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <AOWhBru7nRUoOZjD_Arwlnqwapvps5BAJNl7dpSd1pU=.7666f23b-253b-467f-b16b-e1aacce97cea@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflected further review comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/68db1a79..cafde56a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=03-04

  Stats: 14 lines in 1 file changed: 6 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

PR: https://git.openjdk.java.net/jdk/pull/3419

From lancea at openjdk.java.net  Tue Apr 13 18:17:19 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 13 Apr 2021 18:17:19 GMT
Subject: RFR: 8265019 : Update tests for additional TestNG test permissions
Message-ID: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>

Hi all,

Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG.

Best,
Lance

-------------

Commit messages:
 - TestNG updates

Changes: https://git.openjdk.java.net/jdk/pull/3471/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3471&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265019
  Stats: 21 lines in 2 files changed: 11 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3471.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3471/head:pull/3471

PR: https://git.openjdk.java.net/jdk/pull/3471

From redestad at openjdk.java.net  Tue Apr 13 18:18:04 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 13 Apr 2021 18:18:04 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms
Message-ID: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>

This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.

- Lazily resolve MemberNames.
- Streamline MethodType creation. This reduces the number of MethodTypes created. 

Net effect is a reduction in bytecode executed per VH class by 50-60%.

-------------

Commit messages:
 - Reduce work initializing VarForms

Changes: https://git.openjdk.java.net/jdk/pull/3472/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3472&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265135
  Stats: 77 lines in 2 files changed: 37 ins; 30 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3472/head:pull/3472

PR: https://git.openjdk.java.net/jdk/pull/3472

From naoto at openjdk.java.net  Tue Apr 13 18:28:00 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 13 Apr 2021 18:28:00 GMT
Subject: RFR: 8264208: Console charset API [v4]
In-Reply-To: <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>
 <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com>
Message-ID: <stbpJeBxVnb-KzyTXT4Pbre2f6viz2Z6DXVLo2_xbiE=.30d8a1b4-89f9-41a7-99d3-8a2095e96475@github.com>

On Tue, 13 Apr 2021 02:34:15 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverted PrintStream changes
>
> src/java.base/share/classes/java/lang/System.java line 2020:
> 
>> 2018:         setIn0(new BufferedInputStream(fdIn));
>> 2019:         setOut0(newPrintStream(fdOut, cs));
>> 2020:         setErr0(newPrintStream(fdErr, cs));
> 
> It was getting from sun.stdout.encoding or sun.stderr.encoding. After the change, when there is no console, it would be set with Charset.defaultCharset(). Would that be an incompatible change?

Although the code path is different, the logic to determine the encoding is not changed, as `sun.stdout/err.encoding` are only set if the VM is invoked from a terminal (in fact, there's a bug where they aren't set even in a terminal on unix env, which I fixed in this patch) which is the same condition in which `System.console()` returns the console. And for both cases, it will default to `Charset.defaultCharset()` if they are not available.

Having said that, one regression test started to fail with this implementation change as follows:

Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated.
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199)
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287)
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258)
	at java.base/java.text.NumberFormat.getInstance(NumberFormat.java:960)
	at java.base/java.text.NumberFormat.getNumberInstance(NumberFormat.java:518)
	at java.base/java.util.Scanner.useLocale(Scanner.java:1270)
	at java.base/java.util.Scanner.<init>(Scanner.java:543)
	at java.base/java.util.Scanner.<init>(Scanner.java:554)
	at TestConsole.main(TestConsole.java:54)
Caused by: java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188)
	... 8 more

I haven't looked at it in detail but it seems that calling `System.console()` in `System.initPhase1()` is not allowed, as the module system is not there yet. So I reverted the implementation to the original and simply retained the description in `System.out/err` with a change to `determined by` to `equivalent to`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From naoto at openjdk.java.net  Tue Apr 13 18:31:59 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 13 Apr 2021 18:31:59 GMT
Subject: RFR: 8264208: Console charset API [v4]
In-Reply-To: <u9qboLV9vbNGCr-trYWN-9IgemAWegG4VrlkCtPJj2s=.7a4b5cce-4612-4877-abfc-42d0e28a857b@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>
 <uypgTi0B0VjpQTYYDl0vml47d4h1axGvD3W6TU5M0Ls=.8cfc4081-da3c-4a5e-b671-bb483ee10327@github.com>
 <u9qboLV9vbNGCr-trYWN-9IgemAWegG4VrlkCtPJj2s=.7a4b5cce-4612-4877-abfc-42d0e28a857b@github.com>
Message-ID: <cuzZb0IcW9PVsMvi8vUjZFHHPrrSey8FWlvnFCDMJ7A=.93fd6ba6-19cb-450c-bef7-d08366f26295@github.com>

On Tue, 13 Apr 2021 13:04:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 1. I think method name "charset()" is too short. It's not called frequently. This method name should explain functionality.

As for this one, I am open for suggestions. I thought `consoel()` was concise, and analogous to `Charset.defaultCharset()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From alanb at openjdk.java.net  Tue Apr 13 18:37:59 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 13 Apr 2021 18:37:59 GMT
Subject: RFR: 8265019 : Update tests for additional TestNG test permissions
In-Reply-To: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
References: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
Message-ID: <57PI-dQFnVeVAuSOgw4BBqAr4vrxTVlWLoMjo3UdCYo=.cde0ab6d-0080-492a-9944-3b3684a15493@github.com>

On Tue, 13 Apr 2021 18:01:49 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG.
> 
> Best,
> Lance

test/jdk/java/lang/ProcessHandle/PermissionTest.java line 215:

> 213:         permissions.add(new PropertyPermission("testng.report.xml.name", "read"));
> 214:         permissions.add(new ReflectPermission("suppressAccessChecks"));
> 215:         permissions.add(new PropertyPermission("testng.timezone", "read"));

might be better to group the testng.* properties so they aren't mixed up with the other runtime permissions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3471

From lancea at openjdk.java.net  Tue Apr 13 18:56:22 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 13 Apr 2021 18:56:22 GMT
Subject: RFR: 8265019 : Update tests for additional TestNG test
 permissions [v2]
In-Reply-To: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
References: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
Message-ID: <SNAPo8-GUwi9EJMEGcJGoPTryr0KRTm9bYAkkNysuiw=.93f7f2c9-7dfa-46ec-a829-1f2a49dd0cc1@github.com>

> Hi all,
> 
> Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG.
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  TestNG updates Permission re-organization

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3471/files
  - new: https://git.openjdk.java.net/jdk/pull/3471/files/0183f88b..20ef2bd0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3471&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3471&range=00-01

  Stats: 20 lines in 2 files changed: 10 ins; 10 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3471.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3471/head:pull/3471

PR: https://git.openjdk.java.net/jdk/pull/3471

From herrick at openjdk.java.net  Tue Apr 13 19:03:12 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Apr 2021 19:03:12 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp files
Message-ID: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>

two changes:
One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).

-------------

Commit messages:
 - JDK-8265078: jpackage tests on Windows leave large temp files

Changes: https://git.openjdk.java.net/jdk/pull/3473/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3473&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265078
  Stats: 29 lines in 3 files changed: 27 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3473.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3473/head:pull/3473

PR: https://git.openjdk.java.net/jdk/pull/3473

From joehw at openjdk.java.net  Tue Apr 13 19:33:59 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 13 Apr 2021 19:33:59 GMT
Subject: RFR: 8264208: Console charset API [v4]
In-Reply-To: <stbpJeBxVnb-KzyTXT4Pbre2f6viz2Z6DXVLo2_xbiE=.30d8a1b4-89f9-41a7-99d3-8a2095e96475@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>
 <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com>
 <stbpJeBxVnb-KzyTXT4Pbre2f6viz2Z6DXVLo2_xbiE=.30d8a1b4-89f9-41a7-99d3-8a2095e96475@github.com>
Message-ID: <Xp30Ynq54nR7HSL_xeqvNWglGYGU07xRAGHGPFC-Nf0=.2173b499-bfa9-4691-864e-49c22e4ed826@github.com>

On Tue, 13 Apr 2021 18:24:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 2020:
>> 
>>> 2018:         setIn0(new BufferedInputStream(fdIn));
>>> 2019:         setOut0(newPrintStream(fdOut, cs));
>>> 2020:         setErr0(newPrintStream(fdErr, cs));
>> 
>> It was getting from sun.stdout.encoding or sun.stderr.encoding. After the change, when there is no console, it would be set with Charset.defaultCharset(). Would that be an incompatible change?
>
> Although the code path is different, the logic to determine the encoding is not changed, as `sun.stdout/err.encoding` are only set if the VM is invoked from a terminal (in fact, there's a bug where they aren't set even in a terminal on unix env, which I fixed in this patch) which is the same condition in which `System.console()` returns the console. And for both cases, it will default to `Charset.defaultCharset()` if they are not available.
> 
> Having said that, one regression test started to fail with this implementation change as follows:
> 
> Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated.
> 	at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199)
> 	at java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287)
> 	at java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258)
> 	at java.base/java.text.NumberFormat.getInstance(NumberFormat.java:960)
> 	at java.base/java.text.NumberFormat.getNumberInstance(NumberFormat.java:518)
> 	at java.base/java.util.Scanner.useLocale(Scanner.java:1270)
> 	at java.base/java.util.Scanner.<init>(Scanner.java:543)
> 	at java.base/java.util.Scanner.<init>(Scanner.java:554)
> 	at TestConsole.main(TestConsole.java:54)
> Caused by: java.lang.reflect.InvocationTargetException
> 	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> 	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> 	at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188)
> 	... 8 more
> 
> I haven't looked at it in detail but it seems that calling `System.console()` in `System.initPhase1()` is not allowed, as the module system is not there yet. So I reverted the implementation to the original and simply retained the description in `System.out/err` with a change to `determined by` to `equivalent to`.

Thanks for the explanation and updates. It's a worthwhile exercise to attempt to align things around the new method. A short note above line 2023 to record this might be useful as well (sth. like it's eq to console != null ? console.charset() : Charset.defaultCharset();). No need to create another update if you decide to add the note.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From asemenyuk at openjdk.java.net  Tue Apr 13 19:55:01 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 13 Apr 2021 19:55:01 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp files
In-Reply-To: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
Message-ID: <zxlTQua3v_o4B6T3PkAuQTMB5Ke9OEX7vwYPhYM0LPI=.6229919d-b7f6-4fde-a8fd-3ba5d8da5eda@github.com>

On Tue, 13 Apr 2021 18:57:20 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> two changes:
> One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
> The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 59:

> 57: 
> 58:     public static void deleteRecursive(Path directory) throws IOException {
> 59:         final IOException [] exception = { (IOException) null };

Do we know `Files.walkFileTree()` synchronizes calls on callback object? If not, I'd use `AtomicReference` to store the first exception.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java line 92:

> 90:     }
> 91: 
> 92:     public Executor setTmpDir(String tmp) {

As this would work only on Windows, I'd throw `IllegalStateException` if the method is called on other platform.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 646:

> 644:         } else {
> 645:             exec.setExecutable(JavaTool.JPACKAGE);
> 646:             exec.setTmpDir(System.getProperty("java.io.tmpdir"));

This would work only on Windows. I'd put corresponding `if` around this statement to avoid future confusion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3473

From naoto at openjdk.java.net  Tue Apr 13 19:59:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 13 Apr 2021 19:59:30 GMT
Subject: RFR: 8264208: Console charset API [v4]
In-Reply-To: <Xp30Ynq54nR7HSL_xeqvNWglGYGU07xRAGHGPFC-Nf0=.2173b499-bfa9-4691-864e-49c22e4ed826@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <g3MjKV4DhZraeJzywLvymIDNZTtE_4LARyn-rDBIhe0=.b1fc78fe-9922-4f3c-8927-1bf49f52262e@github.com>
 <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com>
 <stbpJeBxVnb-KzyTXT4Pbre2f6viz2Z6DXVLo2_xbiE=.30d8a1b4-89f9-41a7-99d3-8a2095e96475@github.com>
 <Xp30Ynq54nR7HSL_xeqvNWglGYGU07xRAGHGPFC-Nf0=.2173b499-bfa9-4691-864e-49c22e4ed826@github.com>
Message-ID: <ObpHAO36q7z5o-uUC_X-qloR3LoZamIPYffyDTITnE8=.9e9880c8-9b77-425b-acab-746ba15d99a7@github.com>

On Tue, 13 Apr 2021 19:30:53 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Although the code path is different, the logic to determine the encoding is not changed, as `sun.stdout/err.encoding` are only set if the VM is invoked from a terminal (in fact, there's a bug where they aren't set even in a terminal on unix env, which I fixed in this patch) which is the same condition in which `System.console()` returns the console. And for both cases, it will default to `Charset.defaultCharset()` if they are not available.
>> 
>> Having said that, one regression test started to fail with this implementation change as follows:
>> 
>> Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated.
>> 	at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199)
>> 	at java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287)
>> 	at java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258)
>> 	at java.base/java.text.NumberFormat.getInstance(NumberFormat.java:960)
>> 	at java.base/java.text.NumberFormat.getNumberInstance(NumberFormat.java:518)
>> 	at java.base/java.util.Scanner.useLocale(Scanner.java:1270)
>> 	at java.base/java.util.Scanner.<init>(Scanner.java:543)
>> 	at java.base/java.util.Scanner.<init>(Scanner.java:554)
>> 	at TestConsole.main(TestConsole.java:54)
>> Caused by: java.lang.reflect.InvocationTargetException
>> 	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> 	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
>> 	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
>> 	at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188)
>> 	... 8 more
>> 
>> I haven't looked at it in detail but it seems that calling `System.console()` in `System.initPhase1()` is not allowed, as the module system is not there yet. So I reverted the implementation to the original and simply retained the description in `System.out/err` with a change to `determined by` to `equivalent to`.
>
> Thanks for the explanation and updates. It's a worthwhile exercise to attempt to align things around the new method. A short note above line 2023 to record this might be useful as well (sth. like it's eq to console != null ? console.charset() : Charset.defaultCharset();). No need to create another update if you decide to add the note.

Thanks. Added some explanations as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From naoto at openjdk.java.net  Tue Apr 13 19:59:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 13 Apr 2021 19:59:30 GMT
Subject: RFR: 8264208: Console charset API [v6]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <Tt0qyS4hDfElNxFnuuZLpMCFymOdWdH2Jb7sSrMbbv0=.786cae20-7d7b-48ba-9d22-029c6d72c1e5@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added comment to System.out/err init.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/cafde56a..9e323145

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=04-05

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

PR: https://git.openjdk.java.net/jdk/pull/3419

From herrick at openjdk.java.net  Tue Apr 13 20:35:58 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Apr 2021 20:35:58 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp files
In-Reply-To: <zxlTQua3v_o4B6T3PkAuQTMB5Ke9OEX7vwYPhYM0LPI=.6229919d-b7f6-4fde-a8fd-3ba5d8da5eda@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
 <zxlTQua3v_o4B6T3PkAuQTMB5Ke9OEX7vwYPhYM0LPI=.6229919d-b7f6-4fde-a8fd-3ba5d8da5eda@github.com>
Message-ID: <e8AZIVFflWJiU-2wbQv2c1xr9q066J4KR_yNFBhVn0w=.21c3d0a8-292d-4231-973b-216bcb97f76a@github.com>

On Tue, 13 Apr 2021 19:48:24 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> two changes:
>> One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
>> The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 59:
> 
>> 57: 
>> 58:     public static void deleteRecursive(Path directory) throws IOException {
>> 59:         final IOException [] exception = { (IOException) null };
> 
> Do we know `Files.walkFileTree()` synchronizes calls on callback object? If not, I'd use `AtomicReference` to store the first exception.

That seems like overkill.  walkFileTree must call visitFile, preVisitDirectory, and postVisitDirectory synchronously, because their return value tells walkFileTree where to go next.

> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 646:
> 
>> 644:         } else {
>> 645:             exec.setExecutable(JavaTool.JPACKAGE);
>> 646:             exec.setTmpDir(System.getProperty("java.io.tmpdir"));
> 
> This would work only on Windows. I'd put corresponding `if` around this statement to avoid future confusion.

That makes sense, should this be here in JPackageCommand.CreateExecutor() or in Executor.setTempDir() (maybe renamed setWinTempDir ?)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3473

From herrick at openjdk.java.net  Tue Apr 13 20:35:58 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Apr 2021 20:35:58 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp files
In-Reply-To: <e8AZIVFflWJiU-2wbQv2c1xr9q066J4KR_yNFBhVn0w=.21c3d0a8-292d-4231-973b-216bcb97f76a@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
 <zxlTQua3v_o4B6T3PkAuQTMB5Ke9OEX7vwYPhYM0LPI=.6229919d-b7f6-4fde-a8fd-3ba5d8da5eda@github.com>
 <e8AZIVFflWJiU-2wbQv2c1xr9q066J4KR_yNFBhVn0w=.21c3d0a8-292d-4231-973b-216bcb97f76a@github.com>
Message-ID: <e8u3kYmBkucPpZm7NZSi3tQmygC1y6-jrcb1EDWkBcw=.43fb8af6-899f-4592-b695-77b0919deb25@github.com>

On Tue, 13 Apr 2021 20:26:56 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 59:
>> 
>>> 57: 
>>> 58:     public static void deleteRecursive(Path directory) throws IOException {
>>> 59:         final IOException [] exception = { (IOException) null };
>> 
>> Do we know `Files.walkFileTree()` synchronizes calls on callback object? If not, I'd use `AtomicReference` to store the first exception.
>
> That seems like overkill.  walkFileTree must call visitFile, preVisitDirectory, and postVisitDirectory synchronously, because their return value tells walkFileTree where to go next.

I can use AtomicReference instead of Array to hold the IOException, but must I lock around access, there is no "setIfNull()" method

-------------

PR: https://git.openjdk.java.net/jdk/pull/3473

From herrick at openjdk.java.net  Tue Apr 13 20:35:59 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Apr 2021 20:35:59 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp files
In-Reply-To: <e8u3kYmBkucPpZm7NZSi3tQmygC1y6-jrcb1EDWkBcw=.43fb8af6-899f-4592-b695-77b0919deb25@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
 <zxlTQua3v_o4B6T3PkAuQTMB5Ke9OEX7vwYPhYM0LPI=.6229919d-b7f6-4fde-a8fd-3ba5d8da5eda@github.com>
 <e8AZIVFflWJiU-2wbQv2c1xr9q066J4KR_yNFBhVn0w=.21c3d0a8-292d-4231-973b-216bcb97f76a@github.com>
 <e8u3kYmBkucPpZm7NZSi3tQmygC1y6-jrcb1EDWkBcw=.43fb8af6-899f-4592-b695-77b0919deb25@github.com>
Message-ID: <GYZfpzOLRKpneU91ROLCqGuUMqv6OkjS5Ia1WTl5fxI=.d1241ee2-121e-4480-a1bc-00d0a79bc66a@github.com>

On Tue, 13 Apr 2021 20:31:38 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> That seems like overkill.  walkFileTree must call visitFile, preVisitDirectory, and postVisitDirectory synchronously, because their return value tells walkFileTree where to go next.
>
> I can use AtomicReference instead of Array to hold the IOException, but must I lock around access, there is no "setIfNull()" method

Actually there is: compareAndSet(newValue, null)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3473

From herrick at openjdk.java.net  Tue Apr 13 21:05:26 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Apr 2021 21:05:26 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp
 files [v2]
In-Reply-To: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
Message-ID: <zBwihqww3OEBTy1nCBCgih9UoNQY89JSIbabQhUp9kM=.dd31451d-6504-49b5-887c-15f0ce7773ff@github.com>

> two changes:
> One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
> The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8265078: jpackage tests on Windows leave large temp files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3473/files
  - new: https://git.openjdk.java.net/jdk/pull/3473/files/69949578..e78442ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3473&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3473&range=00-01

  Stats: 19 lines in 3 files changed: 3 ins; 4 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3473.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3473/head:pull/3473

PR: https://git.openjdk.java.net/jdk/pull/3473

From kcr at openjdk.java.net  Tue Apr 13 21:14:00 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Apr 2021 21:14:00 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp
 files [v2]
In-Reply-To: <zBwihqww3OEBTy1nCBCgih9UoNQY89JSIbabQhUp9kM=.dd31451d-6504-49b5-887c-15f0ce7773ff@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
 <zBwihqww3OEBTy1nCBCgih9UoNQY89JSIbabQhUp9kM=.dd31451d-6504-49b5-887c-15f0ce7773ff@github.com>
Message-ID: <fLgoORpLNrQfBdHDAUD5BqD3apwDFR4P_G9gvBDB3Rw=.3263e848-5763-486d-bcc2-ea1ff996d4f1@github.com>

On Tue, 13 Apr 2021 21:05:26 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> two changes:
>> One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
>> The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8265078: jpackage tests on Windows leave large temp files

Are you sure you need an `AtomicReference` to set the exception? I don't see any use of multiple threads, but I might be missing something. If you do need it, you need to fix the order of arguments.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 96:

> 94:                     Files.delete(dir);
> 95:                 } catch (IOException ex) {
> 96:                     exception.compareAndSet(ex, null);

The arguments are backwards. The first argument is the one used for comparison, and if the current reference is equal to the first, it is set to the second value.

-------------

Changes requested by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/3473

From dnsimon at openjdk.java.net  Tue Apr 13 21:22:14 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 13 Apr 2021 21:22:14 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v3]
In-Reply-To: <tXz08rqVPR_leQJMDGrYd4-Z-CrN8vIX105a8Z-GFho=.4b53feba-294e-4a9d-8b6a-d5cdcfaa1367@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <tXz08rqVPR_leQJMDGrYd4-Z-CrN8vIX105a8Z-GFho=.4b53feba-294e-4a9d-8b6a-d5cdcfaa1367@github.com>
Message-ID: <ey1KPPydMltPmdsD1a3t_p7D77EYszQrCWoaY7tKidw=.121360c8-e175-4246-b169-78339888927d@github.com>

On Mon, 12 Apr 2021 22:10:06 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> 
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore Compiler::isGraalEnabled()

Approved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3421

From naoto at openjdk.java.net  Tue Apr 13 21:37:00 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 13 Apr 2021 21:37:00 GMT
Subject: RFR: 8265019 : Update tests for additional TestNG test
 permissions [v2]
In-Reply-To: <SNAPo8-GUwi9EJMEGcJGoPTryr0KRTm9bYAkkNysuiw=.93f7f2c9-7dfa-46ec-a829-1f2a49dd0cc1@github.com>
References: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
 <SNAPo8-GUwi9EJMEGcJGoPTryr0KRTm9bYAkkNysuiw=.93f7f2c9-7dfa-46ec-a829-1f2a49dd0cc1@github.com>
Message-ID: <AN6U9gunbsYWOPVYV620_p5SsTegADCFGR-rBSrETm4=.146f3d0a-0d3b-452f-b9cd-fbbf1d3f458e@github.com>

On Tue, 13 Apr 2021 18:56:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG.
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestNG updates Permission re-organization

Looks good.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3471

From joehw at openjdk.java.net  Tue Apr 13 21:39:05 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 13 Apr 2021 21:39:05 GMT
Subject: RFR: 8264208: Console charset API [v6]
In-Reply-To: <Tt0qyS4hDfElNxFnuuZLpMCFymOdWdH2Jb7sSrMbbv0=.786cae20-7d7b-48ba-9d22-029c6d72c1e5@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <Tt0qyS4hDfElNxFnuuZLpMCFymOdWdH2Jb7sSrMbbv0=.786cae20-7d7b-48ba-9d22-029c6d72c1e5@github.com>
Message-ID: <MqmAbwYGMlRSBtdWhiRtjEq5CJbdR53agtDxsjvSC48=.b4c2de32-ead6-40a8-8615-2ad40854eae2@github.com>

On Tue, 13 Apr 2021 19:59:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to System.out/err init.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From almatvee at openjdk.java.net  Tue Apr 13 21:39:59 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 13 Apr 2021 21:39:59 GMT
Subject: Integrated: 8263157: [macos]: java.library.path is being set
 incorrectly
In-Reply-To: <v7NMd4LY3RreLut_ZvMF-uieaeAmeyXC4yzNRS4A0TY=.fbb2eae4-9c39-46ff-b4a4-a62d0096ed03@github.com>
References: <v7NMd4LY3RreLut_ZvMF-uieaeAmeyXC4yzNRS4A0TY=.fbb2eae4-9c39-46ff-b4a4-a62d0096ed03@github.com>
Message-ID: <RdgAa-yR4zwSmM0P4Fh58AkHC489HDeBE2xNM__sMIk=.4bde6432-efda-4b43-a7a3-88cb5006e740@github.com>

On Mon, 12 Apr 2021 20:18:46 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8242302. Fixed by setting java.library.path to same values as it was before JDK-8242302.

This pull request has now been integrated.

Changeset: 55d56495
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/55d56495
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8263157: [macos]: java.library.path is being set incorrectly

Reviewed-by: asemenyuk, herrick

-------------

PR: https://git.openjdk.java.net/jdk/pull/3443

From bpb at openjdk.java.net  Tue Apr 13 21:48:58 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 13 Apr 2021 21:48:58 GMT
Subject: RFR: 8265019 : Update tests for additional TestNG test
 permissions [v2]
In-Reply-To: <SNAPo8-GUwi9EJMEGcJGoPTryr0KRTm9bYAkkNysuiw=.93f7f2c9-7dfa-46ec-a829-1f2a49dd0cc1@github.com>
References: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
 <SNAPo8-GUwi9EJMEGcJGoPTryr0KRTm9bYAkkNysuiw=.93f7f2c9-7dfa-46ec-a829-1f2a49dd0cc1@github.com>
Message-ID: <Gx9lMGLixgdLRq2rPiyAsJYBqWif82AEBX9DgBPlyT8=.c04f8667-d319-47fc-83a4-9c07bbfa4ee5@github.com>

On Tue, 13 Apr 2021 18:56:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG.
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestNG updates Permission re-organization

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3471

From forax at univ-mlv.fr  Tue Apr 13 21:50:48 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 13 Apr 2021 23:50:48 +0200 (CEST)
Subject: [External] : Re: RFR: 8263087: Add a MethodHandle combinator
 that switches over a set of MethodHandles
In-Reply-To: <45B89776-037B-43A3-92C8-4FDC0486F25F@oracle.com>
References: <1039463632.1515198.1617987284725.JavaMail.zimbra@u-pem.fr>
 <2D79F7CF-8A3E-482A-A5F3-BEBF83AD75D3@oracle.com>
 <1676065058.1536496.1617992124966.JavaMail.zimbra@u-pem.fr>
 <3C42C8CE-19B0-4DEA-906B-9065C21FC468@oracle.com>
 <45B89776-037B-43A3-92C8-4FDC0486F25F@oracle.com>
Message-ID: <231464559.1743142.1618350648877.JavaMail.zimbra@u-pem.fr>

> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jorn Vernee" <jvernee at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Samedi 10 Avril 2021 01:43:49
> Objet: Re: [External] : Re: RFR: 8263087: Add a MethodHandle combinator that
> switches over a set of MethodHandles

> On Apr 9, 2021, at 4:00 PM, John Rose < [ mailto:john.r.rose at oracle.com |
> john.r.rose at oracle.com ] > wrote:

>> The MH combinator for lookupswitch can use a data-driven
>> reverse lookup in a (frozen/stable) int[] array, using binary
>> search. The bytecode emitter can render such a thing as
>> an internal lookupswitch, if that seems desirable. But
>> the stable array with binary search scales to other types
>> besides int, so it?s the right primitive.

> This may be confusing on a couple of points.
> First, the mapping function I?m talking about is not
> a MH combinator, but rather a MH factory, which takes
> a non-MH argument, probably an unsorted array or List
> of items of any type. It then DTRT (internal hash map
> or tree map or flat binary search or flat table lookup or
> lookupswitch or any combination thereof) to get
> an algorithm to classify the array or List elements
> into a compact enumeration [0,N).

> Second, when the input array or List is of int (or
> Integer) then it *might* be a lookupswitch internally,
> and I?m abusing the terminology to call this particular
> case a lookupswitch. But it?s really just a classifier
> factory, whose output is a MH of type K ? [0,N) for
> some K. The output might also be ToIntFunction<K>
> for all I care; that can be inter-converted with a MH.

As you said, the classifier is either a lookup switch or a hashmap.get() or a perfect hash function like ordinal(). 
The last two can be already be seen as MH, that you can already compose. 
The only one we can not currently, without generating bytecode, is the lookup switch, so we should have a lookupswitch combinator. 

This does not mean we do not need the tableswitch combinator, it means we need both. 

Firthermore, if we do have both combinators, there is no need to a special mechanism, or am i missing something ? 

R?mi 

From forax at univ-mlv.fr  Tue Apr 13 21:58:59 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 13 Apr 2021 23:58:59 +0200 (CEST)
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over
 a set of MethodHandles
In-Reply-To: <MyoY0peEKPsYkB8LE-habtVh4QzSdu3f5gxCFw5TTYQ=.ab28222c-783b-4f41-9081-6a2c31a7e1a5@github.com>
References: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
 <MyoY0peEKPsYkB8LE-habtVh4QzSdu3f5gxCFw5TTYQ=.ab28222c-783b-4f41-9081-6a2c31a7e1a5@github.com>
Message-ID: <1624357242.1744310.1618351139318.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Jorn Vernee" <jvernee at openjdk.java.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 13 Avril 2021 16:59:58
> Objet: Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

> On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:
> 
>> This patch adds a `tableSwitch` combinator that can be used to switch over a set
>> of method handles given an index, with a fallback in case the index is out of
>> bounds, much like the `tableswitch` bytecode. Here is a description of how it
>> works (copied from the javadoc):
>> 
>>      Creates a table switch method handle, which can be used to switch over a set of
>>      target
>>      method handles, based on a given target index, called selector.
>> 
>>      For a selector value of {@code n}, where {@code n} falls in the range {@code [0,
>>      N)},
>>      and where {@code N} is the number of target method handles, the table switch
>>      method
>>      handle will invoke the n-th target method handle from the list of target method
>>      handles.
>> 
>>      For a selector value that does not fall in the range {@code [0, N)}, the table
>>      switch
>>      method handle will invoke the given fallback method handle.
>> 
>>      All method handles passed to this method must have the same type, with the
>>      additional
>>      requirement that the leading parameter be of type {@code int}. The leading
>>      parameter
>>      represents the selector.
>> 
>>      Any trailing parameters present in the type will appear on the returned table
>>      switch
>>      method handle as well. Any arguments assigned to these parameters will be
>>      forwarded,
>>      together with the selector value, to the selected method handle when invoking
>>      it.
>> 
>> The combinator does not support specifying the starting index, so the switch
>> cases always run from 0 to however many target handles are specified. A
>> starting index can be added manually with another combination step that filters
>> the input index by adding or subtracting a constant from it, which does not
>> affect performance. One of the reasons for not supporting a starting index is
>> that it allows for more lambda form sharing, but also simplifies the
>> implementation somewhat. I guess an open question is if a convenience overload
>> should be added for that case?
>> 
>> Lookup switch can also be simulated by filtering the input through an injection
>> function that translates it into a case index, which has also proven to have
>> the ability to have comparable performance to, or even better performance than,
>> a bytecode-native `lookupswitch` instruction. I plan to add such an injection
>> function to the runtime libraries in the future as well. Maybe at that point it
>> could be evaluated if it's worth it to add a lookup switch combinator as well,
>> but I don't see an immediate need to include it in this patch.
>> 
>> The current bytecode intrinsification generates a call for each switch case,
>> which guarantees full inlining of the target method handles. Alternatively we
>> could only have 1 callsite at the end of the switch, where each case just loads
>> the target method handle, but currently this does not allow for inlining of the
>> handles, since they are not constant.
>> 
>> Maybe a future C2 optimization could look at the receiver input for invokeBasic
>> call sites, and if the input is a phi node, clone the call for each constant
>> input of the phi. I believe that would allow simplifying the bytecode without
>> giving up on inlining.
>> 
>> Some numbers from the added benchmarks:
>> 
>> Benchmark                                        (numCases)  (offset)  (sorted)
>> Mode  Cnt   Score   Error  Units
>> MethodHandlesTableSwitchConstant.testSwitch               5         0       N/A
>> avgt   30   4.186 ? 0.054  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch               5       150       N/A
>> avgt   30   4.164 ? 0.057  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              10         0       N/A
>> avgt   30   4.124 ? 0.023  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              10       150       N/A
>> avgt   30   4.126 ? 0.025  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              25         0       N/A
>> avgt   30   4.137 ? 0.042  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              25       150       N/A
>> avgt   30   4.113 ? 0.016  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              50         0       N/A
>> avgt   30   4.118 ? 0.028  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch              50       150       N/A
>> avgt   30   4.127 ? 0.019  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch             100         0       N/A
>> avgt   30   4.116 ? 0.013  ms/op
>> MethodHandlesTableSwitchConstant.testSwitch             100       150       N/A
>> avgt   30   4.121 ? 0.020  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5         0       N/A
>> avgt   30   4.113 ? 0.009  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch           5       150       N/A
>> avgt   30   4.149 ? 0.041  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10         0       N/A
>> avgt   30   4.121 ? 0.026  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          10       150       N/A
>> avgt   30   4.113 ? 0.021  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25         0       N/A
>> avgt   30   4.129 ? 0.028  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          25       150       N/A
>> avgt   30   4.105 ? 0.019  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50         0       N/A
>> avgt   30   4.097 ? 0.021  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch          50       150       N/A
>> avgt   30   4.131 ? 0.037  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100         0       N/A
>> avgt   30   4.135 ? 0.025  ms/op
>> MethodHandlesTableSwitchOpaqueSingle.testSwitch         100       150       N/A
>> avgt   30   4.139 ? 0.145  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5         0      true
>> avgt   30   4.894 ? 0.028  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5         0     false
>> avgt   30  11.526 ? 0.194  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5       150      true
>> avgt   30   4.882 ? 0.025  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                 5       150     false
>> avgt   30  11.532 ? 0.034  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10         0      true
>> avgt   30   5.065 ? 0.076  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10         0     false
>> avgt   30  13.016 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10       150      true
>> avgt   30   5.103 ? 0.051  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                10       150     false
>> avgt   30  12.984 ? 0.102  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25         0      true
>> avgt   30   8.441 ? 0.165  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25         0     false
>> avgt   30  13.371 ? 0.060  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25       150      true
>> avgt   30   8.628 ? 0.032  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                25       150     false
>> avgt   30  13.542 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50         0      true
>> avgt   30   4.701 ? 0.015  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50         0     false
>> avgt   30  13.562 ? 0.063  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50       150      true
>> avgt   30   7.991 ? 3.111  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch                50       150     false
>> avgt   30  13.543 ? 0.088  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100         0      true
>> avgt   30   4.712 ? 0.020  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100         0     false
>> avgt   30  13.600 ? 0.085  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100       150      true
>> avgt   30   4.676 ? 0.011  ms/op
>> MethodHandlesTableSwitchRandom.testSwitch               100       150     false
>> avgt   30  13.476 ? 0.043  ms/op
>> 
>> 
>> Testing:
>> - [x] Running of included benchmarks
>> - [x] Inspecting inlining trace and verifying method handle targets are inlined
>> - [x] Running TestTableSwitch test (currently the only user of the new code)
>> - [x] Running java/lang/invoke tests (just in case)
>> - [x] Some manual testing
>> 
>> Thanks,
>> Jorn
> 
>> you have two strategy to de-sugar a switch,
>> 
>> * if what you do after the case do not mutate any variables, you can desugar
>> each case to a method more or less like a lambda (it's not exactly like a
>> lambda because there is no capture) and you have an indy in front that will
>> call the right method handles
>> 
>> * you have a front end, with an indy that associate the object to an int and a
>> backend which is tableswitch in the bytecode
>> 
>> ...
>>
>> The tests above are using the first strategy
> 
> No, they are using the second strategy. The SwitchBootstraps patch I linked to
> replaces the front end `lookupswitch` of a String switch with an
> `invokedynamic` that computes an index for the back end jump table, which is
> still a `tableswitch` in the bytecode.
> 
> As John also described, a hypothetical lookupSwitch combinator can be emulated
> by using a `k -> [0, N)` projection that feeds into the tableSwitch combinator
> that is proposed by this PR. The point of the examples I linked to was to show
> several flavors of projection functions as an example of how this could be
> implemented, and to show that they have competitive performance with a native
> `lookupswitch` instruction (the 'legacy' case). i.e. the benchmarks show the
> difference between `lookupswitch` implemented in bytecode, and a `k -> [0, N)`
> projection function built by an `invokedynamic`. (sorry, I should have offered
> more explanation in the first place)
> 
> The combinator added by _this_ PR is not meant to replace any part of the String
> switch translation. For pattern switch the `tableSwitch` combinator _could_ be
> used to implement the front end `k -> [0, N)` projection, but it is not
> strictly required. Either way, that seems orthogonal to this PR.

I agree this is orthogonal and we can continue that discussion without blocking this PR.

About your benchmark, did you test with some strings going into "default", because it is usually in that case that you need a proper lookup switch,
another way to say it is that, your results are too good when you use a cascade of guardWithTest.


> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3401

R?mi

From darcy at openjdk.java.net  Tue Apr 13 22:25:17 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 13 Apr 2021 22:25:17 GMT
Subject: RFR: 8265174: Update Class.getDeclaredMethods to discuss synethetic
 and bridge methods
Message-ID: <cPYsX6waW3UYtAa2CNRzxcR6pE_npzYaGs1hQJ6JLOM=.ede42a4f-7757-4491-9991-ed08e90654ca@github.com>

The results from Class.getDeclaredMethods can include bridge and other synthetic methods, which can be unexpected by users (JDK-6815786, JDK-8142904) and appear to be inherited methods. The javadoc for Class.getDeclaredMethods should be updated to explicitly mention the possibility of synthetic methods appearing.

-------------

Commit messages:
 - 8265174: Update Class.getDeclaredMethods to discuss synethetic and bridge methods

Changes: https://git.openjdk.java.net/jdk/pull/3477/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3477&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265174
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3477.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3477/head:pull/3477

PR: https://git.openjdk.java.net/jdk/pull/3477

From jvernee at openjdk.java.net  Tue Apr 13 22:39:57 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Apr 2021 22:39:57 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: <1624357242.1744310.1618351139318.JavaMail.zimbra@u-pem.fr>
References: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
 <1624357242.1744310.1618351139318.JavaMail.zimbra@u-pem.fr>
Message-ID: <2tuHYAse87RFRBXzMvM9bapHsHo-8ldL5_m1yCqXDcQ=.fd576eb5-b758-4f85-964f-90754c7c55eb@github.com>

On Tue, 13 Apr 2021 22:00:57 GMT, Remi Forax <forax at univ-mlv.fr> wrote:

> About your benchmark, did you test with some strings going into "default", because it is usually in that case that you need a proper lookup switch,
another way to say it is that, your results are too good when you use a cascade of guardWithTest.

Yes, for the benchmarks I ran, the default case was just as likely as the other cases, so e.g. if there were 10 cases, there was a 1/11 chance the default case was hit. This might need tweaking to be more realistic but...

Note that the cascading guard with test actually works more like a binary search, where each guard tests against a pivot point in the search, and then decides to go either to the left or the right side of the tree. So, when looking up the default value we don't necessarily need to do a search over all the cases. Only for hash collisions does it fall back to a linear search over all the values with the same hash code.

This is also how C2 translates `lookupswitch` as far as I know (but maybe John can confirm or deny whether my reading of the C2 code is correct), so I'm not surprised to see that the if-tree approach is so close to a native `lookupswitch` instruction in performance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3401

From jvernee at openjdk.java.net  Tue Apr 13 22:40:57 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Apr 2021 22:40:57 GMT
Subject: RFR: 8263087: Add a MethodHandle combinator that switches over a
 set of MethodHandles
In-Reply-To: <1624357242.1744310.1618351139318.JavaMail.zimbra@u-pem.fr>
References: <m7YxwI0QC0DHCgohe3x0eYeRKRLPxrziTGdTSWVPtYU=.62966c81-cec0-490d-9e30-0a32fd3aa707@github.com>
 <1624357242.1744310.1618351139318.JavaMail.zimbra@u-pem.fr>
Message-ID: <2tuHYAse87RFRBXzMvM9bapHsHo-8ldL5_m1yCqXDcQ=.37b2712e-2bd1-4a3b-9213-bbefdc043d00@github.com>

On Tue, 13 Apr 2021 22:00:57 GMT, Remi Forax <forax at univ-mlv.fr> wrote:

> About your benchmark, did you test with some strings going into "default", because it is usually in that case that you need a proper lookup switch,
another way to say it is that, your results are too good when you use a cascade of guardWithTest.

Yes, for the benchmarks I ran, the default case was just as likely as the other cases, so e.g. if there were 10 cases, there was a 1/11 chance the default case was hit. This might need tweaking to be more realistic but...

Note that the cascading guard with test actually works more like a binary search, where each guard tests against a pivot point in the search, and then decides to go either to the left or the right side of the tree. So, when looking up the default value we don't necessarily need to do a search over all the cases. Only for hash collisions does it fall back to a linear search over all the values with the same hash code.

This is also how C2 translates `lookupswitch` as far as I know (but maybe John can confirm or deny whether my reading of the C2 code is correct), so I'm not surprised to see that the if-tree approach is so close to a native `lookupswitch` instruction in performance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3401

From herrick at openjdk.java.net  Tue Apr 13 22:50:12 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Apr 2021 22:50:12 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp
 files [v3]
In-Reply-To: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
Message-ID: <06AIwPLNMc5dbhvkc5VWGUrbfCFH2wKFMDn-Va7YR0c=.da788bf2-375d-4093-b6b5-0ee189488c23@github.com>

> two changes:
> One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
> The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8265078: jpackage tests on Windows leave large temp files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3473/files
  - new: https://git.openjdk.java.net/jdk/pull/3473/files/e78442ba..4b9e59f6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3473&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3473&range=01-02

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3473.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3473/head:pull/3473

PR: https://git.openjdk.java.net/jdk/pull/3473

From psandoz at openjdk.java.net  Tue Apr 13 23:12:59 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 13 Apr 2021 23:12:59 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms
In-Reply-To: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
Message-ID: <BMPpJ71J_nADsOkyDOnHGLwSIhudV4FbKJz1Jd_Bg80=.637c52fc-311f-40c4-9df3-90dd5aabaf7c@github.com>

On Tue, 13 Apr 2021 18:11:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
> 
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
> 
> Net effect is a reduction in bytecode executed per VH class by 50-60%.

Very nice.

src/java.base/share/classes/java/lang/invoke/VarForm.java line 130:

> 128:         } catch (NoSuchMethodException | IllegalAccessException e) {
> 129:             throw new UnsupportedOperationException();
> 130:         }

Suggestion:

        } catch (ReflectiveOperationException e) {
                throw newInternalError("Failed resolving VarHandle member name", ex);
        }

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3472

From kcr at openjdk.java.net  Tue Apr 13 23:17:00 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Apr 2021 23:17:00 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp
 files [v3]
In-Reply-To: <06AIwPLNMc5dbhvkc5VWGUrbfCFH2wKFMDn-Va7YR0c=.da788bf2-375d-4093-b6b5-0ee189488c23@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
 <06AIwPLNMc5dbhvkc5VWGUrbfCFH2wKFMDn-Va7YR0c=.da788bf2-375d-4093-b6b5-0ee189488c23@github.com>
Message-ID: <PiZGEt3l47NzVAmho7RmvpwGW-aZPMQ5ug5CXBiTaiM=.b9739ad6-ad66-48ee-ad54-1804e8e7a6cd@github.com>

On Tue, 13 Apr 2021 22:50:12 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> two changes:
>> One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
>> The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8265078: jpackage tests on Windows leave large temp files

This looks fine. I see that this bug is listed as Windows-specific. Are any similar changes needed for other platforms, or do they already write test files only to `java.io.tmpdir`?

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/3473

From redestad at openjdk.java.net  Wed Apr 14 00:37:56 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Apr 2021 00:37:56 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms
In-Reply-To: <BMPpJ71J_nADsOkyDOnHGLwSIhudV4FbKJz1Jd_Bg80=.637c52fc-311f-40c4-9df3-90dd5aabaf7c@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
 <BMPpJ71J_nADsOkyDOnHGLwSIhudV4FbKJz1Jd_Bg80=.637c52fc-311f-40c4-9df3-90dd5aabaf7c@github.com>
Message-ID: <VXm7ZP216skAWfoMNSTij82ZQz777t9V1HvvZwTzltk=.91c1365b-3ffa-4d3f-99ab-cb8b711d9187@github.com>

On Tue, 13 Apr 2021 23:09:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
>> 
>> - Lazily resolve MemberNames.
>> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
>> 
>> Net effect is a reduction in bytecode executed per VH class by 50-60%.
>
> src/java.base/share/classes/java/lang/invoke/VarForm.java line 130:
> 
>> 128:         } catch (NoSuchMethodException | IllegalAccessException e) {
>> 129:             throw new UnsupportedOperationException();
>> 130:         }
> 
> Suggestion:
> 
>         } catch (ReflectiveOperationException e) {
>                 throw newInternalError("Failed resolving VarHandle member name", ex);
>         }

Thanks for reviewing!

Is there's a way to provoke this exception through the public API? If not then the suggested behavior change seems reasonable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3472

From psandoz at openjdk.java.net  Wed Apr 14 00:48:59 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 14 Apr 2021 00:48:59 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms
In-Reply-To: <VXm7ZP216skAWfoMNSTij82ZQz777t9V1HvvZwTzltk=.91c1365b-3ffa-4d3f-99ab-cb8b711d9187@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
 <BMPpJ71J_nADsOkyDOnHGLwSIhudV4FbKJz1Jd_Bg80=.637c52fc-311f-40c4-9df3-90dd5aabaf7c@github.com>
 <VXm7ZP216skAWfoMNSTij82ZQz777t9V1HvvZwTzltk=.91c1365b-3ffa-4d3f-99ab-cb8b711d9187@github.com>
Message-ID: <Gh_PgA0HF8MMqnHYu4dqkCgO03eRH71aRtSLptqxeGU=.1eccde6c-9e49-41eb-95d9-a2d39434a03f@github.com>

On Wed, 14 Apr 2021 00:35:38 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarForm.java line 130:
>> 
>>> 128:         } catch (NoSuchMethodException | IllegalAccessException e) {
>>> 129:             throw new UnsupportedOperationException();
>>> 130:         }
>> 
>> Suggestion:
>> 
>>         } catch (ReflectiveOperationException e) {
>>                 throw newInternalError("Failed resolving VarHandle member name", ex);
>>         }
>
> Thanks for reviewing!
> 
> Is there's a way to provoke this exception through the public API? If not then the suggested behavior change seems reasonable.

No, since VarHandles are not publicly extensible, the exception should not occur unless something has gone very wrong (the correspondence between access mode and implementing method is broken).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3472

From skypencil at gmail.com  Wed Apr 14 01:04:49 2021
From: skypencil at gmail.com (Kengo TODA)
Date: Wed, 14 Apr 2021 09:04:49 +0800
Subject: ObjectMethods seems generating wrong methods for array-type field
Message-ID: <CAO1eWSDOhGqxmAy7FenUeBp8BkRboRuq+xs-7-A8VQ215rGyXg@mail.gmail.com>

Hello there,


I'm Kengo TODA, an engineer learning about the Record feature.
Today I found a nonintentional behavior, and it seems that the bug database
has no info about it.
Let me ask here to confirm it's by-design or not. If it's a bug, I want to
try to send a patch to OpenJDK.

Here is the code reproducing the nonintentional behavior:
https://gist.github.com/KengoTODA/4d7ef6a5226d347ad9385241fee6bc63

In short, the ObjectMethods class in OpenJDK v16 generates code
that invokes the fields' method, even when the field is an array.

Please help me to understand this behavior, or
make an entry in the bug database to propose a patch.
Thanks in advance! :)

***
Kengo TODA
skypencil at gmail.com

From jpai at openjdk.java.net  Wed Apr 14 02:14:57 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 14 Apr 2021 02:14:57 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v2]
In-Reply-To: <vQfvLgmYok7-v_7bt-8T7BtJkZB0Fh4pJnjT7heAzCE=.beb892e4-5d16-41d3-85f6-2a7209753f9f@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
 <vQfvLgmYok7-v_7bt-8T7BtJkZB0Fh4pJnjT7heAzCE=.beb892e4-5d16-41d3-85f6-2a7209753f9f@github.com>
Message-ID: <EsyRp7TVqWQ6XWkLHfizqX0DjvLtv2r0AalyTb64xkY=.60f227fb-5e6e-436b-8675-f3727e3d220e@github.com>

On Tue, 13 Apr 2021 17:56:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>Have you run regression tests in java.time? If I am not mistaken, your changes simply seem to nullify the day period support.

Hello @naotoj, my tier1 test run passed without issues locally with this change:


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier1                     1750  1746     4     0 <<
   jtreg:test/jdk:tier1                               2022  2022     0     0   
   jtreg:test/langtools:tier1                         4158  4158     0     0   
   jtreg:test/jaxp:tier1                                 0     0     0     0   
   jtreg:test/lib-test:tier1                             0     0     0     0   
==============================

(the 4 hotspot failures are unrelated environmental issues).

After seeing your message, I now ran the `java/time` regression tests:


jtreg -jdk:build/macosx-x86_64-server-release/images/jdk/ test/jdk/java/time/
Test results: passed: 184

and even those passed.

I don't have much knowledge in this area of the code, but as far as I can see, this doesn't touch the changes introduced in the java.time to support the new day period construct.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From darcy at openjdk.java.net  Wed Apr 14 02:56:11 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 14 Apr 2021 02:56:11 GMT
Subject: RFR: 8265174: Update Class.getDeclaredMethods to discuss
 synthetic and bridge methods [v2]
In-Reply-To: <cPYsX6waW3UYtAa2CNRzxcR6pE_npzYaGs1hQJ6JLOM=.ede42a4f-7757-4491-9991-ed08e90654ca@github.com>
References: <cPYsX6waW3UYtAa2CNRzxcR6pE_npzYaGs1hQJ6JLOM=.ede42a4f-7757-4491-9991-ed08e90654ca@github.com>
Message-ID: <GnBDcIMrgEtAElRnZhlB3MqzPISt5oLVq8phfyaWlek=.67189aa3-a565-4c23-9d78-751380d4f173@github.com>

> The results from Class.getDeclaredMethods can include bridge and other synthetic methods, which can be unexpected by users (JDK-6815786, JDK-8142904) and appear to be inherited methods. The javadoc for Class.getDeclaredMethods should be updated to explicitly mention the possibility of synthetic methods appearing.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add links to discussion in java.lang.reflect package javadoc.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3477/files
  - new: https://git.openjdk.java.net/jdk/pull/3477/files/696daa59..dc1a5381

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3477&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3477&range=00-01

  Stats: 24 lines in 5 files changed: 22 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3477.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3477/head:pull/3477

PR: https://git.openjdk.java.net/jdk/pull/3477

From mchung at openjdk.java.net  Wed Apr 14 03:17:02 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 14 Apr 2021 03:17:02 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms
In-Reply-To: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
Message-ID: <uzhI1w2zRRuTQr9W2D2pXGpQeKBhwA2Ho3kBX7zisks=.c5abffa5-69d1-44f8-b902-148e51b52bfa@github.com>

On Tue, 13 Apr 2021 18:11:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
> 
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
> 
> Net effect is a reduction in bytecode executed per VH class by 50-60%.

Looks good to me.  I also agree with Paul's suggestion to throw InternalError for errors that should never happen.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3472

From shade at openjdk.java.net  Wed Apr 14 06:06:06 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 14 Apr 2021 06:06:06 GMT
Subject: RFR: 8264976: Minor numeric bug in
 AbstractSplittableWithBrineGenerator.makeSplitsSpliterator
In-Reply-To: <qzQKVrErONUrofcWd5FuIztqiIaA9_SYBeJRIwZxLxs=.a5232bfa-db14-486f-8940-74b2707b1265@github.com>
References: <qzQKVrErONUrofcWd5FuIztqiIaA9_SYBeJRIwZxLxs=.a5232bfa-db14-486f-8940-74b2707b1265@github.com>
Message-ID: <-yRIRh-_3g4S9PpZiIoNXweHPQzcmJRAl0txAj0h1KA=.65edc624-32d3-4799-855a-27cf5aba75e8@github.com>

On Fri, 9 Apr 2021 09:41:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports:
>   Cast one of the operands of this subtraction operation to a "long".
> 
> Here:
> 
>         Spliterator<SplittableGenerator> makeSplitsSpliterator(long index, long fence, SplittableGenerator source) {
>             ...
>             long multiplier = (1 << SALT_SHIFT) - 1; // <---- here
> 
> 
> The shift is integer, and the implicit cast to `long` happens too late. `SALT_SHIFT` is currently 4, so this is not the problem yet. But it would become a problem if `SALT_SHIFT` ever becomes 32 or larger. The shift operand should be `1L` for safety. Observe:
> 
> 
> jshell> Long.toHexString((1 << 31) - 1)
> $2 ==> "7fffffff"
> 
> jshell> Long.toHexString((1 << 32) - 1)
> $3 ==> "0"
> 
> jshell> Long.toHexString((1L << 32) - 1)
> $4 ==> "ffffffff"
> 
> 
> Additional testing: 
>  - [x] Linux x86_64 fastdebug, `jdk/utils/Random`

Anyone? :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3409

From alanb at openjdk.java.net  Wed Apr 14 06:13:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 14 Apr 2021 06:13:57 GMT
Subject: RFR: 8265019 : Update tests for additional TestNG test
 permissions [v2]
In-Reply-To: <SNAPo8-GUwi9EJMEGcJGoPTryr0KRTm9bYAkkNysuiw=.93f7f2c9-7dfa-46ec-a829-1f2a49dd0cc1@github.com>
References: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
 <SNAPo8-GUwi9EJMEGcJGoPTryr0KRTm9bYAkkNysuiw=.93f7f2c9-7dfa-46ec-a829-1f2a49dd0cc1@github.com>
Message-ID: <gJ7dc5xBWm7BWTrZ3sVZ1QHtDC-Ww1h-WWEKpz9KouA=.10273aee-f6c7-44ec-8abc-194bb7ecb7e2@github.com>

On Tue, 13 Apr 2021 18:56:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG.
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestNG updates Permission re-organization

Marked as reviewed by alanb (Reviewer).

test/jdk/java/sql/testng/util/TestPolicy.java line 27:

> 25: import java.io.FilePermission;
> 26: import java.lang.reflect.ReflectPermission;
> 27: import java.security.*;

My guess is that you didn't mean the change the import.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3471

From pliden at openjdk.java.net  Wed Apr 14 07:21:19 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 14 Apr 2021 07:21:19 GMT
Subject: RFR: 8265136: ZGC: Expose GarbageCollectorMXBeans for both pauses and
 cycles
Message-ID: <TBZlFAaIRIS0qThqPp2j6XT4lnDHIiV9hr1McWjaTd8=.3b889880-5f7f-4442-9241-708aa3538cef@github.com>

JDK-8240679 introduced a change where the information exposed via the GarbageCollectorMXBean went from being related to the GC pauses to instead be related to the GC cycles. This helped provide more accurate heap usage information. However, some users have noticed that that you no longer get timing information related to the GC pauses, only related to the GC cycle.

Shenandoah has opted for having two distinct memory managers to provide timing information about both pauses and cycles. To align how concurent GCs report this information, ZGC should probably do the same.

Testing:
 * Tier1-7 with ZGC
 * Manual testing with relevant jtreg tests

-------------

Commit messages:
 - 8265136: ZGC: Expose GarbageCollectorMXBeans for both pauses and cycles

Changes: https://git.openjdk.java.net/jdk/pull/3483/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3483&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265136
  Stats: 179 lines in 9 files changed: 107 ins; 25 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3483.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3483/head:pull/3483

PR: https://git.openjdk.java.net/jdk/pull/3483

From jfranck at openjdk.java.net  Wed Apr 14 07:29:04 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Wed, 14 Apr 2021 07:29:04 GMT
Subject: RFR: 8265174: Update Class.getDeclaredMethods to discuss
 synthetic and bridge methods [v2]
In-Reply-To: <GnBDcIMrgEtAElRnZhlB3MqzPISt5oLVq8phfyaWlek=.67189aa3-a565-4c23-9d78-751380d4f173@github.com>
References: <cPYsX6waW3UYtAa2CNRzxcR6pE_npzYaGs1hQJ6JLOM=.ede42a4f-7757-4491-9991-ed08e90654ca@github.com>
 <GnBDcIMrgEtAElRnZhlB3MqzPISt5oLVq8phfyaWlek=.67189aa3-a565-4c23-9d78-751380d4f173@github.com>
Message-ID: <xeJq9mOP3_RAcg_L-gBVSViDhxMMZkuFHfZn6TULdb0=.0f867ea8-2240-484c-9298-2404439b421d@github.com>

On Wed, 14 Apr 2021 02:56:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The results from Class.getDeclaredMethods can include bridge and other synthetic methods, which can be unexpected by users (JDK-6815786, JDK-8142904) and appear to be inherited methods. The javadoc for Class.getDeclaredMethods should be updated to explicitly mention the possibility of synthetic methods appearing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add links to discussion in java.lang.reflect package javadoc.

Marked as reviewed by jfranck (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3477

From jbachorik at openjdk.java.net  Wed Apr 14 08:31:55 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 14 Apr 2021 08:31:55 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Roll back conditional registration of container events
 - Remove container events flag
 - Remove trailing spaces
 - Doh
 - Report container type and register events conditionally
 - Remove unused test files
 - Initial test support for JFR container events
 - Update the JFR control files
 - Split off the CPU throttling metrics
 - Formatting spaces
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/faed1f5b...67a61bd7

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3126/files
  - new: https://git.openjdk.java.net/jdk/pull/3126/files/f4372e23..67a61bd7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=06-07

  Stats: 76531 lines in 2761 files changed: 49167 ins; 17238 del; 10126 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126

PR: https://git.openjdk.java.net/jdk/pull/3126

From jbachorik at openjdk.java.net  Wed Apr 14 08:31:59 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 14 Apr 2021 08:31:59 GMT
Subject: RFR: 8203359: Container level resources events [v7]
In-Reply-To: <ejPb-pIuXnItPJfNsuEqQ3u54Nu38GeN7RYf4ftrapo=.5b71e65c-399f-4933-8490-b897564aa325@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <VfQQscAw_gy6to6NS4kUlABJ_ErFH4_9denWYtB9zE0=.ff5ad719-110a-46c2-97d2-b2641b065949@github.com>
 <ejPb-pIuXnItPJfNsuEqQ3u54Nu38GeN7RYf4ftrapo=.5b71e65c-399f-4933-8490-b897564aa325@github.com>
Message-ID: <e6Z4rBbM_waVNgqs9NQYVG5EZiSAV5s8cOqtdOe6Q9g=.068fc057-98bc-4192-91a1-dcc5a6e1c1b9@github.com>

On Mon, 12 Apr 2021 18:53:07 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove trailing spaces
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 163:
> 
>> 161:     private static void initializeContainerEvents() {
>> 162:         containerMetrics = Container.metrics();
>> 163:         if (containerMetrics != null) {
> 
> I understand this will reduce startup time, but it's contrary to how we treat other events. 
> 
> We register events, even if they can't be used. We want users to see what events are available (and their metadata) and use JMC recording wizard or other means to configure a .jfc file without actually being connected to a containerized process. We want the same events to minimize (subtle) platform dependent bugs.
> 
> I think we should try to find other means to reduce the startup time. It's better to have consistent behaviour, but an initial implementation than isn't as performant, than inconsistent behavior and somewhat faster implementation.
> 
> At some point we will need to address the startup cost of registering Java events anyway. For example, we could generate metadata at build time in a binary format, similar to what we already do with native events. Could even be the same file. Then we can have hundreds of Java events without the cost of reflection and unnecessary class loading at startup. We could add a simple check so that bytecode for the container events (commit() etc) are not generated unless in a container environment. A couple of (cached) checks in JVMUpcalls may be sufficient to prevent instrumentation cost.

Right. So, for the initial drop I will just leave the container events registered unconditionally.

> src/jdk.jfr/share/conf/jfr/default.jfc line 1051:
> 
>> 1049:       <flag name="class-loading-enabled" label="Class Loading">false</flag>
>> 1050: 
>> 1051:       <flag name="container-events-enabled" label="Container Events">true</flag>
> 
> I don't think we should create "flag" for "Container Events". Instead we should treat them like CPU and other OS events, always on. Since JFR can be used outside a container, it seems wrong to have this as an option.

Ok. So what would be a good rule-of-thumb for when one should introduce a flag?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From egahlin at openjdk.java.net  Wed Apr 14 08:46:00 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 14 Apr 2021 08:46:00 GMT
Subject: RFR: 8203359: Container level resources events [v7]
In-Reply-To: <e6Z4rBbM_waVNgqs9NQYVG5EZiSAV5s8cOqtdOe6Q9g=.068fc057-98bc-4192-91a1-dcc5a6e1c1b9@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <VfQQscAw_gy6to6NS4kUlABJ_ErFH4_9denWYtB9zE0=.ff5ad719-110a-46c2-97d2-b2641b065949@github.com>
 <ejPb-pIuXnItPJfNsuEqQ3u54Nu38GeN7RYf4ftrapo=.5b71e65c-399f-4933-8490-b897564aa325@github.com>
 <e6Z4rBbM_waVNgqs9NQYVG5EZiSAV5s8cOqtdOe6Q9g=.068fc057-98bc-4192-91a1-dcc5a6e1c1b9@github.com>
Message-ID: <l-fDknZfyGTJI7SkKjlKmoTCycB6aymXW0Q7ND4ePoM=.2129c5c1-2a43-47ed-aa9e-e3cbd9d309cb@github.com>

On Wed, 14 Apr 2021 08:28:37 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 163:
>> 
>>> 161:     private static void initializeContainerEvents() {
>>> 162:         containerMetrics = Container.metrics();
>>> 163:         if (containerMetrics != null) {
>> 
>> I understand this will reduce startup time, but it's contrary to how we treat other events. 
>> 
>> We register events, even if they can't be used. We want users to see what events are available (and their metadata) and use JMC recording wizard or other means to configure a .jfc file without actually being connected to a containerized process. We want the same events to minimize (subtle) platform dependent bugs.
>> 
>> I think we should try to find other means to reduce the startup time. It's better to have consistent behaviour, but an initial implementation than isn't as performant, than inconsistent behavior and somewhat faster implementation.
>> 
>> At some point we will need to address the startup cost of registering Java events anyway. For example, we could generate metadata at build time in a binary format, similar to what we already do with native events. Could even be the same file. Then we can have hundreds of Java events without the cost of reflection and unnecessary class loading at startup. We could add a simple check so that bytecode for the container events (commit() etc) are not generated unless in a container environment. A couple of (cached) checks in JVMUpcalls may be sufficient to prevent instrumentation cost.
>
> Right. So, for the initial drop I will just leave the container events registered unconditionally.

I think that is fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From raffaello.giulietti at gmail.com  Wed Apr 14 09:38:40 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 14 Apr 2021 11:38:40 +0200
Subject: ObjectMethods seems generating wrong methods for array-type field
Message-ID: <4746a697-fd0a-968a-2e2b-a6c6ec2287a8@gmail.com>

Hi Kengo,

I don't think this is a bug, as records are designed to "act as 
transparent carriers for immutable data". A record having an array-typed 
component is far from being immutable because everyone can change the 
array contents. So you probably shouldn't opt for records for such use 
cases, since you would loose the semantic benefits of records.

But if you need deeper hashing and comparison over array-typed 
components of records, as you are probably expecting in your example, 
you have to override the record hashCode() and equals() yourself. But 
then (http://openjdk.java.net/jeps/395):
"Any explicit implementation of accessors or the equals or hashCode 
methods should be careful to preserve the semantic invariants of the 
record class."


Greetings
Raffaello



> Hello there,
> 
> 
> I'm Kengo TODA, an engineer learning about the Record feature.
> Today I found a nonintentional behavior, and it seems that the bug database
> has no info about it.
> Let me ask here to confirm it's by-design or not. If it's a bug, I want to
> try to send a patch to OpenJDK.
> 
> Here is the code reproducing the nonintentional behavior:
> https://gist.github.com/KengoTODA/4d7ef6a5226d347ad9385241fee6bc63
> 
> In short, the ObjectMethods class in OpenJDK v16 generates code
> that invokes the fields' method, even when the field is an array.
> 
> Please help me to understand this behavior, or
> make an entry in the bug database to propose a patch.
> Thanks in advance! :)
> 
> ***
> Kengo TODA
> skypencil at gmail.com


From skypencil at gmail.com  Wed Apr 14 09:03:14 2021
From: skypencil at gmail.com (Kengo TODA)
Date: Wed, 14 Apr 2021 17:03:14 +0800
Subject: ObjectMethods seems generating wrong methods for array-type field
In-Reply-To: <CAO1eWSDOhGqxmAy7FenUeBp8BkRboRuq+xs-7-A8VQ215rGyXg@mail.gmail.com>
References: <CAO1eWSDOhGqxmAy7FenUeBp8BkRboRuq+xs-7-A8VQ215rGyXg@mail.gmail.com>
Message-ID: <CAO1eWSCEnoLPSTSq4Mg21EjELkhsnjg7hjR027+n3LfK-fHeMw@mail.gmail.com>

I found that the JLS 16 does not cover the array type record component:
https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10.3

So it could be not a core-lib issue but a JLS issue.

Do I need to forward this thread to another mailing list?
If so, please let me know which is the preferred one.
I've checked https://mail.openjdk.java.net/mailman/listinfo but not so sure.


Thank you very much.

***
Kengo TODA
skypencil at gmail.com


On Wed, Apr 14, 2021 at 9:04 AM Kengo TODA <skypencil at gmail.com> wrote:

> Hello there,
>
>
> I'm Kengo TODA, an engineer learning about the Record feature.
> Today I found a nonintentional behavior, and it seems that the bug
> database has no info about it.
> Let me ask here to confirm it's by-design or not. If it's a bug, I want to
> try to send a patch to OpenJDK.
>
> Here is the code reproducing the nonintentional behavior:
> https://gist.github.com/KengoTODA/4d7ef6a5226d347ad9385241fee6bc63
>
> In short, the ObjectMethods class in OpenJDK v16 generates code
> that invokes the fields' method, even when the field is an array.
>
> Please help me to understand this behavior, or
> make an entry in the bug database to propose a patch.
> Thanks in advance! :)
>
> ***
> Kengo TODA
> skypencil at gmail.com
>

From forax at univ-mlv.fr  Wed Apr 14 10:12:06 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 14 Apr 2021 12:12:06 +0200 (CEST)
Subject: ObjectMethods seems generating wrong methods for array-type field
In-Reply-To: <CAO1eWSCEnoLPSTSq4Mg21EjELkhsnjg7hjR027+n3LfK-fHeMw@mail.gmail.com>
References: <CAO1eWSDOhGqxmAy7FenUeBp8BkRboRuq+xs-7-A8VQ215rGyXg@mail.gmail.com>
 <CAO1eWSCEnoLPSTSq4Mg21EjELkhsnjg7hjR027+n3LfK-fHeMw@mail.gmail.com>
Message-ID: <1638432481.2244346.1618395126510.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Kengo TODA" <skypencil at gmail.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 14 Avril 2021 11:03:14
> Objet: Re: ObjectMethods seems generating wrong methods for array-type field

Hello,

> I found that the JLS 16 does not cover the array type record component:
> https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10.3
> 
> So it could be not a core-lib issue but a JLS issue.

Nope, the implementation of a record is covered in the javadoc of java.lang.Record
for equals, see https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Record.html#equals(java.lang.Object)

As you can see the spec clearly says that for any fields which is an object (arrays are objects), it should be semantically equivalent to calling java.util.Objects.equals() on those fields.

So it's not a bug, it's how record.equals() works, as Raffaello said, records are dumb containers, this is how we have specified them.

Records have been specified as part of the project Amber, you can take a look to the mailing list [1] for more if you want.

> 
> Do I need to forward this thread to another mailing list?
> If so, please let me know which is the preferred one.
> I've checked https://mail.openjdk.java.net/mailman/listinfo but not so sure.
> 
> 
> Thank you very much.

regards,
R?mi

[1] https://mail.openjdk.java.net/mailman/listinfo/amber-spec-experts

> 
> ***
> Kengo TODA
> skypencil at gmail.com
> 
> 
> On Wed, Apr 14, 2021 at 9:04 AM Kengo TODA <skypencil at gmail.com> wrote:
> 
>> Hello there,
>>
>>
>> I'm Kengo TODA, an engineer learning about the Record feature.
>> Today I found a nonintentional behavior, and it seems that the bug
>> database has no info about it.
>> Let me ask here to confirm it's by-design or not. If it's a bug, I want to
>> try to send a patch to OpenJDK.
>>
>> Here is the code reproducing the nonintentional behavior:
>> https://gist.github.com/KengoTODA/4d7ef6a5226d347ad9385241fee6bc63
>>
>> In short, the ObjectMethods class in OpenJDK v16 generates code
>> that invokes the fields' method, even when the field is an array.
>>
>> Please help me to understand this behavior, or
>> make an entry in the bug database to propose a patch.
>> Thanks in advance! :)
>>
>> ***
>> Kengo TODA
>> skypencil at gmail.com

From redestad at openjdk.java.net  Wed Apr 14 10:22:12 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Apr 2021 10:22:12 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms [v2]
In-Reply-To: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
Message-ID: <ExLiecR_ocrOgX06spp5ncLpX1MvaajPc0I_ioUlHnU=.c1df564c-8a34-49c4-b73b-4e54c5d0c4b2@github.com>

> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
> 
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
> 
> Net effect is a reduction in bytecode executed per VH class by 50-60%.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Change from UOE to InternalError

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3472/files
  - new: https://git.openjdk.java.net/jdk/pull/3472/files/f2067686..708c0e28

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3472&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3472&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3472/head:pull/3472

PR: https://git.openjdk.java.net/jdk/pull/3472

From lance.andersen at oracle.com  Wed Apr 14 10:24:50 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 14 Apr 2021 10:24:50 +0000
Subject: RFR: 8265019 : Update tests for additional TestNG test
 permissions [v2]
In-Reply-To: <gJ7dc5xBWm7BWTrZ3sVZ1QHtDC-Ww1h-WWEKpz9KouA=.10273aee-f6c7-44ec-8abc-194bb7ecb7e2@github.com>
References: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
 <SNAPo8-GUwi9EJMEGcJGoPTryr0KRTm9bYAkkNysuiw=.93f7f2c9-7dfa-46ec-a829-1f2a49dd0cc1@github.com>
 <gJ7dc5xBWm7BWTrZ3sVZ1QHtDC-Ww1h-WWEKpz9KouA=.10273aee-f6c7-44ec-8abc-194bb7ecb7e2@github.com>
Message-ID: <7F0A5B55-D68E-463B-9F12-878099C51583@oracle.com>



On Apr 14, 2021, at 2:13 AM, Alan Bateman <alanb at openjdk.java.net<mailto:alanb at openjdk.java.net>> wrote:

On Tue, 13 Apr 2021 18:56:22 GMT, Lance Andersen <lancea at openjdk.org<mailto:lancea at openjdk.org>> wrote:

Hi all,

Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG.

Best,
Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

 TestNG updates Permission re-organization

Marked as reviewed by alanb (Reviewer).

test/jdk/java/sql/testng/util/TestPolicy.java line 27:

25: import java.io.FilePermission;
26: import java.lang.reflect.ReflectPermission;
27: import java.security.*;

My guess is that you didn't mean the change the import.

Intellij did that automagically.  I just reverted the change for consistency

-------------

PR: https://git.openjdk.java.net/jdk/pull/3471

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From lancea at openjdk.java.net  Wed Apr 14 10:29:25 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 14 Apr 2021 10:29:25 GMT
Subject: RFR: 8265019 : Update tests for additional TestNG test
 permissions [v3]
In-Reply-To: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
References: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
Message-ID: <2Nl-25kOgdTL5fpDd-Mn8Y5USLCzT9BAITtNeMXIMbI=.4ecfc9b6-e050-4fbf-8577-601c1fe9bf6b@github.com>

> Hi all,
> 
> Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG.
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Add back individual security imports

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3471/files
  - new: https://git.openjdk.java.net/jdk/pull/3471/files/20ef2bd0..31edda8e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3471&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3471&range=01-02

  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3471.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3471/head:pull/3471

PR: https://git.openjdk.java.net/jdk/pull/3471

From egahlin at openjdk.java.net  Wed Apr 14 11:24:12 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 14 Apr 2021 11:24:12 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
Message-ID: <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>

On Wed, 14 Apr 2021 08:31:55 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
>> 
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
>> * CPU related metrics
>> * Memory related metrics
>> * I/O related metrics
>> 
>> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
>> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).
>
> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Roll back conditional registration of container events
>  - Remove container events flag
>  - Remove trailing spaces
>  - Doh
>  - Report container type and register events conditionally
>  - Remove unused test files
>  - Initial test support for JFR container events
>  - Update the JFR control files
>  - Split off the CPU throttling metrics
>  - Formatting spaces
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/1f93be70...67a61bd7

src/jdk.jfr/share/classes/jdk/jfr/events/ContainerCPUThrottlingEvent.java line 44:

> 42: @Category({"Operating System", "Container", "Processor"})
> 43: @Description("Container CPU throttling related information.")
> 44: public class ContainerCPUThrottlingEvent extends AbstractJDKEvent {

I wonder if we should put all the container events in the same category {"Operating System", "Container"}, Or possibly add them under the already existing categories under "Operating System"?

src/jdk.jfr/share/classes/jdk/jfr/events/ContainerCPUThrottlingEvent.java line 46:

> 44: public class ContainerCPUThrottlingEvent extends AbstractJDKEvent {
> 45:   @Label("CPU Elapsed Slices")
> 46:   @Description("Number of time-slice periods that have elapsed if a CPU quota has been setup for the container.")

If the description is one sentence, period should not be included.

src/jdk.jfr/share/classes/jdk/jfr/events/ContainerCPUUsageEvent.java line 46:

> 44: public class ContainerCPUUsageEvent extends AbstractJDKEvent {
> 45:   @Label("CPU Time")
> 46:   @Description("Aggregate time, in nanoseconds, consumed by all tasks in the container.")

We usually skip the unit "nanoseconds" in descriptions when the field has a content type that describes the unit.

src/jdk.jfr/share/classes/jdk/jfr/events/ContainerConfigurationEvent.java line 45:

> 43: @Description("A set of container specific attributes.")
> 44: public final class ContainerConfigurationEvent extends AbstractJDKEvent {
> 45:     @Label("Container type")

Capitalize "type" in the label

src/jdk.jfr/share/classes/jdk/jfr/events/ContainerConfigurationEvent.java line 78:

> 76: 
> 77:     @Label("Memory and Swap Limit")
> 78:     @Description("Maximum amount of physical memory and swap space, in bytes, that can be allocated in the container.")

No need to mention bytes in the description when the field has DataAmount annotation.

src/jdk.jfr/share/classes/jdk/jfr/events/ContainerIOUsageEvent.java line 47:

> 45: public class ContainerIOUsageEvent extends AbstractJDKEvent {
> 46: 
> 47:   @Label("BlkIO Request Count")

Change to "Block IO"

src/jdk.jfr/share/classes/jdk/jfr/events/ContainerMemoryUsageEvent.java line 46:

> 44: public final class ContainerMemoryUsageEvent extends AbstractJDKEvent {
> 45:     @Label("Memory Pressure")
> 46:     @Description("(attempts per second * 1000), if enabled, that the operating system tries to satisfy a memory request for any " +

This unit seems a bit strange. Do we really need to multiply by 1000?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From redestad at openjdk.java.net  Wed Apr 14 11:35:14 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Apr 2021 11:35:14 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms [v3]
In-Reply-To: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
Message-ID: <qwlNA0PFBnJYXXSiIk72ypsiW2XaWJB3I-Kq4ULR7Vw=.cf37d821-4ac0-4901-8f01-45e907c58c2f@github.com>

> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
> 
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
> 
> Net effect is a reduction in bytecode executed per VH class by 50-60%.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Revert UOE change, ensure VarHandle.isAccessModeSupported behaves well

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3472/files
  - new: https://git.openjdk.java.net/jdk/pull/3472/files/708c0e28..dc56c25b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3472&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3472&range=01-02

  Stats: 25 lines in 2 files changed: 13 ins; 6 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3472/head:pull/3472

PR: https://git.openjdk.java.net/jdk/pull/3472

From redestad at openjdk.java.net  Wed Apr 14 11:35:14 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Apr 2021 11:35:14 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms [v3]
In-Reply-To: <Gh_PgA0HF8MMqnHYu4dqkCgO03eRH71aRtSLptqxeGU=.1eccde6c-9e49-41eb-95d9-a2d39434a03f@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
 <BMPpJ71J_nADsOkyDOnHGLwSIhudV4FbKJz1Jd_Bg80=.637c52fc-311f-40c4-9df3-90dd5aabaf7c@github.com>
 <VXm7ZP216skAWfoMNSTij82ZQz777t9V1HvvZwTzltk=.91c1365b-3ffa-4d3f-99ab-cb8b711d9187@github.com>
 <Gh_PgA0HF8MMqnHYu4dqkCgO03eRH71aRtSLptqxeGU=.1eccde6c-9e49-41eb-95d9-a2d39434a03f@github.com>
Message-ID: <wO0daqoywG84bJXWKzVmVYzphDIAS8j7a9adRh6lqL4=.f3c82edf-1e06-4517-abf3-ca14f52f4490@github.com>

On Wed, 14 Apr 2021 00:46:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Thanks for reviewing!
>> 
>> Is there's a way to provoke this exception through the public API? If not then the suggested behavior change seems reasonable.
>
> No, since VarHandles are not publicly extensible, the exception should not occur unless something has gone very wrong (the correspondence between access mode and implementing method is broken).

Unfortunately the change to InternalError breaks a number of tests, since the UOE does bubble up through the public API. I also found a few failing tests I had overlooked due VarHandle.isAccessModeSupported throwing rather than returning false, so I had to slightly rework the patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3472

From github.com+10835776+stsypanov at openjdk.java.net  Wed Apr 14 11:36:01 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Apr 2021 11:36:01 GMT
Subject: RFR: 8265075: Improve and simplify Class.resolveName()
In-Reply-To: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
References: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
Message-ID: <alNk2Whw0JLo5puKUlbx3JtPEa2XCZ2aoEZ3IxoQMNc=.e386a3c5-b38e-432d-a91a-6218394e85de@github.com>

On Tue, 13 Apr 2021 12:47:50 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In mentioned method this code snippet
> 
> int len = baseName.length() + 1 + name.length();
> StringBuilder sb = new StringBuilder(len);
> name = sb.append(baseName.replace('.', '/'))
>         .append('/')
>         .append(name)
>         .toString();
> 
> 
> can be simplified with performance improvement as
> 
> name = baseName.replace('.', '/') + '/' + name;
> 
> Also null check of `baseName` can be removed as Class.getPackageName() never returns null.
> 
> This benchmark
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ResolveNameBenchmark {
> 
>   private final Class<? extends ResolveNameBenchmark> klazz = getClass();
> 
>   @Benchmark
>   public Object original() {
>     return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   @Benchmark
>   public Object patched() {
>     return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   private String original(String name) {
>     if (!name.startsWith("/")) {
>       String baseName = getPackageName();
>       if (baseName != null && !baseName.isEmpty()) {
>         int len = baseName.length() + 1 + name.length();
>         StringBuilder sb = new StringBuilder(len);
>         name = sb.append(baseName.replace('.', '/'))
>                 .append('/')
>                 .append(name)
>                 .toString();
>       }
>     } else {
>       name = name.substring(1);
>     }
>     return name;
>   }
> 
>   private String patched(String name) {
>       if (!name.startsWith("/")) {
>           String baseName = getPackageName();
>           if (!baseName.isEmpty()) {
>               return baseName.replace('.', '/') + '/' + name;
>           }
>           return name;
>       }
>       return name.substring(1);
>   }
> 
>   private String getPackageName() {
>     return klazz.getPackageName();
>   }
> }
> 
> demonstrates good improvement, especially as of memory consumption:
> 
>                                             Mode  Cnt     Score     Error   Units
> 
> original                                    avgt   50    57.974 ?   0.365   ns/op
> original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
> original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
> original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
> original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
> original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
> original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
> original:?gc.count                          avgt   50   208.000            counts
> original:?gc.time                           avgt   50   224.000                ms
> 
> patched                                     avgt   50    44.367 ?   0.162   ns/op
> patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
> patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
> patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
> patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
> patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
> patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
> patched:?gc.count                           avgt   50   167.000            counts
> patched:?gc.time                            avgt   50   181.000                ms

@plevart you are right, when the method is called from `java.lang.Class` there's no improvement observed. I'll close the PR then along with the ticket

-------------

PR: https://git.openjdk.java.net/jdk/pull/3464

From jvernee at openjdk.java.net  Wed Apr 14 11:38:15 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 14 Apr 2021 11:38:15 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching [v3]
In-Reply-To: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
Message-ID: <8YiE6q8ttulbS9HkRmp6YyGgm4yCssfVcMgUASKaIME=.06050e95-3fe0-4456-a4fd-74435be1ac60@github.com>

> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
> 
> This piggybacks on the existing mechanism for method handle invoker caching.
> 
> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Review comment: simplify test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3439/files
  - new: https://git.openjdk.java.net/jdk/pull/3439/files/93681f77..fa5a721f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3439&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3439&range=01-02

  Stats: 19 lines in 1 file changed: 4 ins; 12 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3439/head:pull/3439

PR: https://git.openjdk.java.net/jdk/pull/3439

From jvernee at openjdk.java.net  Wed Apr 14 11:38:16 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 14 Apr 2021 11:38:16 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching [v2]
In-Reply-To: <_-phSure3gT_HTsELSnIMeUZyJjaYQCBYzwqB1qk6IA=.5ce197a6-e17d-43af-9654-aeaa96c4235d@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
 <faOru3LOMx0Cx0AvZvw6kwt_lQ2hcEmfYZFquQhJwWI=.425f41d6-e904-45e2-aa7f-6ca65ac8f526@github.com>
 <_-phSure3gT_HTsELSnIMeUZyJjaYQCBYzwqB1qk6IA=.5ce197a6-e17d-43af-9654-aeaa96c4235d@github.com>
Message-ID: <afyUP6alwTXYsdoXVeHssJur1ameB5T-HLxkCL393Gs=.e4f4fd37-f4de-4c79-a719-ac11cbec6b29@github.com>

On Tue, 13 Apr 2021 15:24:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments:
>>   - Use boolean instead of index for var handle cache
>
> test/jdk/java/lang/invoke/TestVHInvokerCaching.java line 88:
> 
>> 86:         MethodHandles.Lookup lookup = lookup();
>> 87: 
>> 88:         for (Class<?> type : TEST_TYPES) {
> 
> A simpler approach would be to iterate over the fields of `Holder` and use `unreflectVarHandle`, then you can remove `TEST_TYPES`.

Yeah, that's a good idea. Fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3439

From alanb at openjdk.java.net  Wed Apr 14 11:44:04 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 14 Apr 2021 11:44:04 GMT
Subject: RFR: 8265075: Improve and simplify Class.resolveName()
In-Reply-To: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
References: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
Message-ID: <3dfK67g55Hy6Eqfq0_yPTDVwfR1-jHjvHw9JDf5IcVk=.2c8fd323-fc05-4ad5-bd04-b52f6dc1a2be@github.com>

On Tue, 13 Apr 2021 12:47:50 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In mentioned method this code snippet
> 
> int len = baseName.length() + 1 + name.length();
> StringBuilder sb = new StringBuilder(len);
> name = sb.append(baseName.replace('.', '/'))
>         .append('/')
>         .append(name)
>         .toString();
> 
> 
> can be simplified with performance improvement as
> 
> name = baseName.replace('.', '/') + '/' + name;
> 
> Also null check of `baseName` can be removed as Class.getPackageName() never returns null.
> 
> This benchmark
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ResolveNameBenchmark {
> 
>   private final Class<? extends ResolveNameBenchmark> klazz = getClass();
> 
>   @Benchmark
>   public Object original() {
>     return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   @Benchmark
>   public Object patched() {
>     return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   private String original(String name) {
>     if (!name.startsWith("/")) {
>       String baseName = getPackageName();
>       if (baseName != null && !baseName.isEmpty()) {
>         int len = baseName.length() + 1 + name.length();
>         StringBuilder sb = new StringBuilder(len);
>         name = sb.append(baseName.replace('.', '/'))
>                 .append('/')
>                 .append(name)
>                 .toString();
>       }
>     } else {
>       name = name.substring(1);
>     }
>     return name;
>   }
> 
>   private String patched(String name) {
>       if (!name.startsWith("/")) {
>           String baseName = getPackageName();
>           if (!baseName.isEmpty()) {
>               return baseName.replace('.', '/') + '/' + name;
>           }
>           return name;
>       }
>       return name.substring(1);
>   }
> 
>   private String getPackageName() {
>     return klazz.getPackageName();
>   }
> }
> 
> demonstrates good improvement, especially as of memory consumption:
> 
>                                             Mode  Cnt     Score     Error   Units
> 
> original                                    avgt   50    57.974 ?   0.365   ns/op
> original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
> original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
> original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
> original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
> original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
> original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
> original:?gc.count                          avgt   50   208.000            counts
> original:?gc.time                           avgt   50   224.000                ms
> 
> patched                                     avgt   50    44.367 ?   0.162   ns/op
> patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
> patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
> patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
> patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
> patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
> patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
> patched:?gc.count                           avgt   50   167.000            counts
> patched:?gc.time                            avgt   50   181.000                ms

We can remove the check for baseName being null, that's a left over from iteration during JDK 9.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3464

From github.com+10835776+stsypanov at openjdk.java.net  Wed Apr 14 11:46:58 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Apr 2021 11:46:58 GMT
Subject: RFR: 8265075: Improve and simplify Class.resolveName()
In-Reply-To: <oMuAh68jwHr1vwFUFwcwZxSLwR3CmHn8PYB4GxOIoLw=.8eb928a0-6305-414a-89d4-bab5265533cb@github.com>
References: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
 <oMuAh68jwHr1vwFUFwcwZxSLwR3CmHn8PYB4GxOIoLw=.8eb928a0-6305-414a-89d4-bab5265533cb@github.com>
Message-ID: <ZlZOJD7ibs0aBt9sfnRhiKYJBDr-5ka-HSqKz6Mz9rc=.c21372fe-7f4a-4421-89b0-31be11955743@github.com>

On Tue, 13 Apr 2021 14:36:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In mentioned method this code snippet
>> 
>> int len = baseName.length() + 1 + name.length();
>> StringBuilder sb = new StringBuilder(len);
>> name = sb.append(baseName.replace('.', '/'))
>>         .append('/')
>>         .append(name)
>>         .toString();
>> 
>> 
>> can be simplified with performance improvement as
>> 
>> name = baseName.replace('.', '/') + '/' + name;
>> 
>> Also null check of `baseName` can be removed as Class.getPackageName() never returns null.
>> 
>> This benchmark
>> 
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class ResolveNameBenchmark {
>> 
>>   private final Class<? extends ResolveNameBenchmark> klazz = getClass();
>> 
>>   @Benchmark
>>   public Object original() {
>>     return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
>>   }
>> 
>>   @Benchmark
>>   public Object patched() {
>>     return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
>>   }
>> 
>>   private String original(String name) {
>>     if (!name.startsWith("/")) {
>>       String baseName = getPackageName();
>>       if (baseName != null && !baseName.isEmpty()) {
>>         int len = baseName.length() + 1 + name.length();
>>         StringBuilder sb = new StringBuilder(len);
>>         name = sb.append(baseName.replace('.', '/'))
>>                 .append('/')
>>                 .append(name)
>>                 .toString();
>>       }
>>     } else {
>>       name = name.substring(1);
>>     }
>>     return name;
>>   }
>> 
>>   private String patched(String name) {
>>       if (!name.startsWith("/")) {
>>           String baseName = getPackageName();
>>           if (!baseName.isEmpty()) {
>>               return baseName.replace('.', '/') + '/' + name;
>>           }
>>           return name;
>>       }
>>       return name.substring(1);
>>   }
>> 
>>   private String getPackageName() {
>>     return klazz.getPackageName();
>>   }
>> }
>> 
>> demonstrates good improvement, especially as of memory consumption:
>> 
>>                                             Mode  Cnt     Score     Error   Units
>> 
>> original                                    avgt   50    57.974 ?   0.365   ns/op
>> original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
>> original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
>> original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
>> original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
>> original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
>> original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
>> original:?gc.count                          avgt   50   208.000            counts
>> original:?gc.time                           avgt   50   224.000                ms
>> 
>> patched                                     avgt   50    44.367 ?   0.162   ns/op
>> patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
>> patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
>> patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
>> patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
>> patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
>> patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
>> patched:?gc.count                           avgt   50   167.000            counts
>> patched:?gc.time                            avgt   50   181.000                ms
>
> src/java.base/share/classes/java/lang/Class.java line 3067:
> 
>> 3065:      */
>> 3066:     private String resolveName(String name) {
>> 3067:         if (!name.startsWith("/")) {
> 
> I expect this would be more more readable if you invert it, i.e. "if (name.startsWith("/") { return name.substring(1); } else { ... }.
> 
> Note that the baseName == null check was needed when it was originally created because getPackageName could return null in the initial version.

@AlanBateman As Peter commented below there's likely to be no improvement when the code is called from `j.l.Class` itself, and indeed there's no any. 

However, there's still unnecessary null check here and in other places, so is it reasonable to reword the ticker and this PR to rid that check, or create another ticket, or it's not worth the effort? What do you thinl?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3464

From github.com+10835776+stsypanov at openjdk.java.net  Wed Apr 14 11:49:58 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Apr 2021 11:49:58 GMT
Subject: RFR: 8265075: Improve and simplify Class.resolveName()
In-Reply-To: <3dfK67g55Hy6Eqfq0_yPTDVwfR1-jHjvHw9JDf5IcVk=.2c8fd323-fc05-4ad5-bd04-b52f6dc1a2be@github.com>
References: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
 <3dfK67g55Hy6Eqfq0_yPTDVwfR1-jHjvHw9JDf5IcVk=.2c8fd323-fc05-4ad5-bd04-b52f6dc1a2be@github.com>
Message-ID: <34F9lfpukVDwTC_CNLB7iW404cn-4AoSRbP1dSgU4so=.42497995-459b-4a8b-a5fc-ff750a2b086e@github.com>

On Wed, 14 Apr 2021 11:41:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In mentioned method this code snippet
>> 
>> int len = baseName.length() + 1 + name.length();
>> StringBuilder sb = new StringBuilder(len);
>> name = sb.append(baseName.replace('.', '/'))
>>         .append('/')
>>         .append(name)
>>         .toString();
>> 
>> 
>> can be simplified with performance improvement as
>> 
>> name = baseName.replace('.', '/') + '/' + name;
>> 
>> Also null check of `baseName` can be removed as Class.getPackageName() never returns null.
>> 
>> This benchmark
>> 
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class ResolveNameBenchmark {
>> 
>>   private final Class<? extends ResolveNameBenchmark> klazz = getClass();
>> 
>>   @Benchmark
>>   public Object original() {
>>     return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
>>   }
>> 
>>   @Benchmark
>>   public Object patched() {
>>     return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
>>   }
>> 
>>   private String original(String name) {
>>     if (!name.startsWith("/")) {
>>       String baseName = getPackageName();
>>       if (baseName != null && !baseName.isEmpty()) {
>>         int len = baseName.length() + 1 + name.length();
>>         StringBuilder sb = new StringBuilder(len);
>>         name = sb.append(baseName.replace('.', '/'))
>>                 .append('/')
>>                 .append(name)
>>                 .toString();
>>       }
>>     } else {
>>       name = name.substring(1);
>>     }
>>     return name;
>>   }
>> 
>>   private String patched(String name) {
>>       if (!name.startsWith("/")) {
>>           String baseName = getPackageName();
>>           if (!baseName.isEmpty()) {
>>               return baseName.replace('.', '/') + '/' + name;
>>           }
>>           return name;
>>       }
>>       return name.substring(1);
>>   }
>> 
>>   private String getPackageName() {
>>     return klazz.getPackageName();
>>   }
>> }
>> 
>> demonstrates good improvement, especially as of memory consumption:
>> 
>>                                             Mode  Cnt     Score     Error   Units
>> 
>> original                                    avgt   50    57.974 ?   0.365   ns/op
>> original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
>> original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
>> original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
>> original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
>> original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
>> original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
>> original:?gc.count                          avgt   50   208.000            counts
>> original:?gc.time                           avgt   50   224.000                ms
>> 
>> patched                                     avgt   50    44.367 ?   0.162   ns/op
>> patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
>> patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
>> patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
>> patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
>> patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
>> patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
>> patched:?gc.count                           avgt   50   167.000            counts
>> patched:?gc.time                            avgt   50   181.000                ms
>
> We can remove the check for baseName being null, that's a left over from iteration during JDK 9.

@AlanBateman should I then do it only for `Class.resolveName()` or everywhere we call `Class.getPackageName()`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3464

From redestad at openjdk.java.net  Wed Apr 14 11:50:59 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Apr 2021 11:50:59 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching [v3]
In-Reply-To: <8YiE6q8ttulbS9HkRmp6YyGgm4yCssfVcMgUASKaIME=.06050e95-3fe0-4456-a4fd-74435be1ac60@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
 <8YiE6q8ttulbS9HkRmp6YyGgm4yCssfVcMgUASKaIME=.06050e95-3fe0-4456-a4fd-74435be1ac60@github.com>
Message-ID: <hB1X0_08ATtvnmfLpT1TSFxphimlMIUtsfxflqq1d1I=.b5977e54-34fd-4cf8-863b-d861924db597@github.com>

On Wed, 14 Apr 2021 11:38:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
>> 
>> This piggybacks on the existing mechanism for method handle invoker caching.
>> 
>> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: simplify test

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3439

From jbachorik at openjdk.java.net  Wed Apr 14 12:06:14 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 14 Apr 2021 12:06:14 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
 <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
Message-ID: <ZJz55cGDYSoIVUVwjhD_FnF3CMhlEz2URhLCrlYVtno=.0d2ed24f-29c3-4218-bc28-b2177302ee77@github.com>

On Wed, 14 Apr 2021 11:17:14 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Roll back conditional registration of container events
>>  - Remove container events flag
>>  - Remove trailing spaces
>>  - Doh
>>  - Report container type and register events conditionally
>>  - Remove unused test files
>>  - Initial test support for JFR container events
>>  - Update the JFR control files
>>  - Split off the CPU throttling metrics
>>  - Formatting spaces
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b72abe91...67a61bd7
>
> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerMemoryUsageEvent.java line 46:
> 
>> 44: public final class ContainerMemoryUsageEvent extends AbstractJDKEvent {
>> 45:     @Label("Memory Pressure")
>> 46:     @Description("(attempts per second * 1000), if enabled, that the operating system tries to satisfy a memory request for any " +
> 
> This unit seems a bit strange. Do we really need to multiply by 1000?

This is taken as reported by cgroups - I didn't want to change the semantics so it does not confuse people familiar with cgroups.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From jbachorik at openjdk.java.net  Wed Apr 14 12:17:09 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 14 Apr 2021 12:17:09 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
 <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
Message-ID: <Dgx1j0XYG0RYwTa1Hpbg80ETOqU4xhSQB_DiQnfJQKw=.410be2e5-8525-44c3-aab0-c251720ade91@github.com>

On Wed, 14 Apr 2021 10:25:09 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Roll back conditional registration of container events
>>  - Remove container events flag
>>  - Remove trailing spaces
>>  - Doh
>>  - Report container type and register events conditionally
>>  - Remove unused test files
>>  - Initial test support for JFR container events
>>  - Update the JFR control files
>>  - Split off the CPU throttling metrics
>>  - Formatting spaces
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/19aad098...67a61bd7
>
> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerCPUThrottlingEvent.java line 44:
> 
>> 42: @Category({"Operating System", "Container", "Processor"})
>> 43: @Description("Container CPU throttling related information.")
>> 44: public class ContainerCPUThrottlingEvent extends AbstractJDKEvent {
> 
> I wonder if we should put all the container events in the same category {"Operating System", "Container"}, Or possibly add them under the already existing categories under "Operating System"?

I guess we could fit those events under `Operating System/Memory` and `Operating System/Processor` categories.
What about I/O? Currently, there is only `Operating System/Network` category. The options are:
* Add `Operating System/IO` category and move `Network` to `Operating System/IO/Network`
* Add `Operation System/FileSystem` category and move the container IO event there

What would you prefer?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From jlaskey at openjdk.java.net  Wed Apr 14 12:27:55 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 14 Apr 2021 12:27:55 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v2]
In-Reply-To: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
Message-ID: <7UrrQfN-2x0P37lfeuwTlgMNtWFyPS_xLBhkW6ZityI=.f7c16c28-a2df-48c2-852b-ae702ca05224@github.com>

> Move makeXXXSpilterator from public (@hidden) to protected. No API ch

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Make makeXXXSpliterator final

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3469/files
  - new: https://git.openjdk.java.net/jdk/pull/3469/files/4bde44fc..a6e35c6b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=00-01

  Stats: 79 lines in 2 files changed: 29 ins; 43 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3469.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469

PR: https://git.openjdk.java.net/jdk/pull/3469

From herrick at openjdk.java.net  Wed Apr 14 12:37:58 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 14 Apr 2021 12:37:58 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp
 files [v3]
In-Reply-To: <06AIwPLNMc5dbhvkc5VWGUrbfCFH2wKFMDn-Va7YR0c=.da788bf2-375d-4093-b6b5-0ee189488c23@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
 <06AIwPLNMc5dbhvkc5VWGUrbfCFH2wKFMDn-Va7YR0c=.da788bf2-375d-4093-b6b5-0ee189488c23@github.com>
Message-ID: <FkIofRA0Y1bUkpZpAFcnWIkLScJf62Tis3vc35lCIRM=.ba0ec8e4-375e-4830-a11c-691edcedf9aa@github.com>

On Tue, 13 Apr 2021 22:50:12 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> two changes:
>> One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
>> The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8265078: jpackage tests on Windows leave large temp files

Although jpackage failing to clean up has only been seen as an issue on Windows, allowing it to write outside the test directory (in default tmp dir) still exists on mac and linux - I will look into enhancing (what is now setWindowsTmpDir()) to be usefull on all platforms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3473

From alanb at openjdk.java.net  Wed Apr 14 13:45:44 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 14 Apr 2021 13:45:44 GMT
Subject: RFR: 8265075: Improve and simplify Class.resolveName()
In-Reply-To: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
References: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
Message-ID: <cEr7JUDCV-MXBoTxfjtmt_-edj7CmkwA-KWZk8rRedM=.73ef0bfb-b155-41e1-bd83-21cbfc3c4c53@github.com>

On Tue, 13 Apr 2021 12:47:50 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In mentioned method this code snippet
> 
> int len = baseName.length() + 1 + name.length();
> StringBuilder sb = new StringBuilder(len);
> name = sb.append(baseName.replace('.', '/'))
>         .append('/')
>         .append(name)
>         .toString();
> 
> 
> can be simplified with performance improvement as
> 
> name = baseName.replace('.', '/') + '/' + name;
> 
> Also null check of `baseName` can be removed as Class.getPackageName() never returns null.
> 
> This benchmark
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ResolveNameBenchmark {
> 
>   private final Class<? extends ResolveNameBenchmark> klazz = getClass();
> 
>   @Benchmark
>   public Object original() {
>     return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   @Benchmark
>   public Object patched() {
>     return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   private String original(String name) {
>     if (!name.startsWith("/")) {
>       String baseName = getPackageName();
>       if (baseName != null && !baseName.isEmpty()) {
>         int len = baseName.length() + 1 + name.length();
>         StringBuilder sb = new StringBuilder(len);
>         name = sb.append(baseName.replace('.', '/'))
>                 .append('/')
>                 .append(name)
>                 .toString();
>       }
>     } else {
>       name = name.substring(1);
>     }
>     return name;
>   }
> 
>   private String patched(String name) {
>       if (!name.startsWith("/")) {
>           String baseName = getPackageName();
>           if (!baseName.isEmpty()) {
>               return baseName.replace('.', '/') + '/' + name;
>           }
>           return name;
>       }
>       return name.substring(1);
>   }
> 
>   private String getPackageName() {
>     return klazz.getPackageName();
>   }
> }
> 
> demonstrates good improvement, especially as of memory consumption:
> 
>                                             Mode  Cnt     Score     Error   Units
> 
> original                                    avgt   50    57.974 ?   0.365   ns/op
> original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
> original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
> original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
> original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
> original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
> original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
> original:?gc.count                          avgt   50   208.000            counts
> original:?gc.time                           avgt   50   224.000                ms
> 
> patched                                     avgt   50    44.367 ?   0.162   ns/op
> patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
> patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
> patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
> patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
> patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
> patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
> patched:?gc.count                           avgt   50   167.000            counts
> patched:?gc.time                            avgt   50   181.000                ms

If you have the time, then looking for usages of getPackageName where it checks for null would be useful. We can close this PR and open a new issue/PR for that cleanup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3464

From github.com+10835776+stsypanov at openjdk.java.net  Wed Apr 14 13:45:44 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Apr 2021 13:45:44 GMT
Subject: RFR: 8265075: Improve and simplify Class.resolveName()
In-Reply-To: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
References: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
Message-ID: <N1OqEAm1QyJG1OeSpowlZiPvTQ58O1RQCT4CCbqYsqU=.498ed99e-86fe-45d0-9856-e573fb1cd1c8@github.com>

On Tue, 13 Apr 2021 12:47:50 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In mentioned method this code snippet
> 
> int len = baseName.length() + 1 + name.length();
> StringBuilder sb = new StringBuilder(len);
> name = sb.append(baseName.replace('.', '/'))
>         .append('/')
>         .append(name)
>         .toString();
> 
> 
> can be simplified with performance improvement as
> 
> name = baseName.replace('.', '/') + '/' + name;
> 
> Also null check of `baseName` can be removed as Class.getPackageName() never returns null.
> 
> This benchmark
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ResolveNameBenchmark {
> 
>   private final Class<? extends ResolveNameBenchmark> klazz = getClass();
> 
>   @Benchmark
>   public Object original() {
>     return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   @Benchmark
>   public Object patched() {
>     return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   private String original(String name) {
>     if (!name.startsWith("/")) {
>       String baseName = getPackageName();
>       if (baseName != null && !baseName.isEmpty()) {
>         int len = baseName.length() + 1 + name.length();
>         StringBuilder sb = new StringBuilder(len);
>         name = sb.append(baseName.replace('.', '/'))
>                 .append('/')
>                 .append(name)
>                 .toString();
>       }
>     } else {
>       name = name.substring(1);
>     }
>     return name;
>   }
> 
>   private String patched(String name) {
>       if (!name.startsWith("/")) {
>           String baseName = getPackageName();
>           if (!baseName.isEmpty()) {
>               return baseName.replace('.', '/') + '/' + name;
>           }
>           return name;
>       }
>       return name.substring(1);
>   }
> 
>   private String getPackageName() {
>     return klazz.getPackageName();
>   }
> }
> 
> demonstrates good improvement, especially as of memory consumption:
> 
>                                             Mode  Cnt     Score     Error   Units
> 
> original                                    avgt   50    57.974 ?   0.365   ns/op
> original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
> original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
> original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
> original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
> original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
> original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
> original:?gc.count                          avgt   50   208.000            counts
> original:?gc.time                           avgt   50   224.000                ms
> 
> patched                                     avgt   50    44.367 ?   0.162   ns/op
> patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
> patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
> patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
> patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
> patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
> patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
> patched:?gc.count                           avgt   50   167.000            counts
> patched:?gc.time                            avgt   50   181.000                ms

Ok, then I close this one

-------------

PR: https://git.openjdk.java.net/jdk/pull/3464

From github.com+10835776+stsypanov at openjdk.java.net  Wed Apr 14 13:45:45 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Apr 2021 13:45:45 GMT
Subject: Withdrawn: 8265075: Improve and simplify Class.resolveName()
In-Reply-To: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
References: <VgYM_JybbT_tOjkIDD0Z6v_YzQzwlCGpHWx3E2erSBI=.a2566a3f-d3e9-4c9a-8e81-874ca72b6124@github.com>
Message-ID: <yA3IopsRUuk9qBsFqpI3lwnpcxPm1BIQuQs9OlmI4xI=.ea43acde-3b85-4cdf-a9b9-4ab64f8f7f8c@github.com>

On Tue, 13 Apr 2021 12:47:50 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In mentioned method this code snippet
> 
> int len = baseName.length() + 1 + name.length();
> StringBuilder sb = new StringBuilder(len);
> name = sb.append(baseName.replace('.', '/'))
>         .append('/')
>         .append(name)
>         .toString();
> 
> 
> can be simplified with performance improvement as
> 
> name = baseName.replace('.', '/') + '/' + name;
> 
> Also null check of `baseName` can be removed as Class.getPackageName() never returns null.
> 
> This benchmark
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ResolveNameBenchmark {
> 
>   private final Class<? extends ResolveNameBenchmark> klazz = getClass();
> 
>   @Benchmark
>   public Object original() {
>     return original("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   @Benchmark
>   public Object patched() {
>     return patched("com/tsypanov/ovn/ResolveNameBenchmark.class");
>   }
> 
>   private String original(String name) {
>     if (!name.startsWith("/")) {
>       String baseName = getPackageName();
>       if (baseName != null && !baseName.isEmpty()) {
>         int len = baseName.length() + 1 + name.length();
>         StringBuilder sb = new StringBuilder(len);
>         name = sb.append(baseName.replace('.', '/'))
>                 .append('/')
>                 .append(name)
>                 .toString();
>       }
>     } else {
>       name = name.substring(1);
>     }
>     return name;
>   }
> 
>   private String patched(String name) {
>       if (!name.startsWith("/")) {
>           String baseName = getPackageName();
>           if (!baseName.isEmpty()) {
>               return baseName.replace('.', '/') + '/' + name;
>           }
>           return name;
>       }
>       return name.substring(1);
>   }
> 
>   private String getPackageName() {
>     return klazz.getPackageName();
>   }
> }
> 
> demonstrates good improvement, especially as of memory consumption:
> 
>                                             Mode  Cnt     Score     Error   Units
> 
> original                                    avgt   50    57.974 ?   0.365   ns/op
> original:?gc.alloc.rate                     avgt   50  3419.447 ?  21.154  MB/sec
> original:?gc.alloc.rate.norm                avgt   50   312.006 ?   0.001    B/op
> original:?gc.churn.G1_Eden_Space            avgt   50  3399.396 ? 149.836  MB/sec
> original:?gc.churn.G1_Eden_Space.norm       avgt   50   310.198 ?  13.628    B/op
> original:?gc.churn.G1_Survivor_Space        avgt   50     0.004 ?   0.001  MB/sec
> original:?gc.churn.G1_Survivor_Space.norm   avgt   50    ? 10??              B/op
> original:?gc.count                          avgt   50   208.000            counts
> original:?gc.time                           avgt   50   224.000                ms
> 
> patched                                     avgt   50    44.367 ?   0.162   ns/op
> patched:?gc.alloc.rate                      avgt   50  2749.265 ?  10.014  MB/sec
> patched:?gc.alloc.rate.norm                 avgt   50   192.004 ?   0.001    B/op
> patched:?gc.churn.G1_Eden_Space             avgt   50  2729.221 ? 193.552  MB/sec
> patched:?gc.churn.G1_Eden_Space.norm        avgt   50   190.615 ?  13.539    B/op
> patched:?gc.churn.G1_Survivor_Space         avgt   50     0.003 ?   0.001  MB/sec
> patched:?gc.churn.G1_Survivor_Space.norm    avgt   50    ? 10??              B/op
> patched:?gc.count                           avgt   50   167.000            counts
> patched:?gc.time                            avgt   50   181.000                ms

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3464

From michaelm at openjdk.java.net  Wed Apr 14 14:09:45 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Apr 2021 14:09:45 GMT
Subject: RFR: 8262883: doccheck: Broken links in java.base
Message-ID: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>

Hi,

Could I get the following trivial doc changes reviewed please, caused by:

- broken <A> tags in MethodHandles referring to package.html instead of package-summary.html

- references to a package level #unixdomain anchor that no longer exists.

- a <a> tag missing a "../" in SocketChannel

Thanks,

Michael

-------------

Commit messages:
 - Fixed SocketChannel
 - fixed links in apidoc

Changes: https://git.openjdk.java.net/jdk/pull/3491/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3491&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262883
  Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3491/head:pull/3491

PR: https://git.openjdk.java.net/jdk/pull/3491

From rriggs at openjdk.java.net  Wed Apr 14 14:14:56 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Apr 2021 14:14:56 GMT
Subject: RFR: 8265173: [test] divert spurious log output away from stream
 under test in ProcessBuilder Basic test
Message-ID: <FBD5K-n8B-61e9DPHxhcPz9g_saiHrepEIvpP_3IFg0=.af1b3e51-aa1a-4712-982c-594827b2fb11@github.com>

The most recent intermittent failure showed that the error occurred during VM initialization.
Only the tty output was diverted, but not log output.
Add diversion of log output as well tty output.

Add `-Xlog:all=warning:stderr` and `-Xlog:all=warning:stdout` to correspond to 
`-XX:+DisplayVMOutputToStderr` and `-XX:+DisplayVMOutputToStdout`

-------------

Commit messages:
 - 8265173: [test] divert spurious log output away from stream under test in ProcessBuilder Basic test

Changes: https://git.openjdk.java.net/jdk/pull/3492/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3492&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265173
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3492.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3492/head:pull/3492

PR: https://git.openjdk.java.net/jdk/pull/3492

From lancea at openjdk.java.net  Wed Apr 14 14:25:45 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 14 Apr 2021 14:25:45 GMT
Subject: RFR: 8262883: doccheck: Broken links in java.base
In-Reply-To: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>
References: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>
Message-ID: <YlqDhijwC2fIRFJTTlBuDhlzpzkfAiqbbjEP617zawg=.50c32a22-704d-493c-8869-f32bbedc0c4b@github.com>

On Wed, 14 Apr 2021 14:03:01 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following trivial doc changes reviewed please, caused by:
> 
> - broken <A> tags in MethodHandles referring to package.html instead of package-summary.html
> 
> - references to a package level #unixdomain anchor that no longer exists.
> 
> - a <a> tag missing a "../" in SocketChannel
> 
> Thanks,
> 
> Michael

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3491

From sgehwolf at openjdk.java.net  Wed Apr 14 14:35:49 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 14 Apr 2021 14:35:49 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <ZJz55cGDYSoIVUVwjhD_FnF3CMhlEz2URhLCrlYVtno=.0d2ed24f-29c3-4218-bc28-b2177302ee77@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
 <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
 <ZJz55cGDYSoIVUVwjhD_FnF3CMhlEz2URhLCrlYVtno=.0d2ed24f-29c3-4218-bc28-b2177302ee77@github.com>
Message-ID: <hNZI-flA6UWphaEyK3MHZ_oXnV8qWkYNkEC7O17o0Bs=.40e6b763-3600-4352-bfad-487309043d98@github.com>

On Wed, 14 Apr 2021 12:03:12 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerMemoryUsageEvent.java line 46:
>> 
>>> 44: public final class ContainerMemoryUsageEvent extends AbstractJDKEvent {
>>> 45:     @Label("Memory Pressure")
>>> 46:     @Description("(attempts per second * 1000), if enabled, that the operating system tries to satisfy a memory request for any " +
>> 
>> This unit seems a bit strange. Do we really need to multiply by 1000?
>
> This is taken as reported by cgroups - I didn't want to change the semantics so it does not confuse people familiar with cgroups.

I don't see this event field being set anywhere? Which Metrics API call is this using?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From michaelm at openjdk.java.net  Wed Apr 14 15:03:40 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Apr 2021 15:03:40 GMT
Subject: Integrated: 8262883: doccheck: Broken links in java.base
In-Reply-To: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>
References: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>
Message-ID: <HmG02GPL3mRskKltOBXgDFe05_mjL0_5fDysreYQhuk=.3b46e0a2-1ca7-4e07-9304-dbe554ab2069@github.com>

On Wed, 14 Apr 2021 14:03:01 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following trivial doc changes reviewed please, caused by:
> 
> - broken <A> tags in MethodHandles referring to package.html instead of package-summary.html
> 
> - references to a package level #unixdomain anchor that no longer exists.
> 
> - a <a> tag missing a "../" in SocketChannel
> 
> Thanks,
> 
> Michael

This pull request has now been integrated.

Changeset: 46616909
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/46616909
Stats:     5 lines in 4 files changed: 0 ins; 0 del; 5 mod

8262883: doccheck: Broken links in java.base

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/3491

From alanb at openjdk.java.net  Wed Apr 14 15:06:47 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 14 Apr 2021 15:06:47 GMT
Subject: RFR: 8264208: Console charset API [v6]
In-Reply-To: <Tt0qyS4hDfElNxFnuuZLpMCFymOdWdH2Jb7sSrMbbv0=.786cae20-7d7b-48ba-9d22-029c6d72c1e5@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <Tt0qyS4hDfElNxFnuuZLpMCFymOdWdH2Jb7sSrMbbv0=.786cae20-7d7b-48ba-9d22-029c6d72c1e5@github.com>
Message-ID: <TTR-7pS11bfmy5Glq8TaqUZCCx8h7V5he4D4T7YNGoQ=.5cafa019-dd38-4208-bea7-d161ec4e0965@github.com>

On Tue, 13 Apr 2021 19:59:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to System.out/err init.

src/java.base/share/classes/java/lang/System.java line 166:

> 164:      * exists, {@link Charset#defaultCharset()} otherwise.
> 165:      */
> 166:     public static final PrintStream err = null;

I still think we need something in System.in to link to Console::charset. If someone creates an InputStreamReader(System.in) then it will use the default charset, they should be using Console::reader for these cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From psandoz at openjdk.java.net  Wed Apr 14 15:18:39 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 14 Apr 2021 15:18:39 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms [v3]
In-Reply-To: <wO0daqoywG84bJXWKzVmVYzphDIAS8j7a9adRh6lqL4=.f3c82edf-1e06-4517-abf3-ca14f52f4490@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
 <BMPpJ71J_nADsOkyDOnHGLwSIhudV4FbKJz1Jd_Bg80=.637c52fc-311f-40c4-9df3-90dd5aabaf7c@github.com>
 <VXm7ZP216skAWfoMNSTij82ZQz777t9V1HvvZwTzltk=.91c1365b-3ffa-4d3f-99ab-cb8b711d9187@github.com>
 <Gh_PgA0HF8MMqnHYu4dqkCgO03eRH71aRtSLptqxeGU=.1eccde6c-9e49-41eb-95d9-a2d39434a03f@github.com>
 <wO0daqoywG84bJXWKzVmVYzphDIAS8j7a9adRh6lqL4=.f3c82edf-1e06-4517-abf3-ca14f52f4490@github.com>
Message-ID: <di97iHuKvufAND2CXxWHYPeD4b-MJgFUUx_uk2YNYFw=.24bf5a20-2ef9-447c-9efb-af017cad1cd8@github.com>

On Wed, 14 Apr 2021 11:31:55 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> No, since VarHandles are not publicly extensible, the exception should not occur unless something has gone very wrong (the correspondence between access mode and implementing method is broken).
>
> Unfortunately the change to InternalError breaks a number of tests, since the UOE does bubble up through the public API. I also found a few failing tests I had overlooked due VarHandle.isAccessModeSupported throwing rather than returning false, so I had to slightly rework the patch.

Oops, my bad. I got confused and forgot that VH implementations can avoid implementing access mode methods that would just throw UOE. This slightly complicates lazily resolution.

We don't cache the result of a failed method resolution, which would require a non-null sentinel value, probably does not matter.

Using `resolveOrNull` seems a better fit rather than catching and dropping ROE, less work performed too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3472

From psandoz at openjdk.java.net  Wed Apr 14 15:24:39 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 14 Apr 2021 15:24:39 GMT
Subject: RFR: 8264976: Minor numeric bug in
 AbstractSplittableWithBrineGenerator.makeSplitsSpliterator
In-Reply-To: <qzQKVrErONUrofcWd5FuIztqiIaA9_SYBeJRIwZxLxs=.a5232bfa-db14-486f-8940-74b2707b1265@github.com>
References: <qzQKVrErONUrofcWd5FuIztqiIaA9_SYBeJRIwZxLxs=.a5232bfa-db14-486f-8940-74b2707b1265@github.com>
Message-ID: <_aFq0YhPn_upSB39MKGKt4h1VOccQA3-58cL9M2LSCI=.46955cd9-c01a-4ff7-9a97-dac3b4b671e6@github.com>

On Fri, 9 Apr 2021 09:41:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports:
>   Cast one of the operands of this subtraction operation to a "long".
> 
> Here:
> 
>         Spliterator<SplittableGenerator> makeSplitsSpliterator(long index, long fence, SplittableGenerator source) {
>             ...
>             long multiplier = (1 << SALT_SHIFT) - 1; // <---- here
> 
> 
> The shift is integer, and the implicit cast to `long` happens too late. `SALT_SHIFT` is currently 4, so this is not the problem yet. But it would become a problem if `SALT_SHIFT` ever becomes 32 or larger. The shift operand should be `1L` for safety. Observe:
> 
> 
> jshell> Long.toHexString((1 << 31) - 1)
> $2 ==> "7fffffff"
> 
> jshell> Long.toHexString((1 << 32) - 1)
> $3 ==> "0"
> 
> jshell> Long.toHexString((1L << 32) - 1)
> $4 ==> "ffffffff"
> 
> 
> Additional testing: 
>  - [x] Linux x86_64 fastdebug, `jdk/utils/Random`

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3409

From psandoz at openjdk.java.net  Wed Apr 14 15:25:43 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 14 Apr 2021 15:25:43 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching [v3]
In-Reply-To: <8YiE6q8ttulbS9HkRmp6YyGgm4yCssfVcMgUASKaIME=.06050e95-3fe0-4456-a4fd-74435be1ac60@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
 <8YiE6q8ttulbS9HkRmp6YyGgm4yCssfVcMgUASKaIME=.06050e95-3fe0-4456-a4fd-74435be1ac60@github.com>
Message-ID: <leUJU7cLJJnPxEAzhCCOzs8LCdI1uLummFOv8GL-QNA=.c972430c-992d-4609-aed8-0d9c77a9861f@github.com>

On Wed, 14 Apr 2021 11:38:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
>> 
>> This piggybacks on the existing mechanism for method handle invoker caching.
>> 
>> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: simplify test

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3439

From alanb at openjdk.java.net  Wed Apr 14 15:30:44 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 14 Apr 2021 15:30:44 GMT
Subject: RFR: 8262883: doccheck: Broken links in java.base
In-Reply-To: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>
References: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>
Message-ID: <iVGekPDvfUIg-Msy0Dsn_j4VH0sN7fXN0zXTgRrYqjE=.128f32ea-1729-4f3c-90f2-14ff18d6af9c@github.com>

On Wed, 14 Apr 2021 14:03:01 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following trivial doc changes reviewed please, caused by:
> 
> - broken <A> tags in MethodHandles referring to package.html instead of package-summary.html
> 
> - references to a package level #unixdomain anchor that no longer exists.
> 
> - a <a> tag missing a "../" in SocketChannel
> 
> Thanks,
> 
> Michael

src/java.base/share/classes/java/nio/channels/DatagramChannel.java line 175:

> 173:      * connected.
> 174:      *
> 175:      * @apiNote {@linkplain java.net.UnixDomainSocketAddress Unix domain} sockets

The parameter to this method is a ProtocolFamily and maybe this note should be say that StandardProtocolFamily#UNIX is not supported.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3491

From jlaskey at openjdk.java.net  Wed Apr 14 15:32:41 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 14 Apr 2021 15:32:41 GMT
Subject: RFR: 8264976: Minor numeric bug in
 AbstractSplittableWithBrineGenerator.makeSplitsSpliterator
In-Reply-To: <qzQKVrErONUrofcWd5FuIztqiIaA9_SYBeJRIwZxLxs=.a5232bfa-db14-486f-8940-74b2707b1265@github.com>
References: <qzQKVrErONUrofcWd5FuIztqiIaA9_SYBeJRIwZxLxs=.a5232bfa-db14-486f-8940-74b2707b1265@github.com>
Message-ID: <x6XoQ9XJUPKshyOHqnSg5blsYzOJmuiwheWzGFEF7Gg=.6340c6ff-2994-4372-b719-2aed6d244ac1@github.com>

On Fri, 9 Apr 2021 09:41:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports:
>   Cast one of the operands of this subtraction operation to a "long".
> 
> Here:
> 
>         Spliterator<SplittableGenerator> makeSplitsSpliterator(long index, long fence, SplittableGenerator source) {
>             ...
>             long multiplier = (1 << SALT_SHIFT) - 1; // <---- here
> 
> 
> The shift is integer, and the implicit cast to `long` happens too late. `SALT_SHIFT` is currently 4, so this is not the problem yet. But it would become a problem if `SALT_SHIFT` ever becomes 32 or larger. The shift operand should be `1L` for safety. Observe:
> 
> 
> jshell> Long.toHexString((1 << 31) - 1)
> $2 ==> "7fffffff"
> 
> jshell> Long.toHexString((1 << 32) - 1)
> $3 ==> "0"
> 
> jshell> Long.toHexString((1L << 32) - 1)
> $4 ==> "ffffffff"
> 
> 
> Additional testing: 
>  - [x] Linux x86_64 fastdebug, `jdk/utils/Random`

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3409

From lancea at openjdk.java.net  Wed Apr 14 15:45:39 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 14 Apr 2021 15:45:39 GMT
Subject: Integrated: 8265019 : Update tests for additional TestNG test
 permissions
In-Reply-To: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
References: <UCN2QYJiY9hgcLikb2OU1xmRfEf6ak0iKSmJmBgmHZ0=.376e794c-1f15-4dc9-96b1-1d5dc0ff931b@github.com>
Message-ID: <Y9292_icBaRNFLZsQ-npppRTpoysCDw13E3SS15aN6E=.b05bcbc0-633b-46a4-9848-80334cbd4b8b@github.com>

On Tue, 13 Apr 2021 18:01:49 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG.
> 
> Best,
> Lance

This pull request has now been integrated.

Changeset: ffb37718
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ffb37718
Stats:     22 lines in 2 files changed: 16 ins; 4 del; 2 mod

8265019: Update tests for additional TestNG test permissions

Reviewed-by: naoto, bpb, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3471

From naoto at openjdk.java.net  Wed Apr 14 16:04:38 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 16:04:38 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v2]
In-Reply-To: <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
Message-ID: <ANqqM9JXBCDik7LhzAf9vvJkN94Ea8Fsmm3FCLTgu8o=.e32683ea-38c2-4b32-a947-69462690e886@github.com>

On Tue, 13 Apr 2021 15:03:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year and @bug id reference in existing test
>  - copyright year on source

Thanks for checking.
`CalendarNameProviderImpl` is an implementation detail, which is shared between `j.u.Calendar` and `j.t.f.DateTimeFormatter(Builder)` class, where it provides localized names for Calendar fields. For the field `Calendar.AM_PM`, it includes not only am/pm translations, but also day periods translations as you see. So blindly mapping day period translations to Calendar.AM/PM index is incorrect. I'd rather modify the code like:

                            if (field == AM_PM && !javatime && i > PM) {
                                continue;
                            } else {
                                map.put(name, base + i);
                            }

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From rriggs at openjdk.java.net  Wed Apr 14 16:08:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Apr 2021 16:08:41 GMT
Subject: RFR: 8262883: doccheck: Broken links in java.base
In-Reply-To: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>
References: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>
Message-ID: <WJkiiOdT6lRyz_vdRaLUkegCT2XtqdCuPAUgy7gVRYg=.75297097-dc27-4eb5-8e57-a59d424ebd4d@github.com>

On Wed, 14 Apr 2021 14:03:01 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following trivial doc changes reviewed please, caused by:
> 
> - broken <A> tags in MethodHandles referring to package.html instead of package-summary.html
> 
> - references to a package level #unixdomain anchor that no longer exists.
> 
> - a <a> tag missing a "../" in SocketChannel
> 
> Thanks,
> 
> Michael

Integrating less than an hour after the PR is started seems to be a bit too quick to allow useful input.
Perhaps even for 'trivial' changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3491

From darcy at openjdk.java.net  Wed Apr 14 16:18:40 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 14 Apr 2021 16:18:40 GMT
Subject: Integrated: 8265174: Update Class.getDeclaredMethods to discuss
 synthetic and bridge methods
In-Reply-To: <cPYsX6waW3UYtAa2CNRzxcR6pE_npzYaGs1hQJ6JLOM=.ede42a4f-7757-4491-9991-ed08e90654ca@github.com>
References: <cPYsX6waW3UYtAa2CNRzxcR6pE_npzYaGs1hQJ6JLOM=.ede42a4f-7757-4491-9991-ed08e90654ca@github.com>
Message-ID: <4KRVS6oipV93Lb6eBJpomEWIvKMAMKNxGeZQhuC7Jbg=.41628ff8-eee9-48f2-a789-c412f66f2615@github.com>

On Tue, 13 Apr 2021 22:18:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The results from Class.getDeclaredMethods can include bridge and other synthetic methods, which can be unexpected by users (JDK-6815786, JDK-8142904) and appear to be inherited methods. The javadoc for Class.getDeclaredMethods should be updated to explicitly mention the possibility of synthetic methods appearing.

This pull request has now been integrated.

Changeset: 80026d81
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/80026d81
Stats:     28 lines in 5 files changed: 26 ins; 1 del; 1 mod

8265174: Update Class.getDeclaredMethods to discuss synthetic and bridge methods

Reviewed-by: jfranck

-------------

PR: https://git.openjdk.java.net/jdk/pull/3477

From shade at openjdk.java.net  Wed Apr 14 16:20:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 14 Apr 2021 16:20:39 GMT
Subject: Integrated: 8264976: Minor numeric bug in
 AbstractSplittableWithBrineGenerator.makeSplitsSpliterator
In-Reply-To: <qzQKVrErONUrofcWd5FuIztqiIaA9_SYBeJRIwZxLxs=.a5232bfa-db14-486f-8940-74b2707b1265@github.com>
References: <qzQKVrErONUrofcWd5FuIztqiIaA9_SYBeJRIwZxLxs=.a5232bfa-db14-486f-8940-74b2707b1265@github.com>
Message-ID: <kFR08C_IfJTrLBXYOH5yapOvAMIYTzBRqQ-NHgayJBM=.e34d71a5-336d-4339-837e-44bd5a50d916@github.com>

On Fri, 9 Apr 2021 09:41:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports:
>   Cast one of the operands of this subtraction operation to a "long".
> 
> Here:
> 
>         Spliterator<SplittableGenerator> makeSplitsSpliterator(long index, long fence, SplittableGenerator source) {
>             ...
>             long multiplier = (1 << SALT_SHIFT) - 1; // <---- here
> 
> 
> The shift is integer, and the implicit cast to `long` happens too late. `SALT_SHIFT` is currently 4, so this is not the problem yet. But it would become a problem if `SALT_SHIFT` ever becomes 32 or larger. The shift operand should be `1L` for safety. Observe:
> 
> 
> jshell> Long.toHexString((1 << 31) - 1)
> $2 ==> "7fffffff"
> 
> jshell> Long.toHexString((1 << 32) - 1)
> $3 ==> "0"
> 
> jshell> Long.toHexString((1L << 32) - 1)
> $4 ==> "ffffffff"
> 
> 
> Additional testing: 
>  - [x] Linux x86_64 fastdebug, `jdk/utils/Random`

This pull request has now been integrated.

Changeset: 94067446
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/94067446
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8264976: Minor numeric bug in AbstractSplittableWithBrineGenerator.makeSplitsSpliterator

Reviewed-by: psandoz, jlaskey

-------------

PR: https://git.openjdk.java.net/jdk/pull/3409

From michaelm at openjdk.java.net  Wed Apr 14 16:20:51 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Apr 2021 16:20:51 GMT
Subject: RFR: 8262883: doccheck: Broken links in java.base
In-Reply-To: <iVGekPDvfUIg-Msy0Dsn_j4VH0sN7fXN0zXTgRrYqjE=.128f32ea-1729-4f3c-90f2-14ff18d6af9c@github.com>
References: <pWctAl3mVJbsY_-rmILHoAEmJM6yn88e1acmEbzqMoI=.6e8548db-206f-49de-88eb-f581a0c2edd3@github.com>
 <iVGekPDvfUIg-Msy0Dsn_j4VH0sN7fXN0zXTgRrYqjE=.128f32ea-1729-4f3c-90f2-14ff18d6af9c@github.com>
Message-ID: <Iloxid3xzlKLVsWBrYdIJfx4eyeSeEx03oiJZBoEzfs=.20370cee-9718-402d-a757-079d8b6d2d1a@github.com>

On Wed, 14 Apr 2021 15:27:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following trivial doc changes reviewed please, caused by:
>> 
>> - broken <A> tags in MethodHandles referring to package.html instead of package-summary.html
>> 
>> - references to a package level #unixdomain anchor that no longer exists.
>> 
>> - a <a> tag missing a "../" in SocketChannel
>> 
>> Thanks,
>> 
>> Michael
>
> src/java.base/share/classes/java/nio/channels/DatagramChannel.java line 175:
> 
>> 173:      * connected.
>> 174:      *
>> 175:      * @apiNote {@linkplain java.net.UnixDomainSocketAddress Unix domain} sockets
> 
> The parameter to this method is a ProtocolFamily and maybe this note should be say that StandardProtocolFamily#UNIX is not supported.

Okay, reasonable suggestion. I was a bit quick integrating. I will file a new issue to update the spec as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3491

From naoto at openjdk.java.net  Wed Apr 14 16:55:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 16:55:03 GMT
Subject: RFR: 8264208: Console charset API [v7]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <g2kAAl8Q_BYnQ7FdEc2XZMLJZbq8sgDqi1HEHS23FtA=.f08399f0-f9d5-4366-8520-08413b0980d2@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added Console::charset() relation with System.in

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/9e323145..45ab77b3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=05-06

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

PR: https://git.openjdk.java.net/jdk/pull/3419

From naoto at openjdk.java.net  Wed Apr 14 16:55:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 16:55:05 GMT
Subject: RFR: 8264208: Console charset API [v6]
In-Reply-To: <TTR-7pS11bfmy5Glq8TaqUZCCx8h7V5he4D4T7YNGoQ=.5cafa019-dd38-4208-bea7-d161ec4e0965@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <Tt0qyS4hDfElNxFnuuZLpMCFymOdWdH2Jb7sSrMbbv0=.786cae20-7d7b-48ba-9d22-029c6d72c1e5@github.com>
 <TTR-7pS11bfmy5Glq8TaqUZCCx8h7V5he4D4T7YNGoQ=.5cafa019-dd38-4208-bea7-d161ec4e0965@github.com>
Message-ID: <drU6uO9BEQY2lbEaDu2dLQnZ9nbxdF92beyjS86e8oI=.00fd985b-56a4-46f6-ab86-e1645bc80e86@github.com>

On Wed, 14 Apr 2021 15:03:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added comment to System.out/err init.
>
> src/java.base/share/classes/java/lang/System.java line 166:
> 
>> 164:      * exists, {@link Charset#defaultCharset()} otherwise.
>> 165:      */
>> 166:     public static final PrintStream err = null;
> 
> I still think we need something in System.in to link to Console::charset. If someone creates an InputStreamReader(System.in) then it will use the default charset, they should be using Console::reader for these cases.

Added some explanation to it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From uschindler at openjdk.java.net  Wed Apr 14 17:00:39 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 14 Apr 2021 17:00:39 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v2]
In-Reply-To: <7UrrQfN-2x0P37lfeuwTlgMNtWFyPS_xLBhkW6ZityI=.f7c16c28-a2df-48c2-852b-ae702ca05224@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <7UrrQfN-2x0P37lfeuwTlgMNtWFyPS_xLBhkW6ZityI=.f7c16c28-a2df-48c2-852b-ae702ca05224@github.com>
Message-ID: <F7JFOr5PakQMdSJp3Ai0kBkQfyen3CxrkAJPNfoth3U=.ff41946a-c6bc-44b2-a506-bd81fe27c2c9@github.com>

On Wed, 14 Apr 2021 12:27:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make makeXXXSpliterator final

To me this looks fine. It is all a bit of hack, but this makes sure the public API of java.util.Random does not change in comparison to JDK 16.
The final protected method may be visible by IDEs but it cannot be called und is not overrideable as it is final.

-------------

Marked as reviewed by uschindler (Author).

PR: https://git.openjdk.java.net/jdk/pull/3469

From ralph.goers at dslextreme.com  Wed Apr 14 17:00:43 2021
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Wed, 14 Apr 2021 10:00:43 -0700
Subject: Garbage Free Check
In-Reply-To: <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
 <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>
 <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>
Message-ID: <15EF4F44-B64E-4B93-BB35-088541798819@dslextreme.com>

I don?t have an account in the bug tracking system. Could someone possibly update the issue noted below to indicate that Apache Log4j 2 would also like that enhancement?

Thanks,

Ralph

> On Apr 5, 2021, at 1:26 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi,
> 
> Java does not have a data type with enough resolution to hold a full nanosecond value.
> Hence the implementation of Instant holding seconds and nanos.
> 
> There is an long dormant enhancement request to return micro-seconds as a long.
> 8196003 <https://bugs.openjdk.java.net/browse/JDK-8196003> java.time Instant and Duration methods for microseconds
> 
> That might be useful if the application gets enough resolution from microseconds.
> There might be some clever interpolation between System.currentTimeMillis()
> and adjusting with System.nanoTime().
> Though it would likely not be exactly synchronized with the values from Instant.
> 
> Regards, Roger
> 
> 
> On 4/5/21 3:56 PM, Brian Goetz wrote:
>> Project Valhalla will allow Instant to be migrated to a primitive class, which would address your problem.
>> 
>> On 4/2/2021 7:47 PM, Ralph Goers wrote:
>>> Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.
>>> 
>>> The code we have simply does
>>> 
>>> public void init(MutableInstant mutableInstant) {
>>>      Instant instant = java.time.Clock.systemUTC().instant();
>>> mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
>>> }
>>> In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
>>> Ideally we would really like something like
>>> 
>>> public void init(MutableInstant mutableInstant) {
>>>         java.time.Clock.systemUTC().initInstant(mutableInstant);
>>> }
>>> 
>>> where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.
>>> 
>>> This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.
>>> 
>>> Do you know of another way to do this? Am I missing something?
>>> 
>>> Ralph
>> 
> 
> 



From jpai at openjdk.java.net  Wed Apr 14 17:14:55 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 14 Apr 2021 17:14:55 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v3]
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - Update existing NarrowNamesTest to match expectations
 - Naoto's review suggestion

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3463/files
  - new: https://git.openjdk.java.net/jdk/pull/3463/files/84b11879..e7194733

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=01-02

  Stats: 33 lines in 2 files changed: 12 ins; 6 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3463/head:pull/3463

PR: https://git.openjdk.java.net/jdk/pull/3463

From naoto at openjdk.java.net  Wed Apr 14 17:17:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 17:17:03 GMT
Subject: RFR: 8264208: Console charset API [v8]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <nyFumoILMAmxH1N4n-S18tzvKKFiEjJKFZpnjs5mgPI=.525f4ef4-fe1f-4dec-8995-d07129807db5@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added @see links.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/45ab77b3..5988f600

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=06-07

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

PR: https://git.openjdk.java.net/jdk/pull/3419

From jpai at openjdk.java.net  Wed Apr 14 17:18:44 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 14 Apr 2021 17:18:44 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v3]
In-Reply-To: <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
Message-ID: <eVK9Znvfa28ElqKBZr1j2yypTTPx-SPBjqg9PjIKOuY=.3de7299f-d3ab-4c92-9a81-51187de76563@github.com>

On Wed, 14 Apr 2021 17:14:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update existing NarrowNamesTest to match expectations
>  - Naoto's review suggestion

Hello Naoto,

> CalendarNameProviderImpl is an implementation detail, which is shared between j.u.Calendar and j.t.f.DateTimeFormatter(Builder) class, where it provides localized names for Calendar fields. For the field Calendar.AM_PM, it includes not only am/pm translations, but also day periods translations as you see.

Thank you for those details. That's very helpful.

>I'd rather modify the code like:

                            if (field == AM_PM && !javatime && i > PM) {
                                continue;
                            } else {
                                map.put(name, base + i);
                            }


I've taken your suggestion and updated the code to match this. In the update, I've included a code comment to explain what this block does. Please do let me know if that code comment isn't accurate and needs any updates.

 The new `CalendarDisplayNamesTest` continues to pass with this change. I updated the existing `NarrowNamesTest` to match the expectations of the `Calendar.getDisplayName()` API.

All jtreg tests in `test/jdk/java/util/Calendar` and `test/jdk/java/time/` continue to pass too. I have triggered a local run of `tier1` tests and will check back the results early morning tomorrow.

Thank you for your reviews so far.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From github.com+828220+forax at openjdk.java.net  Wed Apr 14 17:34:38 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 14 Apr 2021 17:34:38 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v2]
In-Reply-To: <7UrrQfN-2x0P37lfeuwTlgMNtWFyPS_xLBhkW6ZityI=.f7c16c28-a2df-48c2-852b-ae702ca05224@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <7UrrQfN-2x0P37lfeuwTlgMNtWFyPS_xLBhkW6ZityI=.f7c16c28-a2df-48c2-852b-ae702ca05224@github.com>
Message-ID: <wAWim7PQER_Mw84yCnJUG8pR9hkT73qJs-G_hMYcUE0=.8b2ad7f4-c71d-4194-a1af-887c88d3999f@github.com>

On Wed, 14 Apr 2021 12:27:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make makeXXXSpliterator final

I don't see the point of having those methods virtual, they can be public static in RandomSupport given that there is only one implementation (the one with an if ... instanceof).
Also the static final proxy should be spelled PROXY.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From redestad at openjdk.java.net  Wed Apr 14 17:37:55 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Apr 2021 17:37:55 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms [v4]
In-Reply-To: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
Message-ID: <3Y2sxOysru28Y2FI2_hdNpVo2GbWmwZ-bXkbWERXhr8=.e766d8ea-4124-4183-80e6-668a44f71906@github.com>

> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
> 
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
> 
> Net effect is a reduction in bytecode executed per VH class by 50-60%.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Simplify resolveMemberName

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3472/files
  - new: https://git.openjdk.java.net/jdk/pull/3472/files/dc56c25b..f84f5194

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3472&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3472&range=02-03

  Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3472/head:pull/3472

PR: https://git.openjdk.java.net/jdk/pull/3472

From mchung at openjdk.java.net  Wed Apr 14 17:37:56 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 14 Apr 2021 17:37:56 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms [v3]
In-Reply-To: <qwlNA0PFBnJYXXSiIk72ypsiW2XaWJB3I-Kq4ULR7Vw=.cf37d821-4ac0-4901-8f01-45e907c58c2f@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
 <qwlNA0PFBnJYXXSiIk72ypsiW2XaWJB3I-Kq4ULR7Vw=.cf37d821-4ac0-4901-8f01-45e907c58c2f@github.com>
Message-ID: <rn5pmhfjUAqIBqAvSGLY2EVSFZ1y1IwjML6nZiJB_74=.4af2f565-0014-4818-a5c7-e288eaa3408f@github.com>

On Wed, 14 Apr 2021 11:35:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
>> 
>> - Lazily resolve MemberNames.
>> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
>> 
>> Net effect is a reduction in bytecode executed per VH class by 50-60%.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert UOE change, ensure VarHandle.isAccessModeSupported behaves well

src/java.base/share/classes/java/lang/invoke/VarForm.java line 136:

> 134:             return memberName_table[mode]
> 135:                 = MethodHandles.Lookup.IMPL_LOOKUP
> 136:                     .resolveOrFail(REF_invokeStatic, implClass, methodName, type);

An alternative way can be:


final MemberName getMemberName(int mode) {
     MemberName mn = getMemberNameOrNull(mode);
     if (mn == null) {
           throw new UnsupportedOperationException();
     }
 }       


This way `resolveMemberName(int mode)` can simply call IMPL_LOOKUP.resolveOrNull`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3472

From jlaskey at openjdk.java.net  Wed Apr 14 17:38:50 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 14 Apr 2021 17:38:50 GMT
Subject: RFR: 8265208: [JEP-356] : SplittableRandom and SplittableGenerators -
 splits() methods does not throw NullPointerException when source is null
Message-ID: <olZ38NqBbTb4DK67GznN5AWoE1GRPcTO-Q199lW4khM=.10b50747-ecff-4504-80a2-b6666c5502a6@github.com>

Add check for null.

-------------

Commit messages:
 - Check for null source
 - Make makeXXXSpliterator final
 - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

Changes: https://git.openjdk.java.net/jdk/pull/3495/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3495&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265208
  Stats: 178 lines in 4 files changed: 28 ins; 131 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3495.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3495/head:pull/3495

PR: https://git.openjdk.java.net/jdk/pull/3495

From asemenyuk at openjdk.java.net  Wed Apr 14 17:39:38 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 14 Apr 2021 17:39:38 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp
 files [v3]
In-Reply-To: <06AIwPLNMc5dbhvkc5VWGUrbfCFH2wKFMDn-Va7YR0c=.da788bf2-375d-4093-b6b5-0ee189488c23@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
 <06AIwPLNMc5dbhvkc5VWGUrbfCFH2wKFMDn-Va7YR0c=.da788bf2-375d-4093-b6b5-0ee189488c23@github.com>
Message-ID: <AfOdSzf6vA14n5ijE0OjgPK_LMhIz6s3tKYR6j4OD6I=.60dad9cd-4310-4d41-8126-2aee05bfa781@github.com>

On Tue, 13 Apr 2021 22:50:12 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> two changes:
>> One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
>> The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8265078: jpackage tests on Windows leave large temp files

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3473

From asemenyuk at openjdk.java.net  Wed Apr 14 17:39:38 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 14 Apr 2021 17:39:38 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp
 files [v2]
In-Reply-To: <fLgoORpLNrQfBdHDAUD5BqD3apwDFR4P_G9gvBDB3Rw=.3263e848-5763-486d-bcc2-ea1ff996d4f1@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
 <zBwihqww3OEBTy1nCBCgih9UoNQY89JSIbabQhUp9kM=.dd31451d-6504-49b5-887c-15f0ce7773ff@github.com>
 <fLgoORpLNrQfBdHDAUD5BqD3apwDFR4P_G9gvBDB3Rw=.3263e848-5763-486d-bcc2-ea1ff996d4f1@github.com>
Message-ID: <tQh9Mvg8BXhOoi6UMLvkJdRHhzQDe2a7dxpQaxCDXTE=.68cc2cbd-8fe8-445b-97f6-0bc2e3fbc518@github.com>

On Tue, 13 Apr 2021 21:10:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Are you sure you need an `AtomicReference` to set the exception? I don't see any use of multiple threads, but I might be missing something. If you do need it, you need to fix the order of arguments.

`postVisitDirectory()` and `visitFile()` methods can be potentially called concurrently by `walkFileTree()`. Javadoc https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Files.html#walkFileTree(java.nio.file.Path,java.util.Set,int,java.nio.file.FileVisitor) doesn't say anything about synchronization, so I think it is fair to assume it is not guaranteed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3473

From jlaskey at openjdk.java.net  Wed Apr 14 17:55:58 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 14 Apr 2021 17:55:58 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v3]
In-Reply-To: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
Message-ID: <wjMX68K_wC5pdTjd9-OoAhof4CkjTAw3_SxUNBYJjYE=.b8a45d39-9336-42e4-ad45-c4f8afe6ade7@github.com>

> Move makeXXXSpilterator from public (@hidden) to protected. No API ch

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  change static final from 'proxy' to 'PROXY'

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3469/files
  - new: https://git.openjdk.java.net/jdk/pull/3469/files/a6e35c6b..c6b5da30

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3469.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469

PR: https://git.openjdk.java.net/jdk/pull/3469

From kcr at openjdk.java.net  Wed Apr 14 18:03:36 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Apr 2021 18:03:36 GMT
Subject: RFR: JDK-8265078: jpackage tests on Windows leave large temp
 files [v2]
In-Reply-To: <tQh9Mvg8BXhOoi6UMLvkJdRHhzQDe2a7dxpQaxCDXTE=.68cc2cbd-8fe8-445b-97f6-0bc2e3fbc518@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
 <zBwihqww3OEBTy1nCBCgih9UoNQY89JSIbabQhUp9kM=.dd31451d-6504-49b5-887c-15f0ce7773ff@github.com>
 <fLgoORpLNrQfBdHDAUD5BqD3apwDFR4P_G9gvBDB3Rw=.3263e848-5763-486d-bcc2-ea1ff996d4f1@github.com>
 <tQh9Mvg8BXhOoi6UMLvkJdRHhzQDe2a7dxpQaxCDXTE=.68cc2cbd-8fe8-445b-97f6-0bc2e3fbc518@github.com>
Message-ID: <yQgyTrBNgElXm8Wfhkv9iLGcM4vCkyW9utizPsFvBOc=.e52cc8bf-5537-451c-b6bd-8c24a7cdf28e@github.com>

On Wed, 14 Apr 2021 17:36:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> postVisitDirectory() and visitFile() methods can be potentially called concurrently by walkFileTree()

I don't think they can.

> Javadoc ... doesn't say anything about synchronization, so I think it is fair to assume it is not guaranteed.

Given that the `Files` class says nothing about running its various file walking operations in parallel, I think you can be confident that the visitor methods are only ever run on the same thread that calls walkFileTree. I would consider it a bug if the thread used to callback into the visitor were different from the calling thread.

Still, I think using `AtomicReference` is fine here, so this is a moot point for this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3473

From naoto at openjdk.java.net  Wed Apr 14 18:21:39 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 18:21:39 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v3]
In-Reply-To: <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
Message-ID: <iUjZIPE7jl6ynAxVkX7Em1ZLIwpLz80156uB_M9MAO8=.30e5943f-d743-493d-8729-1bea5ba90be2@github.com>

On Wed, 14 Apr 2021 17:14:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update existing NarrowNamesTest to match expectations
>  - Naoto's review suggestion

Changes requested by naoto (Reviewer).

src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java line 193:

> 191:                             }
> 192:                             if (field == AM_PM && !javatime && i > PM) {
> 193:                                 // when dealing with calendar fields, don't set AM_PM field value

Make it explicit that this block only serves for `java.util.Calendar`, not `java.time.format.DateTimeFormatter(Builder)`.

test/jdk/java/util/Calendar/CalendarDisplayNamesTest.java line 53:

> 51:             for (final int style : styles) {
> 52:                 final Calendar cal = Calendar.getInstance();
> 53:                 cal.setLenient(false);

Don't think leniency is relevant here.

test/jdk/java/util/Calendar/NarrowNamesTest.java line 119:

> 117:             expectedFieldValues.put("a", Calendar.AM);
> 118:             expectedFieldValues.put("p", Calendar.PM);
> 119:             testAM_PM(US, ALL_STYLES, expectedFieldValues);

I believe this can be reverted to the original, as the original code compares the exact map (including the length of the map).  , i.e., 

           testMap(US, AM_PM, ALL_STYLES,
                    "AM", "PM",
                    RESET_INDEX,
                    "a", "p");

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From plevart at openjdk.java.net  Wed Apr 14 19:14:24 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 14 Apr 2021 19:14:24 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved further
Message-ID: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>

While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:

https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce

The comparative results are here:

https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15

The jmh-result.json files are here:

https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15

Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.

So WDYT?

-------------

Commit messages:
 - Make JavaLangAccess JLA field private static final
 - Alternative String.join

Changes: https://git.openjdk.java.net/jdk/pull/3501/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265237
  Stats: 97 lines in 4 files changed: 61 ins; 18 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3501.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3501/head:pull/3501

PR: https://git.openjdk.java.net/jdk/pull/3501

From plevart at openjdk.java.net  Wed Apr 14 19:45:40 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 14 Apr 2021 19:45:40 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved further
In-Reply-To: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
Message-ID: <r6pGAsM4rXg1BZd16tsUI5hDM2m_OA8nMk3pea6ahIQ=.35a8fd2e-e176-4648-97bd-083d98b6a691@github.com>

On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart <plevart at openjdk.org> wrote:

> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
> 
> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
> 
> The comparative results are here:
> 
> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
> 
> The jmh-result.json files are here:
> 
> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
> 
> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
> 
> So WDYT?

Some background: This change was motivated by Sergey Tsypanov's attempt to replace usage of StringBuilder with string concatenation in JDK-8265075 only to find out that string concatenation in java.base module is compiled down to inline usage of StringBuilder, so no improvement was possible.
StringJoiner API and String.join static utility methods lend itself to a better implementation, but in last incarnation they are implemented with StringBuilder internally: String.join -> StringJoiner -> StringBuilder. A lot of JDK internal usages of StringBuilder were already replaced with StringJoiner (JDK-8054714) but under the hood the StringBuilder is still used. There were also lots of incremental attempts to improve StringJoiner. I think this one is the last one for some time to come... :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From github.com+592810+efge at openjdk.java.net  Wed Apr 14 19:57:42 2021
From: github.com+592810+efge at openjdk.java.net (Florent Guillaume)
Date: Wed, 14 Apr 2021 19:57:42 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved further
In-Reply-To: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
Message-ID: <C1wIoN-sX7qrwtsuKOKQ8CUfdBbzAo1c3fw62p2OozQ=.5f5d7b78-a04a-4e68-b391-f4ec907cb4bd@github.com>

On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart <plevart at openjdk.org> wrote:

> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
> 
> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
> 
> The comparative results are here:
> 
> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
> 
> The jmh-result.json files are here:
> 
> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
> 
> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
> 
> So WDYT?

src/java.base/share/classes/java/lang/String.java line 3230:

> 3228: 
> 3229:     /**
> 3230:      * Designated join routine.

Did you mean "dedicated"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From herrick at openjdk.java.net  Wed Apr 14 19:59:37 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 14 Apr 2021 19:59:37 GMT
Subject: Integrated: JDK-8265078: jpackage tests on Windows leave large temp
 files
In-Reply-To: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
References: <hb4D6WNQX5SY-dI5hSHoWHzpHVH4vg8MpdIl7gnx9A4=.57da89b3-1726-47aa-a5a6-d62aa8ca1621@github.com>
Message-ID: <Cynl4DO2yE41siWzYEn_MJg269ATebV04UbUz2EAOMI=.19e195a1-3b2c-4f98-860a-c11df61c5c78@github.com>

On Tue, 13 Apr 2021 18:57:20 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> two changes:
> One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception.
> The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir".  This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits).

This pull request has now been integrated.

Changeset: e1675778
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e1675778
Stats:     30 lines in 3 files changed: 28 ins; 0 del; 2 mod

8265078: jpackage tests on Windows leave large temp files

Reviewed-by: asemenyuk, kcr

-------------

PR: https://git.openjdk.java.net/jdk/pull/3473

From redestad at openjdk.java.net  Wed Apr 14 20:06:38 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Apr 2021 20:06:38 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved further
In-Reply-To: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
Message-ID: <5lcL44Q8ptrdLGm9T6OhAUfK9Qf3qr-3APVax-LNAfM=.3d7d6f77-501b-4374-b414-f7992ba9edef@github.com>

On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart <plevart at openjdk.org> wrote:

> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
> 
> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
> 
> The comparative results are here:
> 
> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
> 
> The jmh-result.json files are here:
> 
> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
> 
> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
> 
> So WDYT?

I think this seems reasonable. The String encoding details doesn't leak outside of java.lang, and numbers do look convincing.

There's a StringJoinerBenchmark micro added by JDK-8148937 which could perhaps be expanded with the scenarios you've experimented with here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From naoto at openjdk.java.net  Wed Apr 14 21:21:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 21:21:10 GMT
Subject: RFR: 8258794: Support for CLDR version 39
Message-ID: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>

Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

-------------

Commit messages:
 - 8258794: Support for CLDR version 39
 - CLDR 38.1

Changes: https://git.openjdk.java.net/jdk/pull/3502/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3502&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258794
  Stats: 26326 lines in 815 files changed: 761 ins; 23140 del; 2425 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3502.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3502/head:pull/3502

PR: https://git.openjdk.java.net/jdk/pull/3502

From redestad at openjdk.java.net  Wed Apr 14 21:26:52 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Apr 2021 21:26:52 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms [v5]
In-Reply-To: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
Message-ID: <ZpNBhw2mHzECAK_v7CXNHY1SEz6J7gKZXx-a7FQVpw4=.c242e98f-c465-4c65-b24c-292ef3a97875@github.com>

> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
> 
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
> 
> Net effect is a reduction in bytecode executed per VH class by 50-60%.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add resolveOrNull for exploded MemberName

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3472/files
  - new: https://git.openjdk.java.net/jdk/pull/3472/files/f84f5194..1c2208c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3472&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3472&range=03-04

  Stats: 24 lines in 2 files changed: 13 ins; 7 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3472/head:pull/3472

PR: https://git.openjdk.java.net/jdk/pull/3472

From joehw at openjdk.java.net  Wed Apr 14 21:54:43 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 14 Apr 2021 21:54:43 GMT
Subject: RFR: 8258794: Support for CLDR version 39
In-Reply-To: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
References: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
Message-ID: <dVqVOfj97RMC84t7-YM1oLv7_urFf0RndlAHGgPRItQ=.1a4e2333-98c4-4e89-927f-59083dc88c36@github.com>

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

Naoto, are you testing GitHub ('s ability to handle a large number of files) ;-)

Indeed, the majority changes were version and copyright. If you hadn't mentioned the changed class, it would be almost impossible to find it :-)

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3502

From naoto at openjdk.java.net  Wed Apr 14 22:01:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 22:01:40 GMT
Subject: RFR: 8258794: Support for CLDR version 39
In-Reply-To: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
References: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
Message-ID: <J4PLvADNaDPY-haDWW90tPTfI9tWJcapaowlhP9ZYi8=.0f98db23-5d04-4181-a282-e7cbe4bae425@github.com>

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

Thanks, Joe.

> Naoto, are you testing GitHub ('s ability to handle a large number of files) ;-)

CLDR itself has been hosted on GitHub too, so it shouldn't be a problem ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/3502

From plevart at openjdk.java.net  Wed Apr 14 22:26:39 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 14 Apr 2021 22:26:39 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved further
In-Reply-To: <C1wIoN-sX7qrwtsuKOKQ8CUfdBbzAo1c3fw62p2OozQ=.5f5d7b78-a04a-4e68-b391-f4ec907cb4bd@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <C1wIoN-sX7qrwtsuKOKQ8CUfdBbzAo1c3fw62p2OozQ=.5f5d7b78-a04a-4e68-b391-f4ec907cb4bd@github.com>
Message-ID: <cJNn8kft1tAWKgfwQDTJUDenFz1szQdUXTZlNDdl6Ao=.2c1cd1f1-85fd-444d-bb70-962c7877cdd3@github.com>

On Wed, 14 Apr 2021 19:54:26 GMT, Florent Guillaume <github.com+592810+efge at openjdk.org> wrote:

>> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
>> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
>> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
>> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
>> 
>> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
>> 
>> The comparative results are here:
>> 
>> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
>> 
>> The jmh-result.json files are here:
>> 
>> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
>> 
>> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
>> 
>> So WDYT?
>
> src/java.base/share/classes/java/lang/String.java line 3230:
> 
>> 3228: 
>> 3229:     /**
>> 3230:      * Designated join routine.
> 
> Did you mean "dedicated"?

No, I meant designated. It is the routine that all other public API entry points call at the end to do the job. Would some other word more accurately describe that? I definitely didn't mean "dedicated".

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From erikj at openjdk.java.net  Wed Apr 14 22:30:13 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 14 Apr 2021 22:30:13 GMT
Subject: RFR: 8258794: Support for CLDR version 39
In-Reply-To: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
References: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
Message-ID: <5HWDRokYdhdJciJWcGWySJoDe7dTxtIX4nzLA1he1eY=.f67d81f3-8d2d-443a-9f1f-09d5133953fe@github.com>

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3502

From mchung at openjdk.java.net  Wed Apr 14 22:47:35 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 14 Apr 2021 22:47:35 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms [v5]
In-Reply-To: <ZpNBhw2mHzECAK_v7CXNHY1SEz6J7gKZXx-a7FQVpw4=.c242e98f-c465-4c65-b24c-292ef3a97875@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
 <ZpNBhw2mHzECAK_v7CXNHY1SEz6J7gKZXx-a7FQVpw4=.c242e98f-c465-4c65-b24c-292ef3a97875@github.com>
Message-ID: <YqKnAKbNnVGFNhYzhq3rhIBGnRPUZN77AEcCQK40uOM=.85714ef4-116c-456d-87bb-5ba5a3e8e78b@github.com>

On Wed, 14 Apr 2021 21:26:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
>> 
>> - Lazily resolve MemberNames.
>> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
>> 
>> Net effect is a reduction in bytecode executed per VH class by 50-60%.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add resolveOrNull for exploded MemberName

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3472

From mchung at openjdk.java.net  Wed Apr 14 23:01:38 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 14 Apr 2021 23:01:38 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching [v3]
In-Reply-To: <8YiE6q8ttulbS9HkRmp6YyGgm4yCssfVcMgUASKaIME=.06050e95-3fe0-4456-a4fd-74435be1ac60@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
 <8YiE6q8ttulbS9HkRmp6YyGgm4yCssfVcMgUASKaIME=.06050e95-3fe0-4456-a4fd-74435be1ac60@github.com>
Message-ID: <XD2RSANCtS6j2s1ZP5M3No17N2rc-RaWnmRjSIaPzzE=.f5f47756-8093-42f7-891a-edabdd80ad09@github.com>

On Wed, 14 Apr 2021 11:38:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
>> 
>> This piggybacks on the existing mechanism for method handle invoker caching.
>> 
>> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: simplify test

Marked as reviewed by mchung (Reviewer).

test/jdk/java/lang/invoke/TestVHInvokerCaching.java line 26:

> 24: /* @test
> 25:  * @bug 8265079
> 26:  * @run testng/othervm -Xverify:all -ea -esa TestVHInvokerCaching

Nit: the makefile to run jtreg set `-ea -esa`.   It's not strictly necessary in `@run`.  If you want to run it standalone, you can run with `jtreg -ea -esa` option.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3439

From dalibor.topic at oracle.com  Thu Apr 15 01:20:01 2021
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Thu, 15 Apr 2021 03:20:01 +0200
Subject: Garbage Free Check
In-Reply-To: <15EF4F44-B64E-4B93-BB35-088541798819@dslextreme.com>
References: <E311AAA3-F5D2-4603-A291-8F544E4E269B@dslextreme.com>
 <cbab707a-16be-8482-9781-6baa7ddedc85@oracle.com>
 <5218e240-2f42-54da-5d6e-b26918040503@oracle.com>
 <15EF4F44-B64E-4B93-BB35-088541798819@dslextreme.com>
Message-ID: <7fc49983-cc1d-37b2-6667-c66dd1a9c5dd@oracle.com>

Hi Ralph,

I've added an apache-log4j-interest label to the issue.

cheers,
dalibor topic

On 14.04.2021 19:00, Ralph Goers wrote:
> I don?t have an account in the bug tracking system. Could someone possibly update the issue noted below to indicate that Apache Log4j 2 would also like that enhancement?
> 
> Thanks,
> 
> Ralph
> 
>> On Apr 5, 2021, at 1:26 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>
>> Hi,
>>
>> Java does not have a data type with enough resolution to hold a full nanosecond value.
>> Hence the implementation of Instant holding seconds and nanos.
>>
>> There is an long dormant enhancement request to return micro-seconds as a long.
>> 8196003 <https://bugs.openjdk.java.net/browse/JDK-8196003> java.time Instant and Duration methods for microseconds
>>
>> That might be useful if the application gets enough resolution from microseconds.
>> There might be some clever interpolation between System.currentTimeMillis()
>> and adjusting with System.nanoTime().
>> Though it would likely not be exactly synchronized with the values from Instant.
>>
>> Regards, Roger
>>
>>
>> On 4/5/21 3:56 PM, Brian Goetz wrote:
>>> Project Valhalla will allow Instant to be migrated to a primitive class, which would address your problem.
>>>
>>> On 4/2/2021 7:47 PM, Ralph Goers wrote:
>>>> Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant.
>>>>
>>>> The code we have simply does
>>>>
>>>> public void init(MutableInstant mutableInstant) {
>>>>       Instant instant = java.time.Clock.systemUTC().instant();
>>>> mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano());
>>>> }
>>>> In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case.
>>>> Ideally we would really like something like
>>>>
>>>> public void init(MutableInstant mutableInstant) {
>>>>          java.time.Clock.systemUTC().initInstant(mutableInstant);
>>>> }
>>>>
>>>> where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object.
>>>>
>>>> This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation.
>>>>
>>>> Do you know of another way to do this? Am I missing something?
>>>>
>>>> Ralph
>>>
>>
>>
> 
> 

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>, Video: dalibor.topic at oracle.com
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From almatvee at openjdk.java.net  Thu Apr 15 01:29:57 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 15 Apr 2021 01:29:57 GMT
Subject: RFR: 8263154: [macos] DMG builds have finder errors
Message-ID: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>

- Issue was reproducible when install-dir points to some invalid location.
 - Fixed by defaulting DMG drag and drop location to /Applications folder and --install-dir will be ignored with warning for DMG.
 - I do not see any way to support other valid, but uncommon locations for drag and drop. For example: /Users/USERNAME/Applications is not possible to support since user name is not known. /usr/bin requires root privileges and should contain symbolic links. Locations which does not exist also not possible to support, since DMG cannot create paths. So /Applications/MyCompany is not possible for DMG.

-------------

Commit messages:
 - 8263154: [macos] DMG builds have finder errors

Changes: https://git.openjdk.java.net/jdk/pull/3505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3505&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263154
  Stats: 18 lines in 6 files changed: 7 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3505/head:pull/3505

PR: https://git.openjdk.java.net/jdk/pull/3505

From jpai at openjdk.java.net  Thu Apr 15 01:57:01 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 15 Apr 2021 01:57:01 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v4]
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - update existing testcase based on review comment
 - Improve code comment to be clear it's only applicable for java.util.Calendar
 - Remove irrelevant setLenient from new testcase

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3463/files
  - new: https://git.openjdk.java.net/jdk/pull/3463/files/e7194733..607776b3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=02-03

  Stats: 9 lines in 3 files changed: 1 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3463/head:pull/3463

PR: https://git.openjdk.java.net/jdk/pull/3463

From jpai at openjdk.java.net  Thu Apr 15 01:57:03 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 15 Apr 2021 01:57:03 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v3]
In-Reply-To: <iUjZIPE7jl6ynAxVkX7Em1ZLIwpLz80156uB_M9MAO8=.30e5943f-d743-493d-8729-1bea5ba90be2@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
 <iUjZIPE7jl6ynAxVkX7Em1ZLIwpLz80156uB_M9MAO8=.30e5943f-d743-493d-8729-1bea5ba90be2@github.com>
Message-ID: <hRZPlfHktC4SIXpiE874R96FVgfIneIp7DHRCAaGEsM=.bcf8cd86-4a6b-4c96-b931-5fe715dcc62e@github.com>

On Wed, 14 Apr 2021 18:01:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update existing NarrowNamesTest to match expectations
>>  - Naoto's review suggestion
>
> src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java line 193:
> 
>> 191:                             }
>> 192:                             if (field == AM_PM && !javatime && i > PM) {
>> 193:                                 // when dealing with calendar fields, don't set AM_PM field value
> 
> Make it explicit that this block only serves for `java.util.Calendar`, not `java.time.format.DateTimeFormatter(Builder)`.

Hello Naoto, I've now updated the PR to be more explicit in this code comment.

> test/jdk/java/util/Calendar/CalendarDisplayNamesTest.java line 53:
> 
>> 51:             for (final int style : styles) {
>> 52:                 final Calendar cal = Calendar.getInstance();
>> 53:                 cal.setLenient(false);
> 
> Don't think leniency is relevant here.

Removed in the latest update of this PR. This was a leftover from my experimental testing.

> test/jdk/java/util/Calendar/NarrowNamesTest.java line 119:
> 
>> 117:             expectedFieldValues.put("a", Calendar.AM);
>> 118:             expectedFieldValues.put("p", Calendar.PM);
>> 119:             testAM_PM(US, ALL_STYLES, expectedFieldValues);
> 
> I believe this can be reverted to the original, as the original code compares the exact map (including the length of the map).  , i.e., 
> 
>            testMap(US, AM_PM, ALL_STYLES,
>                     "AM", "PM",
>                     RESET_INDEX,
>                     "a", "p");

Done. Reverted this specific part to what it was originally. Test continues to pass with this change and the latest PR update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From naoto at openjdk.java.net  Thu Apr 15 04:00:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 15 Apr 2021 04:00:35 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v4]
In-Reply-To: <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
Message-ID: <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>

On Thu, 15 Apr 2021 01:57:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update existing testcase based on review comment
>  - Improve code comment to be clear it's only applicable for java.util.Calendar
>  - Remove irrelevant setLenient from new testcase

Changes requested by naoto (Reviewer).

test/jdk/java/util/Calendar/NarrowNamesTest.java line 115:

> 113:         } else {
> 114:             testMap(US, AM_PM, ALL_STYLES,
> 115:                     "AM", "PM",

What I meant was there is no need to check the providers and introduce the am/pm specific test method. Both `CLDR` and `COMPAT` (i.e., no "if" statement) should be tested with `testMap()` method as other tests do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From dholmes at openjdk.java.net  Thu Apr 15 05:20:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 15 Apr 2021 05:20:32 GMT
Subject: RFR: 8265173: [test] divert spurious log output away from stream
 under test in ProcessBuilder Basic test
In-Reply-To: <FBD5K-n8B-61e9DPHxhcPz9g_saiHrepEIvpP_3IFg0=.af1b3e51-aa1a-4712-982c-594827b2fb11@github.com>
References: <FBD5K-n8B-61e9DPHxhcPz9g_saiHrepEIvpP_3IFg0=.af1b3e51-aa1a-4712-982c-594827b2fb11@github.com>
Message-ID: <K0fMag4iuRLwVyAUvInQYjL6-0CHko95z2umNHCMRXY=.d7fb37e4-bf31-45e6-9201-ddd31b950fdd@github.com>

On Wed, 14 Apr 2021 14:08:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The most recent intermittent failure showed that the error occurred during VM initialization.
> Only the tty output was diverted, but not log output.
> Add diversion of log output as well tty output.
> 
> Add `-Xlog:all=warning:stderr` and `-Xlog:all=warning:stdout` to correspond to 
> `-XX:+DisplayVMOutputToStderr` and `-XX:+DisplayVMOutputToStdout`

Hi Roger,

The fix looks good, but it strikes me that any test using -XX:+DisplayVMOutputToXXX can potentially suffer from a similar problem e.g. (in this space):

test/jdk/java/lang/ProcessHandle/JavaChild.java

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3492

From sergei.tsypanov at yandex.ru  Thu Apr 15 07:33:12 2021
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Thu, 15 Apr 2021 09:33:12 +0200
Subject: Enhancement proposal regarding bufferization of InputStream
Message-ID: <37788811618471992@myt6-aaa7a2dc5b3e.qloud-c.yandex.net>

Hello,

buffering with j.i.BufferedInputStream is a handy way to improve performance of IO operations.
However in many cases buffering is redundant. Consider this code snippet from Spring Framework:

static ClassReader getClassReader(Resource rsc) throws Exception {
 try (var is = new BufferedInputStream(rsc.getInputStream())) {
   return new ClassReader(is);
 }
}

Interface Resource has lots of implementations some of them return buffered InputStream,
others don't, but all of them get wrapped with BufferedInputStream.

Apart from obvious misuses like BufferedInputStream cascade such wrapping is not necessary,
e.g. when we read a huge file using FileInputStream.readAllBytes(),
in others cases it's harmful e.g. when we read a small (comparing to the default 
size of buffer in BufferedInputStream) file with readAllBytes() or
when we read from ByteArrayInputStream which is kind of buffered one by its nature.

I think an instance of InputStream should decide itself whether it requires buffering,
so I suggest to add a couple of methods into j.i.InputStream:

// subclasses can override this
protected boolean needsBuffer() {
 return true;
}

public InputStream buffered() {
 return needsBuffer() ? new BufferedInputStream(this) : this;
}

this allows subclasses of InputStream to override needsBuffer() to declare buffering redundancy.
Let's imagine we've overridden needsBuffer() in BufferedInputStream:

public class BufferedInputStream {
 @Override
 public boolean needsBuffer() {
   return true;
 }
}

then the code we've mentioned above should be rewritten as

static ClassReader getClassReader(Resource rsc) throws Exception {
 try (var is = rsc.getInputStream().buffered()) {
   return new ClassReader(is);
 }
}

preventing cascade of BufferedInputStreams.

There are also cases when the need for buffering depends on the way how we read from InputStream:

new FileInputStream(file).buffered().readAllBytes() // buffering is redundant

var data = new DataInputStream(new FileInputStream(file).buffered())
for (int i = 0; i < 1000; i++) {
  data.readInt();                          // readInt() does 4 calls to InputStream.read() so buffering is needed
}

here if FileInputStream.needsBuffer() is overridden and returns false (assuming most of reads from it are bulk)
then we won't have buffering for DataInputStream. To avoid this we can also
add InputStream.buffered(boolean enforceBuffering) to have manual control.

To sum up, my proposal is to add those methods to InputStream:

protected static boolean needsBuffer() {
 return true;
}

public InputStream buffered() {
 return buffered(needsBuffer());
}

public InputStream buffered(boolean enforceBuffering) {
 return enforceBuffering ? new BufferedInputStream(this) : this;
}

What do you think?

With best regards,
Sergey Tsypanov

From pavel.rappo at oracle.com  Thu Apr 15 11:08:19 2021
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 15 Apr 2021 11:08:19 +0000
Subject: Enhancement proposal regarding bufferization of InputStream
In-Reply-To: <37788811618471992@myt6-aaa7a2dc5b3e.qloud-c.yandex.net>
References: <37788811618471992@myt6-aaa7a2dc5b3e.qloud-c.yandex.net>
Message-ID: <B3F21DD1-1265-4F7C-8EB5-F9A6F1015FB0@oracle.com>


> On 15 Apr 2021, at 08:33, ?????? ??????? <sergei.tsypanov at yandex.ru> wrote:
> 
> Hello,
> 
> buffering with j.i.BufferedInputStream is a handy way to improve performance of IO operations.
> However in many cases buffering is redundant. Consider this code snippet from Spring Framework:
> 
> static ClassReader getClassReader(Resource rsc) throws Exception {
> try (var is = new BufferedInputStream(rsc.getInputStream())) {
>   return new ClassReader(is);
> }
> }
> 
> Interface Resource has lots of implementations some of them return buffered InputStream,
> others don't, but all of them get wrapped with BufferedInputStream.
> 
> Apart from obvious misuses like BufferedInputStream cascade such wrapping is not necessary,
> e.g. when we read a huge file using FileInputStream.readAllBytes(),
> in others cases it's harmful e.g. when we read a small (comparing to the default 
> size of buffer in BufferedInputStream) file with readAllBytes() or
> when we read from ByteArrayInputStream which is kind of buffered one by its nature.
> 
> I think an instance of InputStream should decide itself whether it requires buffering,
> so I suggest to add a couple of methods into j.i.InputStream:
> 
> // subclasses can override this
> protected boolean needsBuffer() {
> return true;
> }
> 
> public InputStream buffered() {
> return needsBuffer() ? new BufferedInputStream(this) : this;
> }
> 
> this allows subclasses of InputStream to override needsBuffer() to declare buffering redundancy.
> Let's imagine we've overridden needsBuffer() in BufferedInputStream:
> 
> public class BufferedInputStream {
> @Override
> public boolean needsBuffer() {
>   return true;
> }
> }
> 
> then the code we've mentioned above should be rewritten as
> 
> static ClassReader getClassReader(Resource rsc) throws Exception {
> try (var is = rsc.getInputStream().buffered()) {
>   return new ClassReader(is);
> }
> }
> 
> preventing cascade of BufferedInputStreams.
> 

When I read this part

> There are also cases when the need for buffering depends on the way how we read from InputStream:
> 
> new FileInputStream(file).buffered().readAllBytes() // buffering is redundant

my knee-jerk reaction was that a better solution likely lies with introducing a marker interface and selectively implementing it as opposed to adding two new methods to the existing class and selectively overriding them. Let's call this interface java.io.Buffered: Bufferred is to InputStream as RandomAccess is to List.

Just to be clear: I'm not proposing to actually do this. It's just a thought.

-Pavel

> var data = new DataInputStream(new FileInputStream(file).buffered())
> for (int i = 0; i < 1000; i++) {
>  data.readInt();                          // readInt() does 4 calls to InputStream.read() so buffering is needed
> }
> 
> here if FileInputStream.needsBuffer() is overridden and returns false (assuming most of reads from it are bulk)
> then we won't have buffering for DataInputStream. To avoid this we can also
> add InputStream.buffered(boolean enforceBuffering) to have manual control.
> 
> To sum up, my proposal is to add those methods to InputStream:
> 
> protected static boolean needsBuffer() {
> return true;
> }
> 
> public InputStream buffered() {
> return buffered(needsBuffer());
> }
> 
> public InputStream buffered(boolean enforceBuffering) {
> return enforceBuffering ? new BufferedInputStream(this) : this;
> }
> 
> What do you think?
> 
> With best regards,
> Sergey Tsypanov


From github.com+592810+efge at openjdk.java.net  Thu Apr 15 11:24:36 2021
From: github.com+592810+efge at openjdk.java.net (Florent Guillaume)
Date: Thu, 15 Apr 2021 11:24:36 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved further
In-Reply-To: <cJNn8kft1tAWKgfwQDTJUDenFz1szQdUXTZlNDdl6Ao=.2c1cd1f1-85fd-444d-bb70-962c7877cdd3@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <C1wIoN-sX7qrwtsuKOKQ8CUfdBbzAo1c3fw62p2OozQ=.5f5d7b78-a04a-4e68-b391-f4ec907cb4bd@github.com>
 <cJNn8kft1tAWKgfwQDTJUDenFz1szQdUXTZlNDdl6Ao=.2c1cd1f1-85fd-444d-bb70-962c7877cdd3@github.com>
Message-ID: <NTFITsxWQ7XNdswvMuxyAH-6rut6MK180vIN5j2Kb7w=.49e06f0c-25a0-4788-b6e2-e92379b16c05@github.com>

On Wed, 14 Apr 2021 22:23:57 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 3230:
>> 
>>> 3228: 
>>> 3229:     /**
>>> 3230:      * Designated join routine.
>> 
>> Did you mean "dedicated"?
>
> No, I meant designated. It is the routine that all other public API entry points call at the end to do the job. Would some other word more accurately describe that? I definitely didn't mean "dedicated".

Oh then sorry, I thought it was a typo of some sort. I'd have said something like "Centralized join logic". But whatever works for you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From jlaskey at openjdk.java.net  Thu Apr 15 12:01:07 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 15 Apr 2021 12:01:07 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v4]
In-Reply-To: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
Message-ID: <RWHOu929wlgVn5zDszU0aWj551fI6s_NpjP7Svc-2VQ=.200daabd-046d-43a0-a402-a08f0a87683e@github.com>

> Move makeXXXSpilterator from public (@hidden) to protected. No API ch

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Move makeXXXSpliterator methods to RandomSupport

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3469/files
  - new: https://git.openjdk.java.net/jdk/pull/3469/files/c6b5da30..0094c43a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=02-03

  Stats: 87 lines in 2 files changed: 40 ins; 44 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3469.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469

PR: https://git.openjdk.java.net/jdk/pull/3469

From uschindler at openjdk.java.net  Thu Apr 15 12:14:39 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Thu, 15 Apr 2021 12:14:39 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v4]
In-Reply-To: <RWHOu929wlgVn5zDszU0aWj551fI6s_NpjP7Svc-2VQ=.200daabd-046d-43a0-a402-a08f0a87683e@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <RWHOu929wlgVn5zDszU0aWj551fI6s_NpjP7Svc-2VQ=.200daabd-046d-43a0-a402-a08f0a87683e@github.com>
Message-ID: <IeR3O6gCBBZJzm5I6ISgSnQp_JqEC27Uf0IcAlPl4qQ=.d7169c52-c9ac-4f43-ab79-dcbe6c62de95@github.com>

On Thu, 15 Apr 2021 12:01:07 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move makeXXXSpliterator methods to RandomSupport

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1656:

> 1654:         // Methods required by class AbstractSpliteratorGenerator
> 1655: 
> 1656:         protected Spliterator.OfInt makeIntsSpliterator(long index, long fence, int origin, int bound) {

Are those still needed? It looks like because of the missing `@Override` those could also be private?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From jlaskey at openjdk.java.net  Thu Apr 15 12:20:44 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 15 Apr 2021 12:20:44 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v4]
In-Reply-To: <IeR3O6gCBBZJzm5I6ISgSnQp_JqEC27Uf0IcAlPl4qQ=.d7169c52-c9ac-4f43-ab79-dcbe6c62de95@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <RWHOu929wlgVn5zDszU0aWj551fI6s_NpjP7Svc-2VQ=.200daabd-046d-43a0-a402-a08f0a87683e@github.com>
 <IeR3O6gCBBZJzm5I6ISgSnQp_JqEC27Uf0IcAlPl4qQ=.d7169c52-c9ac-4f43-ab79-dcbe6c62de95@github.com>
Message-ID: <8WMeTb7egLgmwoimo7VTgEYJhUrOo4oJHawc8lH7nmA=.cd93c13b-140b-429e-8388-d352ee3510fb@github.com>

On Thu, 15 Apr 2021 12:11:56 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move makeXXXSpliterator methods to RandomSupport
>
> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1656:
> 
>> 1654:         // Methods required by class AbstractSpliteratorGenerator
>> 1655: 
>> 1656:         protected Spliterator.OfInt makeIntsSpliterator(long index, long fence, int origin, int bound) {
> 
> Are those still needed? It looks like this was not detected because of the missing `@Override`. Those could also be private or removed at all? The code is also handled by the above private versions (`this` is not instanceof `ThreadLocalRandom`).

True that. There are also some mentions in the comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From lzang at openjdk.java.net  Thu Apr 15 12:28:13 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 15 Apr 2021 12:28:13 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v5]
In-Reply-To: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
Message-ID: <q1Hbmi1Xi-hFHeoyYiukn_D4CBJ92r0maNaMx1-3QfA=.34bfa268-732e-49ac-8d4e-6559432844e3@github.com>

> 4890732: GZIPOutputStream doesn't support optional GZIP fields

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  Use record and Builder pattern

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3072/files
  - new: https://git.openjdk.java.net/jdk/pull/3072/files/03b3e966..35eb55eb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=03-04

  Stats: 692 lines in 4 files changed: 363 ins; 323 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

PR: https://git.openjdk.java.net/jdk/pull/3072

From lzang at openjdk.java.net  Thu Apr 15 12:33:41 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 15 Apr 2021 12:33:41 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v3]
In-Reply-To: <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
Message-ID: <ujwZrgs6geX2mUiU9dC-TY5IoxdicO7Ja8xudXLl9Ac=.ec800808-ade7-4550-bd4b-4447a30dba79@github.com>

On Wed, 24 Mar 2021 10:25:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyright
>>  - reuse arguments constructor for non-argument one.
>
> Hi Lin,
> 
> On Mar 24, 2021, at 2:51 AM, Lin Zang ***@***.******@***.***>> wrote:
> 
> 
> 
> Hi Lance?
> Thanks a lot for your review. I will update the PR ASAP.
> May I ask your help to also review the CSR?
> 
> I believe we need to flush out some of the issues I raised that were not test related as they will result in updates to the javadoc which will require an update to the CSR.
> 
> 
> 
> Thanks!
> 
> BRs,
> Lin
> 
> ?
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/3072#issuecomment-805549600>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABQPFO5R4INTAUFZ3QS6WL3TFGDXHANCNFSM4ZMLU6SA>.
> 
> ***@***.***
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> ***@***.******@***.***>

Dear @LanceAndersen, 
Thanks a lot for your guidance, I have updated a commit that use record and builder pattern. 
In summary it creates a class named `GZIPHeaderBuilder`, and a **recor**d named `GZIPHeaderData`. 

The `GZIPHeaderData` **record** holds the header `flags`, `extra field`, `file name`, `file comments`, `header crc` and a byte array that contains the generated header data. 

The `GZIPHeaderBuilder` is mainly used for generating the `GZIPHeaderData`.  

User could set `optional gzip header fields` by calling different api like `withFileName()` of `GZIPHeaderBuilder` and generate the `GZIPHeaderData` finally by calling build().

Would you like to help review whether this update looks better?

Thanks,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From jlaskey at openjdk.java.net  Thu Apr 15 12:37:52 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 15 Apr 2021 12:37:52 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v5]
In-Reply-To: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
Message-ID: <i_M9vZiz7Ltzz0lOw3XzbRJK4wH7i93f7WJ7tfE3voM=.cd098431-31b8-46cc-ba21-ca4d1675f5ef@github.com>

> Move makeXXXSpilterator from public (@hidden) to protected. No API ch

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove extraneous references to makeXXXSpliterator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3469/files
  - new: https://git.openjdk.java.net/jdk/pull/3469/files/0094c43a..d72575d5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=03-04

  Stats: 32 lines in 1 file changed: 0 ins; 31 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3469.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469

PR: https://git.openjdk.java.net/jdk/pull/3469

From lzang at openjdk.java.net  Thu Apr 15 12:41:17 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 15 Apr 2021 12:41:17 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v6]
In-Reply-To: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
Message-ID: <EIq06Sr2HC72GyP_n1zQtPjGQ-FMSwTQteonPK39IsQ=.ede214cb-15c6-4cfa-ab09-174894c88e5c@github.com>

> 4890732: GZIPOutputStream doesn't support optional GZIP fields

Lin Zang 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 ten additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into gzip-field
 - remove trailing spaces
 - Use record and Builder pattern
 - add class GZIPHeaderData, refine testcases
 - update copyright
 - reuse arguments constructor for non-argument one.
 - add test case
 - remove trailing spaces
 - 4890732: support optional GZIP fields in GZIPOutputStream

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3072/files
  - new: https://git.openjdk.java.net/jdk/pull/3072/files/35eb55eb..24c1b45f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=04-05

  Stats: 78610 lines in 2885 files changed: 49815 ins; 18293 del; 10502 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

PR: https://git.openjdk.java.net/jdk/pull/3072

From jlaskey at openjdk.java.net  Thu Apr 15 12:59:55 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 15 Apr 2021 12:59:55 GMT
Subject: RFR: 8265279: Remove unused RandomGeneratorFactory.all(Class<T>
 category)
Message-ID: <D2pi0ttI4hIuJE51pgBE1Usg0dC6SE0kHM0wVl4nol4=.0dafd200-2aee-480b-8852-18a776c33e64@github.com>

No longer needed

-------------

Commit messages:
 - RandomGeneratorFactory.all(Class<T> category) no longer needed
 - Remove extraneous references to makeXXXSpliterator
 - Move makeXXXSpliterator methods to RandomSupport
 - change static final from 'proxy' to 'PROXY'
 - Make makeXXXSpliterator final
 - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

Changes: https://git.openjdk.java.net/jdk/pull/3516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3516&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265279
  Stats: 229 lines in 5 files changed: 19 ins; 184 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3516/head:pull/3516

PR: https://git.openjdk.java.net/jdk/pull/3516

From roger.riggs at oracle.com  Thu Apr 15 13:51:04 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 15 Apr 2021 09:51:04 -0400
Subject: Enhancement proposal regarding bufferization of InputStream
In-Reply-To: <B3F21DD1-1265-4F7C-8EB5-F9A6F1015FB0@oracle.com>
References: <37788811618471992@myt6-aaa7a2dc5b3e.qloud-c.yandex.net>
 <B3F21DD1-1265-4F7C-8EB5-F9A6F1015FB0@oracle.com>
Message-ID: <502b0914-fc32-8d00-417c-41e4e5d1faaa@oracle.com>

Hi Sergey,

Are you taking into account that for many reads the data is not copied 
into the local buffer.
See the comments in BufferedInputStream.read1: 277:280?

How much is the slowdown, when BufferedInputStreams are chained?

Thanks, Roger

On 4/15/21 7:08 AM, Pavel Rappo wrote:
>> On 15 Apr 2021, at 08:33, ?????? ??????? <sergei.tsypanov at yandex.ru> wrote:
>>
>> Hello,
>>
>> buffering with j.i.BufferedInputStream is a handy way to improve performance of IO operations.
>> However in many cases buffering is redundant. Consider this code snippet from Spring Framework:
>>
>> static ClassReader getClassReader(Resource rsc) throws Exception {
>> try (var is = new BufferedInputStream(rsc.getInputStream())) {
>>    return new ClassReader(is);
>> }
>> }
>>
>> Interface Resource has lots of implementations some of them return buffered InputStream,
>> others don't, but all of them get wrapped with BufferedInputStream.
>>
>> Apart from obvious misuses like BufferedInputStream cascade such wrapping is not necessary,
>> e.g. when we read a huge file using FileInputStream.readAllBytes(),
>> in others cases it's harmful e.g. when we read a small (comparing to the default
>> size of buffer in BufferedInputStream) file with readAllBytes() or
>> when we read from ByteArrayInputStream which is kind of buffered one by its nature.
>>
>> I think an instance of InputStream should decide itself whether it requires buffering,
>> so I suggest to add a couple of methods into j.i.InputStream:
>>
>> // subclasses can override this
>> protected boolean needsBuffer() {
>> return true;
>> }
>>
>> public InputStream buffered() {
>> return needsBuffer() ? new BufferedInputStream(this) : this;
>> }
>>
>> this allows subclasses of InputStream to override needsBuffer() to declare buffering redundancy.
>> Let's imagine we've overridden needsBuffer() in BufferedInputStream:
>>
>> public class BufferedInputStream {
>> @Override
>> public boolean needsBuffer() {
>>    return true;
>> }
>> }
>>
>> then the code we've mentioned above should be rewritten as
>>
>> static ClassReader getClassReader(Resource rsc) throws Exception {
>> try (var is = rsc.getInputStream().buffered()) {
>>    return new ClassReader(is);
>> }
>> }
>>
>> preventing cascade of BufferedInputStreams.
>>
> When I read this part
>
>> There are also cases when the need for buffering depends on the way how we read from InputStream:
>>
>> new FileInputStream(file).buffered().readAllBytes() // buffering is redundant
> my knee-jerk reaction was that a better solution likely lies with introducing a marker interface and selectively implementing it as opposed to adding two new methods to the existing class and selectively overriding them. Let's call this interface java.io.Buffered: Bufferred is to InputStream as RandomAccess is to List.
>
> Just to be clear: I'm not proposing to actually do this. It's just a thought.
>
> -Pavel
>
>> var data = new DataInputStream(new FileInputStream(file).buffered())
>> for (int i = 0; i < 1000; i++) {
>>   data.readInt();                          // readInt() does 4 calls to InputStream.read() so buffering is needed
>> }
>>
>> here if FileInputStream.needsBuffer() is overridden and returns false (assuming most of reads from it are bulk)
>> then we won't have buffering for DataInputStream. To avoid this we can also
>> add InputStream.buffered(boolean enforceBuffering) to have manual control.
>>
>> To sum up, my proposal is to add those methods to InputStream:
>>
>> protected static boolean needsBuffer() {
>> return true;
>> }
>>
>> public InputStream buffered() {
>> return buffered(needsBuffer());
>> }
>>
>> public InputStream buffered(boolean enforceBuffering) {
>> return enforceBuffering ? new BufferedInputStream(this) : this;
>> }
>>
>> What do you think?
>>
>> With best regards,
>> Sergey Tsypanov


From ccleary at openjdk.java.net  Thu Apr 15 14:11:35 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 15 Apr 2021 14:11:35 GMT
Subject: Integrated: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI
In-Reply-To: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
Message-ID: <MoKLExQdB7U1mioTLUTRGNO17GzTK58bXs4WpCEQ-Kc=.cbe33edf-d946-497f-8155-4202abe7aa7b@github.com>

On Fri, 9 Apr 2021 13:15:16 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> ### Description
> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.
> 
> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.
> 
> ### Fixes
> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.

This pull request has now been integrated.

Changeset: 4e90d740
Author:    Conor Cleary <ccleary at openjdk.org>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4e90d740
Stats:     84 lines in 5 files changed: 0 ins; 48 del; 36 mod

8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI

Reviewed-by: rriggs, dfuchs, aefimov, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/3416

From alanb at openjdk.java.net  Thu Apr 15 14:29:35 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 15 Apr 2021 14:29:35 GMT
Subject: RFR: 8264208: Console charset API [v8]
In-Reply-To: <nyFumoILMAmxH1N4n-S18tzvKKFiEjJKFZpnjs5mgPI=.525f4ef4-fe1f-4dec-8995-d07129807db5@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <nyFumoILMAmxH1N4n-S18tzvKKFiEjJKFZpnjs5mgPI=.525f4ef4-fe1f-4dec-8995-d07129807db5@github.com>
Message-ID: <tWW7zZ0lCWi3y-AVSaRts6gOfBts8hdPpoTkWHV5lKE=.10c733cc-0204-4bbc-80aa-100601785896@github.com>

On Wed, 14 Apr 2021 17:17:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @see links.

src/java.base/share/classes/java/io/Console.java line 397:

> 395:     /**
> 396:      * Returns the {@link java.nio.charset.Charset Charset} object used in
> 397:      * the {@code Console}.

What would you think about re-phrasing the first sentence to use "for the Console" rather than "in the Console".

src/java.base/share/classes/java/lang/System.java line 123:

> 121:      *
> 122:      * @see Console#charset()
> 123:      * @see Console#reader()

What would you think about changing the example in InputStreamReader class description as part of this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From rriggs at openjdk.java.net  Thu Apr 15 14:40:36 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 15 Apr 2021 14:40:36 GMT
Subject: RFR: 8265173: [test] divert spurious log output away from stream
 under test in ProcessBuilder Basic test
In-Reply-To: <FBD5K-n8B-61e9DPHxhcPz9g_saiHrepEIvpP_3IFg0=.af1b3e51-aa1a-4712-982c-594827b2fb11@github.com>
References: <FBD5K-n8B-61e9DPHxhcPz9g_saiHrepEIvpP_3IFg0=.af1b3e51-aa1a-4712-982c-594827b2fb11@github.com>
Message-ID: <UuviK1epFyjkyZyYMrSeBW0lowBOEfje2GMyqJF-y9s=.37b736d1-19a0-415b-bdd4-db0f2f9c299e@github.com>

On Wed, 14 Apr 2021 14:08:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The most recent intermittent failure showed that the error occurred during VM initialization.
> Only the tty output was diverted, but not log output.
> Add diversion of log output as well tty output.
> 
> Add `-Xlog:all=warning:stderr` and `-Xlog:all=warning:stdout` to correspond to 
> `-XX:+DisplayVMOutputToStderr` and `-XX:+DisplayVMOutputToStdout`

I checked the other uses of -XX:+Display... and they work as intended.
Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/3492

From rriggs at openjdk.java.net  Thu Apr 15 14:40:37 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 15 Apr 2021 14:40:37 GMT
Subject: Integrated: 8265173: [test] divert spurious log output away from
 stream under test in ProcessBuilder Basic test
In-Reply-To: <FBD5K-n8B-61e9DPHxhcPz9g_saiHrepEIvpP_3IFg0=.af1b3e51-aa1a-4712-982c-594827b2fb11@github.com>
References: <FBD5K-n8B-61e9DPHxhcPz9g_saiHrepEIvpP_3IFg0=.af1b3e51-aa1a-4712-982c-594827b2fb11@github.com>
Message-ID: <iXjVlllpQQjDCq8pncaspI9SgpNMquiUzV7z_ik4b7Y=.984cd5f4-51b2-4557-a56b-e6a62cfbdddb@github.com>

On Wed, 14 Apr 2021 14:08:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The most recent intermittent failure showed that the error occurred during VM initialization.
> Only the tty output was diverted, but not log output.
> Add diversion of log output as well tty output.
> 
> Add `-Xlog:all=warning:stderr` and `-Xlog:all=warning:stdout` to correspond to 
> `-XX:+DisplayVMOutputToStderr` and `-XX:+DisplayVMOutputToStdout`

This pull request has now been integrated.

Changeset: 7b61a426
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b61a426
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8265173: [test] divert spurious log output away from stream under test in ProcessBuilder Basic test

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/3492

From herrick at openjdk.java.net  Thu Apr 15 15:39:34 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 15 Apr 2021 15:39:34 GMT
Subject: RFR: 8263154: [macos] DMG builds have finder errors
In-Reply-To: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
References: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
Message-ID: <V7FoWxXK7vUNEMr-bBS9fc0oMygmBddVInDDQWfG0FE=.ff373fb4-bbb5-480d-869f-49f851a2abf3@github.com>

On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Issue was reproducible when install-dir points to some invalid location.
>  - Fixed by defaulting DMG drag and drop location to /Applications folder and --install-dir will be ignored with warning for DMG.
>  - I do not see any way to support other valid, but uncommon locations for drag and drop. For example: /Users/USERNAME/Applications is not possible to support since user name is not known. /usr/bin requires root privileges and should contain symbolic links. Locations which does not exist also not possible to support, since DMG cannot create paths. So /Applications/MyCompany is not possible for DMG.

Doesn't much of this argument apply to pkg builds too ?
I hate to abandon install-dir option entirely for dmg, and just printing a warning and ignoring the argument is contrary to what is done for other arguments.
Is there any way, in the apple script, to check if the install-dir exists, and to use it if it does ?
Also wouldn't it be useful (for both pkg and dmg) to have ability to install into the users home directory ?
just specifying ~ or ~/Applications gets expanded before going in script if not quoted, and doesn't work if it is quoted.
Unless we define a meaning for non-fully qualified path in install-dir that should probably be a hard error..

-------------

PR: https://git.openjdk.java.net/jdk/pull/3505

From jlahoda at openjdk.java.net  Thu Apr 15 17:26:33 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 15 Apr 2021 17:26:33 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <fX_8t_9HiXDHUk8dRaewqO1rMss3xIUKkrN0E6jaw8A=.339ba5d9-cc72-4f2d-8061-50b90aa55e76@github.com>

On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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

Regarding the `ElementStructureTest`, it prints the API elements (including compile-time constants) computes hash for the printed API and compares it with an expected hash. doubles and floats are printed using String.valueOf, and it apparently changed for `Float.MIN_NORMAL` from `1.17549435E-38` to `1.1754944E-38` (I assume that is intentional). So regarding `ElementStructureTest.java` we can just update it. How about this?


diff --git a/test/langtools/tools/javac/sym/ElementStructureTest.java b/test/langtools/tools/javac/sym/ElementStructureTest.java
index 29776ce28c2..d15f2447749 100644
--- a/test/langtools/tools/javac/sym/ElementStructureTest.java
+++ b/test/langtools/tools/javac/sym/ElementStructureTest.java
@@ -121,29 +121,22 @@ import toolbox.ToolBox;
  */
 public class ElementStructureTest {
 
-    static final byte[] hash6 = new byte[] {
-        (byte) 0x99, (byte) 0x34, (byte) 0x82, (byte) 0xCF,
-        (byte) 0xE0, (byte) 0x53, (byte) 0xF3, (byte) 0x13,
-        (byte) 0x4E, (byte) 0xCF, (byte) 0x49, (byte) 0x32,
-        (byte) 0xB7, (byte) 0x52, (byte) 0x0F, (byte) 0x68
-    };
     static final byte[] hash7 = new byte[] {
-        (byte) 0x3C, (byte) 0x03, (byte) 0xEA, (byte) 0x4A,
-        (byte) 0x62, (byte) 0xD2, (byte) 0x18, (byte) 0xE5,
-        (byte) 0xA5, (byte) 0xC2, (byte) 0xB7, (byte) 0x85,
-        (byte) 0x90, (byte) 0xFA, (byte) 0x98, (byte) 0xCD
+        (byte) 0xA7, (byte) 0x3B, (byte) 0x91, (byte) 0xF6,
+        (byte) 0xEF, (byte) 0x99, (byte) 0x07, (byte) 0xF2,
+        (byte) 0x79, (byte) 0xAB, (byte) 0x19, (byte) 0xF4,
+        (byte) 0x59, (byte) 0x44, (byte) 0xF7, (byte) 0x65
     };
     static final byte[] hash8 = new byte[] {
-        (byte) 0x24, (byte) 0x38, (byte) 0x52, (byte) 0x1C,
-        (byte) 0x5E, (byte) 0x83, (byte) 0x82, (byte) 0xE6,
-        (byte) 0x41, (byte) 0xC2, (byte) 0xDD, (byte) 0x2A,
-        (byte) 0xFD, (byte) 0xFF, (byte) 0x5E, (byte) 0x2F
+        (byte) 0xF3, (byte) 0x93, (byte) 0xCA, (byte) 0x53,
+        (byte) 0xFD, (byte) 0xA3, (byte) 0x5D, (byte) 0x57,
+        (byte) 0xD2, (byte) 0xED, (byte) 0x39, (byte) 0xC5,
+        (byte) 0x56, (byte) 0x62, (byte) 0xE0, (byte) 0x1F
     };
 
     final static Map<String, byte[]> version2Hash = new HashMap<>();
 
     static {
-        version2Hash.put("6", hash6);
         version2Hash.put("7", hash7);
         version2Hash.put("8", hash8);
     }
@@ -484,7 +477,7 @@ public class ElementStructureTest {
                 return null;
             try {
                 analyzeElement(e);
-                out.write(String.valueOf(e.getConstantValue()));
+                writeConstant(e.getConstantValue());
                 out.write("\n");
             } catch (IOException ex) {
                 ex.printStackTrace();
@@ -514,6 +507,16 @@ public class ElementStructureTest {
             throw new IllegalStateException("Should not get here.");
         }
 
+        private void writeConstant(Object value) throws IOException {
+            if (value instanceof Double) {
+                out.write(Long.toString(Double.doubleToRawLongBits((Double) value)));
+            } else if (value instanceof Float) {
+                out.write(Integer.toString(Float.floatToRawIntBits((Float) value)));
+            } else {
+                out.write(String.valueOf(value));
+            }
+        }
+
     }
 
     final class TestFileManager implements JavaFileManager {

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From naoto at openjdk.java.net  Thu Apr 15 18:29:17 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 15 Apr 2021 18:29:17 GMT
Subject: RFR: 8264208: Console charset API [v9]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <tSR166SSfd65-2r-NLrbR4Q1F7uWCsYFJqZ3G0VkMbM=.f754091d-d858-46c4-b5d3-3196d03ef3bd@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Modified javadocs per suggestions.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/5988f600..083f6180

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=07-08

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

PR: https://git.openjdk.java.net/jdk/pull/3419

From naoto at openjdk.java.net  Thu Apr 15 18:36:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 15 Apr 2021 18:36:40 GMT
Subject: RFR: 8264208: Console charset API [v8]
In-Reply-To: <tWW7zZ0lCWi3y-AVSaRts6gOfBts8hdPpoTkWHV5lKE=.10c733cc-0204-4bbc-80aa-100601785896@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <nyFumoILMAmxH1N4n-S18tzvKKFiEjJKFZpnjs5mgPI=.525f4ef4-fe1f-4dec-8995-d07129807db5@github.com>
 <tWW7zZ0lCWi3y-AVSaRts6gOfBts8hdPpoTkWHV5lKE=.10c733cc-0204-4bbc-80aa-100601785896@github.com>
Message-ID: <GaQb-R7r6ORS2ELoc9cER0QwdZUWk7_i0MTraxfBgBo=.80fec414-086f-4042-9f3e-5b38674beec3@github.com>

On Thu, 15 Apr 2021 14:17:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added @see links.
>
> src/java.base/share/classes/java/io/Console.java line 397:
> 
>> 395:     /**
>> 396:      * Returns the {@link java.nio.charset.Charset Charset} object used in
>> 397:      * the {@code Console}.
> 
> What would you think about re-phrasing the first sentence to use "for the Console" rather than "in the Console".

Changed to "for the Console", as well as `@return`.

> src/java.base/share/classes/java/lang/System.java line 123:
> 
>> 121:      *
>> 122:      * @see Console#charset()
>> 123:      * @see Console#reader()
> 
> What would you think about changing the example in InputStreamReader class description as part of this?

Replaced `System.in` with generic `anInputStream`, as changing `new InputStreamReader` with `Console.reader()` would defy the purpose of the example.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From joe.darcy at oracle.com  Thu Apr 15 19:13:32 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 15 Apr 2021 12:13:32 -0700
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <fX_8t_9HiXDHUk8dRaewqO1rMss3xIUKkrN0E6jaw8A=.339ba5d9-cc72-4f2d-8061-50b90aa55e76@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <fX_8t_9HiXDHUk8dRaewqO1rMss3xIUKkrN0E6jaw8A=.339ba5d9-cc72-4f2d-8061-50b90aa55e76@github.com>
Message-ID: <ea418a03-d1e9-d782-9899-8ab0a2e147fc@oracle.com>

Hi Jan,

I recommend using {Double, Float}.toHexString to get a straightforward 
textual form of the floating-point values. The hex string is isomorphic 
to the big-level value, but is (more) human readable as a numerical 
quantity.

-Joe

On 4/15/2021 10:26 AM, Jan Lahoda wrote:
> On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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
> Regarding the `ElementStructureTest`, it prints the API elements (including compile-time constants) computes hash for the printed API and compares it with an expected hash. doubles and floats are printed using String.valueOf, and it apparently changed for `Float.MIN_NORMAL` from `1.17549435E-38` to `1.1754944E-38` (I assume that is intentional). So regarding `ElementStructureTest.java` we can just update it. How about this?
>
>
> diff --git a/test/langtools/tools/javac/sym/ElementStructureTest.java b/test/langtools/tools/javac/sym/ElementStructureTest.java
> index 29776ce28c2..d15f2447749 100644
> --- a/test/langtools/tools/javac/sym/ElementStructureTest.java
> +++ b/test/langtools/tools/javac/sym/ElementStructureTest.java
> @@ -121,29 +121,22 @@ import toolbox.ToolBox;
>    */
>   public class ElementStructureTest {
>   
> -    static final byte[] hash6 = new byte[] {
> -        (byte) 0x99, (byte) 0x34, (byte) 0x82, (byte) 0xCF,
> -        (byte) 0xE0, (byte) 0x53, (byte) 0xF3, (byte) 0x13,
> -        (byte) 0x4E, (byte) 0xCF, (byte) 0x49, (byte) 0x32,
> -        (byte) 0xB7, (byte) 0x52, (byte) 0x0F, (byte) 0x68
> -    };
>       static final byte[] hash7 = new byte[] {
> -        (byte) 0x3C, (byte) 0x03, (byte) 0xEA, (byte) 0x4A,
> -        (byte) 0x62, (byte) 0xD2, (byte) 0x18, (byte) 0xE5,
> -        (byte) 0xA5, (byte) 0xC2, (byte) 0xB7, (byte) 0x85,
> -        (byte) 0x90, (byte) 0xFA, (byte) 0x98, (byte) 0xCD
> +        (byte) 0xA7, (byte) 0x3B, (byte) 0x91, (byte) 0xF6,
> +        (byte) 0xEF, (byte) 0x99, (byte) 0x07, (byte) 0xF2,
> +        (byte) 0x79, (byte) 0xAB, (byte) 0x19, (byte) 0xF4,
> +        (byte) 0x59, (byte) 0x44, (byte) 0xF7, (byte) 0x65
>       };
>       static final byte[] hash8 = new byte[] {
> -        (byte) 0x24, (byte) 0x38, (byte) 0x52, (byte) 0x1C,
> -        (byte) 0x5E, (byte) 0x83, (byte) 0x82, (byte) 0xE6,
> -        (byte) 0x41, (byte) 0xC2, (byte) 0xDD, (byte) 0x2A,
> -        (byte) 0xFD, (byte) 0xFF, (byte) 0x5E, (byte) 0x2F
> +        (byte) 0xF3, (byte) 0x93, (byte) 0xCA, (byte) 0x53,
> +        (byte) 0xFD, (byte) 0xA3, (byte) 0x5D, (byte) 0x57,
> +        (byte) 0xD2, (byte) 0xED, (byte) 0x39, (byte) 0xC5,
> +        (byte) 0x56, (byte) 0x62, (byte) 0xE0, (byte) 0x1F
>       };
>   
>       final static Map<String, byte[]> version2Hash = new HashMap<>();
>   
>       static {
> -        version2Hash.put("6", hash6);
>           version2Hash.put("7", hash7);
>           version2Hash.put("8", hash8);
>       }
> @@ -484,7 +477,7 @@ public class ElementStructureTest {
>                   return null;
>               try {
>                   analyzeElement(e);
> -                out.write(String.valueOf(e.getConstantValue()));
> +                writeConstant(e.getConstantValue());
>                   out.write("\n");
>               } catch (IOException ex) {
>                   ex.printStackTrace();
> @@ -514,6 +507,16 @@ public class ElementStructureTest {
>               throw new IllegalStateException("Should not get here.");
>           }
>   
> +        private void writeConstant(Object value) throws IOException {
> +            if (value instanceof Double) {
> +                out.write(Long.toString(Double.doubleToRawLongBits((Double) value)));
> +            } else if (value instanceof Float) {
> +                out.write(Integer.toString(Float.floatToRawIntBits((Float) value)));
> +            } else {
> +                out.write(String.valueOf(value));
> +            }
> +        }
> +
>       }
>   
>       final class TestFileManager implements JavaFileManager {
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/3402

From plevart at openjdk.java.net  Thu Apr 15 19:26:48 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Thu, 15 Apr 2021 19:26:48 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v2]
In-Reply-To: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
Message-ID: <Q0KrFJ5y96KgNO15EOLFT6XU-0OkxjiA3ezBf0lujy8=.9e2d4b07-820c-4c86-9475-fa6b8696d3c3@github.com>

> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
> 
> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
> 
> The comparative results are here:
> 
> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
> 
> The jmh-result.json files are here:
> 
> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
> 
> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
> 
> So WDYT?

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  Add String.join benchmark method to StringJoinerBenchmark and adjust some parameters to cover bigger range

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3501/files
  - new: https://git.openjdk.java.net/jdk/pull/3501/files/62b577fd..6160e5aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=00-01

  Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3501.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3501/head:pull/3501

PR: https://git.openjdk.java.net/jdk/pull/3501

From plevart at openjdk.java.net  Thu Apr 15 19:38:33 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Thu, 15 Apr 2021 19:38:33 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved further
In-Reply-To: <5lcL44Q8ptrdLGm9T6OhAUfK9Qf3qr-3APVax-LNAfM=.3d7d6f77-501b-4374-b414-f7992ba9edef@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <5lcL44Q8ptrdLGm9T6OhAUfK9Qf3qr-3APVax-LNAfM=.3d7d6f77-501b-4374-b414-f7992ba9edef@github.com>
Message-ID: <4Tz9nGuYDst6V9GXbl_q-2R8JhPSQgeZJeMU00k5wBg=.d4269d05-133f-4935-8216-a130d250b5f5@github.com>

On Wed, 14 Apr 2021 20:03:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There's a StringJoinerBenchmark micro added by JDK-8148937 which could perhaps be expanded with the scenarios you've experimented with here?

I modified that micro benchmark and added a method to also measure String.join static method along with StringJoiner for same parameters and extended the range of parameters to cover more diversity. The results are here:

https://jmh.morethan.io/?gist=c38cc13d63774ec505cc8d394c00d502

It is apparent that there is a huge speedup when strings are bigger. But even smaller strings get a substantial speedup. There's also substantial reduction of garbage per operation. Previously the garbage amounted to the internal array of String elements and the StringBuffer with its internal byte[] array of characters. Now only the array of elements is the garbage.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From bpb at openjdk.java.net  Thu Apr 15 20:22:36 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 15 Apr 2021 20:22:36 GMT
Subject: Integrated: 8261301: StringWriter.flush() is NOOP but documentation
 does not indicate it
In-Reply-To: <0RH475n7cuVmKrEsDrROhuNshYwHny1ITlHPYlzNg4Q=.952e9c4a-2e62-4426-be0c-5f91ce7dc7b5@github.com>
References: <0RH475n7cuVmKrEsDrROhuNshYwHny1ITlHPYlzNg4Q=.952e9c4a-2e62-4426-be0c-5f91ce7dc7b5@github.com>
Message-ID: <m7Hfk7bBj8F-ANJPDGWOD_29bu0qfsrq9aA8fMWAnGw=.b6b244d3-9711-4088-8452-b43bd8fa3e11@github.com>

On Wed, 7 Apr 2021 21:01:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The specification of the method `flush()` in the `java.io` classes `CharArrayWriter` and `StringWriter` is not explicit about the fact that the method has no effect. This request proposes to add to the specification of each flush() method the sentence
> 
> The {@code flush} method of {@code <ClassName/>} does nothing.
> 
> The corresponding CSR is JDK-8264867.

This pull request has now been integrated.

Changeset: e89fd151
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e89fd151
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8261301: StringWriter.flush() is NOOP but documentation does not indicate it

Reviewed-by: naoto, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/3383

From naoto at openjdk.java.net  Thu Apr 15 21:31:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 15 Apr 2021 21:31:36 GMT
Subject: Integrated: 8258794: Support for CLDR version 39
In-Reply-To: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
References: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
Message-ID: <UN5NsIpRRh51MnfQn8ey1x8qafTFJ8qALQ36UIP9_9M=.258a6823-e691-43f1-b469-31917a751b54@github.com>

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

This pull request has now been integrated.

Changeset: f6e54f2f
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f6e54f2f
Stats:     26326 lines in 815 files changed: 761 ins; 23140 del; 2425 mod

8258794: Support for CLDR version 39

Reviewed-by: joehw, erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/3502

From almatvee at openjdk.java.net  Thu Apr 15 22:21:41 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 15 Apr 2021 22:21:41 GMT
Subject: RFR: 8263154: [macos] DMG builds have finder errors
In-Reply-To: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
References: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
Message-ID: <1kz6_ZG9ogfSgs5Oj-bL9xh6wwXpHq8HnaAyFQkrKb0=.5bdadfb6-1daa-4d07-a2f8-dee3bff8447f@github.com>

On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Issue was reproducible when install-dir points to some invalid location.
>  - Fixed by defaulting DMG drag and drop location to /Applications folder and --install-dir will be ignored with warning for DMG.
>  - I do not see any way to support other valid, but uncommon locations for drag and drop. For example: /Users/USERNAME/Applications is not possible to support since user name is not known. /usr/bin requires root privileges and should contain symbolic links. Locations which does not exist also not possible to support, since DMG cannot create paths. So /Applications/MyCompany is not possible for DMG.

Not sure if I understood question about PKG. PKG can create destination folders and will have root access once elevated, so user can specify any locations for --install-dir in case of PKG.
Well DMG is not an installer it is just disk image which contains app (think of it as archive file), so we cannot really support all functionality with DMG as with actual installers.
Yes, I can check if install-dir exist with apple script, but destination machine might not have this folder. Permissions might be different on folder on machine which generates DMG and machine which will install it.
If PKG cannot be install into user home Applications folder, then it is another bug.

Also, if someone really want --install-dir to some other location they can overwrite apple script we using via resource folder. This fix only affects apple script we generate to customize DMG. Extra step for user, but I think it will not be common anyway.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3505

From vromero at openjdk.java.net  Fri Apr 16 01:15:58 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 01:15:58 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature
Message-ID: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>

Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases.

Thanks

-------------

Commit messages:
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - fixing failing regression tests
 - JVM related changes
 - 8260517: Compiler implementation for Sealed Classes

Changes: https://git.openjdk.java.net/jdk/pull/3526/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260517
  Stats: 450 lines in 56 files changed: 48 ins; 282 del; 120 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526

PR: https://git.openjdk.java.net/jdk/pull/3526

From dholmes at openjdk.java.net  Fri Apr 16 02:14:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Apr 2021 02:14:02 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v2]
In-Reply-To: <Llnn9ItDfpg4apLNxPsV_YEwhic9cLOYJZ7TO7e6U7A=.17db82ff-2b75-4efa-8f8e-2a80363ee3cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <Llnn9ItDfpg4apLNxPsV_YEwhic9cLOYJZ7TO7e6U7A=.17db82ff-2b75-4efa-8f8e-2a80363ee3cc@github.com>
Message-ID: <Y_Gtqn1nI1-LxCYiuYEB-cGh85zCgvX3ms5Jb95QlGI=.bdd26a69-18cd-4680-adcc-6a500bb4f3c9@github.com>

On Fri, 16 Apr 2021 02:11:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>> 
>> Thanks
>> 
>> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing javax.lang.model changes

Hi Vincente,

Hotspot and hotspot tests all look fine. One query: why was this test removed?

 test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java

is that functionality tested elsewhere? (The other deleted test seemed obviously trivial.)

Thanks,
David

src/hotspot/share/classfile/classFileParser.cpp line 3916:

> 3914:             record_attribute_start = cfs->current();
> 3915:             record_attribute_length = attribute_length;
> 3916:           } else if (_major_version >= JAVA_17_VERSION) {

Can you update the comment at L3932 to say JAVA_17_VERSION please.

src/hotspot/share/classfile/classFileParser.hpp line 345:

> 343: 
> 344:   bool supports_sealed_types();
> 345:   bool supports_records();

Good catch!

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3526

From vromero at openjdk.java.net  Fri Apr 16 02:14:01 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 02:14:01 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v2]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <Llnn9ItDfpg4apLNxPsV_YEwhic9cLOYJZ7TO7e6U7A=.17db82ff-2b75-4efa-8f8e-2a80363ee3cc@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  removing javax.lang.model changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/6e2a99c6..5aef5108

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=00-01

  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526

PR: https://git.openjdk.java.net/jdk/pull/3526

From jpai at openjdk.java.net  Fri Apr 16 02:38:36 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 02:38:36 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v4]
In-Reply-To: <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
 <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>
Message-ID: <v8hvPGYcyBqJArhm8_TyF3cHEXbt04Sx-VPB95Efgis=.6d0280f5-0633-432e-a048-2e32d0551b8b@github.com>

On Thu, 15 Apr 2021 03:57:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - update existing testcase based on review comment
>>  - Improve code comment to be clear it's only applicable for java.util.Calendar
>>  - Remove irrelevant setLenient from new testcase
>
> test/jdk/java/util/Calendar/NarrowNamesTest.java line 115:
> 
>> 113:         } else {
>> 114:             testMap(US, AM_PM, ALL_STYLES,
>> 115:                     "AM", "PM",
> 
> What I meant was there is no need to check the providers and introduce the am/pm specific test method. Both `CLDR` and `COMPAT` (i.e., no "if" statement) should be tested with `testMap()` method as other tests do.

Hello Naoto,

As far as I can see, the testMap cannot be used to test the day period strings. More specifically, consider this change (git diff) that I did as you suggested (unless I misunderstood what you meant):


+        testMap(US, AM_PM, ALL_STYLES,
+                "AM",
+                "PM",
+                "midnight",
+                "noon",
+                "in the morning",
+                "",
+                "in the afternoon",
+                "",
+                "in the evening",
+                "",
+                "at night",
+                "",
+                RESET_INDEX,
+                "a", "p", "mi", "n", "", "", "", "", "", "", "", "");
+        testMap(US, AM_PM, ALL_STYLES,
+                "AM", "PM",
+                RESET_INDEX,
+                "a", "p");



This will fail with the following error.

testMap: locale=en_US, field=9, style=0, expected={in the afternoon=6, in the evening=8, in the morning=4, at night=10, midnight=2, noon=3, AM=0, PM=1, mi=2, a=0, n=3, p=1}, got={AM=0, PM=1, a=0, p=1}
java.lang.RuntimeException: test failed


That failure is due to the `testMap` method expecting these day period string to be part of the returned Map from `Calendar.getDisplayNames()` which won't be the case because that API (as per the javadoc) will only return a Map whose display names have valid field values, so in this case only those display names which will have `AM` or `PM` as a value.

If it's easier to review, I will go ahead and push the suggested change in this testcase and let if fail so that you can get a chance to look at the actual test code and error. Let me know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From vromero at openjdk.java.net  Fri Apr 16 03:26:34 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 03:26:34 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v2]
In-Reply-To: <Y_Gtqn1nI1-LxCYiuYEB-cGh85zCgvX3ms5Jb95QlGI=.bdd26a69-18cd-4680-adcc-6a500bb4f3c9@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <Llnn9ItDfpg4apLNxPsV_YEwhic9cLOYJZ7TO7e6U7A=.17db82ff-2b75-4efa-8f8e-2a80363ee3cc@github.com>
 <Y_Gtqn1nI1-LxCYiuYEB-cGh85zCgvX3ms5Jb95QlGI=.bdd26a69-18cd-4680-adcc-6a500bb4f3c9@github.com>
Message-ID: <DeHK882Tz7EuaIN3cMmuHGyCm1HFPwiBG31dVb9OMy0=.df2bc23b-34e1-40f3-be52-82fc4393dd06@github.com>

On Fri, 16 Apr 2021 02:10:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Vicente,
> 
> Hotspot and hotspot tests all look fine. One query: why was this test removed?
> 
> test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java
> 
> is that functionality tested elsewhere? (The other deleted test seemed obviously trivial.)
> 
> Thanks,
> David

Hi David, thanks for your comments, yes regarding `test test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java`, it was removed because the functionality is tested in `test/langtools/tools/javac/sealed/SealedCompilationTests.java`

> src/hotspot/share/classfile/classFileParser.cpp line 3916:
> 
>> 3914:             record_attribute_start = cfs->current();
>> 3915:             record_attribute_length = attribute_length;
>> 3916:           } else if (_major_version >= JAVA_17_VERSION) {
> 
> Can you update the comment at L3932 to say JAVA_17_VERSION please.

sure

-------------

PR: https://git.openjdk.java.net/jdk/pull/3526

From vromero at openjdk.java.net  Fri Apr 16 03:35:06 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 16 Apr 2021 03:35:06 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v3]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <G43LId0M-ZZiM447iIsG4geyGogSR7HryckiLcXDj6I=.82585196-9db7-45fc-9688-b9ef9d2507ab@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  updating comment after review feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/5aef5108..8ebe56fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526

PR: https://git.openjdk.java.net/jdk/pull/3526

From naoto at openjdk.java.net  Fri Apr 16 03:56:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 03:56:35 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v4]
In-Reply-To: <v8hvPGYcyBqJArhm8_TyF3cHEXbt04Sx-VPB95Efgis=.6d0280f5-0633-432e-a048-2e32d0551b8b@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
 <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>
 <v8hvPGYcyBqJArhm8_TyF3cHEXbt04Sx-VPB95Efgis=.6d0280f5-0633-432e-a048-2e32d0551b8b@github.com>
Message-ID: <P4IP_SUlVoGV9ggcEPenkKGR-Oz7Ar9eX2wxlxnqxZk=.500680d5-6c3e-4444-8c0f-d443e4753e4f@github.com>

On Fri, 16 Apr 2021 02:35:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/util/Calendar/NarrowNamesTest.java line 115:
>> 
>>> 113:         } else {
>>> 114:             testMap(US, AM_PM, ALL_STYLES,
>>> 115:                     "AM", "PM",
>> 
>> What I meant was there is no need to check the providers and introduce the am/pm specific test method. Both `CLDR` and `COMPAT` (i.e., no "if" statement) should be tested with `testMap()` method as other tests do.
>
> Hello Naoto,
> 
> As far as I can see, the testMap cannot be used to test the day period strings. More specifically, consider this change (git diff) that I did as you suggested (unless I misunderstood what you meant):
> 
> 
> +        testMap(US, AM_PM, ALL_STYLES,
> +                "AM",
> +                "PM",
> +                "midnight",
> +                "noon",
> +                "in the morning",
> +                "",
> +                "in the afternoon",
> +                "",
> +                "in the evening",
> +                "",
> +                "at night",
> +                "",
> +                RESET_INDEX,
> +                "a", "p", "mi", "n", "", "", "", "", "", "", "", "");
> +        testMap(US, AM_PM, ALL_STYLES,
> +                "AM", "PM",
> +                RESET_INDEX,
> +                "a", "p");
> 
> 
> 
> This will fail with the following error.
> 
> testMap: locale=en_US, field=9, style=0, expected={in the afternoon=6, in the evening=8, in the morning=4, at night=10, midnight=2, noon=3, AM=0, PM=1, mi=2, a=0, n=3, p=1}, got={AM=0, PM=1, a=0, p=1}
> java.lang.RuntimeException: test failed
> 
> 
> That failure is due to the `testMap` method expecting these day period string to be part of the returned Map from `Calendar.getDisplayNames()` which won't be the case because that API (as per the javadoc) will only return a Map whose display names have valid field values, so in this case only those display names which will have `AM` or `PM` as a value.
> 
> If it's easier to review, I will go ahead and push the suggested change in this testcase and let if fail so that you can get a chance to look at the actual test code and error. Let me know.

Sorry if I wasn't clear. The whole test for am/pm (line 98 - 118) can simply be:

            testMap(US, AM_PM, ALL_STYLES,
                    "AM", "PM",
                    RESET_INDEX,
                    "a", "p");

Since we now know that day periods strings won't be leaked into display names, then the map simply should contain only 4 entries (`AM`, `PM`, `a`, and `p`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From jpai at openjdk.java.net  Fri Apr 16 04:06:54 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 04:06:54 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v4]
In-Reply-To: <P4IP_SUlVoGV9ggcEPenkKGR-Oz7Ar9eX2wxlxnqxZk=.500680d5-6c3e-4444-8c0f-d443e4753e4f@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
 <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>
 <v8hvPGYcyBqJArhm8_TyF3cHEXbt04Sx-VPB95Efgis=.6d0280f5-0633-432e-a048-2e32d0551b8b@github.com>
 <P4IP_SUlVoGV9ggcEPenkKGR-Oz7Ar9eX2wxlxnqxZk=.500680d5-6c3e-4444-8c0f-d443e4753e4f@github.com>
Message-ID: <6adYjCCfmbNAFRUD2cHge7uj7Ttf_PGzNb75zrnkEJY=.dc685641-9ab8-4b75-b109-debe4a91f792@github.com>

On Fri, 16 Apr 2021 03:51:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello Naoto,
>> 
>> As far as I can see, the testMap cannot be used to test the day period strings. More specifically, consider this change (git diff) that I did as you suggested (unless I misunderstood what you meant):
>> 
>> 
>> +        testMap(US, AM_PM, ALL_STYLES,
>> +                "AM",
>> +                "PM",
>> +                "midnight",
>> +                "noon",
>> +                "in the morning",
>> +                "",
>> +                "in the afternoon",
>> +                "",
>> +                "in the evening",
>> +                "",
>> +                "at night",
>> +                "",
>> +                RESET_INDEX,
>> +                "a", "p", "mi", "n", "", "", "", "", "", "", "", "");
>> +        testMap(US, AM_PM, ALL_STYLES,
>> +                "AM", "PM",
>> +                RESET_INDEX,
>> +                "a", "p");
>> 
>> 
>> 
>> This will fail with the following error.
>> 
>> testMap: locale=en_US, field=9, style=0, expected={in the afternoon=6, in the evening=8, in the morning=4, at night=10, midnight=2, noon=3, AM=0, PM=1, mi=2, a=0, n=3, p=1}, got={AM=0, PM=1, a=0, p=1}
>> java.lang.RuntimeException: test failed
>> 
>> 
>> That failure is due to the `testMap` method expecting these day period string to be part of the returned Map from `Calendar.getDisplayNames()` which won't be the case because that API (as per the javadoc) will only return a Map whose display names have valid field values, so in this case only those display names which will have `AM` or `PM` as a value.
>> 
>> If it's easier to review, I will go ahead and push the suggested change in this testcase and let if fail so that you can get a chance to look at the actual test code and error. Let me know.
>
> Sorry if I wasn't clear. The whole test for am/pm (line 98 - 118) can simply be:
> 
>             testMap(US, AM_PM, ALL_STYLES,
>                     "AM", "PM",
>                     RESET_INDEX,
>                     "a", "p");
> 
> Since we now know that day periods strings won't be leaked into display names, then the map simply should contain only 4 entries (`AM`, `PM`, `a`, and `p`).

Thank you for that clarification. I now understand what you mean. I've updated the test to follow this suggestion in the latest update to this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From jpai at openjdk.java.net  Fri Apr 16 04:06:54 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 04:06:54 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v5]
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Update existing test based on review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3463/files
  - new: https://git.openjdk.java.net/jdk/pull/3463/files/607776b3..ea0d3c77

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=03-04

  Stats: 49 lines in 1 file changed: 0 ins; 45 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3463/head:pull/3463

PR: https://git.openjdk.java.net/jdk/pull/3463

From naoto at openjdk.java.net  Fri Apr 16 04:22:37 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 04:22:37 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v5]
In-Reply-To: <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>
Message-ID: <M4MGC-RYTP0oLVXTVfY03iXuIiIp2Zs_t4zsotprhOE=.921a18cd-4dc8-49d3-bf3f-d6918cbf1b17@github.com>

On Fri, 16 Apr 2021 04:06:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update existing test based on review comments

Looks good. Thank you for fixing the issue.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3463

From jpai at openjdk.java.net  Fri Apr 16 06:48:37 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 06:48:37 GMT
Subject: RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
 [v5]
In-Reply-To: <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>
Message-ID: <Sc1dddQ7enVWUD6_u8644UO3--If8xJ0kWyhqpyA0xU=.44399949-33d3-4484-b0a9-15b33ae085c1@github.com>

On Fri, 16 Apr 2021 04:06:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update existing test based on review comments

Thank you Naoto for your reviews and guidance in fixing this issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From jpai at openjdk.java.net  Fri Apr 16 06:48:39 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 06:48:39 GMT
Subject: Integrated: 8262108: SimpleDateFormat formatting broken for sq_MK
 Locale
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <97UbBWokWjmUgpXG9C_gP7hoeoJHribfqbWTpYJwILY=.c88a6414-ea6d-4ded-8f1c-dd3d985895b7@github.com>

On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

This pull request has now been integrated.

Changeset: 64e21307
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/64e21307
Stats:     99 lines in 3 files changed: 73 ins; 18 del; 8 mod

8262108: SimpleDateFormat formatting broken for sq_MK Locale

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/3463

From github.com+70726043+rgiulietti at openjdk.java.net  Fri Apr 16 08:09:35 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 16 Apr 2021 08:09:35 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <LXq5UyCPa8SyFnKbvn9NcPVQcwFGCW5Gce4gEScRKW0=.30b27698-a878-4cfa-8c54-9aa4cf96c608@github.com>

On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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

Hi Jan,

I had to change a string in test
    test/jdk/java/lang/String/concat/ImplicitStringConcatBoundaries.java
because it failed with the current string but passes with the new one. Indeed, the new implementation of Float.toString(float) produces the new string, which, like the current one, is correct in the sense that, upon reading, it recovers Float.MIN_NORMAL.

However, I didn't change the definition of MIN_NORMAL in java.lang.Float because there it is already expressed in hex notation.

As suggested before and by Joe, using the hex representation instead of the decimal would be more robust because the conversions from/to hex are almost trivial, hence much less subject to slight errors. So, rather than printing the raw bits as you suggest, you could use the hex string rendering instead.


Thanks
Raffaello

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From jlahoda at openjdk.java.net  Fri Apr 16 08:14:48 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 16 Apr 2021 08:14:48 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <wDr0CRwcDK04lph5tY_fFZxaMl2oS8Emhl43BYwzeQI=.d28c2bcb-18d9-4e60-bfc7-3167427d29de@github.com>

On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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

Sure, here you are:

diff --git a/test/langtools/tools/javac/sym/ElementStructureTest.java b/test/langtools/tools/javac/sym/ElementStructureTest.java
index 29776ce28c2..428ba03361f 100644
--- a/test/langtools/tools/javac/sym/ElementStructureTest.java
+++ b/test/langtools/tools/javac/sym/ElementStructureTest.java
@@ -121,29 +121,22 @@ import toolbox.ToolBox;
  */
 public class ElementStructureTest {
 
-    static final byte[] hash6 = new byte[] {
-        (byte) 0x99, (byte) 0x34, (byte) 0x82, (byte) 0xCF,
-        (byte) 0xE0, (byte) 0x53, (byte) 0xF3, (byte) 0x13,
-        (byte) 0x4E, (byte) 0xCF, (byte) 0x49, (byte) 0x32,
-        (byte) 0xB7, (byte) 0x52, (byte) 0x0F, (byte) 0x68
-    };
     static final byte[] hash7 = new byte[] {
-        (byte) 0x3C, (byte) 0x03, (byte) 0xEA, (byte) 0x4A,
-        (byte) 0x62, (byte) 0xD2, (byte) 0x18, (byte) 0xE5,
-        (byte) 0xA5, (byte) 0xC2, (byte) 0xB7, (byte) 0x85,
-        (byte) 0x90, (byte) 0xFA, (byte) 0x98, (byte) 0xCD
+        (byte) 0x65, (byte) 0x41, (byte) 0xC8, (byte) 0x17,
+        (byte) 0xF0, (byte) 0xB1, (byte) 0x62, (byte) 0x9A,
+        (byte) 0xD8, (byte) 0x19, (byte) 0xBA, (byte) 0xB0,
+        (byte) 0xC1, (byte) 0x70, (byte) 0x5E, (byte) 0x3E
     };
     static final byte[] hash8 = new byte[] {
-        (byte) 0x24, (byte) 0x38, (byte) 0x52, (byte) 0x1C,
-        (byte) 0x5E, (byte) 0x83, (byte) 0x82, (byte) 0xE6,
-        (byte) 0x41, (byte) 0xC2, (byte) 0xDD, (byte) 0x2A,
-        (byte) 0xFD, (byte) 0xFF, (byte) 0x5E, (byte) 0x2F
+        (byte) 0x83, (byte) 0x62, (byte) 0x2F, (byte) 0x1C,
+        (byte) 0x95, (byte) 0x6D, (byte) 0x31, (byte) 0x18,
+        (byte) 0xF5, (byte) 0xB2, (byte) 0x8C, (byte) 0x39,
+        (byte) 0x81, (byte) 0x2E, (byte) 0x2C, (byte) 0x34
     };
 
     final static Map<String, byte[]> version2Hash = new HashMap<>();
 
     static {
-        version2Hash.put("6", hash6);
         version2Hash.put("7", hash7);
         version2Hash.put("8", hash8);
     }
@@ -484,7 +477,7 @@ public class ElementStructureTest {
                 return null;
             try {
                 analyzeElement(e);
-                out.write(String.valueOf(e.getConstantValue()));
+                writeConstant(e.getConstantValue());
                 out.write("\n");
             } catch (IOException ex) {
                 ex.printStackTrace();
@@ -514,6 +507,16 @@ public class ElementStructureTest {
             throw new IllegalStateException("Should not get here.");
         }
 
+        private void writeConstant(Object value) throws IOException {
+            if (value instanceof Double) {
+                out.write(Double.toHexString((Double) value));
+            } else if (value instanceof Float) {
+                out.write(Float.toHexString((Float) value));
+            } else {
+                out.write(String.valueOf(value));
+            }
+        }
+
     }
 
     final class TestFileManager implements JavaFileManager {

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From github.com+70726043+rgiulietti at openjdk.java.net  Fri Apr 16 08:22:35 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 16 Apr 2021 08:22:35 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <1D8YLR2nmAIjk_mGB1ThIL1ysL5iaQhOdvMyU8GLHtw=.759f4988-b805-49f0-a6d1-dc63f68834ce@github.com>

On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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

Fine, thanks!

Will your change be integrated soon on master?
What am I supposed to do then, rebasing my branch with the updated master?

(BTW, you could make use of instanceof pattern matching if you don't need backward compat ;-) )

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From jlahoda at openjdk.java.net  Fri Apr 16 08:25:35 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 16 Apr 2021 08:25:35 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <FaavD_9Ur13Qr4DOZ09xLimg-qDQuG2hE5-nLC-CCbs=.03a988fc-a223-4aff-995c-9f36f4164dbd@github.com>

On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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

@ rgiulietti, I thought you'd simply add the test change to your patch. But I can start a PR for it, if you prefer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From github.com+70726043+rgiulietti at openjdk.java.net  Fri Apr 16 08:29:33 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 16 Apr 2021 08:29:33 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <FaavD_9Ur13Qr4DOZ09xLimg-qDQuG2hE5-nLC-CCbs=.03a988fc-a223-4aff-995c-9f36f4164dbd@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <FaavD_9Ur13Qr4DOZ09xLimg-qDQuG2hE5-nLC-CCbs=.03a988fc-a223-4aff-995c-9f36f4164dbd@github.com>
Message-ID: <7XPw4-q4bxx-Gd4BotnzrFCcgTdTUm4pDNpxZSYtVdk=.049a9fe4-2a76-4115-9e32-c9174aa03451@github.com>

On Fri, 16 Apr 2021 08:22:41 GMT, Jan Lahoda <jlahoda at openjdk.org> 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
>
> @ rgiulietti, I thought you'd simply add the test change to your patch. But I can start a PR for it, if you prefer.

@lahodaj Oh, my understanding was that yours is a permanent change worth of integrating anyway. But yes, I can add your change to my changeset.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From uschindler at openjdk.java.net  Fri Apr 16 09:52:38 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 16 Apr 2021 09:52:38 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v5]
In-Reply-To: <i_M9vZiz7Ltzz0lOw3XzbRJK4wH7i93f7WJ7tfE3voM=.cd098431-31b8-46cc-ba21-ca4d1675f5ef@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <i_M9vZiz7Ltzz0lOw3XzbRJK4wH7i93f7WJ7tfE3voM=.cd098431-31b8-46cc-ba21-ca4d1675f5ef@github.com>
Message-ID: <oX2k79TcfsMJabuxvjPvU_mPZunEZzdxrHkoSYqRF9o=.8057ad1e-71d7-4bb7-9c9e-e967f7ccc512@github.com>

On Thu, 15 Apr 2021 12:37:52 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extraneous references to makeXXXSpliterator

Due to the changes now: I think the CSR got obsolete?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From jlaskey at openjdk.java.net  Fri Apr 16 10:49:35 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 16 Apr 2021 10:49:35 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v5]
In-Reply-To: <i_M9vZiz7Ltzz0lOw3XzbRJK4wH7i93f7WJ7tfE3voM=.cd098431-31b8-46cc-ba21-ca4d1675f5ef@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <i_M9vZiz7Ltzz0lOw3XzbRJK4wH7i93f7WJ7tfE3voM=.cd098431-31b8-46cc-ba21-ca4d1675f5ef@github.com>
Message-ID: <JPnpbmvkDLjdz8s8rt8ysYPkdKIYZYt8MAXNrVW6lHw=.c162d5c2-f727-4b6e-b7bc-7b234c1915f3@github.com>

On Thu, 15 Apr 2021 12:37:52 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extraneous references to makeXXXSpliterator

I put the CSR back to draft until I was happy with the changeset.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From github.com+70726043+rgiulietti at openjdk.java.net  Fri Apr 16 11:30:32 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 16 Apr 2021 11:30:32 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results [v2]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <Nd6utSzkKOGc1ynbZ30UxckmgacySChXLBRT7DGlkA4=.5d00bb70-1150-42bf-8c64-145404c3aa89@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3402/files
  - new: https://git.openjdk.java.net/jdk/pull/3402/files/cc10a92d..22092f0c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=00-01

  Stats: 26 lines in 1 file changed: 10 ins; 7 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402

PR: https://git.openjdk.java.net/jdk/pull/3402

From github.com+70726043+rgiulietti at openjdk.java.net  Fri Apr 16 11:30:33 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 16 Apr 2021 11:30:33 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <1WZNqpR5jqqsTZHCJB1jS4B-SfVYe016M6freoqW0-8=.2e7d5879-c27b-4fdb-bff1-e039761b9cc7@github.com>

On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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

Modified
test/langtools/tools/javac/sym/ElementStructureTest.java
as suggested by @lahodaj

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From winterhalter at openjdk.java.net  Fri Apr 16 13:52:07 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Fri, 16 Apr 2021 13:52:07 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
Message-ID: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>

To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.

-------------

Commit messages:
 - 8200559: Java agents doing instrumentation need a means to define auxiliary classes

Changes: https://git.openjdk.java.net/jdk/pull/3546/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8200559
  Stats: 185 lines in 4 files changed: 185 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3546.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3546/head:pull/3546

PR: https://git.openjdk.java.net/jdk/pull/3546

From forax at univ-mlv.fr  Fri Apr 16 14:21:14 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 16 Apr 2021 16:21:14 +0200 (CEST)
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
Message-ID: <1665771929.1527476.1618582874230.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Rafael Winterhalter" <winterhalter at openjdk.java.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "serviceability-dev" <serviceability-dev at openjdk.java.net>
> Envoy?: Vendredi 16 Avril 2021 15:52:07
> Objet: RFR: 8200559: Java agents doing instrumentation need a means to define auxilary classes

> To allow agents the definition of auxiliary classes, an API is needed to allow
> this. Currently, this is often achieved by using `sun.misc.Unsafe` or
> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from
> `sun.misc.Unsafe`.

You can already use Lookup.defineClass() + privateLookupIn() + Instrumentation.redefineModule() for that ?

R?mi

> 
> -------------
> 
> Commit messages:
> - 8200559: Java agents doing instrumentation need a means to define auxiliary
> classes
> 
> Changes: https://git.openjdk.java.net/jdk/pull/3546/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8200559
>  Stats: 185 lines in 4 files changed: 185 ins; 0 del; 0 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/3546.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3546/head:pull/3546
> 
> PR: https://git.openjdk.java.net/jdk/pull/3546

From rriggs at openjdk.java.net  Fri Apr 16 14:30:38 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Apr 2021 14:30:38 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits [v2]
In-Reply-To: <O2mswzonqSXwR182cYYrlA7-lRwGnOCUav_bpVD5EjE=.4f6b2e1c-8fdc-4455-b561-1892804e1788@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <O2mswzonqSXwR182cYYrlA7-lRwGnOCUav_bpVD5EjE=.4f6b2e1c-8fdc-4455-b561-1892804e1788@github.com>
Message-ID: <GhkZVYo0g3PkRg-ZYddWBne9V_cxU6nhm0jkWOssUoA=.9b5476b9-2261-42a3-90c1-c9f3bf000339@github.com>

On Wed, 7 Apr 2021 02:48:00 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding BigDecimal equivalents to tests

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/util/Formatter.java line 3826:

> 3824:                 BigDecimal tenToTheNegFour = BigDecimal.valueOf(1, 4);
> 3825:                 BigDecimal tenToThePrec = BigDecimal.valueOf(1, -prec);
> 3826:                 value = value.round(new MathContext(prec));

While you are in the area, how about inlining the creation of the tenToTheNegFour and tenToThePrec values.
They are used only once and may not be used at all. They don't appear to be needed except for the comparisons.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3363

From rriggs at openjdk.java.net  Fri Apr 16 14:32:39 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Apr 2021 14:32:39 GMT
Subject: RFR: 8037397: RegEx pattern matching loses character class after
 intersection (&&) operator [v4]
In-Reply-To: <pnHWhDOJDGyiifOryf7TpNv-677pJv3_XiKUqr75dRc=.c421eff9-ee20-447b-a65e-beb5a5f98cdb@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
 <pnHWhDOJDGyiifOryf7TpNv-677pJv3_XiKUqr75dRc=.c421eff9-ee20-447b-a65e-beb5a5f98cdb@github.com>
Message-ID: <t_vI9s-9I9CEpKKP8yHW_ff6tHd3-0xh0AUmHhDwVaA=.57b0589b-9021-486d-8af5-d8296f467c3b@github.com>

On Fri, 2 Apr 2021 19:15:39 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bumping copyright date.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3291

From alanb at openjdk.java.net  Fri Apr 16 14:32:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 16 Apr 2021 14:32:39 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
Message-ID: <kMWLlu9p2SCN96YEC7zEAE2YlvdjU_ODvXrU35bQpwU=.86614d0f-4da2-4e8c-a490-143051b13e81@github.com>

On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.

JDK-8200559 is about defining auxiliary classes in the same runtime package at load-time whereas I think the proposal in this PR is adding an unrestricted defineClass to the Instrumentation class. I think this will require a lot of discussion as there are significant issues and concerns here. An unrestricted defineClass might be okay for tool/java agents when started from the command line with -javaagent but only if the Instrumentation object is never ever leaked to library or application code. It could potentially be part of a large effort to reduce the capabilities of agents loaded via the attach mechanism. More generally I think we need clearer separation of the requirements of tool agents from the requirement of framework/libraries that want to inject proxy and other classes at runtime.

Separately, the proposal in JEP 410 is to terminally deprecate ProtectionDomain.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From raffaello.giulietti at gmail.com  Fri Apr 16 15:21:02 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 16 Apr 2021 17:21:02 +0200
Subject: =?UTF-8?B?ODI0NjMzNDogQ2FzdGluZyDigJhkb3VibGUgdG8gaW504oCZIGFuZCA=?=
 =?UTF-8?Q?=e2=80=98long_to_int=e2=80=99_produce_different_results?=
Message-ID: <2e3bb7e3-5a5a-eb18-5cfe-8d67ce40d536@gmail.com>

Hello,

the reporter of [1] seems to understand that the current behavior is 
well specified (since ever) and correctly implemented. Also, it's 
unclear how s/he would like to enhance it.

Shouldn't [1] be closed?


Greetings
Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-8246334

From kustos at gmx.net  Fri Apr 16 15:43:52 2021
From: kustos at gmx.net (Philippe Marschall)
Date: Fri, 16 Apr 2021 17:43:52 +0200
Subject: Looking for reviewer and sponsor for 4926314
Message-ID: <72099137-3641-9b3f-a399-d2d5c69de6bb@gmx.net>

Hello

I am looking for reviewers and a sponsor for JDK-4926314: Optimize
Reader.read(CharBuffer) [1]. The PR [2] went through quite some changes
and is now back to few changes to reduce the impact and the risk.

  [1] https://bugs.openjdk.java.net/browse/JDK-4926314
  [2] https://github.com/openjdk/jdk/pull/1915

Cheers
Philippe

From igraves at openjdk.java.net  Fri Apr 16 16:08:53 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 16 Apr 2021 16:08:53 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits [v3]
In-Reply-To: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
Message-ID: <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>

> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Inlining some single use variables

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3363/files
  - new: https://git.openjdk.java.net/jdk/pull/3363/files/cf40421e..45522605

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3363&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3363&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3363.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3363/head:pull/3363

PR: https://git.openjdk.java.net/jdk/pull/3363

From igraves at openjdk.java.net  Fri Apr 16 16:14:42 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 16 Apr 2021 16:14:42 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits [v2]
In-Reply-To: <GhkZVYo0g3PkRg-ZYddWBne9V_cxU6nhm0jkWOssUoA=.9b5476b9-2261-42a3-90c1-c9f3bf000339@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <O2mswzonqSXwR182cYYrlA7-lRwGnOCUav_bpVD5EjE=.4f6b2e1c-8fdc-4455-b561-1892804e1788@github.com>
 <GhkZVYo0g3PkRg-ZYddWBne9V_cxU6nhm0jkWOssUoA=.9b5476b9-2261-42a3-90c1-c9f3bf000339@github.com>
Message-ID: <_kz15G9r7nsrbUDy8Si6xTDnot4S-IjzaygMQYaPQ_w=.d702a819-1ff2-4be3-a040-a077c7c2f2b1@github.com>

On Fri, 16 Apr 2021 14:26:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding BigDecimal equivalents to tests
>
> src/java.base/share/classes/java/util/Formatter.java line 3826:
> 
>> 3824:                 BigDecimal tenToTheNegFour = BigDecimal.valueOf(1, 4);
>> 3825:                 BigDecimal tenToThePrec = BigDecimal.valueOf(1, -prec);
>> 3826:                 value = value.round(new MathContext(prec));
> 
> While you are in the area, how about inlining the creation of the tenToTheNegFour and tenToThePrec values.
> They are used only once and may not be used at all. They don't appear to be needed except for the comparisons.

Makes sense to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3363

From rafael.wth at gmail.com  Fri Apr 16 16:27:46 2021
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 16 Apr 2021 18:27:46 +0200
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <1665771929.1527476.1618582874230.JavaMail.zimbra@u-pem.fr>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <1665771929.1527476.1618582874230.JavaMail.zimbra@u-pem.fr>
Message-ID: <CA+DM0A=eUqzLS9Ej+0mg5z_KOPZHeQ4bHAtwBdxRQXqWErvWEA@mail.gmail.com>

Not by my understanding. A suitable lookup requires a loaded class for the
package. A Java agent might however not provide a handle for a class that
is not yet loaded. Or how would you suggest to approach this?

Am Fr., 16. Apr. 2021 um 16:21 Uhr schrieb Remi Forax <forax at univ-mlv.fr>:

> ----- Mail original -----
> > De: "Rafael Winterhalter" <winterhalter at openjdk.java.net>
> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>,
> "serviceability-dev" <serviceability-dev at openjdk.java.net>
> > Envoy?: Vendredi 16 Avril 2021 15:52:07
> > Objet: RFR: 8200559: Java agents doing instrumentation need a means to
> define auxilary classes
>
> > To allow agents the definition of auxiliary classes, an API is needed to
> allow
> > this. Currently, this is often achieved by using `sun.misc.Unsafe` or
> > `jdk.internal.misc.Unsafe` ever since the `defineClass` method was
> removed from
> > `sun.misc.Unsafe`.
>
> You can already use Lookup.defineClass() + privateLookupIn() +
> Instrumentation.redefineModule() for that ?
>
> R?mi
>
> >
> > -------------
> >
> > Commit messages:
> > - 8200559: Java agents doing instrumentation need a means to define
> auxiliary
> > classes
> >
> > Changes: https://git.openjdk.java.net/jdk/pull/3546/files
> > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00
> >  Issue: https://bugs.openjdk.java.net/browse/JDK-8200559
> >  Stats: 185 lines in 4 files changed: 185 ins; 0 del; 0 mod
> >  Patch: https://git.openjdk.java.net/jdk/pull/3546.diff
> >  Fetch: git fetch https://git.openjdk.java.net/jdk
> pull/3546/head:pull/3546
> >
> > PR: https://git.openjdk.java.net/jdk/pull/3546
>

From forax at univ-mlv.fr  Fri Apr 16 16:35:32 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 16 Apr 2021 18:35:32 +0200 (CEST)
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <CA+DM0A=eUqzLS9Ej+0mg5z_KOPZHeQ4bHAtwBdxRQXqWErvWEA@mail.gmail.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <1665771929.1527476.1618582874230.JavaMail.zimbra@u-pem.fr>
 <CA+DM0A=eUqzLS9Ej+0mg5z_KOPZHeQ4bHAtwBdxRQXqWErvWEA@mail.gmail.com>
Message-ID: <1924898916.1609700.1618590932170.JavaMail.zimbra@u-pem.fr>

> De: "Rafael Winterhalter" <rafael.wth at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Rafael Winterhalter" <winterhalter at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>, "serviceability-dev"
> <serviceability-dev at openjdk.java.net>
> Envoy?: Vendredi 16 Avril 2021 18:27:46
> Objet: Re: RFR: 8200559: Java agents doing instrumentation need a means to
> define auxilary classes

> Not by my understanding. A suitable lookup requires a loaded class for the
> package. A Java agent might however not provide a handle for a class that is
> not yet loaded. Or how would you suggest to approach this ?

yes, you need a witness class in the package you want to define a new class. 
Apart if you load classes in the unamed module, you can not load a class in a non existing package anyway (apart if you generate your own module-info), 
so you need at least a dummy class to define a package, so you can use it to get a Lookup. 

R?mi 

> Am Fr., 16. Apr. 2021 um 16:21 Uhr schrieb Remi Forax < [
> mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >:

>> ----- Mail original -----
>>> De: "Rafael Winterhalter" < [ mailto:winterhalter at openjdk.java.net |
>> > winterhalter at openjdk.java.net ] >
>>> ?: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net |
>>> core-libs-dev at openjdk.java.net ] >, "serviceability-dev" < [
>>> mailto:serviceability-dev at openjdk.java.net |
>> > serviceability-dev at openjdk.java.net ] >
>> > Envoy?: Vendredi 16 Avril 2021 15:52:07
>>> Objet: RFR: 8200559: Java agents doing instrumentation need a means to define
>> > auxilary classes

>> > To allow agents the definition of auxiliary classes, an API is needed to allow
>> > this. Currently, this is often achieved by using `sun.misc.Unsafe` or
>> > `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from
>> > `sun.misc.Unsafe`.

>> You can already use Lookup.defineClass() + privateLookupIn() +
>> Instrumentation.redefineModule() for that ?

>> R?mi


>> > -------------

>> > Commit messages:
>> > - 8200559: Java agents doing instrumentation need a means to define auxiliary
>> > classes

>>> Changes: [ https://git.openjdk.java.net/jdk/pull/3546/files |
>> > https://git.openjdk.java.net/jdk/pull/3546/files ]
>>> Webrev: [ https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00 |
>> > https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00 ]
>>> Issue: [ https://bugs.openjdk.java.net/browse/JDK-8200559 |
>> > https://bugs.openjdk.java.net/browse/JDK-8200559 ]
>> > Stats: 185 lines in 4 files changed: 185 ins; 0 del; 0 mod
>>> Patch: [ https://git.openjdk.java.net/jdk/pull/3546.diff |
>> > https://git.openjdk.java.net/jdk/pull/3546.diff ]
>>> Fetch: git fetch [ https://git.openjdk.java.net/jdk |
>> > https://git.openjdk.java.net/jdk ] pull/3546/head:pull/3546

>>> PR: [ https://git.openjdk.java.net/jdk/pull/3546 |
>> > https://git.openjdk.java.net/jdk/pull/3546 ]

From winterhalter at openjdk.java.net  Fri Apr 16 16:40:35 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Fri, 16 Apr 2021 16:40:35 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
Message-ID: <otJgXr8zEtbXJFznspEo-rahiUVnPSW3mcD7iOGo5s4=.941b58d9-2522-4d59-944c-1468c975c23e@github.com>

On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.

The ticket was created as a reaction to a [write-up I made in January 2018](http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000405.html). I certainly did not intend to limit the scope to same-package class definitions for instrumented classes, and even for those I do not think a package-restricted API would be sufficient as I outlined in the comments to [JDK-8200559](https://bugs.openjdk.java.net/browse/JDK-8200559).

I will try to make my case on the mailing list. I hoped this could get resolved within the release of Java 17 as this would make it possible to write agents without use of Unsafe API to support Java 17 and later. Since agents often are supplementary to a broad range of Java applications, the LTS release will likely be an important support boundary for years and years to come.

You surely mean JEP 411 when mentioning `ProtectionDomain`? The JEP mentions

> We will not deprecate some classes in the java.security package that are related to the Security Manager, for varying reasons: [...] ProtectionDomain ? Several significant APIs depend on ProtectionDomain, e.g., ClassLoader::defineClass and Class::getProtectionDomain. ProtectionDomain also has value independent of the Security Manager since it contains the CodeSource of a class.

Also, since this is still a proposal, I would believe that APIs that are implemented before JEP 411 is realized should support `ProtectionDomain` for users still supporting the security manager in the transition time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From rafael.wth at gmail.com  Fri Apr 16 16:41:26 2021
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 16 Apr 2021 18:41:26 +0200
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <1924898916.1609700.1618590932170.JavaMail.zimbra@u-pem.fr>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <1665771929.1527476.1618582874230.JavaMail.zimbra@u-pem.fr>
 <CA+DM0A=eUqzLS9Ej+0mg5z_KOPZHeQ4bHAtwBdxRQXqWErvWEA@mail.gmail.com>
 <1924898916.1609700.1618590932170.JavaMail.zimbra@u-pem.fr>
Message-ID: <CA+DM0AmH4tqh=PBmUfE35oroNG0O3bdWMoVcVnaDdYgWs1sodw@mail.gmail.com>

This would be a problem, however. Since there is currently no official way
of defining a class, and since Java agents do not control the class loading
order, if a class was loaded for the first time, you could for example not
add a field with a type of an auxiliary class that you had planned to
inject. A class being loaded is normally the first opportunity for a Java
agent and if no witness class is available at this point, using a method
handle is no option. Since it is difficult to know if such a witness class
is available in the general case, it would also add quite a performance and
managerial toll on agent authors. I would hope that an API equally
convenient to today's unsafe options could be added.

Am Fr., 16. Apr. 2021 um 18:35 Uhr schrieb <forax at univ-mlv.fr>:

>
>
> ------------------------------
>
> *De: *"Rafael Winterhalter" <rafael.wth at gmail.com>
> *?: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"Rafael Winterhalter" <winterhalter at openjdk.java.net>,
> "core-libs-dev" <core-libs-dev at openjdk.java.net>, "serviceability-dev" <
> serviceability-dev at openjdk.java.net>
> *Envoy?: *Vendredi 16 Avril 2021 18:27:46
> *Objet: *Re: RFR: 8200559: Java agents doing instrumentation need a means
> to define auxilary classes
>
> Not by my understanding. A suitable lookup requires a loaded class for the
> package. A Java agent might however not provide a handle for a class that
> is not yet loaded. Or how would you suggest to approach this ?
>
>
> yes, you need a witness class in the package you want to define a new
> class.
> Apart if you load classes in the unamed module, you can not load a class
> in a non existing package anyway (apart if you generate your own
> module-info),
> so you need at least a dummy class to define a package, so you can use it
> to get a Lookup.
>
> R?mi
>
>
>
> Am Fr., 16. Apr. 2021 um 16:21 Uhr schrieb Remi Forax <forax at univ-mlv.fr>:
>
>> ----- Mail original -----
>> > De: "Rafael Winterhalter" <winterhalter at openjdk.java.net>
>> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>,
>> "serviceability-dev" <serviceability-dev at openjdk.java.net>
>> > Envoy?: Vendredi 16 Avril 2021 15:52:07
>> > Objet: RFR: 8200559: Java agents doing instrumentation need a means to
>> define auxilary classes
>>
>> > To allow agents the definition of auxiliary classes, an API is needed
>> to allow
>> > this. Currently, this is often achieved by using `sun.misc.Unsafe` or
>> > `jdk.internal.misc.Unsafe` ever since the `defineClass` method was
>> removed from
>> > `sun.misc.Unsafe`.
>>
>> You can already use Lookup.defineClass() + privateLookupIn() +
>> Instrumentation.redefineModule() for that ?
>>
>> R?mi
>>
>> >
>> > -------------
>> >
>> > Commit messages:
>> > - 8200559: Java agents doing instrumentation need a means to define
>> auxiliary
>> > classes
>> >
>> > Changes: https://git.openjdk.java.net/jdk/pull/3546/files
>> > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00
>> >  Issue: https://bugs.openjdk.java.net/browse/JDK-8200559
>> >  Stats: 185 lines in 4 files changed: 185 ins; 0 del; 0 mod
>> >  Patch: https://git.openjdk.java.net/jdk/pull/3546.diff
>> >  Fetch: git fetch https://git.openjdk.java.net/jdk
>> pull/3546/head:pull/3546
>> >
>> > PR: https://git.openjdk.java.net/jdk/pull/3546
>>
>
>

From raffaello.giulietti at gmail.com  Fri Apr 16 16:48:59 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 16 Apr 2021 18:48:59 +0200
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
Message-ID: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>

Hello,

does the enhancement proposed in [1] make sense, both today and when 
wrappers will be migrated to primitive classes?
If so, it should be rather simple to add it and I could prepare a PR.
If not, the issue might perhaps be closed.


Greetings
Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-8252827

From herrick at openjdk.java.net  Fri Apr 16 16:56:39 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 16 Apr 2021 16:56:39 GMT
Subject: RFR: 8263154: [macos] DMG builds have finder errors
In-Reply-To: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
References: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
Message-ID: <Bqx4wazbWQaG3G5RJATv7X5l8awWit2g2fKYVsf1Fqs=.0bcc889d-9c40-4a04-8cbe-3aa6e8dca42b@github.com>

On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Issue was reproducible when install-dir points to some invalid location.
>  - Fixed by defaulting DMG drag and drop location to /Applications folder and --install-dir will be ignored with warning for DMG.
>  - I do not see any way to support other valid, but uncommon locations for drag and drop. For example: /Users/USERNAME/Applications is not possible to support since user name is not known. /usr/bin requires root privileges and should contain symbolic links. Locations which does not exist also not possible to support, since DMG cannot create paths. So /Applications/MyCompany is not possible for DMG.

Since target directory shown by apple script is only a suggestion, and user can drag app to anywhere in finder, I may be able to be convinced to ignore install-dir on dmg builds.
I don't think we should use Log.info() to say given install-dir is ignored, it should just be Log.verbose(). (I started the bad precedence when I used Log.info for messages about foreign app-image, this should have been Log.verbose() too).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3505

From bpb at openjdk.java.net  Fri Apr 16 17:05:43 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 16 Apr 2021 17:05:43 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]
In-Reply-To: <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
Message-ID: <DMkAz61UUwn0jmGXGO1U_rRoOACJCisPZ9c5XFdWYXs=.76e49872-21de-4f0d-a519-39e4f32addf9@github.com>

On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge master
>  - Fix bug in CharArrayReader and add unit test
>  - Clean up unit tests
>  - Revert off-heap code path
>  - Replace c-style array declarations
>  - Share work buffer between #skip and #read
>  - Update copyright year
>  - Implement review comment
>  - Revert StreamDecoder changes
>  - Implement CharArrayReader#read(CharBuffer)
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0

test/jdk/java/io/CharArrayReader/ReadCharBuffer.java line 50:

> 48:     @DataProvider(name = "buffers")
> 49:     public Object[][] createBuffers() {
> 50:         // test both on-heap and off-heap buffers has they may use different code paths

"as they may"

test/jdk/java/io/InputStreamReader/ReadCharBuffer.java line 52:

> 50:     @DataProvider(name = "buffers")
> 51:     public Object[][] createBuffers() {
> 52:         // test both on-heap and off-heap buffers has they make use different code paths

"as they may"

test/jdk/java/io/Reader/ReadCharBuffer.java line 51:

> 49:     @DataProvider(name = "buffers")
> 50:     public Object[][] createBuffers() {
> 51:         // test both on-heap and off-heap buffers has they make use different code paths

"as they may"

-------------

PR: https://git.openjdk.java.net/jdk/pull/1915

From brian.burkhalter at oracle.com  Fri Apr 16 17:23:51 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 16 Apr 2021 17:23:51 +0000
Subject: Looking for reviewer and sponsor for 4926314
In-Reply-To: <72099137-3641-9b3f-a399-d2d5c69de6bb@gmx.net>
References: <72099137-3641-9b3f-a399-d2d5c69de6bb@gmx.net>
Message-ID: <0715CFA5-3768-497E-A2D0-1CF2620D1AFF@oracle.com>

Hello Philippe,

> On Apr 16, 2021, at 8:43 AM, Philippe Marschall <kustos at gmx.net> wrote:
> 
> Hello
> 
> I am looking for reviewers and a sponsor for JDK-4926314: Optimize
> Reader.read(CharBuffer) [1]. The PR [2] went through quite some changes
> and is now back to few changes to reduce the impact and the risk.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-4926314
> [2] https://github.com/openjdk/jdk/pull/1915
> 
> Cheers
> Philippe

The implementation looks fine. I added a few minor comments about the tests.

I can review and sponsor this for you.

Thanks,

Brian

From bpb at openjdk.java.net  Fri Apr 16 17:24:44 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 16 Apr 2021 17:24:44 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]
In-Reply-To: <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
Message-ID: <Wqt5OEwmU9QkRPoIpJZfv36A1bPFFEHxzenFXG_IfPo=.6b716545-310c-4825-86d3-3ea13edb130d@github.com>

On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge master
>  - Fix bug in CharArrayReader and add unit test
>  - Clean up unit tests
>  - Revert off-heap code path
>  - Replace c-style array declarations
>  - Share work buffer between #skip and #read
>  - Update copyright year
>  - Implement review comment
>  - Revert StreamDecoder changes
>  - Implement CharArrayReader#read(CharBuffer)
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0

test/jdk/java/io/Reader/ReadCharBuffer.java line 83:

> 81:             buffer.limit(8 + 8192 + 1);
> 82:             buffer.position(8);
> 83:             assertEquals(reader.read(buffer), 8192 + 1);

Lines 80 + 83 might be easier to read if replaced with

            int position = 8;
            limit = position + 8192 + 1;
            buffer.limit(limit);
            buffer.position(position);
            assertEquals(reader.read(buffer), limit - position);

-------------

PR: https://git.openjdk.java.net/jdk/pull/1915

From Alan.Bateman at oracle.com  Fri Apr 16 17:31:37 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 16 Apr 2021 18:31:37 +0100
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <otJgXr8zEtbXJFznspEo-rahiUVnPSW3mcD7iOGo5s4=.941b58d9-2522-4d59-944c-1468c975c23e@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <otJgXr8zEtbXJFznspEo-rahiUVnPSW3mcD7iOGo5s4=.941b58d9-2522-4d59-944c-1468c975c23e@github.com>
Message-ID: <f44b8074-48a0-2501-b568-cd525580db1d@oracle.com>

On 16/04/2021 17:40, Rafael Winterhalter wrote:
> :
> I will try to make my case on the mailing list. I hoped this could get resolved within the release of Java 17 as this would make it possible to write agents without use of Unsafe API to support Java 17 and later. Since agents often are supplementary to a broad range of Java applications, the LTS release will likely be an important support boundary for years and years to come.
>
"are supplementary to a board range of Java applications" is part of the 
concern with the proposal. If possible, it would be good if the write-up 
could separate the requirements for injection/instrumentation by 
frameworks at runtime from the requirements of tool agents. If the 
requirements cover testing time and mocking then it would useful to 
separate those too.

Just to add to R?mi's comment: For frameworks/libraries, the 
Lookup.defineClass and defineHiddenClass APIs are to define classes in 
the same run-time package as the Lookup class. There isn't any API for 
libraries/frameworks to define class in a "new run-time package". 
There's a chunky project there. Part of it is the Lookup API itself, 
part of is that there isn't an exposed way to extend the set of packages 
in a named module. Mandy has done some exploration on this topic and may 
be able to say a bit more about this.

On Java agents, then I think the discussion will eventually lead into 
putting at least some restrictions on agents loaded into a running VM. 
Agents started on the command line with -javaagent are all-powerful but 
maybe agents loaded into a target VM get a restricted Instrumentation 
object that cannot redefine modules or retransform classes in named 
modules. The narrower requirement for agents doing load time 
instrumentation to define auxiliary classes in the same package as the 
class being loaded fits with the intent of the original API and I don't 
think is controversial.

-Alan

From bpb at openjdk.java.net  Fri Apr 16 17:36:37 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 16 Apr 2021 17:36:37 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits [v3]
In-Reply-To: <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
Message-ID: <aVEiCZJtHi7y8nMjUyrFxtpdAY3KQilN_imD0biX9p4=.27dc635b-868e-45aa-b9a6-4a3476130cc8@github.com>

On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inlining some single use variables

I think this looks all right. I assume you ran all the `java.math` tests.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3363

From stuart.marks at oracle.com  Fri Apr 16 17:40:55 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 16 Apr 2021 10:40:55 -0700
Subject: ReversibleCollection proposal
Message-ID: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>

This is a proposal to add a ReversibleCollection interface to the Collections 
Framework. I'm looking for comments on overall design before I work on detailed 
specifications and tests. Please send such comments as replies on this email thread.

Here's a link to a draft PR that contains the code diffs. It's prototype quality, 
but it should be good enough to build and try out:

     https://github.com/openjdk/jdk/pull/3533

And here's a link to a class diagram showing the proposed additions:

 
https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf

Thanks,

s'marks


# Ordering and Reversibility


A long-standing concept that's been missing from collections is that of the 
positioning, sequencing, or arrangement of elements as a structural property of a 
collection. (This is sometimes called the "iteration order" of a collection.) For 
example, a HashSet is not ordered, but a List is. This concept is mostly not 
manifested in the collections API.

Iterating a collection produces elements one after another in *some* sequence. The 
concept of "ordered" determines whether this sequence is defined or whether it's a 
coincidence of implementation. What does "having an order" mean? It implies that 
there is a first element and that each element has a successor. Since collections 
have a finite number of elements, it further implies that there is a last element 
that has no successor. However, it is difficult to discern whether a collection has 
a defined order. HashSet generally iterates its elements in the same undefined 
order, and you can't actually tell that it's not a defined order.

Streams do have a notion of ordering ("encounter order") and this is preserved, 
where appropriate, through the stream pipeline. It's possible to detect this by 
testing whether its spliterator has the ORDERED characteristic. Any collection with 
a defined order will have a spliterator with this characteristic. However, this is 
quite a roundabout way to determine whether a collection has a defined order. 
Furthermore, knowing this doesn't enable any additional operations. It only provides 
constraints on the stream's implementations (keeping the elements in order) and 
provides stronger semantics for certain operations. For example, findFirst() on an 
unordered stream is the same as findAny(), but actually finds the first element if 
the stream is ordered.

The concept of ordering is thus present in the system but is surfaced only in a 
fairly indirect way. We can strengthen abstraction of ordering by making a few 
observations and considering their implications.

Given that there is a first element and a last element, the sequence of elements has 
two ends. It's reasonable to consider operations (add, get, remove) on either end. 
Indeed, the Deque interface has a full complement of operations at each end. This is 
an oft-requested feature on various other collections.

Each element except for the last has a successor, implying that each element except 
for the first has a predecessor. Thus it's reasonable to consider iterating the 
elements from first to last or from last to first (that is, in forward or reverse 
order). Indeed, the concept of iterating in reverse order appears already in bits 
and pieces in particular places around the collections:

  - List has indexOf() and lastIndexOf()
  - Deque has removeFirstOccurrence() and removeLastOccurrence()
  - List has a ListIterator with hasPrevious/previous methods
  - Deque and NavigableSet have descendingIterator methods

Given an ordered collection, though, there's no general way to iterate it in reverse 
order. Reversed iteration isn't the most common operation, but there are some 
frequent use cases, such as operating on elements in most-recently-added order. 
Questions and bug reports about this have come up repeatedly over the years.

Unfortunately, iterating in reverse order is much harder than iterating in forward 
order. There are a variety of ways to iterate in forward order. For example, given a 
List, one can do any of the following:

     for (var e : list) { ... }
     list.forEach(...)
     list.stream()
     list.toArray()

However, to iterate a list in reverse order, one must use an explicit loop over 
ListIterator:

     for (var it = list.listIterator(list.size()); it.hasPrevious(); ) {
         var e = it.previous();
         ...
     }

Streaming the elements of a List in reverse order is even worse. One approach would 
be to implement a reverse-ordered Iterator that wraps a ListIterator and delegates 
hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then, this 
Iterator can be turned into a Spliterator, which is then turned into a Stream. (The 
code to do this is left as an exercise for the reader.) Obtaining the elements in 
reverse via other means -- forEach() or toArray() -- is similarly difficult.

Obtaining the elements in reverse order can be accomplished by adopting a concept 
from NavigableSet's descendingSet() method, which provides a reverse-ordered view 
collection. This view is also a NavigableSet, which means that any operation that 
can be performed on the original set can also be applied to the reverse-ordered 
view. If it were possible to obtain a similar reverse-ordered view on any kind of 
ordered collection, this would enable the elements to be processed in reverse order 
in any fashion, not just special-purposes APIs such as ListIterator or 
descendingIterator().


# LinkedHashSet


The main feature of LinkedHashSet is that it does have a defined ordering, as 
opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last 
element. However, LinkedHashSet is deficient in a number of ways:

  - access to and removal of the first element is reasonable (using an iterator) but 
it is not possible to add at the front

  - it is possible to add an element at the end, but access to and removal of the 
last element are expensive

  - it's not possible to iterate in reverse without copying the entire collection

Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so 
there is no fundamental implementation reason that prevents these operations from 
being supported. The main reason these operations aren't supported is probably that 
there hasn't been a good place to push such APIs.


# Proposal


Introduce a new ReversibleCollection<E> interface. This provides a new method to 
obtain a reverse-ordered view. It also contains several methods (copied from Deque) 
that allow operating on elements at both ends.


     interface ReversibleCollection<E> extends Collection<E> {
         ReversibleCollection<E> reversed();
         default void addFirst(E e)
         default void addLast(E e)
         default E getFirst()
         default E getLast()
         default E removeFirst()
         default E removeLast()
     }


The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are 
retrofitted to implement ReversibleCollection. They provide covariant overriding 
implementations of the reversed() method. For example, List.reversed() returns a 
List. Default implementations for all of these methods are provided in the 
appropriate interfaces.

Covariant overrides are also provided in several other classes. This presents a 
difficulty for LinkedHashSet, as there's no suitable return type for reversed(). To 
remedy this, we add another interface


     interface ReversibleSet<E> extends ReversibleCollection<E>, Set<E> { }


This adds no new methods but is essentially an intersection of ReversibleCollection 
and Set. As such, it's suitable as the return type of LinkedHashSet.reversed() and 
the set views of LinkedHashMap.

SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because 
SortedSet's ordering is determined by the comparison method and cannot be controlled 
explicitly.

LinkedHashSet::addFirst and addLast add the element at the appropriate position or 
reposition the element if it is already present in the set.

New methods are added to LinkedHashMap

     V putFirst(K, V)
     V putLast(K, V)

which put the mapping at the designated position or reposition the mapping if is 
already present in the map.


# Design & Implementation Issues


Covariant overrides for reversed() are provided where possible. However, there is a 
conflict between List and Deque, as there are examples in the JDK (such as 
LinkedList) that implement both List and Deque. Since List is much more popular than 
Deque, I've decided against adding a covariant override to Deque. Instead, a method 
Deque::reversedDeque is added that returns a Deque, and Deque::reversed returns 
ReversibleCollection.

There is no ReversibleMap interface. Most iteration over maps is over the entrySet, 
keySet, or values views. NavigableMap already has descendingMap(), and LinkedHashMap 
provides ReversibleX views, which cover most of the cases already.

Introducing new methods into an interface hierarchy always raises the possibility of 
name clashes. I've done some searching but I haven't found any major issues, but we 
should be on the lookout for this. I'll continue to do more searching for such 
conflicts.

Introducing covariant overrides on existing methods (notably LinkedHashMap entrySet, 
keySet, and values) could present incompatibility issues with subclasses that 
override these methods. I've done some searching and again I haven't found major 
problems, but this is nonetheless a point of concern. I'll do more searching here, too.

The default implementations for List::reversed, Deque::reversed, and 
SortedSet::reversed return reverse-ordered views that are implemented using only 
public methods of the original interface. This demonstrates the feasibility of 
retrofitting reverse ordering onto any instance of these interfaces. Similarly, the 
various add/get/remove methods' default implementations are all implementable in 
terms of an iterator or reverse-ordered iterator. That said, some concurrent 
collection implementations will need to override these default implementations in 
order to preserve their safety invariants. It would probably also be wise to add 
optimized implementations to the more commonly-used collection implementations.

Given that a ReversibleCollection has a defined ordering, any spliterator obtained 
from such a collection should have the Spliterator.ORDERED characteristic.

This proposal is related to a previous discussion on a similar topic, where Tagir 
Valeev had proposed OrderedSet and OrderedMap:

     http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066028.html

I think there were some good ideas in there and in the ensuing discussion, but it 
didn't go anywhere. Several of the concepts in this proposal are an evolution of 
some ideas discussed in that thread.

One of the ideas from that thread was to use Deque as a common interface for many 
collections to support reversibility and operations at the ends. We've abandoned 
that idea in this proposal. The reasons are that it's cluttered with a bunch of 
methods that are inherited from Queue. Also, some methods are null-returning instead 
of throwing, which introduces confusion for collections that can contain nulls.

# END

From forax at univ-mlv.fr  Fri Apr 16 17:47:16 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 16 Apr 2021 19:47:16 +0200 (CEST)
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <CA+DM0AmH4tqh=PBmUfE35oroNG0O3bdWMoVcVnaDdYgWs1sodw@mail.gmail.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <1665771929.1527476.1618582874230.JavaMail.zimbra@u-pem.fr>
 <CA+DM0A=eUqzLS9Ej+0mg5z_KOPZHeQ4bHAtwBdxRQXqWErvWEA@mail.gmail.com>
 <1924898916.1609700.1618590932170.JavaMail.zimbra@u-pem.fr>
 <CA+DM0AmH4tqh=PBmUfE35oroNG0O3bdWMoVcVnaDdYgWs1sodw@mail.gmail.com>
Message-ID: <259848735.1634666.1618595236467.JavaMail.zimbra@u-pem.fr>

> De: "Rafael Winterhalter" <rafael.wth at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Rafael Winterhalter" <winterhalter at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>, "serviceability-dev"
> <serviceability-dev at openjdk.java.net>
> Envoy?: Vendredi 16 Avril 2021 18:41:26
> Objet: Re: RFR: 8200559: Java agents doing instrumentation need a means to
> define auxilary classes

> This would be a problem, however. Since there is currently no official way of
> defining a class, and since Java agents do not control the class loading order,
> if a class was loaded for the first time, you could for example not add a field
> with a type of an auxiliary class that you had planned to inject. A class being
> loaded is normally the first opportunity for a Java agent and if no witness
> class is available at this point, using a method handle is no option. Since it
> is difficult to know if such a witness class is available in the general case,
> it would also add quite a performance and managerial toll on agent authors. I
> would hope that an API equally convenient to today's unsafe options could be
> added.

I was thinking about adding a dummy class in the package you want to load classes. 

Anyway, you can also call ClassLoader.defineClass directly. Put the code that calls defineClass in a module and use Instrumentation.redefineModule() to open java.base to this module. 

R?mi 

> Am Fr., 16. Apr. 2021 um 18:35 Uhr schrieb < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] >:

>>> De: "Rafael Winterhalter" < [ mailto:rafael.wth at gmail.com | rafael.wth at gmail.com
>>> ] >
>>> ?: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "Rafael Winterhalter" < [ mailto:winterhalter at openjdk.java.net |
>>> winterhalter at openjdk.java.net ] >, "core-libs-dev" < [
>>> mailto:core-libs-dev at openjdk.java.net | core-libs-dev at openjdk.java.net ] >,
>>> "serviceability-dev" < [ mailto:serviceability-dev at openjdk.java.net |
>>> serviceability-dev at openjdk.java.net ] >
>>> Envoy?: Vendredi 16 Avril 2021 18:27:46
>>> Objet: Re: RFR: 8200559: Java agents doing instrumentation need a means to
>>> define auxilary classes

>>> Not by my understanding. A suitable lookup requires a loaded class for the
>>> package. A Java agent might however not provide a handle for a class that is
>>> not yet loaded. Or how would you suggest to approach this ?

>> yes, you need a witness class in the package you want to define a new class.
>> Apart if you load classes in the unamed module, you can not load a class in a
>> non existing package anyway (apart if you generate your own module-info),
>> so you need at least a dummy class to define a package, so you can use it to get
>> a Lookup.

>> R?mi

>>> Am Fr., 16. Apr. 2021 um 16:21 Uhr schrieb Remi Forax < [
>>> mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >:

>>>> ----- Mail original -----
>>>>> De: "Rafael Winterhalter" < [ mailto:winterhalter at openjdk.java.net |
>>>> > winterhalter at openjdk.java.net ] >
>>>>> ?: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net |
>>>>> core-libs-dev at openjdk.java.net ] >, "serviceability-dev" < [
>>>>> mailto:serviceability-dev at openjdk.java.net |
>>>> > serviceability-dev at openjdk.java.net ] >
>>>> > Envoy?: Vendredi 16 Avril 2021 15:52:07
>>>>> Objet: RFR: 8200559: Java agents doing instrumentation need a means to define
>>>> > auxilary classes

>>>> > To allow agents the definition of auxiliary classes, an API is needed to allow
>>>> > this. Currently, this is often achieved by using `sun.misc.Unsafe` or
>>>> > `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from
>>>> > `sun.misc.Unsafe`.

>>>> You can already use Lookup.defineClass() + privateLookupIn() +
>>>> Instrumentation.redefineModule() for that ?

>>>> R?mi


>>>> > -------------

>>>> > Commit messages:
>>>> > - 8200559: Java agents doing instrumentation need a means to define auxiliary
>>>> > classes

>>>>> Changes: [ https://git.openjdk.java.net/jdk/pull/3546/files |
>>>> > https://git.openjdk.java.net/jdk/pull/3546/files ]
>>>>> Webrev: [ https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00 |
>>>> > https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00 ]
>>>>> Issue: [ https://bugs.openjdk.java.net/browse/JDK-8200559 |
>>>> > https://bugs.openjdk.java.net/browse/JDK-8200559 ]
>>>> > Stats: 185 lines in 4 files changed: 185 ins; 0 del; 0 mod
>>>>> Patch: [ https://git.openjdk.java.net/jdk/pull/3546.diff |
>>>> > https://git.openjdk.java.net/jdk/pull/3546.diff ]
>>>>> Fetch: git fetch [ https://git.openjdk.java.net/jdk |
>>>> > https://git.openjdk.java.net/jdk ] pull/3546/head:pull/3546

>>>>> PR: [ https://git.openjdk.java.net/jdk/pull/3546 |
>>>> > https://git.openjdk.java.net/jdk/pull/3546 ]

From rriggs at openjdk.java.net  Fri Apr 16 18:33:38 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Apr 2021 18:33:38 GMT
Subject: RFR: 8264208: Console charset API [v9]
In-Reply-To: <tSR166SSfd65-2r-NLrbR4Q1F7uWCsYFJqZ3G0VkMbM=.f754091d-d858-46c4-b5d3-3196d03ef3bd@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <tSR166SSfd65-2r-NLrbR4Q1F7uWCsYFJqZ3G0VkMbM=.f754091d-d858-46c4-b5d3-3196d03ef3bd@github.com>
Message-ID: <OWZ2x3pmyQlpyt5jFp1P3kFo7pnB-9PEt31yq4svgyM=.d540ab80-1032-4d8c-8295-5bef592b2da9@github.com>

On Thu, 15 Apr 2021 18:29:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified javadocs per suggestions.

For the test, can it be re-written in Java.  
The direction has been to avoid creating new shell tests as they are fragile.
There are test utilities in ProcessTool to make launching and checking for output very easy.

src/java.base/share/classes/java/io/InputStreamReader.java line 48:

> 46:  * <p> For top efficiency, consider wrapping an InputStreamReader within a
> 47:  * BufferedReader.  For example:
> 48:  *

Oddly, none of the reference in this class to the default charset are links to Charset.defaultCharset().
That would be a useful addition, either in the class javadoc or in the 1-arg constructor that uses the default charset.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From roger.riggs at oracle.com  Fri Apr 16 18:36:55 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 16 Apr 2021 14:36:55 -0400
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
In-Reply-To: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
References: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
Message-ID: <e71bbf02-9080-1afa-42af-2094e751688f@oracle.com>

Hi,

Is there any way to quantify the savings?
And what technique can be applied to limit the size of the cache.
The size of the small integer cache is somewhat arbitrary.

Regards, Roger

On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
> Hello,
>
> does the enhancement proposed in [1] make sense, both today and when 
> wrappers will be migrated to primitive classes?
> If so, it should be rather simple to add it and I could prepare a PR.
> If not, the issue might perhaps be closed.
>
>
> Greetings
> Raffaello
>
> ----
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8252827


From alanb at openjdk.java.net  Fri Apr 16 18:43:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 16 Apr 2021 18:43:41 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]
In-Reply-To: <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
Message-ID: <vpxX4MI1arJM6roh52U4qoIgti9_2egKMwNrPRWkheU=.24beb1d5-f692-49ca-b7f4-690c20c3dfcc@github.com>

On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge master
>  - Fix bug in CharArrayReader and add unit test
>  - Clean up unit tests
>  - Revert off-heap code path
>  - Replace c-style array declarations
>  - Share work buffer between #skip and #read
>  - Update copyright year
>  - Implement review comment
>  - Revert StreamDecoder changes
>  - Implement CharArrayReader#read(CharBuffer)
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0

Thanks for rolling back to the direct buffer case, the updated implementation changes look okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1915

From bpb at openjdk.java.net  Fri Apr 16 18:48:42 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 16 Apr 2021 18:48:42 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]
In-Reply-To: <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
Message-ID: <tTtK2LXEj8z2A58L3rgnfQc5ysATZprgXzh_21FfZ0s=.4e8aa616-9ceb-4630-90c3-424ebd0729e5@github.com>

On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge master
>  - Fix bug in CharArrayReader and add unit test
>  - Clean up unit tests
>  - Revert off-heap code path
>  - Replace c-style array declarations
>  - Share work buffer between #skip and #read
>  - Update copyright year
>  - Implement review comment
>  - Revert StreamDecoder changes
>  - Implement CharArrayReader#read(CharBuffer)
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0

Approved modulo my "as they may" remarks on three comment lines in the tests.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1915

From raffaello.giulietti at gmail.com  Fri Apr 16 18:54:40 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 16 Apr 2021 20:54:40 +0200
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
In-Reply-To: <e71bbf02-9080-1afa-42af-2094e751688f@oracle.com>
References: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
 <e71bbf02-9080-1afa-42af-2094e751688f@oracle.com>
Message-ID: <371602c3-69b4-1a1f-1e12-1d04914f3463@gmail.com>

I guess the reporter meant to limit the cache range similarly to the one 
used for valueOf().

I have no clue about the benefit/cost ratio for the proposed String 
cache. It really depends on usage, workload, etc. One can easily imagine 
both extreme scenarios but it's hard to tell how the average one would look.

My post is only about either solving the issue by implementing the 
cache, which I can contribute to; or closing it because of lack of 
real-world need or interest.


Greetings
Raffaello


On 2021-04-16 20:36, Roger Riggs wrote:
> Hi,
> 
> Is there any way to quantify the savings?
> And what technique can be applied to limit the size of the cache.
> The size of the small integer cache is somewhat arbitrary.
> 
> Regards, Roger
> 
> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
>> Hello,
>>
>> does the enhancement proposed in [1] make sense, both today and when 
>> wrappers will be migrated to primitive classes?
>> If so, it should be rather simple to add it and I could prepare a PR.
>> If not, the issue might perhaps be closed.
>>
>>
>> Greetings
>> Raffaello
>>
>> ----
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8252827
> 

From naoto at openjdk.java.net  Fri Apr 16 18:58:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 18:58:35 GMT
Subject: RFR: 8264208: Console charset API [v9]
In-Reply-To: <OWZ2x3pmyQlpyt5jFp1P3kFo7pnB-9PEt31yq4svgyM=.d540ab80-1032-4d8c-8295-5bef592b2da9@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <tSR166SSfd65-2r-NLrbR4Q1F7uWCsYFJqZ3G0VkMbM=.f754091d-d858-46c4-b5d3-3196d03ef3bd@github.com>
 <OWZ2x3pmyQlpyt5jFp1P3kFo7pnB-9PEt31yq4svgyM=.d540ab80-1032-4d8c-8295-5bef592b2da9@github.com>
Message-ID: <SD-k6wtwvnf9Fa06M8QiWjDv6DtqzKfsjGM2OA_CJ4o=.b0a2270d-f55a-464d-8f57-04c077c1154a@github.com>

On Fri, 16 Apr 2021 18:15:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified javadocs per suggestions.
>
> src/java.base/share/classes/java/io/InputStreamReader.java line 48:
> 
>> 46:  * <p> For top efficiency, consider wrapping an InputStreamReader within a
>> 47:  * BufferedReader.  For example:
>> 48:  *
> 
> Oddly, none of the reference in this class to the default charset are links to Charset.defaultCharset().
> That would be a useful addition, either in the class javadoc or in the 1-arg constructor that uses the default charset.

Thanks, Roger. Both are good suggestions. Will incorporate them into the next iteration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From rriggs at openjdk.java.net  Fri Apr 16 19:09:34 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Apr 2021 19:09:34 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v2]
In-Reply-To: <Q0KrFJ5y96KgNO15EOLFT6XU-0OkxjiA3ezBf0lujy8=.9e2d4b07-820c-4c86-9475-fa6b8696d3c3@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <Q0KrFJ5y96KgNO15EOLFT6XU-0OkxjiA3ezBf0lujy8=.9e2d4b07-820c-4c86-9475-fa6b8696d3c3@github.com>
Message-ID: <aA8_XzKvy7slrlD1D2IAtFjCVdCGJnrMM77XW87_Zzs=.c8fda6d1-ba0f-4dfe-8981-80b828b39468@github.com>

On Thu, 15 Apr 2021 19:26:48 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
>> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
>> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
>> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
>> 
>> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
>> 
>> The comparative results are here:
>> 
>> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
>> 
>> The jmh-result.json files are here:
>> 
>> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
>> 
>> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
>> 
>> So WDYT?
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add String.join benchmark method to StringJoinerBenchmark and adjust some parameters to cover bigger range

Look very good.

src/java.base/share/classes/java/lang/String.java line 3254:

> 3252: 
> 3253:         byte[] value = StringConcatHelper.newArray(((long) icoder << 32) | llen);
> 3254:         int off = 0;

StringConcatHelper.newArray() can double the length (based on the coder) and it is then truncated to 32 bits when passed to UNSAFE.allocatlUnitializedArray.
The test of length above only ensures llen can be truncated to 32 bits without loss of data.

src/java.base/share/classes/java/lang/String.java line 3256:

> 3254:         int off = 0;
> 3255:         prefix.getBytes(value, off, coder); off += prefix.length();
> 3256:         for (int i = 0; i < size; i++) {

Can you save a branch inside the loop by handling element 0 outside the loop and
then do the loop for the rest?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From dcubed at openjdk.java.net  Fri Apr 16 19:35:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 19:35:04 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64
Message-ID: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>

A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:

- JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
- JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
- JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
- JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64
- JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
- JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

-------------

Commit messages:
 - 8265370: ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64
 - 8265368: ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
 - 8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64
 - 8265363: ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
 - 8265361: ProblemList a few compiler/whitebox tests on macos-aarch64
 - 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64

Changes: https://git.openjdk.java.net/jdk/pull/3549/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265358
  Stats: 16 lines in 3 files changed: 16 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3549/head:pull/3549

PR: https://git.openjdk.java.net/jdk/pull/3549

From bpb at openjdk.java.net  Fri Apr 16 19:44:33 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 16 Apr 2021 19:44:33 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64
In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
Message-ID: <SsQBbhEMuHyCLH2COOP33e6p8WCRtUZ2aaj5wfbrtEQ=.b88a2bcb-a102-4f64-b062-cc1656c810a4@github.com>

On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
> 
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
> - JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64
> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From mikael at openjdk.java.net  Fri Apr 16 19:49:33 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Fri, 16 Apr 2021 19:49:33 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64
In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
Message-ID: <H7bO5BjUb9UQeO0EejrcQaMLKyGy5-xzHfdhDaj3Q1A=.053183fd-8147-4659-beb3-78f816ddd0d5@github.com>

On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
> 
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
> - JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64
> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From igraves at openjdk.java.net  Fri Apr 16 19:50:36 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 16 Apr 2021 19:50:36 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits [v3]
In-Reply-To: <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
Message-ID: <hYcI1pxic8Rubb1tBu18L-vF2PpIplAO2hYpZ_22_sI=.ef69e1dd-fb72-4554-96e8-0fc1dd7ea896@github.com>

On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inlining some single use variables

That's correct. Passes `java.math` tests. Ran it again, just to be sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3363

From igraves at openjdk.java.net  Fri Apr 16 20:08:39 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 16 Apr 2021 20:08:39 GMT
Subject: Integrated: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits
In-Reply-To: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
Message-ID: <-dcdAT5JQH7sVtoVVNWqJuz8T4-JYBda9FM-EOc25bE=.376e7b4d-1c05-4b18-9b0b-2e823dd7988c@github.com>

On Tue, 6 Apr 2021 20:34:52 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

This pull request has now been integrated.

Changeset: 0bdc3e7a
Author:    Ian Graves <igraves at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0bdc3e7a
Stats:     66 lines in 2 files changed: 62 ins; 1 del; 3 mod

8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits

Reviewed-by: rriggs, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3363

From winterhalter at openjdk.java.net  Fri Apr 16 20:09:34 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Fri, 16 Apr 2021 20:09:34 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
Message-ID: <G9kGpi5IXI1SSAPLSM14zOqMmHvlj5aWSZUrwWGk5qY=.8e21afe1-0d2a-48a0-86de-e3e5b6cdc73a@github.com>

On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.

I have never seen a need for a non-agent to define a class in a
non-existing package. Injection is typically required if you want to work
with package-private types or methods which is really only relevant for the
Spring framework, but even there I do not think it's such a big area that
it cannot be addressed. Non-agent code generation is typically the use of
proxies where the code generation framework is sharing a class loader with
the user code and there is normally a way to weave it. Agents on the other
hand have to deal with unknown class loader hierarchies and it can be
necessary to inject code into a common class loader parent without
instrumenting classes in this loader or even knowing any classes of this
loader. It's really agents where this is required and therefore
Instrumentation is a good target for such an addition.

I have never heard about a 'discussion [that] will eventually lead into
putting at least some restrictions on agents loaded into a running VM' and
as a heavy user and someone who has helped to write a long row of
commercial agents and followed them into their use in production and who
has seen how helpful they are in reducing deployment complexity, I can only
hope that you will change your mind on this. Dynamically attached agents
must already run as the same user as the target process. If you are
concerned about agents 'illegally intruding' your Java process, I'd say you
have bigger security issues at hand and it is already possible to disable
dynamic attachment if you want to avoid it. Dynamic attachment has become
pretty much the default approach for a lot of Java tooling in production
environments. It has proven to be very convenient if a for example a
tracing tool is scanning Java processes to attach to them, rather than
requiring the deployment operators to be explicitly set up command line
arguments which are easily forgotten if they only need to be added in some
environments. This reduction in complexity for operations has literally
saved millions of dollars to Java users and Oracle customers. This makes
Java a popular choice, especially compared to languages such as Go where
this is naturally not possible. It's easy and there is no record of this
feature doing any harm. I would not see any good reason to restrict this by
default.

That said, even if it was restricted in the future, this would mean that
some of the Instrumentation API methods will throw exceptions in the
future. There would not be much difference if an introduced defineClass
method would do the same.

Am Fr., 16. Apr. 2021 um 19:33 Uhr schrieb mlbridge[bot] <
***@***.***>:

> *Mailing list message from Alan Bateman ***@***.***> on
> core-libs-dev ***@***.***>:*
>
> On 16/04/2021 17:40, Rafael Winterhalter wrote:
>
> :
> I will try to make my case on the mailing list. I hoped this could get
> resolved within the release of Java 17 as this would make it possible to
> write agents without use of Unsafe API to support Java 17 and later. Since
> agents often are supplementary to a broad range of Java applications, the
> LTS release will likely be an important support boundary for years and
> years to come.
>
> "are supplementary to a board range of Java applications" is part of the
> concern with the proposal. If possible, it would be good if the write-up
> could separate the requirements for injection/instrumentation by
> frameworks at runtime from the requirements of tool agents. If the
> requirements cover testing time and mocking then it would useful to
> separate those too.
>
> Just to add to R?mi's comment: For frameworks/libraries, the
> Lookup.defineClass and defineHiddenClass APIs are to define classes in
> the same run-time package as the Lookup class. There isn't any API for
> libraries/frameworks to define class in a "new run-time package".
> There's a chunky project there. Part of it is the Lookup API itself,
> part of is that there isn't an exposed way to extend the set of packages
> in a named module. Mandy has done some exploration on this topic and may
> be able to say a bit more about this.
>
> On Java agents, then I think the discussion will eventually lead into
> putting at least some restrictions on agents loaded into a running VM.
> Agents started on the command line with -javaagent are all-powerful but
> maybe agents loaded into a target VM get a restricted Instrumentation
> object that cannot redefine modules or retransform classes in named
> modules. The narrower requirement for agents doing load time
> instrumentation to define auxiliary classes in the same package as the
> class being loaded fits with the intent of the original API and I don't
> think is controversial.
>
> -Alan
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/3546#issuecomment-821329136>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABCIA4CCOJR6LGGDX5YSHQTTJBYG3ANCNFSM43BSDEGQ>
> .
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From mikael at openjdk.java.net  Fri Apr 16 20:16:06 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Fri, 16 Apr 2021 20:16:06 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64 [v2]
In-Reply-To: <qJvuAkCdpiNuj-O3-sgVhYSf74WRUOkBL18kDKoKuGI=.3a7f93f7-f4bf-47ef-9a69-51bf29ddc25b@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
 <qJvuAkCdpiNuj-O3-sgVhYSf74WRUOkBL18kDKoKuGI=.3a7f93f7-f4bf-47ef-9a69-51bf29ddc25b@github.com>
Message-ID: <SI2K-ILzSbVIEWY6g0doYk6Yd9PMD4zhkuj1Ej_BS3Y=.acd3e049-0a6b-4622-93f0-5d17614137ec@github.com>

On Fri, 16 Apr 2021 20:12:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
>> 
>> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
>> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
>> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
>> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
>> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes for JDK-8265366 at @fguallini's request.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From dcubed at openjdk.java.net  Fri Apr 16 20:16:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 20:16:06 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64 [v2]
In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
Message-ID: <qJvuAkCdpiNuj-O3-sgVhYSf74WRUOkBL18kDKoKuGI=.3a7f93f7-f4bf-47ef-9a69-51bf29ddc25b@github.com>

> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
> 
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Remove changes for JDK-8265366 at @fguallini's request.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3549/files
  - new: https://git.openjdk.java.net/jdk/pull/3549/files/5fb3de6a..7f245f4e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3549/head:pull/3549

PR: https://git.openjdk.java.net/jdk/pull/3549

From dcubed at openjdk.java.net  Fri Apr 16 20:16:07 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 20:16:07 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64 [v2]
In-Reply-To: <SsQBbhEMuHyCLH2COOP33e6p8WCRtUZ2aaj5wfbrtEQ=.b88a2bcb-a102-4f64-b062-cc1656c810a4@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
 <SsQBbhEMuHyCLH2COOP33e6p8WCRtUZ2aaj5wfbrtEQ=.b88a2bcb-a102-4f64-b062-cc1656c810a4@github.com>
Message-ID: <Jr2m61yqaIunXX84ywc8hAfRZBCRoJP4sNMl6mbQGvM=.079ecccf-ab4f-4339-93c1-66acbd5da0eb@github.com>

On Fri, 16 Apr 2021 19:42:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove changes for JDK-8265366 at @fguallini's request.
>
> Marked as reviewed by bpb (Reviewer).

@bplb and @vidmik - Thanks for the reviews.

I'm removing the changes for JDK-8265366 at @fguallini's request.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From rafael.wth at gmail.com  Fri Apr 16 20:18:31 2021
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 16 Apr 2021 22:18:31 +0200
Subject: RFC: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes
Message-ID: <CA+DM0AmS2phBdiwEhBM3eXpzZmTbnxN1B4a=Hk=+zz8RpSXxow@mail.gmail.com>

I am trying to revive issue 8200559 (
https://bugs.openjdk.java.net/browse/JDK-8200559) which was briefly
discussed on this mailing list over three years ago (
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000405.html). I
am hopeful that a solution could be reached prior to releasing Java 17.
With the LTS label, JVMs of that version are likely to be seen for quite
some time and without a fix, many Java agents will still rely on unsafe API
to support that version. With the issue resolved, agents that aim to
support Java 17 as a baseline could be implemented using only official API
which I consider a desirable milestone. This would also allow me to remove
use of unsafe API from a range of popular open source projects that I
maintain once Java 17 becomes their baseline. I have proactively added a
pull request (https://github.com/openjdk/jdk/pull/3546) with what I
consider to be the most complete and satisfactory solution for agent
developers. I implemented this patch to test potential migration for my own
and customer projects and can confirm that this would indeed make any
unsafe API obsolete.

I had already lined out why APIs such as MethodHandles.Lookup::defineClass
do not work for ClassFileTransformers in my original posting. I will try to
avoid reiterating on my original argument. As a result of this discussion,
an API was proposed where the ClassFileTransformer would be overloaded with
an additional parameter that receives an instance of ClassDefiner as its
argument. The instance would allow you to define a class but assert that
the auxiliary class is located in the same package as the class under
transformation. For example, if a class:

package p;
class C {
  void m(A a) {
    a.callback(new Value());
  }
}

would be instrumented to become:

package p;
class C {
  void m(A a) {
    a.callback(new Replacement()); // changed
  }
}

then ClassDefiner would assert that the auxiliary class Replacement is also
defined in package 'p'. In my eyes, this is not a very satisfying solution.
In some cases, a Java agent is for example using existing classes to carry
additional state between two instrumented classes. For instance, class
Replacement might be used as a carrier of additional state to pass to class
A which is itself instrumented as follows:

package p2;
class A {
  void callback(Value v) {
    if (v instanceof Replacement) {
      // read data of v and process
    }
  }
}

This example is far from constructed, but a common and effective strategy
to implement tracing, security monitoring or code intelligence.

It is of course possible to implement this pattern by using the
package-restricted ClassDefiner. It is however rather costly and
complicated to implement. A ClassFileTransformer is a simple callback that
is not in control of the class loading order but is only invoked whenever a
class is loaded for the first time. The first class to be loaded might of
course be either C or A, it might not even be deterministic for the same
application. If the class Replacement was required to live in the package
of the class that is currently instrumented, Replacement would need to be
defined in either p or p2, depending on the materialized class loading
order. This would require some form of state management in the class file
transformer to keep track of the package that one would need to use when
instrumenting the second class. Due to parallel class loading and with
constellations that involve even more classes, this can get quite
complicated. Using a stable package name is however not only a convenience.
The name of a package can affect reflection-heavy frameworks, debugging
opportunities, logs, stacktraces and more.

Furthermore, one should consider the costs of migrating an existing agent
in the light that an agent can easily open jdk.internal.misc.Unsafe by
using the instrumentation API or use a class file transformer to erase the
explicit package assertion of ClassDefiner. Current agents often use
sun.misc.Unsafe or jdk.internal.misc.Unsafe to invoke the defineClass
method of these types. This API is very performant and easy to use. To some
degree, it is even possible to emulate the Unsafe API using ClassDefiner by
strategically retransforming classes in the right package. The following
code allows to define a class using a witness class by using a
non-operational class file transformer:

static Class<?> defineClass(Instrumentation inst, final Class<?> witness,
final byte[] classFile) throws Exception {
  AtomicReference<Class<?>> ref = new AtomicReference<>();
  ClassFileTransformer definer = new ClassFileTransformer() {
    @Override
    public byte[] transform(ClassDefiner classDefiner,
                            Module module,
                            ClassLoader loader,
                            String className,
                            Class<?> classBeingRedefined,
                            ProtectionDomain protectionDomain,
                            byte[] classfileBuffer) {
      if (classBeingRedefined == witness) {
        ref.set(classDefiner.define(classFile));
      }
      return null;
    }
  };
  inst.addTransformer(definer, true);
  try {
    inst.retransformClasses(witness);
  } finally {
    inst.removeTransformer(definer);
  }
  return ref.get();
}

In this sense, Java agents already have the possibility to define new
classes within any package. The restriction that ClassDefiner introduces is
therefore merely cosmetic and does not really reduce the actual
capabilities of any owner of an instance of Instrumentation. Beyond that,
JNI already offers a similar API for defining a class which is also used as
there are wrappers that compile the method for any common platform and
architecture.

Finally, many Java agents need to define general infrastructure classes to
function. A tracing framework might for example want to be notified of all
HTTP calls of known frameworks. To accomplish this, some form of common
callback is injected into a generally known class loader, often the
globally visible bootstrap loader:

package com.acme.tracer;
public class AgentCallback {
  public static void callback(String framework) { ... }
}

This is typically done before registering a first ClassFileTransformer
which is later instrumenting framework classes to invoke this callback,
none of which is defined by the boot loader which is only used to assure
that the counter can be seen from all application classes and the agent
framework alike. At the moment,
Instrumentation::appendToBootstrapClassLoaderSearch is the most feasible
approach to this. However, the API also has significant downsides. First of
all, it is of course restricted to the boot or system loader by the way the
API is set up. In some scenarios, another class loader would however be
more appropriate, for example if a JVM is segmented as in a JEE container
where the callback should only apply to a specific deployment area and
might therefore better be placed in a different class loader that is root
to the deployment. Additionally, it is rather inefficient to serialize
these auxiliary classes to the file system, only to pass it to the API
which then reads them back into memory to load the contained classes. In
some environments, a file system for such purposes is not even available.

For all these reasons, I still believe that adding
Instrumentation::defineClass is the best solution to address all of these
legitimate needs. Java agents have created excellent tooling for the JVM
which make the platform successful in the enterprise. In my eyes it is
overdue that these legitimate use cases can start relying on a stable API.
Going this route would offer an easy path for migration and agents that
supported older versions than Java 17 could easily replace their usage of
Unsafe by this similar API which promises a quick adoption. Alternatively,
I am afraid many will find ways around, even by emulating unsafe using
official API as I demonstrated, the cost being decreased performance and
convenience.

Thank you for your comments. I really hope this can be addressed before 17
is released, I am hopeful that this would make the use of unsafe API in
agents disappear sooner rather than later.

Best regards, Rafael

From rafael.wth at gmail.com  Fri Apr 16 20:20:03 2021
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 16 Apr 2021 22:20:03 +0200
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <f44b8074-48a0-2501-b568-cd525580db1d@oracle.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <otJgXr8zEtbXJFznspEo-rahiUVnPSW3mcD7iOGo5s4=.941b58d9-2522-4d59-944c-1468c975c23e@github.com>
 <f44b8074-48a0-2501-b568-cd525580db1d@oracle.com>
Message-ID: <CA+DM0AnNOFEtudMQbt1xT-DLDs48H3FkAEphESnw20FfqLGfrw@mail.gmail.com>

I have never seen a need for a non-agent to define a class in a
non-existing package. Injection is typically required if you want to work
with package-private types or methods which is really only relevant for the
Spring framework, but even there I do not think it's such a big area that
it cannot be addressed. Non-agent code generation is typically the use of
proxies where the code generation framework is sharing a class loader with
the user code and there is normally a way to weave it. Agents on the other
hand have to deal with unknown class loader hierarchies and it can be
necessary to inject code into a common class loader parent without
instrumenting classes in this loader or even knowing any classes of this
loader. It's really agents where this is required and therefore
Instrumentation is a good target for such an addition.

I have never heard about a 'discussion [that] will eventually lead into
putting at least some restrictions on agents loaded into a running VM' and
as a heavy user and someone who has helped to write a long row of
commercial agents and followed them into their use in production and who
has seen how helpful they are in reducing deployment complexity, I can only
hope that you will change your mind on this. Dynamically attached agents
must already run as the same user as the target process. If you are
concerned about agents 'illegally intruding' your Java process, I'd say you
have bigger security issues at hand and it is already possible to disable
dynamic attachment if you want to avoid it. Dynamic attachment has become
pretty much the default approach for a lot of Java tooling in production
environments. It has proven to be very convenient if a for example a
tracing tool is scanning Java processes to attach to them, rather than
requiring the deployment operators to be explicitly set up command line
arguments which are easily forgotten if they only need to be added in some
environments. This reduction in complexity for operations has literally
saved millions of dollars to Java users and Oracle customers. This makes
Java a popular choice, especially compared to languages such as Go where
this is naturally not possible. It's easy and there is no record of this
feature doing any harm. I would not see any good reason to restrict this by
default.

That said, even if it was restricted in the future, this would mean that
some of the Instrumentation API methods will throw exceptions in the
future. There would not be much difference if an introduced defineClass
method would do the same.

Am Fr., 16. Apr. 2021 um 19:31 Uhr schrieb Alan Bateman <
Alan.Bateman at oracle.com>:

> On 16/04/2021 17:40, Rafael Winterhalter wrote:
> > :
> > I will try to make my case on the mailing list. I hoped this could get
> resolved within the release of Java 17 as this would make it possible to
> write agents without use of Unsafe API to support Java 17 and later. Since
> agents often are supplementary to a broad range of Java applications, the
> LTS release will likely be an important support boundary for years and
> years to come.
> >
> "are supplementary to a board range of Java applications" is part of the
> concern with the proposal. If possible, it would be good if the write-up
> could separate the requirements for injection/instrumentation by
> frameworks at runtime from the requirements of tool agents. If the
> requirements cover testing time and mocking then it would useful to
> separate those too.
>
> Just to add to R?mi's comment: For frameworks/libraries, the
> Lookup.defineClass and defineHiddenClass APIs are to define classes in
> the same run-time package as the Lookup class. There isn't any API for
> libraries/frameworks to define class in a "new run-time package".
> There's a chunky project there. Part of it is the Lookup API itself,
> part of is that there isn't an exposed way to extend the set of packages
> in a named module. Mandy has done some exploration on this topic and may
> be able to say a bit more about this.
>
> On Java agents, then I think the discussion will eventually lead into
> putting at least some restrictions on agents loaded into a running VM.
> Agents started on the command line with -javaagent are all-powerful but
> maybe agents loaded into a target VM get a restricted Instrumentation
> object that cannot redefine modules or retransform classes in named
> modules. The narrower requirement for agents doing load time
> instrumentation to define auxiliary classes in the same package as the
> class being loaded fits with the intent of the original API and I don't
> think is controversial.
>
> -Alan
>

From dcubed at openjdk.java.net  Fri Apr 16 20:24:37 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 20:24:37 GMT
Subject: Integrated: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64
In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
Message-ID: <g6aTlQn0_t1Dy3W7dBUZssOqtFiZNu1Z0TRbrjilKZ8=.1b28a8d3-d8c6-4ff9-bf15-85c260141ffd@github.com>

On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
> 
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

This pull request has now been integrated.

Changeset: 888d80b5
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/888d80b5
Stats:     13 lines in 3 files changed: 13 ins; 0 del; 0 mod

8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
8265361: ProblemList a few compiler/whitebox tests on macos-aarch64
8265363: ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
8265368: ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
8265370: ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

Reviewed-by: bpb, mikael

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From winterhalter at openjdk.java.net  Fri Apr 16 20:30:15 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Fri, 16 Apr 2021 20:30:15 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes [v2]
In-Reply-To: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
Message-ID: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>

> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.

Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8200559: Java agents doing instrumentation need a means to define auxiliary classes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3546/files
  - new: https://git.openjdk.java.net/jdk/pull/3546/files/362efc82..2ef21598

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3546.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3546/head:pull/3546

PR: https://git.openjdk.java.net/jdk/pull/3546

From naoto at openjdk.java.net  Fri Apr 16 21:16:59 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 21:16:59 GMT
Subject: RFR: 8265375: Bootcycle builds fail with StackOverflowError in
 cldrconverter
Message-ID: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>

Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`).

-------------

Commit messages:
 - 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter

Changes: https://git.openjdk.java.net/jdk/pull/3553/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3553&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265375
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3553.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3553/head:pull/3553

PR: https://git.openjdk.java.net/jdk/pull/3553

From joehw at openjdk.java.net  Fri Apr 16 21:29:34 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 16 Apr 2021 21:29:34 GMT
Subject: RFR: 8265375: Bootcycle builds fail with StackOverflowError in
 cldrconverter
In-Reply-To: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
References: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
Message-ID: <6UEEUmoNYsRc6LSvDR8Nr2wwPQHbZg9iYFS8TZYqONk=.9e5fc2ca-88e9-4dd8-9ace-4a35fd795625@github.com>

On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`).

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3553

From sergei.tsypanov at yandex.ru  Fri Apr 16 21:41:24 2021
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Fri, 16 Apr 2021 23:41:24 +0200
Subject: Enhancement proposal regarding bufferization of InputStream
In-Reply-To: <502b0914-fc32-8d00-417c-41e4e5d1faaa@oracle.com>
References: <37788811618471992@myt6-aaa7a2dc5b3e.qloud-c.yandex.net>
 <B3F21DD1-1265-4F7C-8EB5-F9A6F1015FB0@oracle.com>
 <502b0914-fc32-8d00-417c-41e4e5d1faaa@oracle.com>
Message-ID: <10001261618609284@vla1-6c4c42cc13df.qloud-c.yandex.net>

Hi Roger,

> Are you taking into account that for many reads the data is not copied
> into the local buffer.
> See the comments in BufferedInputStream.read1: 277:280?

sure, I'm aware of this optimization. The buffer however is always allocated as BufferedInputStream instantiated,
waisting by default 8 kB of memory.

If I take a benchmark [1] measuring costs of reading metadata of a simple Spring bean it demonstrates [2]
measurable imrovement when buffering is dropped:

original
                                       Mode  Cnt      Score     Error   Units
read                                   avgt  100    122.041 ?   1.286   us/op
read:?gc.alloc.rate.norm               avgt  100  50795.798 ?  13.941    B/op  <<

patched
                                       Mode  Cnt      Score     Error   Units
read                                   avgt  100    119.524 ?   1.171   us/op
read:?gc.alloc.rate.norm               avgt  100  42635.578 ?  10.866    B/op <<

So in this case it's about 3 microseconds and 8 KB per bean.

When I measured the impact of change [2] on Spring Boot application I got start-up time improved
from 760 milliseconds to 718 milliseconds a memory consumption decrease from 48,09 MB to 47,47 MB.


Also see https://github.com/openjdk/jdk/pull/2992

1. https://github.com/stsypanov/ovn/blob/master/src/main/java/com/tsypanov/ovn/MetadataReaderBenchmark.java
2. https://github.com/spring-projects/spring-framework/pull/24946


Regards,
Sergey Tsypanov

> Hi Sergey,
> 
> Are you taking into account that for many reads the data is not copied
> into the local buffer.
> See the comments in BufferedInputStream.read1: 277:280?
> 
> How much is the slowdown, when BufferedInputStreams are chained?
> 
> Thanks, Roger
> 
> On 4/15/21 7:08 AM, Pavel Rappo wrote:
> 
>>> On 15 Apr 2021, at 08:33, ?????? ??????? <sergei.tsypanov at yandex.ru> wrote:
>>>
>>> Hello,
>>>
>>> buffering with j.i.BufferedInputStream is a handy way to improve performance of IO operations.
>>> However in many cases buffering is redundant. Consider this code snippet from Spring Framework:
>>>
>>> static ClassReader getClassReader(Resource rsc) throws Exception {
>>> try (var is = new BufferedInputStream(rsc.getInputStream())) {
>>> return new ClassReader(is);
>>> }
>>> }
>>>
>>> Interface Resource has lots of implementations some of them return buffered InputStream,
>>> others don't, but all of them get wrapped with BufferedInputStream.
>>>
>>> Apart from obvious misuses like BufferedInputStream cascade such wrapping is not necessary,
>>> e.g. when we read a huge file using FileInputStream.readAllBytes(),
>>> in others cases it's harmful e.g. when we read a small (comparing to the default
>>> size of buffer in BufferedInputStream) file with readAllBytes() or
>>> when we read from ByteArrayInputStream which is kind of buffered one by its nature.
>>>
>>> I think an instance of InputStream should decide itself whether it requires buffering,
>>> so I suggest to add a couple of methods into j.i.InputStream:
>>>
>>> // subclasses can override this
>>> protected boolean needsBuffer() {
>>> return true;
>>> }
>>>
>>> public InputStream buffered() {
>>> return needsBuffer() ? new BufferedInputStream(this) : this;
>>> }
>>>
>>> this allows subclasses of InputStream to override needsBuffer() to declare buffering redundancy.
>>> Let's imagine we've overridden needsBuffer() in BufferedInputStream:
>>>
>>> public class BufferedInputStream {
>>> @Override
>>> public boolean needsBuffer() {
>>> return true;
>>> }
>>> }
>>>
>>> then the code we've mentioned above should be rewritten as
>>>
>>> static ClassReader getClassReader(Resource rsc) throws Exception {
>>> try (var is = rsc.getInputStream().buffered()) {
>>> return new ClassReader(is);
>>> }
>>> }
>>>
>>> preventing cascade of BufferedInputStreams.
>>
>> When I read this part
>>
>>> There are also cases when the need for buffering depends on the way how we read from InputStream:
>>>
>>> new FileInputStream(file).buffered().readAllBytes() // buffering is redundant
>>
>> my knee-jerk reaction was that a better solution likely lies with introducing a marker interface and selectively implementing it as opposed to adding two new methods to the existing class and selectively overriding them. Let's call this interface java.io.Buffered: Bufferred is to InputStream as RandomAccess is to List.
>>
>> Just to be clear: I'm not proposing to actually do this. It's just a thought.
>>
>> -Pavel
>>
>>> var data = new DataInputStream(new FileInputStream(file).buffered())
>>> for (int i = 0; i < 1000; i++) {
>>> data.readInt(); // readInt() does 4 calls to InputStream.read() so buffering is needed
>>> }
>>>
>>> here if FileInputStream.needsBuffer() is overridden and returns false (assuming most of reads from it are bulk)
>>> then we won't have buffering for DataInputStream. To avoid this we can also
>>> add InputStream.buffered(boolean enforceBuffering) to have manual control.
>>>
>>> To sum up, my proposal is to add those methods to InputStream:
>>>
>>> protected static boolean needsBuffer() {
>>> return true;
>>> }
>>>
>>> public InputStream buffered() {
>>> return buffered(needsBuffer());
>>> }
>>>
>>> public InputStream buffered(boolean enforceBuffering) {
>>> return enforceBuffering ? new BufferedInputStream(this) : this;
>>> }
>>>
>>> What do you think?
>>>
>>> With best regards,
>>> Sergey Tsypanov

From donraab at gmail.com  Fri Apr 16 22:06:47 2021
From: donraab at gmail.com (Donald Raab)
Date: Fri, 16 Apr 2021 18:06:47 -0400
Subject: ReversibleCollection proposal
In-Reply-To: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
Message-ID: <684F957C-11B2-420C-A4DA-D1B8A57C9A88@gmail.com>

Hi Stuart,

We should be cautious when adding new APIs to existing interfaces. There may be libraries which extend JDK types and already have reversed(), toReversed() or asReversed() APIs and corresponding interfaces.

There are OrderedIterable and ReversibleIterable interfaces and asReversed() and toReversed() methods in the Eclipse Collections API. 

JavaDoc:
https://www.eclipse.org/collections/javadoc/10.4.0/org/eclipse/collections/api/ordered/OrderedIterable.html
https://www.eclipse.org/collections/javadoc/10.4.0/org/eclipse/collections/api/ordered/ReversibleIterable.html

Code Browser:
https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/ordered/OrderedIterable.java
https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/ordered/ReversibleIterable.java

OrderedIterable and ReversibleIterable appear in the mind map for RichIterable and have corresponding primitive versions in the mind map for PrimitiveIterable.

https://medium.com/oracledevs/visualizing-eclipse-collections-646dad9533a9?source=friends_link&sk=3370a5e8bb5a516e6b5d7040f7d0955b 

There are methods asReversed() and toReversed() on ReversibleIterable().

https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/ordered/ReversibleIterable.java#org.eclipse.collections.api.ordered.ReversibleIterable%23asReversed%28%29
https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/ordered/ReversibleIterable.java#org.eclipse.collections.api.ordered.ReversibleIterable%23toReversed%28%29

The toReversed() method is co-variantly overridden in subtypes of ReversibleIterable. 

https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/list/ListIterable.java#org.eclipse.collections.api.list.ListIterable%23toReversed%28%29

The asReversed() method returns a ReverseIterable which is lazy.

https://code.yawk.at/org.eclipse.collections/eclipse-collections/9.2.0/org/eclipse/collections/impl/lazy/ReverseIterable.java

Thanks,
Don



> On Apr 16, 2021, at 1:40 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> This is a proposal to add a ReversibleCollection interface to the Collections Framework. I'm looking for comments on overall design before I work on detailed specifications and tests. Please send such comments as replies on this email thread.
> 
> Here's a link to a draft PR that contains the code diffs. It's prototype quality, but it should be good enough to build and try out:
> 
>    https://github.com/openjdk/jdk/pull/3533
> 
> And here's a link to a class diagram showing the proposed additions:
> 
> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
> 
> Thanks,
> 
> s'marks
> 
> 
> # Ordering and Reversibility
> 
> 
> A long-standing concept that's been missing from collections is that of the positioning, sequencing, or arrangement of elements as a structural property of a collection. (This is sometimes called the "iteration order" of a collection.) For example, a HashSet is not ordered, but a List is. This concept is mostly not manifested in the collections API.
> 
> Iterating a collection produces elements one after another in *some* sequence. The concept of "ordered" determines whether this sequence is defined or whether it's a coincidence of implementation. What does "having an order" mean? It implies that there is a first element and that each element has a successor. Since collections have a finite number of elements, it further implies that there is a last element that has no successor. However, it is difficult to discern whether a collection has a defined order. HashSet generally iterates its elements in the same undefined order, and you can't actually tell that it's not a defined order.
> 
> Streams do have a notion of ordering ("encounter order") and this is preserved, where appropriate, through the stream pipeline. It's possible to detect this by testing whether its spliterator has the ORDERED characteristic. Any collection with a defined order will have a spliterator with this characteristic. However, this is quite a roundabout way to determine whether a collection has a defined order. Furthermore, knowing this doesn't enable any additional operations. It only provides constraints on the stream's implementations (keeping the elements in order) and provides stronger semantics for certain operations. For example, findFirst() on an unordered stream is the same as findAny(), but actually finds the first element if the stream is ordered.
> 
> The concept of ordering is thus present in the system but is surfaced only in a fairly indirect way. We can strengthen abstraction of ordering by making a few observations and considering their implications.
> 
> Given that there is a first element and a last element, the sequence of elements has two ends. It's reasonable to consider operations (add, get, remove) on either end. Indeed, the Deque interface has a full complement of operations at each end. This is an oft-requested feature on various other collections.
> 
> Each element except for the last has a successor, implying that each element except for the first has a predecessor. Thus it's reasonable to consider iterating the elements from first to last or from last to first (that is, in forward or reverse order). Indeed, the concept of iterating in reverse order appears already in bits and pieces in particular places around the collections:
> 
> - List has indexOf() and lastIndexOf()
> - Deque has removeFirstOccurrence() and removeLastOccurrence()
> - List has a ListIterator with hasPrevious/previous methods
> - Deque and NavigableSet have descendingIterator methods
> 
> Given an ordered collection, though, there's no general way to iterate it in reverse order. Reversed iteration isn't the most common operation, but there are some frequent use cases, such as operating on elements in most-recently-added order. Questions and bug reports about this have come up repeatedly over the years.
> 
> Unfortunately, iterating in reverse order is much harder than iterating in forward order. There are a variety of ways to iterate in forward order. For example, given a List, one can do any of the following:
> 
>    for (var e : list) { ... }
>    list.forEach(...)
>    list.stream()
>    list.toArray()
> 
> However, to iterate a list in reverse order, one must use an explicit loop over ListIterator:
> 
>    for (var it = list.listIterator(list.size()); it.hasPrevious(); ) {
>        var e = it.previous();
>        ...
>    }
> 
> Streaming the elements of a List in reverse order is even worse. One approach would be to implement a reverse-ordered Iterator that wraps a ListIterator and delegates hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then, this Iterator can be turned into a Spliterator, which is then turned into a Stream. (The code to do this is left as an exercise for the reader.) Obtaining the elements in reverse via other means -- forEach() or toArray() -- is similarly difficult.
> 
> Obtaining the elements in reverse order can be accomplished by adopting a concept from NavigableSet's descendingSet() method, which provides a reverse-ordered view collection. This view is also a NavigableSet, which means that any operation that can be performed on the original set can also be applied to the reverse-ordered view. If it were possible to obtain a similar reverse-ordered view on any kind of ordered collection, this would enable the elements to be processed in reverse order in any fashion, not just special-purposes APIs such as ListIterator or descendingIterator().
> 
> 
> # LinkedHashSet
> 
> 
> The main feature of LinkedHashSet is that it does have a defined ordering, as opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last element. However, LinkedHashSet is deficient in a number of ways:
> 
> - access to and removal of the first element is reasonable (using an iterator) but it is not possible to add at the front
> 
> - it is possible to add an element at the end, but access to and removal of the last element are expensive
> 
> - it's not possible to iterate in reverse without copying the entire collection
> 
> Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so there is no fundamental implementation reason that prevents these operations from being supported. The main reason these operations aren't supported is probably that there hasn't been a good place to push such APIs.
> 
> 
> # Proposal
> 
> 
> Introduce a new ReversibleCollection<E> interface. This provides a new method to obtain a reverse-ordered view. It also contains several methods (copied from Deque) that allow operating on elements at both ends.
> 
> 
>    interface ReversibleCollection<E> extends Collection<E> {
>        ReversibleCollection<E> reversed();
>        default void addFirst(E e)
>        default void addLast(E e)
>        default E getFirst()
>        default E getLast()
>        default E removeFirst()
>        default E removeLast()
>    }
> 
> 
> The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are retrofitted to implement ReversibleCollection. They provide covariant overriding implementations of the reversed() method. For example, List.reversed() returns a List. Default implementations for all of these methods are provided in the appropriate interfaces.
> 
> Covariant overrides are also provided in several other classes. This presents a difficulty for LinkedHashSet, as there's no suitable return type for reversed(). To remedy this, we add another interface
> 
> 
>    interface ReversibleSet<E> extends ReversibleCollection<E>, Set<E> { }
> 
> 
> This adds no new methods but is essentially an intersection of ReversibleCollection and Set. As such, it's suitable as the return type of LinkedHashSet.reversed() and the set views of LinkedHashMap.
> 
> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because SortedSet's ordering is determined by the comparison method and cannot be controlled explicitly.
> 
> LinkedHashSet::addFirst and addLast add the element at the appropriate position or reposition the element if it is already present in the set.
> 
> New methods are added to LinkedHashMap
> 
>    V putFirst(K, V)
>    V putLast(K, V)
> 
> which put the mapping at the designated position or reposition the mapping if is already present in the map.
> 
> 
> # Design & Implementation Issues
> 
> 
> Covariant overrides for reversed() are provided where possible. However, there is a conflict between List and Deque, as there are examples in the JDK (such as LinkedList) that implement both List and Deque. Since List is much more popular than Deque, I've decided against adding a covariant override to Deque. Instead, a method Deque::reversedDeque is added that returns a Deque, and Deque::reversed returns ReversibleCollection.
> 
> There is no ReversibleMap interface. Most iteration over maps is over the entrySet, keySet, or values views. NavigableMap already has descendingMap(), and LinkedHashMap provides ReversibleX views, which cover most of the cases already.
> 
> Introducing new methods into an interface hierarchy always raises the possibility of name clashes. I've done some searching but I haven't found any major issues, but we should be on the lookout for this. I'll continue to do more searching for such conflicts.
> 
> Introducing covariant overrides on existing methods (notably LinkedHashMap entrySet, keySet, and values) could present incompatibility issues with subclasses that override these methods. I've done some searching and again I haven't found major problems, but this is nonetheless a point of concern. I'll do more searching here, too.
> 
> The default implementations for List::reversed, Deque::reversed, and SortedSet::reversed return reverse-ordered views that are implemented using only public methods of the original interface. This demonstrates the feasibility of retrofitting reverse ordering onto any instance of these interfaces. Similarly, the various add/get/remove methods' default implementations are all implementable in terms of an iterator or reverse-ordered iterator. That said, some concurrent collection implementations will need to override these default implementations in order to preserve their safety invariants. It would probably also be wise to add optimized implementations to the more commonly-used collection implementations.
> 
> Given that a ReversibleCollection has a defined ordering, any spliterator obtained from such a collection should have the Spliterator.ORDERED characteristic.
> 
> This proposal is related to a previous discussion on a similar topic, where Tagir Valeev had proposed OrderedSet and OrderedMap:
> 
>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066028.html
> 
> I think there were some good ideas in there and in the ensuing discussion, but it didn't go anywhere. Several of the concepts in this proposal are an evolution of some ideas discussed in that thread.
> 
> One of the ideas from that thread was to use Deque as a common interface for many collections to support reversibility and operations at the ends. We've abandoned that idea in this proposal. The reasons are that it's cluttered with a bunch of methods that are inherited from Queue. Also, some methods are null-returning instead of throwing, which introduces confusion for collections that can contain nulls.
> 
> # END


From donraab at gmail.com  Fri Apr 16 22:06:47 2021
From: donraab at gmail.com (Donald Raab)
Date: Fri, 16 Apr 2021 18:06:47 -0400
Subject: ReversibleCollection proposal
In-Reply-To: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
Message-ID: <684F957C-11B2-420C-A4DA-D1B8A57C9A88@gmail.com>

Hi Stuart,

We should be cautious when adding new APIs to existing interfaces. There may be libraries which extend JDK types and already have reversed(), toReversed() or asReversed() APIs and corresponding interfaces.

There are OrderedIterable and ReversibleIterable interfaces and asReversed() and toReversed() methods in the Eclipse Collections API. 

JavaDoc:
https://www.eclipse.org/collections/javadoc/10.4.0/org/eclipse/collections/api/ordered/OrderedIterable.html
https://www.eclipse.org/collections/javadoc/10.4.0/org/eclipse/collections/api/ordered/ReversibleIterable.html

Code Browser:
https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/ordered/OrderedIterable.java
https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/ordered/ReversibleIterable.java

OrderedIterable and ReversibleIterable appear in the mind map for RichIterable and have corresponding primitive versions in the mind map for PrimitiveIterable.

https://medium.com/oracledevs/visualizing-eclipse-collections-646dad9533a9?source=friends_link&sk=3370a5e8bb5a516e6b5d7040f7d0955b 

There are methods asReversed() and toReversed() on ReversibleIterable().

https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/ordered/ReversibleIterable.java#org.eclipse.collections.api.ordered.ReversibleIterable%23asReversed%28%29
https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/ordered/ReversibleIterable.java#org.eclipse.collections.api.ordered.ReversibleIterable%23toReversed%28%29

The toReversed() method is co-variantly overridden in subtypes of ReversibleIterable. 

https://code.yawk.at/org.eclipse.collections/eclipse-collections-api/10.4.0/org/eclipse/collections/api/list/ListIterable.java#org.eclipse.collections.api.list.ListIterable%23toReversed%28%29

The asReversed() method returns a ReverseIterable which is lazy.

https://code.yawk.at/org.eclipse.collections/eclipse-collections/9.2.0/org/eclipse/collections/impl/lazy/ReverseIterable.java

Thanks,
Don



> On Apr 16, 2021, at 1:40 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> This is a proposal to add a ReversibleCollection interface to the Collections Framework. I'm looking for comments on overall design before I work on detailed specifications and tests. Please send such comments as replies on this email thread.
> 
> Here's a link to a draft PR that contains the code diffs. It's prototype quality, but it should be good enough to build and try out:
> 
>    https://github.com/openjdk/jdk/pull/3533
> 
> And here's a link to a class diagram showing the proposed additions:
> 
> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
> 
> Thanks,
> 
> s'marks
> 
> 
> # Ordering and Reversibility
> 
> 
> A long-standing concept that's been missing from collections is that of the positioning, sequencing, or arrangement of elements as a structural property of a collection. (This is sometimes called the "iteration order" of a collection.) For example, a HashSet is not ordered, but a List is. This concept is mostly not manifested in the collections API.
> 
> Iterating a collection produces elements one after another in *some* sequence. The concept of "ordered" determines whether this sequence is defined or whether it's a coincidence of implementation. What does "having an order" mean? It implies that there is a first element and that each element has a successor. Since collections have a finite number of elements, it further implies that there is a last element that has no successor. However, it is difficult to discern whether a collection has a defined order. HashSet generally iterates its elements in the same undefined order, and you can't actually tell that it's not a defined order.
> 
> Streams do have a notion of ordering ("encounter order") and this is preserved, where appropriate, through the stream pipeline. It's possible to detect this by testing whether its spliterator has the ORDERED characteristic. Any collection with a defined order will have a spliterator with this characteristic. However, this is quite a roundabout way to determine whether a collection has a defined order. Furthermore, knowing this doesn't enable any additional operations. It only provides constraints on the stream's implementations (keeping the elements in order) and provides stronger semantics for certain operations. For example, findFirst() on an unordered stream is the same as findAny(), but actually finds the first element if the stream is ordered.
> 
> The concept of ordering is thus present in the system but is surfaced only in a fairly indirect way. We can strengthen abstraction of ordering by making a few observations and considering their implications.
> 
> Given that there is a first element and a last element, the sequence of elements has two ends. It's reasonable to consider operations (add, get, remove) on either end. Indeed, the Deque interface has a full complement of operations at each end. This is an oft-requested feature on various other collections.
> 
> Each element except for the last has a successor, implying that each element except for the first has a predecessor. Thus it's reasonable to consider iterating the elements from first to last or from last to first (that is, in forward or reverse order). Indeed, the concept of iterating in reverse order appears already in bits and pieces in particular places around the collections:
> 
> - List has indexOf() and lastIndexOf()
> - Deque has removeFirstOccurrence() and removeLastOccurrence()
> - List has a ListIterator with hasPrevious/previous methods
> - Deque and NavigableSet have descendingIterator methods
> 
> Given an ordered collection, though, there's no general way to iterate it in reverse order. Reversed iteration isn't the most common operation, but there are some frequent use cases, such as operating on elements in most-recently-added order. Questions and bug reports about this have come up repeatedly over the years.
> 
> Unfortunately, iterating in reverse order is much harder than iterating in forward order. There are a variety of ways to iterate in forward order. For example, given a List, one can do any of the following:
> 
>    for (var e : list) { ... }
>    list.forEach(...)
>    list.stream()
>    list.toArray()
> 
> However, to iterate a list in reverse order, one must use an explicit loop over ListIterator:
> 
>    for (var it = list.listIterator(list.size()); it.hasPrevious(); ) {
>        var e = it.previous();
>        ...
>    }
> 
> Streaming the elements of a List in reverse order is even worse. One approach would be to implement a reverse-ordered Iterator that wraps a ListIterator and delegates hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then, this Iterator can be turned into a Spliterator, which is then turned into a Stream. (The code to do this is left as an exercise for the reader.) Obtaining the elements in reverse via other means -- forEach() or toArray() -- is similarly difficult.
> 
> Obtaining the elements in reverse order can be accomplished by adopting a concept from NavigableSet's descendingSet() method, which provides a reverse-ordered view collection. This view is also a NavigableSet, which means that any operation that can be performed on the original set can also be applied to the reverse-ordered view. If it were possible to obtain a similar reverse-ordered view on any kind of ordered collection, this would enable the elements to be processed in reverse order in any fashion, not just special-purposes APIs such as ListIterator or descendingIterator().
> 
> 
> # LinkedHashSet
> 
> 
> The main feature of LinkedHashSet is that it does have a defined ordering, as opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last element. However, LinkedHashSet is deficient in a number of ways:
> 
> - access to and removal of the first element is reasonable (using an iterator) but it is not possible to add at the front
> 
> - it is possible to add an element at the end, but access to and removal of the last element are expensive
> 
> - it's not possible to iterate in reverse without copying the entire collection
> 
> Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so there is no fundamental implementation reason that prevents these operations from being supported. The main reason these operations aren't supported is probably that there hasn't been a good place to push such APIs.
> 
> 
> # Proposal
> 
> 
> Introduce a new ReversibleCollection<E> interface. This provides a new method to obtain a reverse-ordered view. It also contains several methods (copied from Deque) that allow operating on elements at both ends.
> 
> 
>    interface ReversibleCollection<E> extends Collection<E> {
>        ReversibleCollection<E> reversed();
>        default void addFirst(E e)
>        default void addLast(E e)
>        default E getFirst()
>        default E getLast()
>        default E removeFirst()
>        default E removeLast()
>    }
> 
> 
> The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are retrofitted to implement ReversibleCollection. They provide covariant overriding implementations of the reversed() method. For example, List.reversed() returns a List. Default implementations for all of these methods are provided in the appropriate interfaces.
> 
> Covariant overrides are also provided in several other classes. This presents a difficulty for LinkedHashSet, as there's no suitable return type for reversed(). To remedy this, we add another interface
> 
> 
>    interface ReversibleSet<E> extends ReversibleCollection<E>, Set<E> { }
> 
> 
> This adds no new methods but is essentially an intersection of ReversibleCollection and Set. As such, it's suitable as the return type of LinkedHashSet.reversed() and the set views of LinkedHashMap.
> 
> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because SortedSet's ordering is determined by the comparison method and cannot be controlled explicitly.
> 
> LinkedHashSet::addFirst and addLast add the element at the appropriate position or reposition the element if it is already present in the set.
> 
> New methods are added to LinkedHashMap
> 
>    V putFirst(K, V)
>    V putLast(K, V)
> 
> which put the mapping at the designated position or reposition the mapping if is already present in the map.
> 
> 
> # Design & Implementation Issues
> 
> 
> Covariant overrides for reversed() are provided where possible. However, there is a conflict between List and Deque, as there are examples in the JDK (such as LinkedList) that implement both List and Deque. Since List is much more popular than Deque, I've decided against adding a covariant override to Deque. Instead, a method Deque::reversedDeque is added that returns a Deque, and Deque::reversed returns ReversibleCollection.
> 
> There is no ReversibleMap interface. Most iteration over maps is over the entrySet, keySet, or values views. NavigableMap already has descendingMap(), and LinkedHashMap provides ReversibleX views, which cover most of the cases already.
> 
> Introducing new methods into an interface hierarchy always raises the possibility of name clashes. I've done some searching but I haven't found any major issues, but we should be on the lookout for this. I'll continue to do more searching for such conflicts.
> 
> Introducing covariant overrides on existing methods (notably LinkedHashMap entrySet, keySet, and values) could present incompatibility issues with subclasses that override these methods. I've done some searching and again I haven't found major problems, but this is nonetheless a point of concern. I'll do more searching here, too.
> 
> The default implementations for List::reversed, Deque::reversed, and SortedSet::reversed return reverse-ordered views that are implemented using only public methods of the original interface. This demonstrates the feasibility of retrofitting reverse ordering onto any instance of these interfaces. Similarly, the various add/get/remove methods' default implementations are all implementable in terms of an iterator or reverse-ordered iterator. That said, some concurrent collection implementations will need to override these default implementations in order to preserve their safety invariants. It would probably also be wise to add optimized implementations to the more commonly-used collection implementations.
> 
> Given that a ReversibleCollection has a defined ordering, any spliterator obtained from such a collection should have the Spliterator.ORDERED characteristic.
> 
> This proposal is related to a previous discussion on a similar topic, where Tagir Valeev had proposed OrderedSet and OrderedMap:
> 
>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066028.html
> 
> I think there were some good ideas in there and in the ensuing discussion, but it didn't go anywhere. Several of the concepts in this proposal are an evolution of some ideas discussed in that thread.
> 
> One of the ideas from that thread was to use Deque as a common interface for many collections to support reversibility and operations at the ends. We've abandoned that idea in this proposal. The reasons are that it's cluttered with a bunch of methods that are inherited from Queue. Also, some methods are null-returning instead of throwing, which introduces confusion for collections that can contain nulls.
> 
> # END


From naoto at openjdk.java.net  Fri Apr 16 22:20:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 22:20:08 GMT
Subject: RFR: 8265375: Bootcycle builds fail with StackOverflowError in
 cldrconverter [v2]
In-Reply-To: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
References: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
Message-ID: <Ng67_896c_coTkheMM9hJagLoZOsYLdt5nizD60L3Hw=.227f8fde-54ce-4fbb-865d-c93c295c179b@github.com>

> Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`).

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Copyright year update.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3553/files
  - new: https://git.openjdk.java.net/jdk/pull/3553/files/91326786..e54cb6ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3553&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3553&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3553.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3553/head:pull/3553

PR: https://git.openjdk.java.net/jdk/pull/3553

From naoto at openjdk.java.net  Fri Apr 16 22:26:46 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 22:26:46 GMT
Subject: Integrated: 8265375: Bootcycle builds fail with StackOverflowError in
 cldrconverter
In-Reply-To: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
References: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
Message-ID: <5VUdiDhBm9E-XcRwHzd0K7gntyW0r0KfKbzUk01XoGU=.fbd8772f-b00c-4bc5-8ca8-4f0024679bb0@github.com>

On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`).

This pull request has now been integrated.

Changeset: ff499701
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff499701
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8265375: Bootcycle builds fail with StackOverflowError in cldrconverter

Reviewed-by: joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/3553

From almatvee at openjdk.java.net  Fri Apr 16 22:38:47 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 16 Apr 2021 22:38:47 GMT
Subject: RFR: 8263154: [macos] DMG builds have finder errors
In-Reply-To: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
References: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
Message-ID: <ISfhqOyaU_CHo1YeU895aduT5eKowBjZj8pxIe6ZWJg=.948c9b77-1a35-4a04-a2e4-d1b469af2719@github.com>

On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Issue was reproducible when install-dir points to some invalid location.
>  - Fixed by defaulting DMG drag and drop location to /Applications folder and --install-dir will be ignored with warning for DMG.
>  - I do not see any way to support other valid, but uncommon locations for drag and drop. For example: /Users/USERNAME/Applications is not possible to support since user name is not known. /usr/bin requires root privileges and should contain symbolic links. Locations which does not exist also not possible to support, since DMG cannot create paths. So /Applications/MyCompany is not possible for DMG.

Should we always show warning messages, especially that output will be different from what user expected? I can switch to Log.verbose(), but I still think it should be displayed always.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3505

From plevart at openjdk.java.net  Fri Apr 16 23:05:37 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 16 Apr 2021 23:05:37 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v2]
In-Reply-To: <aA8_XzKvy7slrlD1D2IAtFjCVdCGJnrMM77XW87_Zzs=.c8fda6d1-ba0f-4dfe-8981-80b828b39468@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <Q0KrFJ5y96KgNO15EOLFT6XU-0OkxjiA3ezBf0lujy8=.9e2d4b07-820c-4c86-9475-fa6b8696d3c3@github.com>
 <aA8_XzKvy7slrlD1D2IAtFjCVdCGJnrMM77XW87_Zzs=.c8fda6d1-ba0f-4dfe-8981-80b828b39468@github.com>
Message-ID: <DJ0r0M9Q__h_-LkXVcaWwcBpv-cuhJb4U4ThoPT1COk=.3d65dd56-c82b-4ad2-9b31-4721a0c23fb6@github.com>

On Fri, 16 Apr 2021 19:05:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add String.join benchmark method to StringJoinerBenchmark and adjust some parameters to cover bigger range
>
> src/java.base/share/classes/java/lang/String.java line 3254:
> 
>> 3252: 
>> 3253:         byte[] value = StringConcatHelper.newArray(((long) icoder << 32) | llen);
>> 3254:         int off = 0;
> 
> StringConcatHelper.newArray() can double the length (based on the coder) and it is then truncated to 32 bits when passed to UNSAFE.allocatlUnitializedArray.
> The test of length above only ensures llen can be truncated to 32 bits without loss of data.

I thought about that, yes. And I think we have to do the check for the doubled length before calling the newArray. I checked the StringJoinerTest and it only deals with ascii strings unfortunately. Will have to add a test for that too...

> src/java.base/share/classes/java/lang/String.java line 3256:
> 
>> 3254:         int off = 0;
>> 3255:         prefix.getBytes(value, off, coder); off += prefix.length();
>> 3256:         for (int i = 0; i < size; i++) {
> 
> Can you save a branch inside the loop by handling element 0 outside the loop and
> then do the loop for the rest?

Thanks, I'll do that and then re-test to see if there's any improvement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From mik3hall at gmail.com  Sat Apr 17 00:57:14 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 16 Apr 2021 19:57:14 -0500
Subject: jpackage bugs 
Message-ID: <02F6EA89-922F-4A50-954F-2423DEF1113A@gmail.com>

Is there anyway to get a simple/test reference type application available that could be used in reproducing bugs?

I had two I think potentially serious bugs that were basically not addressed for problems in reproducing.

JDK-8263156 : [macos]: OS X application signing concerns - a sealed resource is missing or invalid
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156>

The command to reproduce was provided. The error appears to be in files included in the embedded JDK not being signed. So apparently not having to do with anything of mine. (Mentioned I now see in the comments).

As I indicate this is not a serious error for me since I am not submitting the app to the Mac App Store but I believe this would get the app Apple rejected for anyone who is attempting that. A show stopper for a major use case. It seems too bad to simply close it because I missed an email asking for a reproduce. 

With a reference application I could demonstrate the error against would eliminate the need to provide a separate reproducible test case. Quite sized for the application in question. Such an application is actually mentioned in the bug report comments. Could such a application be made available for download or user reproducing - the jpackage command and arguments?

I have looked a little bit at if to see if I can figure out how to sign the embedded jdk files. So far only accomplishing that I can no longer simply use my name for signing but have to use my fully qualified security identity. 

The question now seems to be what is in fact the difference between mine and the, unavailable to me, reference application as to these files verifying as correctly signed.

A second bug 
JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect

I thought a fix for this was all set to go in and was pulled. It was apparently determined that the problem only applies if the ?install-dir parameter is used for DMG?s. Where it really makes no sense. My use apparently held over from when I was just creating the app.I thought this had somehow also in some way regressed to not reproducible. I still think a fairly simple change to the AppleScript as was originally planned would resolve the issue independently of parameters. The default DMG build I would think should _always_ indicate installation to the Applications folder. 

With ?install-dir this remains a reproducible bug for me at 17-ea.

If a reference build was provided somewhere I might have picked up on the parameter difference sooner.






From tvaleev at openjdk.java.net  Sat Apr 17 01:55:26 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sat, 17 Apr 2021 01:55:26 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v3]
In-Reply-To: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
Message-ID: <G5t5vB3HSU5KLAVWRUsaKvoXJaxatuO7W1k0zjh5foo=.59ea7468-a93b-4b70-9b12-4084e0fb8874@github.com>

> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
> 
> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
> 
> 
> After patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
> 
> 
> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
> 
> Before patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
> 
> 
> After patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
> 
> 
> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

Tagir F. Valeev has updated the pull request incrementally with four additional commits since the last revision:

 - More benchmarks
 - adjustSize -> exactOutputSize
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - adjustedLimit -> normalizedLimit
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - adjustSize -> exactOutputSize
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3427/files
  - new: https://git.openjdk.java.net/jdk/pull/3427/files/25755e14..a63e25d0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=01-02

  Stats: 319 lines in 4 files changed: 308 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3427.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427

PR: https://git.openjdk.java.net/jdk/pull/3427

From tvaleev at openjdk.java.net  Sat Apr 17 02:19:35 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sat, 17 Apr 2021 02:19:35 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v3]
In-Reply-To: <G5t5vB3HSU5KLAVWRUsaKvoXJaxatuO7W1k0zjh5foo=.59ea7468-a93b-4b70-9b12-4084e0fb8874@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
 <G5t5vB3HSU5KLAVWRUsaKvoXJaxatuO7W1k0zjh5foo=.59ea7468-a93b-4b70-9b12-4084e0fb8874@github.com>
Message-ID: <IXTMS7Ary44BxMB9FZiM59HtGPSjRtUuLvPOBo9YzN8=.9b8c58d4-0813-4782-bb1e-49f82fbea30c@github.com>

On Sat, 17 Apr 2021 01:55:26 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
>> 
>> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
>> 
>> 
>> After patch:
>> 
>> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
>> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
>> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
>> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
>> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
>> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
>> 
>> 
>> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
>> 
>> Before patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
>> 
>> 
>> After patch:
>> 
>> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
>> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
>> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
>> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
>> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
>> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
>> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
>> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
>> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
>> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
>> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
>> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
>> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
>> 
>> 
>> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.
>
> Tagir F. Valeev has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - More benchmarks
>  - adjustSize -> exactOutputSize
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - adjustedLimit -> normalizedLimit
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - adjustSize -> exactOutputSize
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

I see your concern. I made some additional benchmarks and added them here. First, CountSized, which just gets the stream size without actual traversal. We can see how the performance changes depending on number of stream operations. I also added an optional type profile pollution that makes `exactOutputSize` virtual method polymorphic. Here's the results:

Baseline (The `count10Skip` test added just to ensure that patch works)

Benchmark  (pollute)  (size)  Mode  Cnt       Score      Error  Units
count0         false   10000  avgt  100      15,648 ?    0,182  ns/op
count2         false   10000  avgt  100      31,252 ?    0,113  ns/op
count4         false   10000  avgt  100      47,683 ?    0,165  ns/op
count6         false   10000  avgt  100      64,417 ?    0,203  ns/op
count8         false   10000  avgt  100      80,813 ?    0,265  ns/op
count10        false   10000  avgt  100     101,057 ?    0,295  ns/op
count10Skip    false   10000  avgt  100  497967,375 ? 5946,108  ns/op
count0          true   10000  avgt  100      18,843 ?    0,103  ns/op
count2          true   10000  avgt  100      33,716 ?    0,152  ns/op
count4          true   10000  avgt  100      49,062 ?    0,208  ns/op
count6          true   10000  avgt  100      66,773 ?    0,237  ns/op
count8          true   10000  avgt  100      82,727 ?    0,354  ns/op
count10         true   10000  avgt  100     104,499 ?    0,299  ns/op
count10Skip     true   10000  avgt  100  501723,220 ? 6361,932  ns/op

Type pollution adds some near-constant ~2ns overhead to the non-patched version as well.

Patched:

Benchmark  (pollute)  (size)  Mode  Cnt    Score   Error  Units
count0         false   10000  avgt  100   15,363 ? 0,086  ns/op
count2         false   10000  avgt  100   33,736 ? 0,138  ns/op
count4         false   10000  avgt  100   51,470 ? 0,205  ns/op
count6         false   10000  avgt  100   70,407 ? 0,262  ns/op
count8         false   10000  avgt  100   89,865 ? 0,262  ns/op
count10        false   10000  avgt  100  114,423 ? 0,363  ns/op
count10Skip    false   10000  avgt  100  139,963 ? 0,550  ns/op
count0          true   10000  avgt  100   26,538 ? 0,084  ns/op
count2          true   10000  avgt  100   46,089 ? 0,191  ns/op
count4          true   10000  avgt  100   66,560 ? 0,315  ns/op
count6          true   10000  avgt  100   87,852 ? 0,288  ns/op
count8          true   10000  avgt  100  109,037 ? 0,391  ns/op
count10         true   10000  avgt  100  139,759 ? 0,382  ns/op
count10Skip     true   10000  avgt  100  156,963 ? 1,862  ns/op

So indeed we have some performance drawback in patched version. Here's a chart:

![image](https://user-images.githubusercontent.com/5114450/115098724-c754dd00-9f5b-11eb-86a0-b614a7d36fad.png)
I've calculated linear regression on (patched-baseline) times, depending on the number of ops. It's `y = 1.288x - 0.7078` for clean type profile and `y = 2.6174x + 6.9489` for polluted type profile. So, in the worst case, we have circa 2.6ns per operation plus 7ns constant overhead.

However, using Stream API without actually iterating the stream is very rare case. And if we iterate, the performance will be dominated by the number of iterations. I tried to model this case with SumSized benchmark (replacing count with sum, for 5 and 10 stream elements), but got very confusing results.

Baseline:

Benchmark  (pollute)  (size)  Mode  Cnt    Score    Error  Units
sum0            true       5  avgt  100  126,425 ?  0,793  ns/op
sum2            true       5  avgt  100  195,113 ?  1,359  ns/op
sum4            true       5  avgt  100  304,111 ?  8,302  ns/op
sum6            true       5  avgt  100  414,841 ?  3,215  ns/op
sum8            true       5  avgt  100  507,421 ?  4,781  ns/op
sum10           true       5  avgt  100  633,635 ?  7,105  ns/op
sum0           false       5  avgt  100   45,781 ?  0,258  ns/op
sum2           false       5  avgt  100   86,720 ?  0,573  ns/op
sum4           false       5  avgt  100  195,777 ?  1,145  ns/op
sum6           false       5  avgt  100  291,261 ?  2,091  ns/op
sum8           false       5  avgt  100  376,094 ?  3,283  ns/op
sum10          false       5  avgt  100  492,082 ?  7,914  ns/op
sum0            true      10  avgt  100  127,989 ?  0,758  ns/op
sum2            true      10  avgt  100  219,991 ?  3,081  ns/op
sum4            true      10  avgt  100  374,148 ?  7,426  ns/op
sum6            true      10  avgt  100  557,829 ?  3,959  ns/op
sum8            true      10  avgt  100  698,135 ?  4,915  ns/op
sum10           true      10  avgt  100  904,851 ? 14,458  ns/op
sum0           false      10  avgt  100   43,861 ?  0,107  ns/op
sum2           false      10  avgt  100  105,049 ?  0,276  ns/op
sum4           false      10  avgt  100  294,639 ?  1,499  ns/op
sum6           false      10  avgt  100  439,340 ?  4,223  ns/op
sum8           false      10  avgt  100  577,025 ?  5,760  ns/op
sum10          false      10  avgt  100  729,391 ?  6,045  ns/op


Patched:

Benchmark  (pollute)  (size)  Mode  Cnt    Score   Error  Units
sum0            true       5  avgt  100   68,466 ? 0,167  ns/op
sum2            true       5  avgt  100  107,240 ? 0,261  ns/op
sum4            true       5  avgt  100  209,469 ? 1,098  ns/op
sum6            true       5  avgt  100  300,873 ? 2,020  ns/op
sum8            true       5  avgt  100  378,654 ? 2,620  ns/op
sum10           true       5  avgt  100  473,769 ? 3,665  ns/op
sum0           false       5  avgt  100   49,435 ? 2,702  ns/op
sum2           false       5  avgt  100   96,237 ? 2,906  ns/op
sum4           false       5  avgt  100  195,196 ? 0,961  ns/op
sum6           false       5  avgt  100  286,542 ? 1,874  ns/op
sum8           false       5  avgt  100  371,664 ? 3,416  ns/op
sum10          false       5  avgt  100  457,178 ? 3,776  ns/op
sum0            true      10  avgt  100   69,223 ? 0,195  ns/op
sum2            true      10  avgt  100  120,507 ? 0,752  ns/op
sum4            true      10  avgt  100  291,328 ? 5,581  ns/op
sum6            true      10  avgt  100  439,136 ? 3,787  ns/op
sum8            true      10  avgt  100  569,188 ? 6,440  ns/op
sum10           true      10  avgt  100  709,916 ? 5,022  ns/op
sum0           false      10  avgt  100   46,347 ? 0,174  ns/op
sum2           false      10  avgt  100  109,131 ? 2,381  ns/op
sum4           false      10  avgt  100  296,566 ? 2,079  ns/op
sum6           false      10  avgt  100  430,852 ? 2,629  ns/op
sum8           false      10  avgt  100  562,795 ? 4,442  ns/op
sum10          false      10  avgt  100  716,229 ? 5,659  ns/op


Or, in graphical form:
![image](https://user-images.githubusercontent.com/5114450/115098879-c2dcf400-9f5c-11eb-9fd3-f72ac7c1d59a.png)
![image](https://user-images.githubusercontent.com/5114450/115098884-cc665c00-9f5c-11eb-9e9d-d7c9a7aa10ee.png)

For some reason, non-patched polluted version is the slowest, and I cannot see any stable overhead in patched version. For 4+ intermediate ops, patched version numbers are always better than the corresponding non-patched ones. I would be glad if somebody explains these numbers or point to a flaw in this benchmark.

What do you think, @PaulSandoz? Is it acceptable overhead or should I experiment with the new Stream flag?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3427

From tvaleev at openjdk.java.net  Sat Apr 17 02:46:14 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sat, 17 Apr 2021 02:46:14 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v4]
In-Reply-To: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
Message-ID: <Z9VcBN0wuC0YJnJZ8z_zjPHOVcEr7mWVeeZD3jOQMo0=.5ece10c3-1347-48da-a577-930eb76df09b@github.com>

> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
> 
> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
> 
> 
> After patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
> 
> 
> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
> 
> Before patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
> 
> 
> After patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
> 
> 
> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Fixes after Paul's changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3427/files
  - new: https://git.openjdk.java.net/jdk/pull/3427/files/a63e25d0..0747e174

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=02-03

  Stats: 32 lines in 1 file changed: 12 ins; 0 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3427.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427

PR: https://git.openjdk.java.net/jdk/pull/3427

From tvaleev at openjdk.java.net  Sat Apr 17 02:59:58 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sat, 17 Apr 2021 02:59:58 GMT
Subject: RFR: 8265029: Preserve SIZED characteristics on slice operations
 (skip, limit) [v5]
In-Reply-To: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
References: <So99taGPqGAlT2i6OTlV29yfu9bll7Uawe9slE8iWaw=.26963b78-8b02-4f81-b659-0ab1df531cde@github.com>
Message-ID: <9s3ZEIdEyeT3eINpBDUBC2TjvXlVr7TPd_vnqOQqQ_0=.b66454d4-c7c0-40c2-9f0e-7879a08410ac@github.com>

> With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch.
> 
> Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10   40235,534 ?     0,984    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  106431,101 ?     0,198    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  106544,977 ?     1,983    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10   40121,878 ?     0,247    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  106317,693 ?     1,083    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  106430,954 ?     0,136    B/op
> 
> 
> After patch:
> 
> ref.SliceToList.seq_baseline:?gc.alloc.rate.norm                    10000  thrpt   10  40235,648 ?     1,354    B/op
> ref.SliceToList.seq_limit:?gc.alloc.rate.norm                       10000  thrpt   10  40355,784 ?     1,288    B/op
> ref.SliceToList.seq_skipLimit:?gc.alloc.rate.norm                   10000  thrpt   10  40476,032 ?     2,855    B/op
> value.SliceToArray.seq_baseline:?gc.alloc.rate.norm                 10000  thrpt   10  40121,830 ?     0,308    B/op
> value.SliceToArray.seq_limit:?gc.alloc.rate.norm                    10000  thrpt   10  40242,554 ?     0,443    B/op
> value.SliceToArray.seq_skipLimit:?gc.alloc.rate.norm                10000  thrpt   10  40363,674 ?     1,576    B/op
> 
> 
> Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests.
> 
> Before patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score     Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14876,723 ?  99,770  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  14856,841 ? 215,089  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30   9555,818 ? 991,335  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  23732,290 ? 444,162  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  14894,040 ? 176,496  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  10646,929 ?  36,469  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25093,141 ? 376,402  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  24798,889 ? 760,762  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  16456,310 ? 926,882  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  69669,787 ? 494,562  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  21097,081 ? 117,338  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  15522,871 ? 112,557  ops/s
> 
> 
> After patch:
> 
> Benchmark                         (size)   Mode  Cnt      Score      Error  Units
> ref.SliceToList.par_baseline       10000  thrpt   30  14793,373 ?   64,905  ops/s
> ref.SliceToList.par_limit          10000  thrpt   30  13301,024 ? 1300,431  ops/s
> ref.SliceToList.par_skipLimit      10000  thrpt   30  11131,698 ? 1769,932  ops/s
> ref.SliceToList.seq_baseline       10000  thrpt   30  24101,048 ?  263,528  ops/s
> ref.SliceToList.seq_limit          10000  thrpt   30  16872,168 ?   76,696  ops/s
> ref.SliceToList.seq_skipLimit      10000  thrpt   30  11953,253 ?  105,231  ops/s
> value.SliceToArray.par_baseline    10000  thrpt   30  25442,442 ?  455,554  ops/s
> value.SliceToArray.par_limit       10000  thrpt   30  23111,730 ? 2246,086  ops/s
> value.SliceToArray.par_skipLimit   10000  thrpt   30  17980,750 ? 2329,077  ops/s
> value.SliceToArray.seq_baseline    10000  thrpt   30  66512,898 ? 1001,042  ops/s
> value.SliceToArray.seq_limit       10000  thrpt   30  41792,549 ? 1085,547  ops/s
> value.SliceToArray.seq_skipLimit   10000  thrpt   30  18007,613 ?  141,716  ops/s
> 
> 
> I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  adjustSize -> exactOutputSize

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3427/files
  - new: https://git.openjdk.java.net/jdk/pull/3427/files/0747e174..6e77cfd6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3427.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427

PR: https://git.openjdk.java.net/jdk/pull/3427

From naoto at openjdk.java.net  Sat Apr 17 03:39:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 17 Apr 2021 03:39:55 GMT
Subject: RFR: 8264208: Console charset API [v10]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <O6B5dsDLZySJKuppiq1n7_GH0yopNXNfbGY5y32Jp2U=.a141f459-f492-4a84-89fa-2955d6fa706f@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Changed shell based test into java based
 - Added link to Charset#defaultChaset() in InputStreamReader.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/083f6180..238dbb42

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=08-09

  Stats: 88 lines in 3 files changed: 27 ins; 51 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

PR: https://git.openjdk.java.net/jdk/pull/3419

From david.holmes at oracle.com  Sat Apr 17 05:07:35 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 17 Apr 2021 15:07:35 +1000
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
In-Reply-To: <371602c3-69b4-1a1f-1e12-1d04914f3463@gmail.com>
References: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
 <e71bbf02-9080-1afa-42af-2094e751688f@oracle.com>
 <371602c3-69b4-1a1f-1e12-1d04914f3463@gmail.com>
Message-ID: <fab1c198-6f6c-0149-b027-ae5ce9e1cbf6@oracle.com>

On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
> I guess the reporter meant to limit the cache range similarly to the one 
> used for valueOf().
> 
> I have no clue about the benefit/cost ratio for the proposed String 
> cache. It really depends on usage, workload, etc. One can easily imagine 
> both extreme scenarios but it's hard to tell how the average one would 
> look.
> 
> My post is only about either solving the issue by implementing the 
> cache, which I can contribute to; or closing it because of lack of 
> real-world need or interest.

Caching for the sake of caching is not an objective in itself. Unless 
the caching can be shown to solve a real problem, and the strategy for 
managing the cache is well-defined, then I would just close the 
enhancement request. (Historically whether an issue we don't have any 
firm plans to address is just left open "forever" or closed, depends 
very much on who does the bug triaging in that area. :) )

Cheers,
David

> 
> Greetings
> Raffaello
> 
> 
> On 2021-04-16 20:36, Roger Riggs wrote:
>> Hi,
>>
>> Is there any way to quantify the savings?
>> And what technique can be applied to limit the size of the cache.
>> The size of the small integer cache is somewhat arbitrary.
>>
>> Regards, Roger
>>
>> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
>>> Hello,
>>>
>>> does the enhancement proposed in [1] make sense, both today and when 
>>> wrappers will be migrated to primitive classes?
>>> If so, it should be rather simple to add it and I could prepare a PR.
>>> If not, the issue might perhaps be closed.
>>>
>>>
>>> Greetings
>>> Raffaello
>>>
>>> ----
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252827
>>

From david.holmes at oracle.com  Sat Apr 17 05:14:30 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 17 Apr 2021 15:14:30 +1000
Subject: jpackage bugs
In-Reply-To: <02F6EA89-922F-4A50-954F-2423DEF1113A@gmail.com>
References: <02F6EA89-922F-4A50-954F-2423DEF1113A@gmail.com>
Message-ID: <0a19551f-a321-f027-9b36-529c34a547b3@oracle.com>

Hi Michael,

On 17/04/2021 10:57 am, Michael Hall wrote:
> Is there anyway to get a simple/test reference type application available that could be used in reproducing bugs?
> 
> I had two I think potentially serious bugs that were basically not addressed for problems in reproducing.
> 
> JDK-8263156 : [macos]: OS X application signing concerns - a sealed resource is missing or invalid
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156>
> 
> The command to reproduce was provided. The error appears to be in files included in the embedded JDK not being signed. So apparently not having to do with anything of mine. (Mentioned I now see in the comments).
> 
> As I indicate this is not a serious error for me since I am not submitting the app to the Mac App Store but I believe this would get the app Apple rejected for anyone who is attempting that. A show stopper for a major use case. It seems too bad to simply close it because I missed an email asking for a reproduce.

Note the bug referenced is closed as "incomplete" - that is a temporary 
state while awaiting additional information  (usually from the 
submitter). If we never hear back from the submitter then it will be 
closed with a different (more terminal) state. If we do hear back then 
the bug gets reopened.

Cheers,
David

> With a reference application I could demonstrate the error against would eliminate the need to provide a separate reproducible test case. Quite sized for the application in question. Such an application is actually mentioned in the bug report comments. Could such a application be made available for download or user reproducing - the jpackage command and arguments?
> 
> I have looked a little bit at if to see if I can figure out how to sign the embedded jdk files. So far only accomplishing that I can no longer simply use my name for signing but have to use my fully qualified security identity.
> 
> The question now seems to be what is in fact the difference between mine and the, unavailable to me, reference application as to these files verifying as correctly signed.
> 
> A second bug
> JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect
> 
> I thought a fix for this was all set to go in and was pulled. It was apparently determined that the problem only applies if the ?install-dir parameter is used for DMG?s. Where it really makes no sense. My use apparently held over from when I was just creating the app.I thought this had somehow also in some way regressed to not reproducible. I still think a fairly simple change to the AppleScript as was originally planned would resolve the issue independently of parameters. The default DMG build I would think should _always_ indicate installation to the Applications folder.
> 
> With ?install-dir this remains a reproducible bug for me at 17-ea.
> 
> If a reference build was provided somewhere I might have picked up on the parameter difference sooner.
> 
> 
> 
> 
> 

From tvaleev at openjdk.java.net  Sat Apr 17 09:02:52 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sat, 17 Apr 2021 09:02:52 GMT
Subject: RFR: 8265356: need code example for getting canonical constructor of
 a Record
Message-ID: <YIXReZGwfOekkWodThE2ofggNC1vMVPEoUu9PohR7QA=.3fc2f794-2b4f-4f85-ac41-3f7af9b880d4@github.com>

I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static <T extends Record>\nConstructor<T> getCanonicalConstructor(Class<T> cls)` is unnecessary.

---
Aside from this PR, I've found a couple of things to clean up in `java.lang.Class`:
1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by @jddarcy in #3038). It should be `#isArray()` instead of `isArray()`.
2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused type parameters `<T>`.
3. Probably too much but AnnotationData can be nicely converted to a record! Not sure, probably nobody wants to have `java.lang.Record` initialized too early or increasing the footprint of such a basic class in the metaspace, so I don't insist on this.


    private record AnnotationData(
        Map<Class<? extends Annotation>, Annotation> annotations,
        Map<Class<? extends Annotation>, Annotation> declaredAnnotations,
        // Value of classRedefinedCount when we created this AnnotationData instance
        int redefinedCount) {
    }


Please tell me if it's ok to fix 1 and 2 along with this PR.

-------------

Commit messages:
 - 8265356: need code example for getting canonical constructor of a Record

Changes: https://git.openjdk.java.net/jdk/pull/3556/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3556&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265356
  Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3556.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3556/head:pull/3556

PR: https://git.openjdk.java.net/jdk/pull/3556

From mik3hall at gmail.com  Sat Apr 17 09:05:58 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 17 Apr 2021 04:05:58 -0500
Subject: jpackage bugs 
In-Reply-To: <0a19551f-a321-f027-9b36-529c34a547b3@oracle.com>
References: <02F6EA89-922F-4A50-954F-2423DEF1113A@gmail.com>
 <0a19551f-a321-f027-9b36-529c34a547b3@oracle.com>
Message-ID: <ED1EBEE5-E423-4121-B0A1-E0F9A49E8966@gmail.com>



> On Apr 17, 2021, at 12:14 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
>> 
> 
> Note the bug referenced is closed as "incomplete" - that is a temporary state while awaiting additional information  (usually from the submitter). If we never hear back from the submitter then it will be closed with a different (more terminal) state. If we do hear back then the bug gets reopened.

I was unaware of this distinction. Then I will attempt to come up with a simpler reproducible test case but I don?t know if I?ll succeed. If the test that didn?t reproduce that is mentioned in the comments was available I could try to compare that with what I am doing for differences. 

I could provide my invocation parameters to the email requesting the reproducer. That is my only direct involvement. If it is something else particular to the application itself I don?t know what that might be. Modular vs. my non-modular? Or something like that maybe. I think this always embeds the current JDK and I have checked against more than one so it doesn?t seem to be JDK version specific.

Thanks for pointing this status information out.



From raffaello.giulietti at gmail.com  Sat Apr 17 09:06:26 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Sat, 17 Apr 2021 11:06:26 +0200
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
In-Reply-To: <fab1c198-6f6c-0149-b027-ae5ce9e1cbf6@oracle.com>
References: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
 <e71bbf02-9080-1afa-42af-2094e751688f@oracle.com>
 <371602c3-69b4-1a1f-1e12-1d04914f3463@gmail.com>
 <fab1c198-6f6c-0149-b027-ae5ce9e1cbf6@oracle.com>
Message-ID: <4aa48a1d-0e80-5531-4938-0cf04ce6396f@gmail.com>



On 2021-04-17 07:07, David Holmes wrote:
> On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
>> I guess the reporter meant to limit the cache range similarly to the 
>> one used for valueOf().
>>
>> I have no clue about the benefit/cost ratio for the proposed String 
>> cache. It really depends on usage, workload, etc. One can easily 
>> imagine both extreme scenarios but it's hard to tell how the average 
>> one would look.
>>
>> My post is only about either solving the issue by implementing the 
>> cache, which I can contribute to; or closing it because of lack of 
>> real-world need or interest.
> 
> Caching for the sake of caching is not an objective in itself. Unless 
> the caching can be shown to solve a real problem, and the strategy for 
> managing the cache is well-defined, then I would just close the 
> enhancement request. (Historically whether an issue we don't have any 
> firm plans to address is just left open "forever" or closed, depends 
> very much on who does the bug triaging in that area. :) )
> 
> Cheers,
> David
> 


Indeed, the impression is that many of the issues are probably open 
because it's unclear whether they should be addressed with some 
implementation or spec effort or whether they should be closed. Triaging 
is certainly a harder job than it appears at first sight ;-)

It would be useful to have a kind of "suspended" or "limbo" resolution 
state on the JBS for issues like this one, so people searching for more 
compelling open ones would not encounter them.

Personally, I would close this issue without a "fix"; or "suspend" it.


Greetings
Raffaello



>>
>> Greetings
>> Raffaello
>>
>>
>> On 2021-04-16 20:36, Roger Riggs wrote:
>>> Hi,
>>>
>>> Is there any way to quantify the savings?
>>> And what technique can be applied to limit the size of the cache.
>>> The size of the small integer cache is somewhat arbitrary.
>>>
>>> Regards, Roger
>>>
>>> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
>>>> Hello,
>>>>
>>>> does the enhancement proposed in [1] make sense, both today and when 
>>>> wrappers will be migrated to primitive classes?
>>>> If so, it should be rather simple to add it and I could prepare a PR.
>>>> If not, the issue might perhaps be closed.
>>>>
>>>>
>>>> Greetings
>>>> Raffaello
>>>>
>>>> ----
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252827
>>>

From tvaleev at openjdk.java.net  Sat Apr 17 09:10:36 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sat, 17 Apr 2021 09:10:36 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v2]
In-Reply-To: <Q0KrFJ5y96KgNO15EOLFT6XU-0OkxjiA3ezBf0lujy8=.9e2d4b07-820c-4c86-9475-fa6b8696d3c3@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <Q0KrFJ5y96KgNO15EOLFT6XU-0OkxjiA3ezBf0lujy8=.9e2d4b07-820c-4c86-9475-fa6b8696d3c3@github.com>
Message-ID: <1UfcLtm4PWavofsgtCfu1Ie53QU_Rr_oVJYM7zWAXnc=.67a58066-9d2d-4f35-afaf-7dd276cf14ef@github.com>

On Thu, 15 Apr 2021 19:26:48 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
>> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
>> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
>> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
>> 
>> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
>> 
>> The comparative results are here:
>> 
>> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
>> 
>> The jmh-result.json files are here:
>> 
>> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
>> 
>> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
>> 
>> So WDYT?
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add String.join benchmark method to StringJoinerBenchmark and adjust some parameters to cover bigger range

Great work, thanks! I tried to do something similar a couple of years ago but did not submit my patch. One thing that stopped me is that joining many one-character strings was slower with my patch, compared to the baseline. Something like this:


// setup
String[] strings = new String[100];
Arrays.fill(strings, "a");
// benchmark
return String.join(",", strings);


Could you add this case to your benchmark, for completeness?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From bourges.laurent at gmail.com  Sat Apr 17 09:18:03 2021
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 17 Apr 2021 11:18:03 +0200
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
In-Reply-To: <4aa48a1d-0e80-5531-4938-0cf04ce6396f@gmail.com>
References: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
 <e71bbf02-9080-1afa-42af-2094e751688f@oracle.com>
 <371602c3-69b4-1a1f-1e12-1d04914f3463@gmail.com>
 <fab1c198-6f6c-0149-b027-ae5ce9e1cbf6@oracle.com>
 <4aa48a1d-0e80-5531-4938-0cf04ce6396f@gmail.com>
Message-ID: <CAKjRUT5nC=rQhmdG619uCaowKUN0k1T0RRRosqgYDuK-Nomx9w@mail.gmail.com>

Hi,

I read the JBS bug and I interpret it as:
- IntegerCache provides Integer instances for [-128, 127] by default
- Having Integer.toString(int) could behave the same or at least cache most
probable values like [-1 to 16] or using the IntegerCache range.

It looks trivial and potentially could benefits to jdk itself to reduce
memory garbage : is Integer.toString(int) widely used in the jdk codebase ?

Finally it can be alternatively implemented in application's code.

My 2 cents,
Laurent

Le sam. 17 avr. 2021 ? 11:06, Raffaello Giulietti <
raffaello.giulietti at gmail.com> a ?crit :

>
>
> On 2021-04-17 07:07, David Holmes wrote:
> > On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
> >> I guess the reporter meant to limit the cache range similarly to the
> >> one used for valueOf().
> >>
> >> I have no clue about the benefit/cost ratio for the proposed String
> >> cache. It really depends on usage, workload, etc. One can easily
> >> imagine both extreme scenarios but it's hard to tell how the average
> >> one would look.
> >>
> >> My post is only about either solving the issue by implementing the
> >> cache, which I can contribute to; or closing it because of lack of
> >> real-world need or interest.
> >
> > Caching for the sake of caching is not an objective in itself. Unless
> > the caching can be shown to solve a real problem, and the strategy for
> > managing the cache is well-defined, then I would just close the
> > enhancement request. (Historically whether an issue we don't have any
> > firm plans to address is just left open "forever" or closed, depends
> > very much on who does the bug triaging in that area. :) )
> >
> > Cheers,
> > David
> >
>
>
> Indeed, the impression is that many of the issues are probably open
> because it's unclear whether they should be addressed with some
> implementation or spec effort or whether they should be closed. Triaging
> is certainly a harder job than it appears at first sight ;-)
>
> It would be useful to have a kind of "suspended" or "limbo" resolution
> state on the JBS for issues like this one, so people searching for more
> compelling open ones would not encounter them.
>
> Personally, I would close this issue without a "fix"; or "suspend" it.
>
>
> Greetings
> Raffaello
>
>
>
> >>
> >> Greetings
> >> Raffaello
> >>
> >>
> >> On 2021-04-16 20:36, Roger Riggs wrote:
> >>> Hi,
> >>>
> >>> Is there any way to quantify the savings?
> >>> And what technique can be applied to limit the size of the cache.
> >>> The size of the small integer cache is somewhat arbitrary.
> >>>
> >>> Regards, Roger
> >>>
> >>> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
> >>>> Hello,
> >>>>
> >>>> does the enhancement proposed in [1] make sense, both today and when
> >>>> wrappers will be migrated to primitive classes?
> >>>> If so, it should be rather simple to add it and I could prepare a PR.
> >>>> If not, the issue might perhaps be closed.
> >>>>
> >>>>
> >>>> Greetings
> >>>> Raffaello
> >>>>
> >>>> ----
> >>>>
> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252827
> >>>
>

From scolebourne at joda.org  Sat Apr 17 09:48:29 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 17 Apr 2021 10:48:29 +0100
Subject: ReversibleCollection proposal
In-Reply-To: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
Message-ID: <CACzrW9C+1TTLuid+X1SWeKCtHusDrJ81=ou7MN1tXrbHJ6PVmw@mail.gmail.com>

On Fri, 16 Apr 2021 at 18:41, Stuart Marks <stuart.marks at oracle.com> wrote:
> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on detailed
> specifications and tests. Please send such comments as replies on this email thread.

I think this could be an interesting addition to the framework.

> # Ordering and Reversibility

Reading this section, it seems like ordering is a more significant
quality than reversibility. Yet the API is named "reversible". That
seems odd, esepcially given the stream characteristic.

> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because
> SortedSet's ordering is determined by the comparison method and cannot be controlled
> explicitly.

This seems undesirable. Maybe SortedSet should not implement
reversible/ordered? Maybe they should add to the set but validate
whether they would be in first/last position? Simply allowing users to
get a new instance with a different (eg. reversed) comparator would
meet much of the use case.

Also, SortedSet uses first() and last(), yet the proposed interface
uses getFirst() and getLast().

Stephen

From dev at anthonyv.be  Sat Apr 17 11:29:09 2021
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Sat, 17 Apr 2021 13:29:09 +0200
Subject: =?utf-8?q?Re=3A?= ReversibleCollection proposal
In-Reply-To: <CACzrW9C+1TTLuid+X1SWeKCtHusDrJ81=ou7MN1tXrbHJ6PVmw@mail.gmail.com>
Message-ID: <cc2-607ac680-7f-3a71e280@113542158>

On Saturday, April 17, 2021 11:48 CEST, Stephen Colebourne <scolebourne at joda.org> wrote: 
 
> On Fri, 16 Apr 2021 at 18:41, Stuart Marks <stuart.marks at oracle.com> wrote:
> > This is a proposal to add a ReversibleCollection interface to the Collections
> > Framework. I'm looking for comments on overall design before I work on detailed
> > specifications and tests. Please send such comments as replies on this email thread.
> 
> I think this could be an interesting addition to the framework.
> 
> > # Ordering and Reversibility
> 
> Reading this section, it seems like ordering is a more significant
> quality than reversibility. Yet the API is named "reversible". That
> seems odd, esepcially given the stream characteristic.

Since `reversible = ordered + sized`, using reversible makes sense imho (even though in the context of the Collections Framework, reversible <-> ordered, since all collections are sized). Also, I think "reversible" is much less likely to clash with existing code (e.g. a quick GitHub search shows 1 result for `ReversibleCollection`, while there's plenty for `OrderedCollection`).

> 
> > SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because
> > SortedSet's ordering is determined by the comparison method and cannot be controlled
> > explicitly.
> 
> This seems undesirable. Maybe SortedSet should not implement
> reversible/ordered? Maybe they should add to the set but validate
> whether they would be in first/last position? Simply allowing users to
> get a new instance with a different (eg. reversed) comparator would
> meet much of the use case.

I'd argue throwing UOE is the right thing to do. Not having `SortedSet` implement `ReversibleSet` doesn't make sense to me. Adding with validation is reasonable in itself, but then you'd have to specify `IllegalArgumentException` in `ReversibleCollection` (where you'd have a hard time specifying the conditions under which it might be thrown without explicitly referencing `SortedSet`), just to accommodate these 2 methods which would be very rarely used.

> 
> Also, SortedSet uses first() and last(), yet the proposed interface
> uses getFirst() and getLast().

Since `Deque` uses `getFirst()` and `getLast()`, it's impossible to match all existing methods in the different interfaces.

> 
> Stephen

Kind regards, Anthony


From amaembo at gmail.com  Sat Apr 17 11:49:43 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Sat, 17 Apr 2021 18:49:43 +0700
Subject: ReversibleCollection proposal
In-Reply-To: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
Message-ID: <CAE+3fjav3wGMBQyj1xVbyv-QJyqFmMxz0UYFFJdh7iZyPtWmtg@mail.gmail.com>

Great proposal, thanks!

It has most functionality from my previous proposal, except the
ability to iterate LinkedHashSet starting from a specific element.
Well, probably we can skip this for now.

Some people really want to reverse Streams as well. E. g., the
corresponding StackOverflow question [1] has 171 upvotes and 200k+
views. Also, if the stream were reversible, it would be possible to
implement efficient foldRight/reduceRight operation. See the
discussion at [2]. It would be nice to explore the possibility of
extending Stream API to take into account the source reversibility.
Some existing ordered sources that have no underlying collection (e.g.
IntStream.range, or Arrays.stream) can be easily reversed as well. Map
and filter operations preserve reversibility and flatMap is reversible
if the supplied stream is reversible as well.

With best regards,
Tagir Valeev.

[1] https://stackoverflow.com/q/24010109/4856258
[2] https://bugs.openjdk.java.net/browse/JDK-8133680

On Sat, Apr 17, 2021 at 12:41 AM Stuart Marks <stuart.marks at oracle.com> wrote:
>
> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on detailed
> specifications and tests. Please send such comments as replies on this email thread.
>
> Here's a link to a draft PR that contains the code diffs. It's prototype quality,
> but it should be good enough to build and try out:
>
>      https://github.com/openjdk/jdk/pull/3533
>
> And here's a link to a class diagram showing the proposed additions:
>
>
> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
>
> Thanks,
>
> s'marks
>
>
> # Ordering and Reversibility
>
>
> A long-standing concept that's been missing from collections is that of the
> positioning, sequencing, or arrangement of elements as a structural property of a
> collection. (This is sometimes called the "iteration order" of a collection.) For
> example, a HashSet is not ordered, but a List is. This concept is mostly not
> manifested in the collections API.
>
> Iterating a collection produces elements one after another in *some* sequence. The
> concept of "ordered" determines whether this sequence is defined or whether it's a
> coincidence of implementation. What does "having an order" mean? It implies that
> there is a first element and that each element has a successor. Since collections
> have a finite number of elements, it further implies that there is a last element
> that has no successor. However, it is difficult to discern whether a collection has
> a defined order. HashSet generally iterates its elements in the same undefined
> order, and you can't actually tell that it's not a defined order.
>
> Streams do have a notion of ordering ("encounter order") and this is preserved,
> where appropriate, through the stream pipeline. It's possible to detect this by
> testing whether its spliterator has the ORDERED characteristic. Any collection with
> a defined order will have a spliterator with this characteristic. However, this is
> quite a roundabout way to determine whether a collection has a defined order.
> Furthermore, knowing this doesn't enable any additional operations. It only provides
> constraints on the stream's implementations (keeping the elements in order) and
> provides stronger semantics for certain operations. For example, findFirst() on an
> unordered stream is the same as findAny(), but actually finds the first element if
> the stream is ordered.
>
> The concept of ordering is thus present in the system but is surfaced only in a
> fairly indirect way. We can strengthen abstraction of ordering by making a few
> observations and considering their implications.
>
> Given that there is a first element and a last element, the sequence of elements has
> two ends. It's reasonable to consider operations (add, get, remove) on either end.
> Indeed, the Deque interface has a full complement of operations at each end. This is
> an oft-requested feature on various other collections.
>
> Each element except for the last has a successor, implying that each element except
> for the first has a predecessor. Thus it's reasonable to consider iterating the
> elements from first to last or from last to first (that is, in forward or reverse
> order). Indeed, the concept of iterating in reverse order appears already in bits
> and pieces in particular places around the collections:
>
>   - List has indexOf() and lastIndexOf()
>   - Deque has removeFirstOccurrence() and removeLastOccurrence()
>   - List has a ListIterator with hasPrevious/previous methods
>   - Deque and NavigableSet have descendingIterator methods
>
> Given an ordered collection, though, there's no general way to iterate it in reverse
> order. Reversed iteration isn't the most common operation, but there are some
> frequent use cases, such as operating on elements in most-recently-added order.
> Questions and bug reports about this have come up repeatedly over the years.
>
> Unfortunately, iterating in reverse order is much harder than iterating in forward
> order. There are a variety of ways to iterate in forward order. For example, given a
> List, one can do any of the following:
>
>      for (var e : list) { ... }
>      list.forEach(...)
>      list.stream()
>      list.toArray()
>
> However, to iterate a list in reverse order, one must use an explicit loop over
> ListIterator:
>
>      for (var it = list.listIterator(list.size()); it.hasPrevious(); ) {
>          var e = it.previous();
>          ...
>      }
>
> Streaming the elements of a List in reverse order is even worse. One approach would
> be to implement a reverse-ordered Iterator that wraps a ListIterator and delegates
> hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then, this
> Iterator can be turned into a Spliterator, which is then turned into a Stream. (The
> code to do this is left as an exercise for the reader.) Obtaining the elements in
> reverse via other means -- forEach() or toArray() -- is similarly difficult.
>
> Obtaining the elements in reverse order can be accomplished by adopting a concept
> from NavigableSet's descendingSet() method, which provides a reverse-ordered view
> collection. This view is also a NavigableSet, which means that any operation that
> can be performed on the original set can also be applied to the reverse-ordered
> view. If it were possible to obtain a similar reverse-ordered view on any kind of
> ordered collection, this would enable the elements to be processed in reverse order
> in any fashion, not just special-purposes APIs such as ListIterator or
> descendingIterator().
>
>
> # LinkedHashSet
>
>
> The main feature of LinkedHashSet is that it does have a defined ordering, as
> opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last
> element. However, LinkedHashSet is deficient in a number of ways:
>
>   - access to and removal of the first element is reasonable (using an iterator) but
> it is not possible to add at the front
>
>   - it is possible to add an element at the end, but access to and removal of the
> last element are expensive
>
>   - it's not possible to iterate in reverse without copying the entire collection
>
> Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so
> there is no fundamental implementation reason that prevents these operations from
> being supported. The main reason these operations aren't supported is probably that
> there hasn't been a good place to push such APIs.
>
>
> # Proposal
>
>
> Introduce a new ReversibleCollection<E> interface. This provides a new method to
> obtain a reverse-ordered view. It also contains several methods (copied from Deque)
> that allow operating on elements at both ends.
>
>
>      interface ReversibleCollection<E> extends Collection<E> {
>          ReversibleCollection<E> reversed();
>          default void addFirst(E e)
>          default void addLast(E e)
>          default E getFirst()
>          default E getLast()
>          default E removeFirst()
>          default E removeLast()
>      }
>
>
> The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are
> retrofitted to implement ReversibleCollection. They provide covariant overriding
> implementations of the reversed() method. For example, List.reversed() returns a
> List. Default implementations for all of these methods are provided in the
> appropriate interfaces.
>
> Covariant overrides are also provided in several other classes. This presents a
> difficulty for LinkedHashSet, as there's no suitable return type for reversed(). To
> remedy this, we add another interface
>
>
>      interface ReversibleSet<E> extends ReversibleCollection<E>, Set<E> { }
>
>
> This adds no new methods but is essentially an intersection of ReversibleCollection
> and Set. As such, it's suitable as the return type of LinkedHashSet.reversed() and
> the set views of LinkedHashMap.
>
> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because
> SortedSet's ordering is determined by the comparison method and cannot be controlled
> explicitly.
>
> LinkedHashSet::addFirst and addLast add the element at the appropriate position or
> reposition the element if it is already present in the set.
>
> New methods are added to LinkedHashMap
>
>      V putFirst(K, V)
>      V putLast(K, V)
>
> which put the mapping at the designated position or reposition the mapping if is
> already present in the map.
>
>
> # Design & Implementation Issues
>
>
> Covariant overrides for reversed() are provided where possible. However, there is a
> conflict between List and Deque, as there are examples in the JDK (such as
> LinkedList) that implement both List and Deque. Since List is much more popular than
> Deque, I've decided against adding a covariant override to Deque. Instead, a method
> Deque::reversedDeque is added that returns a Deque, and Deque::reversed returns
> ReversibleCollection.
>
> There is no ReversibleMap interface. Most iteration over maps is over the entrySet,
> keySet, or values views. NavigableMap already has descendingMap(), and LinkedHashMap
> provides ReversibleX views, which cover most of the cases already.
>
> Introducing new methods into an interface hierarchy always raises the possibility of
> name clashes. I've done some searching but I haven't found any major issues, but we
> should be on the lookout for this. I'll continue to do more searching for such
> conflicts.
>
> Introducing covariant overrides on existing methods (notably LinkedHashMap entrySet,
> keySet, and values) could present incompatibility issues with subclasses that
> override these methods. I've done some searching and again I haven't found major
> problems, but this is nonetheless a point of concern. I'll do more searching here, too.
>
> The default implementations for List::reversed, Deque::reversed, and
> SortedSet::reversed return reverse-ordered views that are implemented using only
> public methods of the original interface. This demonstrates the feasibility of
> retrofitting reverse ordering onto any instance of these interfaces. Similarly, the
> various add/get/remove methods' default implementations are all implementable in
> terms of an iterator or reverse-ordered iterator. That said, some concurrent
> collection implementations will need to override these default implementations in
> order to preserve their safety invariants. It would probably also be wise to add
> optimized implementations to the more commonly-used collection implementations.
>
> Given that a ReversibleCollection has a defined ordering, any spliterator obtained
> from such a collection should have the Spliterator.ORDERED characteristic.
>
> This proposal is related to a previous discussion on a similar topic, where Tagir
> Valeev had proposed OrderedSet and OrderedMap:
>
>      http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066028.html
>
> I think there were some good ideas in there and in the ensuing discussion, but it
> didn't go anywhere. Several of the concepts in this proposal are an evolution of
> some ideas discussed in that thread.
>
> One of the ideas from that thread was to use Deque as a common interface for many
> collections to support reversibility and operations at the ends. We've abandoned
> that idea in this proposal. The reasons are that it's cluttered with a bunch of
> methods that are inherited from Queue. Also, some methods are null-returning instead
> of throwing, which introduces confusion for collections that can contain nulls.
>
> # END

From raffaello.giulietti at gmail.com  Sat Apr 17 12:19:21 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Sat, 17 Apr 2021 14:19:21 +0200
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
In-Reply-To: <CAKjRUT5nC=rQhmdG619uCaowKUN0k1T0RRRosqgYDuK-Nomx9w@mail.gmail.com>
References: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
 <e71bbf02-9080-1afa-42af-2094e751688f@oracle.com>
 <371602c3-69b4-1a1f-1e12-1d04914f3463@gmail.com>
 <fab1c198-6f6c-0149-b027-ae5ce9e1cbf6@oracle.com>
 <4aa48a1d-0e80-5531-4938-0cf04ce6396f@gmail.com>
 <CAKjRUT5nC=rQhmdG619uCaowKUN0k1T0RRRosqgYDuK-Nomx9w@mail.gmail.com>
Message-ID: <d14e2c71-0236-d8bc-9917-6198584f7956@gmail.com>

Hi,

in view of Integer becoming a primitive class [1], the IntegerCache is 
probably going to disappear.

For a small, fixed range like the one you are proposing [-1, 16], 
there's no real need for a separate cache class. You could have a switch 
in the implementation of toString(), with the string literals then being 
part of the constant pool of the class. Not free beer, but supported by 
the VM since day 0.

It's only when the range is open that you'd need a cache similar to 
IntegerCache.


My 2 cents as well :-)
Raffaello

----

[1] https://openjdk.java.net/jeps/402

On 2021-04-17 11:18, Laurent Bourg?s wrote:
> Hi,
> 
> I read the JBS bug and I interpret it as:
> - IntegerCache provides Integer instances for [-128, 127] by default
> - Having Integer.toString(int) could behave the same or at least cache 
> most probable values like [-1 to 16] or using the IntegerCache range.
> 
> It looks trivial and potentially could benefits to jdk itself to reduce 
> memory garbage : is Integer.toString(int) widely used in the jdk codebase ?
> 
> Finally it can be alternatively implemented in application's code.
> 
> My 2 cents,
> Laurent
> 
> Le sam. 17 avr. 2021 ? 11:06, Raffaello Giulietti 
> <raffaello.giulietti at gmail.com <mailto:raffaello.giulietti at gmail.com>> a 
> ?crit?:
> 
> 
> 
>     On 2021-04-17 07:07, David Holmes wrote:
>      > On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
>      >> I guess the reporter meant to limit the cache range similarly to
>     the
>      >> one used for valueOf().
>      >>
>      >> I have no clue about the benefit/cost ratio for the proposed String
>      >> cache. It really depends on usage, workload, etc. One can easily
>      >> imagine both extreme scenarios but it's hard to tell how the
>     average
>      >> one would look.
>      >>
>      >> My post is only about either solving the issue by implementing the
>      >> cache, which I can contribute to; or closing it because of lack of
>      >> real-world need or interest.
>      >
>      > Caching for the sake of caching is not an objective in itself.
>     Unless
>      > the caching can be shown to solve a real problem, and the
>     strategy for
>      > managing the cache is well-defined, then I would just close the
>      > enhancement request. (Historically whether an issue we don't have
>     any
>      > firm plans to address is just left open "forever" or closed, depends
>      > very much on who does the bug triaging in that area. :) )
>      >
>      > Cheers,
>      > David
>      >
> 
> 
>     Indeed, the impression is that many of the issues are probably open
>     because it's unclear whether they should be addressed with some
>     implementation or spec effort or whether they should be closed.
>     Triaging
>     is certainly a harder job than it appears at first sight ;-)
> 
>     It would be useful to have a kind of "suspended" or "limbo" resolution
>     state on the JBS for issues like this one, so people searching for more
>     compelling open ones would not encounter them.
> 
>     Personally, I would close this issue without a "fix"; or "suspend" it.
> 
> 
>     Greetings
>     Raffaello
> 
> 
> 
>      >>
>      >> Greetings
>      >> Raffaello
>      >>
>      >>
>      >> On 2021-04-16 20:36, Roger Riggs wrote:
>      >>> Hi,
>      >>>
>      >>> Is there any way to quantify the savings?
>      >>> And what technique can be applied to limit the size of the cache.
>      >>> The size of the small integer cache is somewhat arbitrary.
>      >>>
>      >>> Regards, Roger
>      >>>
>      >>> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
>      >>>> Hello,
>      >>>>
>      >>>> does the enhancement proposed in [1] make sense, both today
>     and when
>      >>>> wrappers will be migrated to primitive classes?
>      >>>> If so, it should be rather simple to add it and I could
>     prepare a PR.
>      >>>> If not, the issue might perhaps be closed.
>      >>>>
>      >>>>
>      >>>> Greetings
>      >>>> Raffaello
>      >>>>
>      >>>> ----
>      >>>>
>      >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252827
>     <https://bugs.openjdk.java.net/browse/JDK-8252827>
>      >>>
> 

From andy.herrick at oracle.com  Sat Apr 17 13:57:24 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Sat, 17 Apr 2021 09:57:24 -0400
Subject: jpackage bugs
In-Reply-To: <0a19551f-a321-f027-9b36-529c34a547b3@oracle.com>
References: <02F6EA89-922F-4A50-954F-2423DEF1113A@gmail.com>
 <0a19551f-a321-f027-9b36-529c34a547b3@oracle.com>
Message-ID: <ea69f19a-07f3-750b-ae5f-0b92baed9e8a@oracle.com>


On 4/17/2021 1:14 AM, David Holmes wrote:
> Hi Michael,
>
> On 17/04/2021 10:57 am, Michael Hall wrote:
>> Is there anyway to get a simple/test reference type application 
>> available that could be used in reproducing bugs?
I put a simple test application I was using in your bug report: 
https://bugs.openjdk.java.net/browse/JDK-8263156
>>
>> I had two I think potentially serious bugs that were basically not 
>> addressed for problems in reproducing.
>>
>> JDK-8263156 : [macos]: OS X application signing concerns - a sealed 
>> resource is missing or invalid
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 
>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156>
>>
>> The command to reproduce was provided. The error appears to be in 
>> files included in the embedded JDK not being signed. So apparently 
>> not having to do with anything of mine. (Mentioned I now see in the 
>> comments).

only executables and libraries are signed - this tool running across the 
whole app will find unsigned files, that would be expected.

>>
>> As I indicate this is not a serious error for me since I am not 
>> submitting the app to the Mac App Store but I believe this would get 
>> the app Apple rejected for anyone who is attempting that. A show 
>> stopper for a major use case. It seems too bad to simply close it 
>> because I missed an email asking for a reproduce.
>
> Note the bug referenced is closed as "incomplete" - that is a 
> temporary state while awaiting additional information? (usually from 
> the submitter). If we never hear back from the submitter then it will 
> be closed with a different (more terminal) state. If we do hear back 
> then the bug gets reopened.
>
> Cheers,
> David
>
>> With a reference application I could demonstrate the error against 
>> would eliminate the need to provide a separate reproducible test 
>> case. Quite sized for the application in question. Such an 
>> application is actually mentioned in the bug report comments. Could 
>> such a application be made available for download or user reproducing 
>> - the jpackage command and arguments?
>>
>> I have looked a little bit at if to see if I can figure out how to 
>> sign the embedded jdk files. So far only accomplishing that I can no 
>> longer simply use my name for signing but have to use my fully 
>> qualified security identity.
>>
>> The question now seems to be what is in fact the difference between 
>> mine and the, unavailable to me, reference application as to these 
>> files verifying as correctly signed.
>>
>> A second bug
>> JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect
>>
>> I thought a fix for this was all set to go in and was pulled. It was 
>> apparently determined that the problem only applies if the 
>> ?install-dir parameter is used for DMG?s. Where it really makes no 
>> sense. My use apparently held over from when I was just creating the 
>> app.I thought this had somehow also in some way regressed to not 
>> reproducible. I still think a fairly simple change to the AppleScript 
>> as was originally planned would resolve the issue independently of 
>> parameters. The default DMG build I would think should _always_ 
>> indicate installation to the Applications folder.

This is the change proposed now by Alexander on pull request: 
https://git.openjdk.java.net/jdk/pull/3505

That? dmg should ignore --input-dir and always propose dragging apps 
into /Applications

>>
>> With ?install-dir this remains a reproducible bug for me at 17-ea.
yes - but what is value of "--install-dir" - can you insure it is a 
fully qualified directory path that exists on all users machines and all 
users have write access to ?? With the current code, if applescript 
cannot create alias to this location on target machine it will show this 
buggy looklin gfinder view.
>>
>> If a reference build was provided somewhere I might have picked up on 
>> the parameter difference sooner.
>>
>>
/Andy
>>
>>
>>

From mik3hall at gmail.com  Sat Apr 17 14:14:13 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 17 Apr 2021 09:14:13 -0500
Subject: jpackage bugs
In-Reply-To: <ea69f19a-07f3-750b-ae5f-0b92baed9e8a@oracle.com>
References: <02F6EA89-922F-4A50-954F-2423DEF1113A@gmail.com>
 <0a19551f-a321-f027-9b36-529c34a547b3@oracle.com>
 <ea69f19a-07f3-750b-ae5f-0b92baed9e8a@oracle.com>
Message-ID: <C37B2E96-CFD7-409E-B2DB-4A9A1E9D41B9@gmail.com>



> On Apr 17, 2021, at 8:57 AM, Andy Herrick <andy.herrick at oracle.com> wrote:
> 
> 
> On 4/17/2021 1:14 AM, David Holmes wrote:
>> Hi Michael,
>> 
>> On 17/04/2021 10:57 am, Michael Hall wrote:
>>> Is there anyway to get a simple/test reference type application available that could be used in reproducing bugs?
> I put a simple test application I was using in your bug report: https://bugs.openjdk.java.net/browse/JDK-8263156 <https://bugs.openjdk.java.net/browse/JDK-8263156>

I?ll start with this or at least take a look at it in attempting a reproducer.

>>> 
>>> I had two I think potentially serious bugs that were basically not addressed for problems in reproducing.
>>> 
>>> JDK-8263156 : [macos]: OS X application signing concerns - a sealed resource is missing or invalid
>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156>>
>>> 
>>> The command to reproduce was provided. The error appears to be in files included in the embedded JDK not being signed. So apparently not having to do with anything of mine. (Mentioned I now see in the comments).
> 
> only executables and libraries are signed - this tool running across the whole app will find unsigned files, that would be expected.

Hmm. ok. Is the jdk separately signed? Would something in copying it change a date or something that would cause the verify to fail on the jdk signature thinking something has changed rather than what you sign for the app?

ls -l HalfPipe.app/Contents/runtime/Contents
total 8
...
drwxr-xr-x  3 mjh  staff   96 Apr 16 19:29 _CodeSignature

> 
>>> 
>>> As I indicate this is not a serious error for me since I am not submitting the app to the Mac App Store but I believe this would get the app Apple rejected for anyone who is attempting that. A show stopper for a major use case. It seems too bad to simply close it because I missed an email asking for a reproduce.
>> 
>> Note the bug referenced is closed as "incomplete" - that is a temporary state while awaiting additional information  (usually from the submitter). If we never hear back from the submitter then it will be closed with a different (more terminal) state. If we do hear back then the bug gets reopened.
>> 
>> Cheers,
>> David
>> 
>>> With a reference application I could demonstrate the error against would eliminate the need to provide a separate reproducible test case. Quite sized for the application in question. Such an application is actually mentioned in the bug report comments. Could such a application be made available for download or user reproducing - the jpackage command and arguments?
>>> 
>>> I have looked a little bit at if to see if I can figure out how to sign the embedded jdk files. So far only accomplishing that I can no longer simply use my name for signing but have to use my fully qualified security identity.
>>> 
>>> The question now seems to be what is in fact the difference between mine and the, unavailable to me, reference application as to these files verifying as correctly signed.
>>> 
>>> A second bug
>>> JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect
>>> 
>>> I thought a fix for this was all set to go in and was pulled. It was apparently determined that the problem only applies if the ?install-dir parameter is used for DMG?s. Where it really makes no sense. My use apparently held over from when I was just creating the app.I thought this had somehow also in some way regressed to not reproducible. I still think a fairly simple change to the AppleScript as was originally planned would resolve the issue independently of parameters. The default DMG build I would think should _always_ indicate installation to the Applications folder.
> 
> This is the change proposed now by Alexander on pull request: https://git.openjdk.java.net/jdk/pull/3505 <https://git.openjdk.java.net/jdk/pull/3505>
> 
> That  dmg should ignore --input-dir and always propose dragging apps into /Applications

Agreed.

> 
>>> 
>>> With ?install-dir this remains a reproducible bug for me at 17-ea.
> yes - but what is value of "--install-dir" - can you insure it is a fully qualified directory path that exists on all users machines and all users have write access to ?  With the current code, if applescript cannot create alias to this location on target machine it will show this buggy looklin gfinder view.
>>> 
>>> If a reference build was provided somewhere I might have picked up on the parameter difference sooner.
>>> 
>>> 
> /Andy

Yes, there is no good reason to do this and my doing it was a mistake. But currently still at 17ea


From mik3hall at gmail.com  Sat Apr 17 14:19:21 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 17 Apr 2021 09:19:21 -0500
Subject: jpackage bugs
In-Reply-To: <C37B2E96-CFD7-409E-B2DB-4A9A1E9D41B9@gmail.com>
References: <02F6EA89-922F-4A50-954F-2423DEF1113A@gmail.com>
 <0a19551f-a321-f027-9b36-529c34a547b3@oracle.com>
 <ea69f19a-07f3-750b-ae5f-0b92baed9e8a@oracle.com>
 <C37B2E96-CFD7-409E-B2DB-4A9A1E9D41B9@gmail.com>
Message-ID: <F09EA655-F585-4B9A-A4BA-0A0E84954766@gmail.com>



> On Apr 17, 2021, at 9:14 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>>>> 
>>>> With ?install-dir this remains a reproducible bug for me at 17-ea.
>> yes - but what is value of "--install-dir" - can you insure it is a fully qualified directory path that exists on all users machines and all users have write access to ?  With the current code, if applescript cannot create alias to this location on target machine it will show this buggy looklin gfinder view.
>>>> 
>>>> If a reference build was provided somewhere I might have picked up on the parameter difference sooner.
>>>> 
>>>> 
>> /Andy
> 
> Yes, there is no good reason to do this and my doing it was a mistake. But currently still at 17ea

Sorry got distracted thinking about the signature thing.
But currently at 17ea if a user, other than myself now, makes the same mistake of including ?install-dir the DMG problem is still there.




From mik3hall at gmail.com  Sat Apr 17 14:37:13 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 17 Apr 2021 09:37:13 -0500
Subject: jpackage bugs
In-Reply-To: <C37B2E96-CFD7-409E-B2DB-4A9A1E9D41B9@gmail.com>
References: <02F6EA89-922F-4A50-954F-2423DEF1113A@gmail.com>
 <0a19551f-a321-f027-9b36-529c34a547b3@oracle.com>
 <ea69f19a-07f3-750b-ae5f-0b92baed9e8a@oracle.com>
 <C37B2E96-CFD7-409E-B2DB-4A9A1E9D41B9@gmail.com>
Message-ID: <828BEAA6-A6E0-4EF3-81D7-C91C4178F04E@gmail.com>



> On Apr 17, 2021, at 9:14 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> only executables and libraries are signed - this tool running across the whole app will find unsigned files, that would be expected.
> 
> Hmm. ok. Is the jdk separately signed? Would something in copying it change a date or something that would cause the verify to fail on the jdk signature thinking something has changed rather than what you sign for the app?
> 
> ls -l HalfPipe.app/Contents/runtime/Contents
> total 8
> ...
> drwxr-xr-x  3 mjh  staff   96 Apr 16 19:29 _CodeSignature

OK I think this may be it. For my testing I sort of force the DMG build back to the ?install-dir one.

open -Wg HalfPipe-1.0.dmg
cp -r /Volumes/HalfPipe/HalfPipe.app outputdir/HalfPipe.app
?
diskutil eject HalfPipe
open outputdir/HalfPipe.app

codesign -v outputdir/HalfPipe.app
outputdir/HalfPipe.app: a sealed resource is missing or invalid

If instead I do the proper drag and drop install to the Applications directory.
codesign -v /Applications/HalfPipe.app

No error. So apparently ?cp? is not a good idea on a signed application. At least not on a signed java one. 

This one can probably be closed permanently.



From brian.goetz at oracle.com  Sat Apr 17 16:00:14 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 17 Apr 2021 12:00:14 -0400
Subject: ReversibleCollection proposal
In-Reply-To: <CAE+3fjav3wGMBQyj1xVbyv-QJyqFmMxz0UYFFJdh7iZyPtWmtg@mail.gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <CAE+3fjav3wGMBQyj1xVbyv-QJyqFmMxz0UYFFJdh7iZyPtWmtg@mail.gmail.com>
Message-ID: <372c9cad-30e1-e3db-477c-4550d1c14044@oracle.com>

Adding a REVERSIBLE characteristic to spliterators is easy enough, and 
as you say, many useful sources can easily provide an efficient reverse 
operation.? Filtering and mapping can preserve reversibility. The real 
question is what to do if someone calls reverse() on a non-reversible 
stream.? (Finite streams that are not easily reversible can still be 
reversed by draining the stream into a buffer, but that's likely 
inefficient; infinite streams have no chance.)? Should reverse() just 
throw when it encounters a source not designed for reversibility?? I 
don't particularly like the idea of throwing based on a dynamic source 
property, but trying to thread ReversibleStream through the static types 
is probably worse.

In the "drain" it case, the user can always simulate this manually: call 
toArray and get a reversed stream from that (since array-based streams 
are trivially reversible.)

I'm not particularly convinced of the value of folding from both 
directions.? The main value of foldr over foldl in Haskell is that 
because of laziness, foldr on infinite lists can work with 
short-circuiting combiners, whereas foldl cannot.? In strict languages, 
this benefit is not present, making the marginal value of foldr over 
foldl much smaller.

But, Stuart's proposal gives us much of this with less fuss.? IF a 
collection is reversible, you can just say

 ??? c.reversed().stream()

and off you go, plus a similar method for arrays 
(Arrays.reversedStream).? Given that, what is the value of pushing this 
further into stream?

On 4/17/2021 7:49 AM, Tagir Valeev wrote:
> Great proposal, thanks!
>
> It has most functionality from my previous proposal, except the
> ability to iterate LinkedHashSet starting from a specific element.
> Well, probably we can skip this for now.
>
> Some people really want to reverse Streams as well. E. g., the
> corresponding StackOverflow question [1] has 171 upvotes and 200k+
> views. Also, if the stream were reversible, it would be possible to
> implement efficient foldRight/reduceRight operation. See the
> discussion at [2]. It would be nice to explore the possibility of
> extending Stream API to take into account the source reversibility.
> Some existing ordered sources that have no underlying collection (e.g.
> IntStream.range, or Arrays.stream) can be easily reversed as well. Map
> and filter operations preserve reversibility and flatMap is reversible
> if the supplied stream is reversible as well.
>
> With best regards,
> Tagir Valeev.
>
> [1] https://stackoverflow.com/q/24010109/4856258
> [2] https://bugs.openjdk.java.net/browse/JDK-8133680
>
> On Sat, Apr 17, 2021 at 12:41 AM Stuart Marks <stuart.marks at oracle.com> wrote:
>> This is a proposal to add a ReversibleCollection interface to the Collections
>> Framework. I'm looking for comments on overall design before I work on detailed
>> specifications and tests. Please send such comments as replies on this email thread.
>>
>> Here's a link to a draft PR that contains the code diffs. It's prototype quality,
>> but it should be good enough to build and try out:
>>
>>       https://github.com/openjdk/jdk/pull/3533
>>
>> And here's a link to a class diagram showing the proposed additions:
>>
>>
>> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
>>
>> Thanks,
>>
>> s'marks
>>
>>
>> # Ordering and Reversibility
>>
>>
>> A long-standing concept that's been missing from collections is that of the
>> positioning, sequencing, or arrangement of elements as a structural property of a
>> collection. (This is sometimes called the "iteration order" of a collection.) For
>> example, a HashSet is not ordered, but a List is. This concept is mostly not
>> manifested in the collections API.
>>
>> Iterating a collection produces elements one after another in *some* sequence. The
>> concept of "ordered" determines whether this sequence is defined or whether it's a
>> coincidence of implementation. What does "having an order" mean? It implies that
>> there is a first element and that each element has a successor. Since collections
>> have a finite number of elements, it further implies that there is a last element
>> that has no successor. However, it is difficult to discern whether a collection has
>> a defined order. HashSet generally iterates its elements in the same undefined
>> order, and you can't actually tell that it's not a defined order.
>>
>> Streams do have a notion of ordering ("encounter order") and this is preserved,
>> where appropriate, through the stream pipeline. It's possible to detect this by
>> testing whether its spliterator has the ORDERED characteristic. Any collection with
>> a defined order will have a spliterator with this characteristic. However, this is
>> quite a roundabout way to determine whether a collection has a defined order.
>> Furthermore, knowing this doesn't enable any additional operations. It only provides
>> constraints on the stream's implementations (keeping the elements in order) and
>> provides stronger semantics for certain operations. For example, findFirst() on an
>> unordered stream is the same as findAny(), but actually finds the first element if
>> the stream is ordered.
>>
>> The concept of ordering is thus present in the system but is surfaced only in a
>> fairly indirect way. We can strengthen abstraction of ordering by making a few
>> observations and considering their implications.
>>
>> Given that there is a first element and a last element, the sequence of elements has
>> two ends. It's reasonable to consider operations (add, get, remove) on either end.
>> Indeed, the Deque interface has a full complement of operations at each end. This is
>> an oft-requested feature on various other collections.
>>
>> Each element except for the last has a successor, implying that each element except
>> for the first has a predecessor. Thus it's reasonable to consider iterating the
>> elements from first to last or from last to first (that is, in forward or reverse
>> order). Indeed, the concept of iterating in reverse order appears already in bits
>> and pieces in particular places around the collections:
>>
>>    - List has indexOf() and lastIndexOf()
>>    - Deque has removeFirstOccurrence() and removeLastOccurrence()
>>    - List has a ListIterator with hasPrevious/previous methods
>>    - Deque and NavigableSet have descendingIterator methods
>>
>> Given an ordered collection, though, there's no general way to iterate it in reverse
>> order. Reversed iteration isn't the most common operation, but there are some
>> frequent use cases, such as operating on elements in most-recently-added order.
>> Questions and bug reports about this have come up repeatedly over the years.
>>
>> Unfortunately, iterating in reverse order is much harder than iterating in forward
>> order. There are a variety of ways to iterate in forward order. For example, given a
>> List, one can do any of the following:
>>
>>       for (var e : list) { ... }
>>       list.forEach(...)
>>       list.stream()
>>       list.toArray()
>>
>> However, to iterate a list in reverse order, one must use an explicit loop over
>> ListIterator:
>>
>>       for (var it = list.listIterator(list.size()); it.hasPrevious(); ) {
>>           var e = it.previous();
>>           ...
>>       }
>>
>> Streaming the elements of a List in reverse order is even worse. One approach would
>> be to implement a reverse-ordered Iterator that wraps a ListIterator and delegates
>> hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then, this
>> Iterator can be turned into a Spliterator, which is then turned into a Stream. (The
>> code to do this is left as an exercise for the reader.) Obtaining the elements in
>> reverse via other means -- forEach() or toArray() -- is similarly difficult.
>>
>> Obtaining the elements in reverse order can be accomplished by adopting a concept
>> from NavigableSet's descendingSet() method, which provides a reverse-ordered view
>> collection. This view is also a NavigableSet, which means that any operation that
>> can be performed on the original set can also be applied to the reverse-ordered
>> view. If it were possible to obtain a similar reverse-ordered view on any kind of
>> ordered collection, this would enable the elements to be processed in reverse order
>> in any fashion, not just special-purposes APIs such as ListIterator or
>> descendingIterator().
>>
>>
>> # LinkedHashSet
>>
>>
>> The main feature of LinkedHashSet is that it does have a defined ordering, as
>> opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last
>> element. However, LinkedHashSet is deficient in a number of ways:
>>
>>    - access to and removal of the first element is reasonable (using an iterator) but
>> it is not possible to add at the front
>>
>>    - it is possible to add an element at the end, but access to and removal of the
>> last element are expensive
>>
>>    - it's not possible to iterate in reverse without copying the entire collection
>>
>> Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so
>> there is no fundamental implementation reason that prevents these operations from
>> being supported. The main reason these operations aren't supported is probably that
>> there hasn't been a good place to push such APIs.
>>
>>
>> # Proposal
>>
>>
>> Introduce a new ReversibleCollection<E> interface. This provides a new method to
>> obtain a reverse-ordered view. It also contains several methods (copied from Deque)
>> that allow operating on elements at both ends.
>>
>>
>>       interface ReversibleCollection<E> extends Collection<E> {
>>           ReversibleCollection<E> reversed();
>>           default void addFirst(E e)
>>           default void addLast(E e)
>>           default E getFirst()
>>           default E getLast()
>>           default E removeFirst()
>>           default E removeLast()
>>       }
>>
>>
>> The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are
>> retrofitted to implement ReversibleCollection. They provide covariant overriding
>> implementations of the reversed() method. For example, List.reversed() returns a
>> List. Default implementations for all of these methods are provided in the
>> appropriate interfaces.
>>
>> Covariant overrides are also provided in several other classes. This presents a
>> difficulty for LinkedHashSet, as there's no suitable return type for reversed(). To
>> remedy this, we add another interface
>>
>>
>>       interface ReversibleSet<E> extends ReversibleCollection<E>, Set<E> { }
>>
>>
>> This adds no new methods but is essentially an intersection of ReversibleCollection
>> and Set. As such, it's suitable as the return type of LinkedHashSet.reversed() and
>> the set views of LinkedHashMap.
>>
>> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because
>> SortedSet's ordering is determined by the comparison method and cannot be controlled
>> explicitly.
>>
>> LinkedHashSet::addFirst and addLast add the element at the appropriate position or
>> reposition the element if it is already present in the set.
>>
>> New methods are added to LinkedHashMap
>>
>>       V putFirst(K, V)
>>       V putLast(K, V)
>>
>> which put the mapping at the designated position or reposition the mapping if is
>> already present in the map.
>>
>>
>> # Design & Implementation Issues
>>
>>
>> Covariant overrides for reversed() are provided where possible. However, there is a
>> conflict between List and Deque, as there are examples in the JDK (such as
>> LinkedList) that implement both List and Deque. Since List is much more popular than
>> Deque, I've decided against adding a covariant override to Deque. Instead, a method
>> Deque::reversedDeque is added that returns a Deque, and Deque::reversed returns
>> ReversibleCollection.
>>
>> There is no ReversibleMap interface. Most iteration over maps is over the entrySet,
>> keySet, or values views. NavigableMap already has descendingMap(), and LinkedHashMap
>> provides ReversibleX views, which cover most of the cases already.
>>
>> Introducing new methods into an interface hierarchy always raises the possibility of
>> name clashes. I've done some searching but I haven't found any major issues, but we
>> should be on the lookout for this. I'll continue to do more searching for such
>> conflicts.
>>
>> Introducing covariant overrides on existing methods (notably LinkedHashMap entrySet,
>> keySet, and values) could present incompatibility issues with subclasses that
>> override these methods. I've done some searching and again I haven't found major
>> problems, but this is nonetheless a point of concern. I'll do more searching here, too.
>>
>> The default implementations for List::reversed, Deque::reversed, and
>> SortedSet::reversed return reverse-ordered views that are implemented using only
>> public methods of the original interface. This demonstrates the feasibility of
>> retrofitting reverse ordering onto any instance of these interfaces. Similarly, the
>> various add/get/remove methods' default implementations are all implementable in
>> terms of an iterator or reverse-ordered iterator. That said, some concurrent
>> collection implementations will need to override these default implementations in
>> order to preserve their safety invariants. It would probably also be wise to add
>> optimized implementations to the more commonly-used collection implementations.
>>
>> Given that a ReversibleCollection has a defined ordering, any spliterator obtained
>> from such a collection should have the Spliterator.ORDERED characteristic.
>>
>> This proposal is related to a previous discussion on a similar topic, where Tagir
>> Valeev had proposed OrderedSet and OrderedMap:
>>
>>       http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066028.html
>>
>> I think there were some good ideas in there and in the ensuing discussion, but it
>> didn't go anywhere. Several of the concepts in this proposal are an evolution of
>> some ideas discussed in that thread.
>>
>> One of the ideas from that thread was to use Deque as a common interface for many
>> collections to support reversibility and operations at the ends. We've abandoned
>> that idea in this proposal. The reasons are that it's cluttered with a bunch of
>> methods that are inherited from Queue. Also, some methods are null-returning instead
>> of throwing, which introduces confusion for collections that can contain nulls.
>>
>> # END


From mik3hall at gmail.com  Sat Apr 17 16:39:11 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 17 Apr 2021 11:39:11 -0500
Subject: jpackage bugs
In-Reply-To: <828BEAA6-A6E0-4EF3-81D7-C91C4178F04E@gmail.com>
References: <02F6EA89-922F-4A50-954F-2423DEF1113A@gmail.com>
 <0a19551f-a321-f027-9b36-529c34a547b3@oracle.com>
 <ea69f19a-07f3-750b-ae5f-0b92baed9e8a@oracle.com>
 <C37B2E96-CFD7-409E-B2DB-4A9A1E9D41B9@gmail.com>
 <828BEAA6-A6E0-4EF3-81D7-C91C4178F04E@gmail.com>
Message-ID: <A1C1662F-8BC7-4708-A3AE-78A39A6DA0BF@gmail.com>



> On Apr 17, 2021, at 9:37 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> So apparently ?cp? is not a good idea on a signed application. At least not on a signed java one. 

Fyi for anyone who wants to copy a Mac signed java app from a script or maybe from java Runtime. Instead of?

cp -r /Volumes/HalfPipe/HalfPipe.app outputdir/HalfPipe.app

this?

ditto /Volumes/HalfPipe outputdir

Copies and still codesign verifies.


From forax at univ-mlv.fr  Sat Apr 17 16:49:34 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 17 Apr 2021 18:49:34 +0200 (CEST)
Subject: ReversibleCollection proposal
In-Reply-To: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
Message-ID: <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 16 Avril 2021 19:40:55
> Objet: ReversibleCollection proposal

> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on detailed
> specifications and tests. Please send such comments as replies on this email
> thread.
> 
> Here's a link to a draft PR that contains the code diffs. It's prototype
> quality,
> but it should be good enough to build and try out:
> 
>     https://github.com/openjdk/jdk/pull/3533
> 
> And here's a link to a class diagram showing the proposed additions:
> 
> 
> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
> 
> Thanks,
> 
> s'marks
> 
> 
> # Ordering and Reversibility
> 
> 
> A long-standing concept that's been missing from collections is that of the
> positioning, sequencing, or arrangement of elements as a structural property of
> a
> collection. (This is sometimes called the "iteration order" of a collection.)
> For
> example, a HashSet is not ordered, but a List is. This concept is mostly not
> manifested in the collections API.
> 
> Iterating a collection produces elements one after another in *some* sequence.
> The
> concept of "ordered" determines whether this sequence is defined or whether it's
> a
> coincidence of implementation. What does "having an order" mean? It implies that
> there is a first element and that each element has a successor. Since
> collections
> have a finite number of elements, it further implies that there is a last
> element
> that has no successor. However, it is difficult to discern whether a collection
> has
> a defined order. HashSet generally iterates its elements in the same undefined
> order, and you can't actually tell that it's not a defined order.
> 
> Streams do have a notion of ordering ("encounter order") and this is preserved,
> where appropriate, through the stream pipeline. It's possible to detect this by
> testing whether its spliterator has the ORDERED characteristic. Any collection
> with
> a defined order will have a spliterator with this characteristic. However, this
> is
> quite a roundabout way to determine whether a collection has a defined order.
> Furthermore, knowing this doesn't enable any additional operations. It only
> provides
> constraints on the stream's implementations (keeping the elements in order) and
> provides stronger semantics for certain operations. For example, findFirst() on
> an
> unordered stream is the same as findAny(), but actually finds the first element
> if
> the stream is ordered.
> 
> The concept of ordering is thus present in the system but is surfaced only in a
> fairly indirect way. We can strengthen abstraction of ordering by making a few
> observations and considering their implications.
> 
> Given that there is a first element and a last element, the sequence of elements
> has
> two ends. It's reasonable to consider operations (add, get, remove) on either
> end.
> Indeed, the Deque interface has a full complement of operations at each end.
> This is
> an oft-requested feature on various other collections.
> 
> Each element except for the last has a successor, implying that each element
> except
> for the first has a predecessor. Thus it's reasonable to consider iterating the
> elements from first to last or from last to first (that is, in forward or
> reverse
> order). Indeed, the concept of iterating in reverse order appears already in
> bits
> and pieces in particular places around the collections:
> 
>  - List has indexOf() and lastIndexOf()
>  - Deque has removeFirstOccurrence() and removeLastOccurrence()
>  - List has a ListIterator with hasPrevious/previous methods
>  - Deque and NavigableSet have descendingIterator methods
> 
> Given an ordered collection, though, there's no general way to iterate it in
> reverse
> order. Reversed iteration isn't the most common operation, but there are some
> frequent use cases, such as operating on elements in most-recently-added order.
> Questions and bug reports about this have come up repeatedly over the years.
> 
> Unfortunately, iterating in reverse order is much harder than iterating in
> forward
> order. There are a variety of ways to iterate in forward order. For example,
> given a
> List, one can do any of the following:
> 
>     for (var e : list) { ... }
>     list.forEach(...)
>     list.stream()
>     list.toArray()
> 
> However, to iterate a list in reverse order, one must use an explicit loop over
> ListIterator:
> 
>     for (var it = list.listIterator(list.size()); it.hasPrevious(); ) {
>         var e = it.previous();
>         ...
>     }
> 
> Streaming the elements of a List in reverse order is even worse. One approach
> would
> be to implement a reverse-ordered Iterator that wraps a ListIterator and
> delegates
> hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then,
> this
> Iterator can be turned into a Spliterator, which is then turned into a Stream.
> (The
> code to do this is left as an exercise for the reader.) Obtaining the elements
> in
> reverse via other means -- forEach() or toArray() -- is similarly difficult.
> 
> Obtaining the elements in reverse order can be accomplished by adopting a
> concept
> from NavigableSet's descendingSet() method, which provides a reverse-ordered
> view
> collection. This view is also a NavigableSet, which means that any operation
> that
> can be performed on the original set can also be applied to the reverse-ordered
> view. If it were possible to obtain a similar reverse-ordered view on any kind
> of
> ordered collection, this would enable the elements to be processed in reverse
> order
> in any fashion, not just special-purposes APIs such as ListIterator or
> descendingIterator().
> 
> 
> # LinkedHashSet
> 
> 
> The main feature of LinkedHashSet is that it does have a defined ordering, as
> opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last
> element. However, LinkedHashSet is deficient in a number of ways:
> 
>  - access to and removal of the first element is reasonable (using an iterator)
>  but
> it is not possible to add at the front
> 
>  - it is possible to add an element at the end, but access to and removal of the
> last element are expensive
> 
>  - it's not possible to iterate in reverse without copying the entire collection
> 
> Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so
> there is no fundamental implementation reason that prevents these operations
> from
> being supported. The main reason these operations aren't supported is probably
> that
> there hasn't been a good place to push such APIs.
> 
> 
> # Proposal
> 
> 
> Introduce a new ReversibleCollection<E> interface. This provides a new method to
> obtain a reverse-ordered view. It also contains several methods (copied from
> Deque)
> that allow operating on elements at both ends.
> 
> 
>     interface ReversibleCollection<E> extends Collection<E> {
>         ReversibleCollection<E> reversed();
>         default void addFirst(E e)
>         default void addLast(E e)
>         default E getFirst()
>         default E getLast()
>         default E removeFirst()
>         default E removeLast()
>     }
> 
> 
> The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are
> retrofitted to implement ReversibleCollection. They provide covariant overriding
> implementations of the reversed() method. For example, List.reversed() returns a
> List. Default implementations for all of these methods are provided in the
> appropriate interfaces.
> 
> Covariant overrides are also provided in several other classes. This presents a
> difficulty for LinkedHashSet, as there's no suitable return type for reversed().
> To
> remedy this, we add another interface
> 
> 
>     interface ReversibleSet<E> extends ReversibleCollection<E>, Set<E> { }
> 
> 
> This adds no new methods but is essentially an intersection of
> ReversibleCollection
> and Set. As such, it's suitable as the return type of LinkedHashSet.reversed()
> and
> the set views of LinkedHashMap.
> 
> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is
> because
> SortedSet's ordering is determined by the comparison method and cannot be
> controlled
> explicitly.
> 
> LinkedHashSet::addFirst and addLast add the element at the appropriate position
> or
> reposition the element if it is already present in the set.
> 
> New methods are added to LinkedHashMap
> 
>     V putFirst(K, V)
>     V putLast(K, V)
> 
> which put the mapping at the designated position or reposition the mapping if is
> already present in the map.
> 


I think the analysis is spot on but I don't think the proposed solution is the right one.

Introducing a new interface (two in this case) has a really huge cost and in this case, i've trouble to see why i will want to write a method that takes a ReversibleCollection as parameter, ReversibleCollection as a type does not seem to be useful. About the cost of introducing a new collection interface, it means that we also have to update all emptyXXX, singleXXX, uncheckedXXX with a new interface, and that only for the JDK. Every libraries that proxy collections has also to be updated to take care of this new type, otherwise the integration with an application that uses this new type and the library is not seamless anymore.

I fully agree that having a way to reverse a collection is a powerful API point, as Brian said, it's better to reverse the collection and then ask for a stream than providing a method reverseStream (and this is true for iterators or views like keySet/entrySet/values or subList too). Several people also ask to have findLast() on Stream, using list.descendingList().findFirst() will be equivalent.

As Donald said, reversed() is perhaps not the right name because there are already collections that have methods with the same name.
Given that we already have descdendingSet() on NavigableSet, i think the method "reversed" should be called descendingDeque() on Deque, descendingList() on List, etc.
This also sove the problem of LinkedList implementing both Deque and List.

Getting the first element of a Set is something that is requested a lot, so having getFirst(), i think directly on Set, is a good idea too,
having a method removeLast() on List (mainly for ArrayList) is also a good idea, because it's better than list.remove(list.size() - 1).

All these methods can be introduced has default methods on the existing collection interfaces, there is no need of a special interface (or two) for that.

[...]

> 
> # END

R?mi

From bourges.laurent at gmail.com  Sat Apr 17 18:02:02 2021
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 17 Apr 2021 20:02:02 +0200
Subject: How to know if cpu supports unaligned memory accesses ?
Message-ID: <CAKjRUT5S8aP_wve-Sxa0QB0RU093ZZwuQKUDE4y3g0iTaVq81Q@mail.gmail.com>

Hi,
In the Marlin renderer & in other Unsafe use cases (pixel tile processing)
for java2d pipelines, I do use putInt()/putLong() primitives even if the
address is not aligned (to 4 or 8 bytes) to get faster processing of byte
buffer or arrays...

Is it possible in java (jdk internals) to query cpu capabilities like
endianness, unaligned support ?

For x86-64: unaligned ~ aligned, so it is not necessary to add padding in
the data layout and then it is better to have smaller buffers.

I would like write code like:
if (cpu_supports_unaligned) {
...
Use int/long to pack bytes...
} else {
Use byte (fallback)
}


Laurent

From stuart.marks at oracle.com  Sat Apr 17 18:24:22 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sat, 17 Apr 2021 11:24:22 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <684F957C-11B2-420C-A4DA-D1B8A57C9A88@gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <684F957C-11B2-420C-A4DA-D1B8A57C9A88@gmail.com>
Message-ID: <1db21714-bb63-57e8-28c9-0dc2acedcace@oracle.com>



On 4/16/21 3:06 PM, Donald Raab wrote:
> We should be cautious when adding new APIs to existing interfaces. There may be libraries which extend JDK types and already have reversed(), toReversed() or asReversed() APIs and corresponding interfaces.
> 
> There are OrderedIterable and ReversibleIterable interfaces and asReversed() and toReversed() methods in the Eclipse Collections API.

Hi Don, thanks for looking at the proposal.

Certainly a lot of care is required when introducing new interfaces, new methods on 
existing interfaces, and covariant overrides. I believe the primary risks are with 
name clashes and with return type mismatches.

On name clashes, "reversed" seems to thread the needle well, as I cannot find any 
methods with that exact name on Eclipse Collections, Guava, Apache Commons 
Collections, or several others. There are methods with similar names, of course, 
such as "reverse", "asReversed", and "toReversed" but they shouldn't cause name 
conflicts.

(There might be semantic conflicts, such as creating an reversed copy instead of a 
reversed view, but I don't think that can be helped.)

If there are no name clashes with "reversed", the covariant overrides in the 
sub-interfaces won't a problem. The covariant overrides on existing methods (such as 
LinkedHashMap.entrySet) are a greater danger, I think. There are a lot of 
LinkedHashMap subclasses (several dozen are visible in the Yawkat browser) but only 
one had a conflicting override. It's trivially fixable, but nonetheless it's an 
incompatibility.

I'm also concerned about conflicts over the other method names; something like 
addFirst() is a pretty obvious method to add to a custom List implementation. I 
haven't seen any, but that doesn't mean there aren't any.

s'marks

From stuart.marks at oracle.com  Sat Apr 17 18:52:47 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sat, 17 Apr 2021 11:52:47 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <CACzrW9C+1TTLuid+X1SWeKCtHusDrJ81=ou7MN1tXrbHJ6PVmw@mail.gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <CACzrW9C+1TTLuid+X1SWeKCtHusDrJ81=ou7MN1tXrbHJ6PVmw@mail.gmail.com>
Message-ID: <aa86c282-a5c1-60a7-bead-4529f3b56256@oracle.com>



On 4/17/21 2:48 AM, Stephen Colebourne wrote:
> On Fri, 16 Apr 2021 at 18:41, Stuart Marks <stuart.marks at oracle.com> wrote:
>> This is a proposal to add a ReversibleCollection interface to the Collections
>> Framework. I'm looking for comments on overall design before I work on detailed
>> specifications and tests. Please send such comments as replies on this email thread.
> 
> I think this could be an interesting addition to the framework.

Great!

>> # Ordering and Reversibility
> 
> Reading this section, it seems like ordering is a more significant
> quality than reversibility. Yet the API is named "reversible". That
> seems odd, esepcially given the stream characteristic.

I probably could have explained this better in the writeup.

"Reversible" is a stronger concept (i.e., it implies more things) than "Ordered". A 
reversible collection is ordered, it is traversable in both directions, both ends 
are accessible, and it affords operations at both ends. However, being ordered does 
not imply reversibility. For example, a PriorityQueue is ordered, but you can't get 
to the tail or iterate in reverse without a bunch of computation.

>> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because
>> SortedSet's ordering is determined by the comparison method and cannot be controlled
>> explicitly.
> 
> This seems undesirable. Maybe SortedSet should not implement
> reversible/ordered? Maybe they should add to the set but validate
> whether they would be in first/last position? Simply allowing users to
> get a new instance with a different (eg. reversed) comparator would
> meet much of the use case.

This is certainly an unpleasant asymmetry. But this is the Collections Framework; we 
should be used to unpleasant asymmetries. :-)

My typical examples of this are: various Map views like entrySet are that elements 
can be removed but they cannot be added; elements in Arrays.asList can be set but 
not added or removed; CopyOnWriteArrayList is mutable, but its iterators are not; etc.

Of course the presence of asymmetries doesn't justify the addition of more. But 
there is a precedent here: collections will implement an interface if they can 
support "most" of the operations, and the ones that aren't appropriate will throw 
UnsupportedOperationException. That's the precedent I'm following here with 
SortedSet (and NavigableSet).

An alternative as you suggest might be that SortedSet::addFirst/addLast could throw 
something like IllegalStateException if the element is wrongly positioned. 
(Deque::addFirst/addLast will throw ISE if the addition would exceed a capacity 
restriction.) This seems error-prone, though, and it's easier to understand and 
specify that these methods simply throw UOE unconditionally. If there's a good use 
case for the alternative I'd be interested in hearing it though.

> Also, SortedSet uses first() and last(), yet the proposed interface
> uses getFirst() and getLast().

Deque defines a full set of operations at both ends, including:

     { add, get, remove } x { First, Last }

so it seemed sensible to take that complete set and promote it to ReversibleCollection.

s'marks



From stuart.marks at oracle.com  Sat Apr 17 19:03:10 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sat, 17 Apr 2021 12:03:10 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <CAE+3fjav3wGMBQyj1xVbyv-QJyqFmMxz0UYFFJdh7iZyPtWmtg@mail.gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <CAE+3fjav3wGMBQyj1xVbyv-QJyqFmMxz0UYFFJdh7iZyPtWmtg@mail.gmail.com>
Message-ID: <323b3e65-a540-49e6-7c1f-0d3668fd7aa1@oracle.com>



On 4/17/21 4:49 AM, Tagir Valeev wrote:
> Great proposal, thanks!
> 
> It has most functionality from my previous proposal, except the
> ability to iterate LinkedHashSet starting from a specific element.
> Well, probably we can skip this for now.

Thanks! And thanks for making that proposal a year ago; the ideas there and in the 
ensuing discussion clearly informed this proposal.

I did spend a bunch of time thinking about the "start from a specific element" case. 
Certainly it isn't difficult to create an iterator that starts from a specific 
element and proceeds in either direction. However, it's 2021, and nobody wants to 
program using Iterators anymore!! :-)

Perhaps an obvious extension is a LinkedHashSet subset-view from a particular 
element to the end (or beginning). This is kind of interesting, however, it leads 
off into the weeds. That is, the complexity in doing this seemed to outweigh the 
rest of the proposal, especially for the limited value it supplies, so I've left it 
aside for now.

It's possible to get a stream of LHS elements starting or ending at a particular 
element though a combination of reversed, takeWhile, and dropWhile.

s'marks

From donraab at gmail.com  Sat Apr 17 19:36:11 2021
From: donraab at gmail.com (Donald Raab)
Date: Sat, 17 Apr 2021 15:36:11 -0400
Subject: ReversibleCollection proposal
In-Reply-To: <1db21714-bb63-57e8-28c9-0dc2acedcace@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <684F957C-11B2-420C-A4DA-D1B8A57C9A88@gmail.com>
 <1db21714-bb63-57e8-28c9-0dc2acedcace@oracle.com>
Message-ID: <F3B3EB35-638C-4131-9AE1-3BBC6F3E25D9@gmail.com>

Hi, Stuart, happy to help.

I took a look at Groovy and Kotlin. Groovy has reverse() [1] and Kotlin has reversed() [2] and asReversed() [3] and reverse() [4]. I?m not quite familiar enough with Kotlin to know whether the reversed() method will collide.

[1] http://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/List.html#reverse()
[2] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/reversed.html
[3] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/as-reversed.html
[4] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/reverse.html

> On Apr 17, 2021, at 2:24 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> 
> 
> On 4/16/21 3:06 PM, Donald Raab wrote:
>> We should be cautious when adding new APIs to existing interfaces. There may be libraries which extend JDK types and already have reversed(), toReversed() or asReversed() APIs and corresponding interfaces.
>> There are OrderedIterable and ReversibleIterable interfaces and asReversed() and toReversed() methods in the Eclipse Collections API.
> 
> Hi Don, thanks for looking at the proposal.
> 
> Certainly a lot of care is required when introducing new interfaces, new methods on existing interfaces, and covariant overrides. I believe the primary risks are with name clashes and with return type mismatches.
> 
> On name clashes, "reversed" seems to thread the needle well, as I cannot find any methods with that exact name on Eclipse Collections, Guava, Apache Commons Collections, or several others. There are methods with similar names, of course, such as "reverse", "asReversed", and "toReversed" but they shouldn't cause name conflicts.
> 
> (There might be semantic conflicts, such as creating an reversed copy instead of a reversed view, but I don't think that can be helped.)
> 
> If there are no name clashes with "reversed", the covariant overrides in the sub-interfaces won't a problem. The covariant overrides on existing methods (such as LinkedHashMap.entrySet) are a greater danger, I think. There are a lot of LinkedHashMap subclasses (several dozen are visible in the Yawkat browser) but only one had a conflicting override. It's trivially fixable, but nonetheless it's an incompatibility.
> 
> I'm also concerned about conflicts over the other method names; something like addFirst() is a pretty obvious method to add to a custom List implementation. I haven't seen any, but that doesn't mean there aren't any.
> 
> s'marks


From donraab at gmail.com  Sat Apr 17 19:50:44 2021
From: donraab at gmail.com (Donald Raab)
Date: Sat, 17 Apr 2021 15:50:44 -0400
Subject: ReversibleCollection proposal
In-Reply-To: <1db21714-bb63-57e8-28c9-0dc2acedcace@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <684F957C-11B2-420C-A4DA-D1B8A57C9A88@gmail.com>
 <1db21714-bb63-57e8-28c9-0dc2acedcace@oracle.com>
Message-ID: <47EA4935-A0A6-48E5-B885-A1042D6F71E3@gmail.com>


> I'm also concerned about conflicts over the other method names; something like addFirst() is a pretty obvious method to add to a custom List implementation. I haven't seen any, but that doesn't mean there aren't any.
> 
> s'marks

The getFirst() and getLast() methods will have collisions. We have both these methods on Eclipse Collections, and thankfully they return the same type. It is possible that someone decided to implement these methods and return Optional.

From amaembo at gmail.com  Sun Apr 18 01:33:36 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 18 Apr 2021 08:33:36 +0700
Subject: ReversibleCollection proposal
In-Reply-To: <372c9cad-30e1-e3db-477c-4550d1c14044@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <CAE+3fjav3wGMBQyj1xVbyv-QJyqFmMxz0UYFFJdh7iZyPtWmtg@mail.gmail.com>
 <372c9cad-30e1-e3db-477c-4550d1c14044@oracle.com>
Message-ID: <CAE+3fjYsUOZTJj9QyaCfS-H1mv66f_iiPQ_uXmnVk9dfLhud6w@mail.gmail.com>

> Adding a REVERSIBLE characteristic to spliterators is easy enough

Actually not. There are already tons of delegating spliterators in the
wild, and many of them delegate characteristics in one or another way.
Usually, it's like 'copy all the source characteristics except A and
B' (i.e. `source.characteristics() & (~(A|B))`), so if we introduce a
new one, some existing spliterators may start reporting it without
actually providing the claimed functionality. As the author of the
library that contains dozens of custom spliterator, I think, this is
the largest problem. I don't buy an infinite streams argument, as
`sorted()` is equally not applicable to infinite streams, yet it's
possible to call it (btw reversed() after sorted() could be optimized,
even if the original source is not reversible). Also, in fact,
infinite streams are not widely used. I think, 99% of real-life
streams start from collection, array, or integral range. Yes, my idea
was to fall back to drain-line implementation.

> But, Stuart's proposal gives us much of this with less fuss.  IF a collection is reversible, you can just say
>
>     c.reversed().stream()
>
> and off you go, plus a similar method for arrays (Arrays.reversedStream).  Given that, what is the value of pushing this further into stream?

Arrays.reversedStream should be added for Object/int/long/double and
probably for array slices. Also, IntStream.reversedRange, please! And
LongStream.reversedRange. And probably `reversedRangeClosed`. So we
already have 12 methods to add (aside from collections). Adding single
.reversed() to the Stream is a much smaller API surface. Though I
admit that it requires much more work. On the other hand, I believe
(efforts/usefulness) for this feature is much bigger than, say, for
parallel streams.

In StreamEx, I have

public static <T> StreamEx<T> ofReversed(List<? extends T> list)
public static <T> StreamEx<T> ofReversed(T[] array)
(did not bother to add IntStreamEx ofReversed(int[] array) and friends)
the List version just assumes that every list is random access and
does something like IntStream.range(0, size).mapToObj(idx ->
list.get(size - idx - 1))
I've found 16 usages of them in IntelliJ IDEA sources (10 for List and
6 for array), which is not very small, given the fact that only a few
of our developers in our project know/use StreamEx.

I also have three-arg IntStreamEx.range(int startInclusive, int
endExclusive, int step) (and rangeClosed, and the corresponding
LongStreamEx), which can be used for reverse range (with step = -1)
I've found a couple of usages with step = -1 to iterate over a slice
of an array in reverse order. Though step = 2 is more popular.

I also checked the uses of Collections::reverse. There are hundreds of
them. Often it's traversal in tree-like structure through the parent
chain from leaf to root, like Stream.iterate(leaf, Objects::nonNull,
Node::getParent),
then the result is dumped into the list (probably with some
intermediate ops like map(Node::getName)), then reversed to get "from
root to leaf" order. Sometimes the resulting list is just returned (so
it's possible to create
Collectors.toReversedList() to avoid extra reversal step), sometimes
it's converted to an array and returned, sometimes it's
iterated/streamed again. In one case, it's even followed by
left-to-right reduction,
so foldRight is what was actually wanted there.

One more case is a simple parser of the Java stack trace:

String[] lines = stack.split("\n");
List<JavaMethodCall> calls =
  StreamEx.of(lines).filter(s -> s.startsWith("\tat")).map(method ->
getMethodCall(method, ...)).nonNull().toList();
Collections.reverse(calls);

Here's an example of a stream where reversibility is preserved during
the whole pipeline. It's possible to rewrite it using
StreamEx.ofReversed() (probably the code author was not aware of this
method). But it also could be stack.lines().reversed() (and it's
possible to make String::lines reversible without extra buffering!),
so with the dedicated reversed() method it could be completely lazy.

I also see patterns like fill LinkedHashSet, dump it to the List, then
reverse the list and iterate from it. Clearly, it can benefit from the
Stuart's proposal.

With best regards,
Tagir Valeev.


>
> On 4/17/2021 7:49 AM, Tagir Valeev wrote:
>
> Great proposal, thanks!
>
> It has most functionality from my previous proposal, except the
> ability to iterate LinkedHashSet starting from a specific element.
> Well, probably we can skip this for now.
>
> Some people really want to reverse Streams as well. E. g., the
> corresponding StackOverflow question [1] has 171 upvotes and 200k+
> views. Also, if the stream were reversible, it would be possible to
> implement efficient foldRight/reduceRight operation. See the
> discussion at [2]. It would be nice to explore the possibility of
> extending Stream API to take into account the source reversibility.
> Some existing ordered sources that have no underlying collection (e.g.
> IntStream.range, or Arrays.stream) can be easily reversed as well. Map
> and filter operations preserve reversibility and flatMap is reversible
> if the supplied stream is reversible as well.
>
> With best regards,
> Tagir Valeev.
>
> [1] https://stackoverflow.com/q/24010109/4856258
> [2] https://bugs.openjdk.java.net/browse/JDK-8133680
>
> On Sat, Apr 17, 2021 at 12:41 AM Stuart Marks <stuart.marks at oracle.com> wrote:
>
> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on detailed
> specifications and tests. Please send such comments as replies on this email thread.
>
> Here's a link to a draft PR that contains the code diffs. It's prototype quality,
> but it should be good enough to build and try out:
>
>      https://github.com/openjdk/jdk/pull/3533
>
> And here's a link to a class diagram showing the proposed additions:
>
>
> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
>
> Thanks,
>
> s'marks
>
>
> # Ordering and Reversibility
>
>
> A long-standing concept that's been missing from collections is that of the
> positioning, sequencing, or arrangement of elements as a structural property of a
> collection. (This is sometimes called the "iteration order" of a collection.) For
> example, a HashSet is not ordered, but a List is. This concept is mostly not
> manifested in the collections API.
>
> Iterating a collection produces elements one after another in *some* sequence. The
> concept of "ordered" determines whether this sequence is defined or whether it's a
> coincidence of implementation. What does "having an order" mean? It implies that
> there is a first element and that each element has a successor. Since collections
> have a finite number of elements, it further implies that there is a last element
> that has no successor. However, it is difficult to discern whether a collection has
> a defined order. HashSet generally iterates its elements in the same undefined
> order, and you can't actually tell that it's not a defined order.
>
> Streams do have a notion of ordering ("encounter order") and this is preserved,
> where appropriate, through the stream pipeline. It's possible to detect this by
> testing whether its spliterator has the ORDERED characteristic. Any collection with
> a defined order will have a spliterator with this characteristic. However, this is
> quite a roundabout way to determine whether a collection has a defined order.
> Furthermore, knowing this doesn't enable any additional operations. It only provides
> constraints on the stream's implementations (keeping the elements in order) and
> provides stronger semantics for certain operations. For example, findFirst() on an
> unordered stream is the same as findAny(), but actually finds the first element if
> the stream is ordered.
>
> The concept of ordering is thus present in the system but is surfaced only in a
> fairly indirect way. We can strengthen abstraction of ordering by making a few
> observations and considering their implications.
>
> Given that there is a first element and a last element, the sequence of elements has
> two ends. It's reasonable to consider operations (add, get, remove) on either end.
> Indeed, the Deque interface has a full complement of operations at each end. This is
> an oft-requested feature on various other collections.
>
> Each element except for the last has a successor, implying that each element except
> for the first has a predecessor. Thus it's reasonable to consider iterating the
> elements from first to last or from last to first (that is, in forward or reverse
> order). Indeed, the concept of iterating in reverse order appears already in bits
> and pieces in particular places around the collections:
>
>   - List has indexOf() and lastIndexOf()
>   - Deque has removeFirstOccurrence() and removeLastOccurrence()
>   - List has a ListIterator with hasPrevious/previous methods
>   - Deque and NavigableSet have descendingIterator methods
>
> Given an ordered collection, though, there's no general way to iterate it in reverse
> order. Reversed iteration isn't the most common operation, but there are some
> frequent use cases, such as operating on elements in most-recently-added order.
> Questions and bug reports about this have come up repeatedly over the years.
>
> Unfortunately, iterating in reverse order is much harder than iterating in forward
> order. There are a variety of ways to iterate in forward order. For example, given a
> List, one can do any of the following:
>
>      for (var e : list) { ... }
>      list.forEach(...)
>      list.stream()
>      list.toArray()
>
> However, to iterate a list in reverse order, one must use an explicit loop over
> ListIterator:
>
>      for (var it = list.listIterator(list.size()); it.hasPrevious(); ) {
>          var e = it.previous();
>          ...
>      }
>
> Streaming the elements of a List in reverse order is even worse. One approach would
> be to implement a reverse-ordered Iterator that wraps a ListIterator and delegates
> hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then, this
> Iterator can be turned into a Spliterator, which is then turned into a Stream. (The
> code to do this is left as an exercise for the reader.) Obtaining the elements in
> reverse via other means -- forEach() or toArray() -- is similarly difficult.
>
> Obtaining the elements in reverse order can be accomplished by adopting a concept
> from NavigableSet's descendingSet() method, which provides a reverse-ordered view
> collection. This view is also a NavigableSet, which means that any operation that
> can be performed on the original set can also be applied to the reverse-ordered
> view. If it were possible to obtain a similar reverse-ordered view on any kind of
> ordered collection, this would enable the elements to be processed in reverse order
> in any fashion, not just special-purposes APIs such as ListIterator or
> descendingIterator().
>
>
> # LinkedHashSet
>
>
> The main feature of LinkedHashSet is that it does have a defined ordering, as
> opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last
> element. However, LinkedHashSet is deficient in a number of ways:
>
>   - access to and removal of the first element is reasonable (using an iterator) but
> it is not possible to add at the front
>
>   - it is possible to add an element at the end, but access to and removal of the
> last element are expensive
>
>   - it's not possible to iterate in reverse without copying the entire collection
>
> Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so
> there is no fundamental implementation reason that prevents these operations from
> being supported. The main reason these operations aren't supported is probably that
> there hasn't been a good place to push such APIs.
>
>
> # Proposal
>
>
> Introduce a new ReversibleCollection<E> interface. This provides a new method to
> obtain a reverse-ordered view. It also contains several methods (copied from Deque)
> that allow operating on elements at both ends.
>
>
>      interface ReversibleCollection<E> extends Collection<E> {
>          ReversibleCollection<E> reversed();
>          default void addFirst(E e)
>          default void addLast(E e)
>          default E getFirst()
>          default E getLast()
>          default E removeFirst()
>          default E removeLast()
>      }
>
>
> The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are
> retrofitted to implement ReversibleCollection. They provide covariant overriding
> implementations of the reversed() method. For example, List.reversed() returns a
> List. Default implementations for all of these methods are provided in the
> appropriate interfaces.
>
> Covariant overrides are also provided in several other classes. This presents a
> difficulty for LinkedHashSet, as there's no suitable return type for reversed(). To
> remedy this, we add another interface
>
>
>      interface ReversibleSet<E> extends ReversibleCollection<E>, Set<E> { }
>
>
> This adds no new methods but is essentially an intersection of ReversibleCollection
> and Set. As such, it's suitable as the return type of LinkedHashSet.reversed() and
> the set views of LinkedHashMap.
>
> SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because
> SortedSet's ordering is determined by the comparison method and cannot be controlled
> explicitly.
>
> LinkedHashSet::addFirst and addLast add the element at the appropriate position or
> reposition the element if it is already present in the set.
>
> New methods are added to LinkedHashMap
>
>      V putFirst(K, V)
>      V putLast(K, V)
>
> which put the mapping at the designated position or reposition the mapping if is
> already present in the map.
>
>
> # Design & Implementation Issues
>
>
> Covariant overrides for reversed() are provided where possible. However, there is a
> conflict between List and Deque, as there are examples in the JDK (such as
> LinkedList) that implement both List and Deque. Since List is much more popular than
> Deque, I've decided against adding a covariant override to Deque. Instead, a method
> Deque::reversedDeque is added that returns a Deque, and Deque::reversed returns
> ReversibleCollection.
>
> There is no ReversibleMap interface. Most iteration over maps is over the entrySet,
> keySet, or values views. NavigableMap already has descendingMap(), and LinkedHashMap
> provides ReversibleX views, which cover most of the cases already.
>
> Introducing new methods into an interface hierarchy always raises the possibility of
> name clashes. I've done some searching but I haven't found any major issues, but we
> should be on the lookout for this. I'll continue to do more searching for such
> conflicts.
>
> Introducing covariant overrides on existing methods (notably LinkedHashMap entrySet,
> keySet, and values) could present incompatibility issues with subclasses that
> override these methods. I've done some searching and again I haven't found major
> problems, but this is nonetheless a point of concern. I'll do more searching here, too.
>
> The default implementations for List::reversed, Deque::reversed, and
> SortedSet::reversed return reverse-ordered views that are implemented using only
> public methods of the original interface. This demonstrates the feasibility of
> retrofitting reverse ordering onto any instance of these interfaces. Similarly, the
> various add/get/remove methods' default implementations are all implementable in
> terms of an iterator or reverse-ordered iterator. That said, some concurrent
> collection implementations will need to override these default implementations in
> order to preserve their safety invariants. It would probably also be wise to add
> optimized implementations to the more commonly-used collection implementations.
>
> Given that a ReversibleCollection has a defined ordering, any spliterator obtained
> from such a collection should have the Spliterator.ORDERED characteristic.
>
> This proposal is related to a previous discussion on a similar topic, where Tagir
> Valeev had proposed OrderedSet and OrderedMap:
>
>      http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066028.html
>
> I think there were some good ideas in there and in the ensuing discussion, but it
> didn't go anywhere. Several of the concepts in this proposal are an evolution of
> some ideas discussed in that thread.
>
> One of the ideas from that thread was to use Deque as a common interface for many
> collections to support reversibility and operations at the ends. We've abandoned
> that idea in this proposal. The reasons are that it's cluttered with a bunch of
> methods that are inherited from Queue. Also, some methods are null-returning instead
> of throwing, which introduces confusion for collections that can contain nulls.
>
> # END
>
>

From amaembo at gmail.com  Sun Apr 18 01:53:08 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 18 Apr 2021 08:53:08 +0700
Subject: ReversibleCollection proposal
In-Reply-To: <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAE+3fjY=rna4qUNejmzmWuMKgH74C0Rtw0OZ2Tx+vHfROp2M4Q@mail.gmail.com>

Hello, Remi!

On Sat, Apr 17, 2021 at 11:50 PM Remi Forax <forax at univ-mlv.fr> wrote:
> Introducing a new interface (two in this case) has a really huge cost and in this case, i've trouble to see why i will want to write a method that takes a ReversibleCollection as parameter, ReversibleCollection as a type does not seem to be useful. About the cost of introducing a new collection interface, it means that we also have to update all emptyXXX, singleXXX, uncheckedXXX with a new interface, and that only for the JDK. Every libraries that proxy collections has also to be updated to take care of this new type, otherwise the integration with an application that uses this new type and the library is not seamless anymore.

Note that in Stuart's proposal, java.util.List extends
ReversibleCollection. So, existing emptyList() and singletonList()
also return ReversibleCollection and no new methods are necessary
here. Probably unmodifiableReversibleSet could be useful as a
LinkedHashSet wrapper. On the other hand, we don't have, e.g.
checkedDeque or synchronizedDeque, and it looks like nobody complains.
So probably it's not always necessary to create a wrapper for every
single collection interface.

> I fully agree that having a way to reverse a collection is a powerful API point, as Brian said, it's better to reverse the collection and then ask for a stream than providing a method reverseStream (and this is true for iterators or views like keySet/entrySet/values or subList too). Several people also ask to have findLast() on Stream, using list.descendingList().findFirst() will be equivalent.

A dedicated findLast() would be a great addition to reversible
streams! It could short-circuit for reversible stream
(reverse().findFirst()) and use reduce((a, b) -> b) for non-reversible
(so intermediate buffering is not necessary). I've found 8 Stream API
call chains ending with .reduce((a, b) -> b) in our sources. Clearly,
some of them could short-circuit, as the source is potentially
reversible (e.g. allAnchors.subList(0,
idx).stream().filter(hasNewName).reduce((x1, x2) -> x2)). Having
dedicated findLast operation would be less error-prone, compared to
creating the stream as reversed().stream(), as you don't have to think
whether the stream is reversible or not. If you accidentally add a
non-reversible operation, you'll miss the optimization but not
correctness.

With best regards,
Tagir Valeev.

From amaembo at gmail.com  Sun Apr 18 05:37:43 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 18 Apr 2021 12:37:43 +0700
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
In-Reply-To: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
References: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
Message-ID: <CAE+3fja9n3ZSH7SaCP1F6oeMCw-UW1nOoGHvz3BkNdch2XP=zA@mail.gmail.com>

Hello!

I would vote to close this. The benefit for all JDK users is questionable.
If it's necessary in a particular application, it could be implemented in
user code.

With best regards,
Tagir Valeev.

??, 16 ???. 2021 ?., 23:49 Raffaello Giulietti <
raffaello.giulietti at gmail.com>:

> Hello,
>
> does the enhancement proposed in [1] make sense, both today and when
> wrappers will be migrated to primitive classes?
> If so, it should be rather simple to add it and I could prepare a PR.
> If not, the issue might perhaps be closed.
>
>
> Greetings
> Raffaello
>
> ----
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8252827
>

From Alan.Bateman at oracle.com  Sun Apr 18 07:10:43 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 18 Apr 2021 08:10:43 +0100
Subject: How to know if cpu supports unaligned memory accesses ?
In-Reply-To: <CAKjRUT5S8aP_wve-Sxa0QB0RU093ZZwuQKUDE4y3g0iTaVq81Q@mail.gmail.com>
References: <CAKjRUT5S8aP_wve-Sxa0QB0RU093ZZwuQKUDE4y3g0iTaVq81Q@mail.gmail.com>
Message-ID: <e20df77e-019a-f47a-070c-a9aecf4976f7@oracle.com>


On 17/04/2021 19:02, Laurent Bourg?s wrote:
> Hi,
> In the Marlin renderer & in other Unsafe use cases (pixel tile processing)
> for java2d pipelines, I do use putInt()/putLong() primitives even if the
> address is not aligned (to 4 or 8 bytes) to get faster processing of byte
> buffer or arrays...
>
> Is it possible in java (jdk internals) to query cpu capabilities like
> endianness, unaligned support ?
>
Since Marlin is in the JDK and using Unsafe already then can't it just 
using the isBigEndian and unalignedAccess methods? The Buffer 
implementation and a few places do the same.

-Alan.

From peter.levart at gmail.com  Sun Apr 18 07:51:04 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 18 Apr 2021 09:51:04 +0200
Subject: ReversibleCollection proposal
In-Reply-To: <CAE+3fjY=rna4qUNejmzmWuMKgH74C0Rtw0OZ2Tx+vHfROp2M4Q@mail.gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <CAE+3fjY=rna4qUNejmzmWuMKgH74C0Rtw0OZ2Tx+vHfROp2M4Q@mail.gmail.com>
Message-ID: <e218e1c3-48b7-1186-d963-d00dd830be3d@gmail.com>

A word for Remi's concern...


While it is good that List (and SortedSet and Deque) extend 
ReversibleCollection in the proposal, it is a pity the same is not true 
for Set and Queue. If Set and Queue could also be 
ReversibleCollection(s), then we would not need ReversibleCollection at 
all and the methods could be added to Collection itself.


So let's see them:

public interface Collection<E> .... {
 ??????? default Collection<E> reversed() { return this; }
 ??????? default void addFirst(E e) { throw new 
UnsupportedOperationException(); }
 ??????? default void addLast(E e) { throw new 
UnsupportedOperationException(); }
 ??????? default E getFirst() { return iterator().next(); }
 ??????? default E getLast() { return iterator().next(); }
 ??????? default E removeFirst() { var i = iterator(); i.next(); 
i.remove(); }
 ??????? default E removeLast() { var i = iterator(); i.next(); 
i.remove(); }
}


List, SortedSet and Deque would of course override them with 
implementations as proposed. Would anything be wrong with above 
implementations?

Collection is an Iterable which allows to iterate over elements. We can 
still iterate a Collection that does not define the order of iteration. 
We can not rely on such undefined order in our code, but we can still 
iterate it. Stream.findFirst() is equivalent to Stream.findAny() for 
unordered streams. So why would Collection.getFirst() and 
Collection.getLast() not be equivalent (to Collection.getAny()) for 
unordered Collections? Why would coll.reversed() be any different than 
coll for unordered collections?

Peter



On 4/18/21 3:53 AM, Tagir Valeev wrote:
> Hello, Remi!
>
> On Sat, Apr 17, 2021 at 11:50 PM Remi Forax <forax at univ-mlv.fr> wrote:
>> Introducing a new interface (two in this case) has a really huge cost and in this case, i've trouble to see why i will want to write a method that takes a ReversibleCollection as parameter, ReversibleCollection as a type does not seem to be useful. About the cost of introducing a new collection interface, it means that we also have to update all emptyXXX, singleXXX, uncheckedXXX with a new interface, and that only for the JDK. Every libraries that proxy collections has also to be updated to take care of this new type, otherwise the integration with an application that uses this new type and the library is not seamless anymore.
> Note that in Stuart's proposal, java.util.List extends
> ReversibleCollection. So, existing emptyList() and singletonList()
> also return ReversibleCollection and no new methods are necessary
> here. Probably unmodifiableReversibleSet could be useful as a
> LinkedHashSet wrapper. On the other hand, we don't have, e.g.
> checkedDeque or synchronizedDeque, and it looks like nobody complains.
> So probably it's not always necessary to create a wrapper for every
> single collection interface.
>
>> I fully agree that having a way to reverse a collection is a powerful API point, as Brian said, it's better to reverse the collection and then ask for a stream than providing a method reverseStream (and this is true for iterators or views like keySet/entrySet/values or subList too). Several people also ask to have findLast() on Stream, using list.descendingList().findFirst() will be equivalent.
> A dedicated findLast() would be a great addition to reversible
> streams! It could short-circuit for reversible stream
> (reverse().findFirst()) and use reduce((a, b) -> b) for non-reversible
> (so intermediate buffering is not necessary). I've found 8 Stream API
> call chains ending with .reduce((a, b) -> b) in our sources. Clearly,
> some of them could short-circuit, as the source is potentially
> reversible (e.g. allAnchors.subList(0,
> idx).stream().filter(hasNewName).reduce((x1, x2) -> x2)). Having
> dedicated findLast operation would be less error-prone, compared to
> creating the stream as reversed().stream(), as you don't have to think
> whether the stream is reversible or not. If you accidentally add a
> non-reversible operation, you'll miss the optimization but not
> correctness.
>
> With best regards,
> Tagir Valeev.

From peter.levart at gmail.com  Sun Apr 18 07:57:34 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 18 Apr 2021 09:57:34 +0200
Subject: ReversibleCollection proposal
In-Reply-To: <e218e1c3-48b7-1186-d963-d00dd830be3d@gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <CAE+3fjY=rna4qUNejmzmWuMKgH74C0Rtw0OZ2Tx+vHfROp2M4Q@mail.gmail.com>
 <e218e1c3-48b7-1186-d963-d00dd830be3d@gmail.com>
Message-ID: <e9d44e02-84c0-e7e6-8fd1-8f12bb4aa399@gmail.com>


On 4/18/21 9:51 AM, Peter Levart wrote:
> public interface Collection<E> .... {
> ??????? default Collection<E> reversed() { return this; }
> ??????? default void addFirst(E e) { throw new 
> UnsupportedOperationException(); }
> ??????? default void addLast(E e) { throw new 
> UnsupportedOperationException(); }


For unordered collections this could as well be:


 ??? ??? default void addFirst(E e) { return add(e); }
 ??? ??? default void addLast(E e) { return add(e); }


As the iteration of such modified unordered collection would not 
guarantee any order. SortedSet would of course override them with 
throwing methods.


> default E getFirst() { return iterator().next(); }
> ??????? default E getLast() { return iterator().next(); }
> ??????? default E removeFirst() { var i = iterator(); i.next(); 
> i.remove(); }
> ??????? default E removeLast() { var i = iterator(); i.next(); 
> i.remove(); }
> } 

From peter.levart at gmail.com  Sun Apr 18 08:26:18 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 18 Apr 2021 10:26:18 +0200
Subject: ReversibleCollection proposal
In-Reply-To: <e218e1c3-48b7-1186-d963-d00dd830be3d@gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <CAE+3fjY=rna4qUNejmzmWuMKgH74C0Rtw0OZ2Tx+vHfROp2M4Q@mail.gmail.com>
 <e218e1c3-48b7-1186-d963-d00dd830be3d@gmail.com>
Message-ID: <57f310dc-533f-ec39-c8e0-1342bee2d063@gmail.com>


On 4/18/21 9:51 AM, Peter Levart wrote:
> public interface Collection<E> .... {
> ??????? default Collection<E> reversed() { return this; }
> ??????? default void addFirst(E e) { throw new 
> UnsupportedOperationException(); }
> ??????? default void addLast(E e) { throw new 
> UnsupportedOperationException(); }
> ??????? default E getFirst() { return iterator().next(); }
> ??????? default E getLast() { return iterator().next(); }
> ??????? default E removeFirst() { var i = iterator(); i.next(); 
> i.remove(); }
> ??????? default E removeLast() { var i = iterator(); i.next(); 
> i.remove(); }
> }
>
>
> List, SortedSet and Deque would of course override them with 
> implementations as proposed. Would anything be wrong with above 
> implementations? 


Yeah, I forgot about the Queue. Would something like the following be 
too much throwing?


public interface Queue<E> ... {
 ??? ??? default Queue<E> reversed() { throw new 
UnsupportedOperationException(); }
 ??????? default void addFirst(E e) { throw new 
UnsupportedOperationException(); }
 ??????? default void addLast(E e) { add(e); }
 ??????? default E getFirst() { return element(); }
 ??????? default E getLast() { throw new UnsupportedOperationException(); }
 ??????? default E removeFirst() {? return remove(); }
 ??????? default E removeLast() { throw new 
UnsupportedOperationException(); }
}



Peter



From ron.pressler at oracle.com  Sun Apr 18 10:30:26 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Sun, 18 Apr 2021 10:30:26 +0000
Subject: RFC: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes
In-Reply-To: <CA+DM0AmS2phBdiwEhBM3eXpzZmTbnxN1B4a=Hk=+zz8RpSXxow@mail.gmail.com>
References: <CA+DM0AmS2phBdiwEhBM3eXpzZmTbnxN1B4a=Hk=+zz8RpSXxow@mail.gmail.com>
Message-ID: <A142A73F-5889-4A6E-86D8-6947D6D36CE1@oracle.com>

Hi Rafael!

The use cases you mention might be legitimate, but why are they legitimate *for 
agents*? For example, why can?t the Replacement class be defined in a regular library, 
not injected by the agent?

As to the existence of Unsafe hacks and others, those are going away, so ?we can do
this anyway,? is not an excuse. I think library authors need to accept that things 
they?re able to achieve with various hacks might not be possible to do as 
conveniently soon. The security and ecosystem maintenance philosophy is that certain 
things are allowed only when the *application* explicitly gives its consent by signifying 
it somehow on the command line. Libraries will not be able to take such permissions for 
themselves, and ?the application gives its consent by choosing my library? is insufficient.

Yes, it will be less convenient, but convenience is not the only important concern.
At this point, that capabilities that might compromise security or upgradability (i.e
reliance on non-API elements) might require explicit consent on the command line, even
when this might be less convenient, should be taken as an axiom for the discussion.

? Ron



> On 16 Apr 2021, at 21:18, Rafael Winterhalter <rafael.wth at gmail.com> wrote:
> 
> I am trying to revive issue 8200559 (
> https://bugs.openjdk.java.net/browse/JDK-8200559) which was briefly
> discussed on this mailing list over three years ago (
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000405.html). I
> am hopeful that a solution could be reached prior to releasing Java 17.
> With the LTS label, JVMs of that version are likely to be seen for quite
> some time and without a fix, many Java agents will still rely on unsafe API
> to support that version. With the issue resolved, agents that aim to
> support Java 17 as a baseline could be implemented using only official API
> which I consider a desirable milestone. This would also allow me to remove
> use of unsafe API from a range of popular open source projects that I
> maintain once Java 17 becomes their baseline. I have proactively added a
> pull request (https://github.com/openjdk/jdk/pull/3546) with what I
> consider to be the most complete and satisfactory solution for agent
> developers. I implemented this patch to test potential migration for my own
> and customer projects and can confirm that this would indeed make any
> unsafe API obsolete.
> 
> I had already lined out why APIs such as MethodHandles.Lookup::defineClass
> do not work for ClassFileTransformers in my original posting. I will try to
> avoid reiterating on my original argument. As a result of this discussion,
> an API was proposed where the ClassFileTransformer would be overloaded with
> an additional parameter that receives an instance of ClassDefiner as its
> argument. The instance would allow you to define a class but assert that
> the auxiliary class is located in the same package as the class under
> transformation. For example, if a class:
> 
> package p;
> class C {
>  void m(A a) {
>    a.callback(new Value());
>  }
> }
> 
> would be instrumented to become:
> 
> package p;
> class C {
>  void m(A a) {
>    a.callback(new Replacement()); // changed
>  }
> }
> 
> then ClassDefiner would assert that the auxiliary class Replacement is also
> defined in package 'p'. In my eyes, this is not a very satisfying solution.
> In some cases, a Java agent is for example using existing classes to carry
> additional state between two instrumented classes. For instance, class
> Replacement might be used as a carrier of additional state to pass to class
> A which is itself instrumented as follows:
> 
> package p2;
> class A {
>  void callback(Value v) {
>    if (v instanceof Replacement) {
>      // read data of v and process
>    }
>  }
> }
> 
> This example is far from constructed, but a common and effective strategy
> to implement tracing, security monitoring or code intelligence.
> 
> It is of course possible to implement this pattern by using the
> package-restricted ClassDefiner. It is however rather costly and
> complicated to implement. A ClassFileTransformer is a simple callback that
> is not in control of the class loading order but is only invoked whenever a
> class is loaded for the first time. The first class to be loaded might of
> course be either C or A, it might not even be deterministic for the same
> application. If the class Replacement was required to live in the package
> of the class that is currently instrumented, Replacement would need to be
> defined in either p or p2, depending on the materialized class loading
> order. This would require some form of state management in the class file
> transformer to keep track of the package that one would need to use when
> instrumenting the second class. Due to parallel class loading and with
> constellations that involve even more classes, this can get quite
> complicated. Using a stable package name is however not only a convenience.
> The name of a package can affect reflection-heavy frameworks, debugging
> opportunities, logs, stacktraces and more.
> 
> Furthermore, one should consider the costs of migrating an existing agent
> in the light that an agent can easily open jdk.internal.misc.Unsafe by
> using the instrumentation API or use a class file transformer to erase the
> explicit package assertion of ClassDefiner. Current agents often use
> sun.misc.Unsafe or jdk.internal.misc.Unsafe to invoke the defineClass
> method of these types. This API is very performant and easy to use. To some
> degree, it is even possible to emulate the Unsafe API using ClassDefiner by
> strategically retransforming classes in the right package. The following
> code allows to define a class using a witness class by using a
> non-operational class file transformer:
> 
> static Class<?> defineClass(Instrumentation inst, final Class<?> witness,
> final byte[] classFile) throws Exception {
>  AtomicReference<Class<?>> ref = new AtomicReference<>();
>  ClassFileTransformer definer = new ClassFileTransformer() {
>    @Override
>    public byte[] transform(ClassDefiner classDefiner,
>                            Module module,
>                            ClassLoader loader,
>                            String className,
>                            Class<?> classBeingRedefined,
>                            ProtectionDomain protectionDomain,
>                            byte[] classfileBuffer) {
>      if (classBeingRedefined == witness) {
>        ref.set(classDefiner.define(classFile));
>      }
>      return null;
>    }
>  };
>  inst.addTransformer(definer, true);
>  try {
>    inst.retransformClasses(witness);
>  } finally {
>    inst.removeTransformer(definer);
>  }
>  return ref.get();
> }
> 
> In this sense, Java agents already have the possibility to define new
> classes within any package. The restriction that ClassDefiner introduces is
> therefore merely cosmetic and does not really reduce the actual
> capabilities of any owner of an instance of Instrumentation. Beyond that,
> JNI already offers a similar API for defining a class which is also used as
> there are wrappers that compile the method for any common platform and
> architecture.
> 
> Finally, many Java agents need to define general infrastructure classes to
> function. A tracing framework might for example want to be notified of all
> HTTP calls of known frameworks. To accomplish this, some form of common
> callback is injected into a generally known class loader, often the
> globally visible bootstrap loader:
> 
> package com.acme.tracer;
> public class AgentCallback {
>  public static void callback(String framework) { ... }
> }
> 
> This is typically done before registering a first ClassFileTransformer
> which is later instrumenting framework classes to invoke this callback,
> none of which is defined by the boot loader which is only used to assure
> that the counter can be seen from all application classes and the agent
> framework alike. At the moment,
> Instrumentation::appendToBootstrapClassLoaderSearch is the most feasible
> approach to this. However, the API also has significant downsides. First of
> all, it is of course restricted to the boot or system loader by the way the
> API is set up. In some scenarios, another class loader would however be
> more appropriate, for example if a JVM is segmented as in a JEE container
> where the callback should only apply to a specific deployment area and
> might therefore better be placed in a different class loader that is root
> to the deployment. Additionally, it is rather inefficient to serialize
> these auxiliary classes to the file system, only to pass it to the API
> which then reads them back into memory to load the contained classes. In
> some environments, a file system for such purposes is not even available.
> 
> For all these reasons, I still believe that adding
> Instrumentation::defineClass is the best solution to address all of these
> legitimate needs. Java agents have created excellent tooling for the JVM
> which make the platform successful in the enterprise. In my eyes it is
> overdue that these legitimate use cases can start relying on a stable API.
> Going this route would offer an easy path for migration and agents that
> supported older versions than Java 17 could easily replace their usage of
> Unsafe by this similar API which promises a quick adoption. Alternatively,
> I am afraid many will find ways around, even by emulating unsafe using
> official API as I demonstrated, the cost being decreased performance and
> convenience.
> 
> Thank you for your comments. I really hope this can be addressed before 17
> is released, I am hopeful that this would make the use of unsafe API in
> agents disappear sooner rather than later.
> 
> Best regards, Rafael


From ysuenaga at openjdk.java.net  Sun Apr 18 15:10:15 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 18 Apr 2021 15:10:15 GMT
Subject: RFR: 8265152: jpackage cleanup fails on Windows with IOException
 deleting msi
Message-ID: <5kVIe79iAW3K6erYsi9jIGuzXQRTPtCSDZnEludo_z0=.8d766457-d8c8-4f1c-9813-c87165694edd@github.com>

When creating an "exe" installer on Windows, `AbstractBundler.cleanup()` calls `IOUtils.deleteRecursive()` to delete the tmp directory. It can intermittently fail trying to delete the msi file.

[JDK-8263135](https://bugs.openjdk.java.net/browse/JDK-8263135) removed `unique_ptr` from jpackage sources due to compiler warnings in VS 2019 (16.9.0), so we need to release the resource manually. However `DatabaseView` didn't do that.

-------------

Commit messages:
 - 8265152: jpackage cleanup fails on Windows with IOException deleting msi

Changes: https://git.openjdk.java.net/jdk/pull/3560/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3560&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265152
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3560/head:pull/3560

PR: https://git.openjdk.java.net/jdk/pull/3560

From Alan.Bateman at oracle.com  Sun Apr 18 16:24:04 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 18 Apr 2021 17:24:04 +0100
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <G9kGpi5IXI1SSAPLSM14zOqMmHvlj5aWSZUrwWGk5qY=.8e21afe1-0d2a-48a0-86de-e3e5b6cdc73a@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <G9kGpi5IXI1SSAPLSM14zOqMmHvlj5aWSZUrwWGk5qY=.8e21afe1-0d2a-48a0-86de-e3e5b6cdc73a@github.com>
Message-ID: <5eda4d71-362f-59f5-6053-1e176873dd91@oracle.com>

On 16/04/2021 21:09, Rafael Winterhalter wrote:
> I have never seen a need for a non-agent to define a class in a
> non-existing package. Injection is typically required if you want to work
> with package-private types or methods which is really only relevant for the
> Spring framework, but even there I do not think it's such a big area that
> it cannot be addressed. Non-agent code generation is typically the use of
> proxies where the code generation framework is sharing a class loader with
> the user code and there is normally a way to weave it. Agents on the other
> hand have to deal with unknown class loader hierarchies and it can be
> necessary to inject code into a common class loader parent without
> instrumenting classes in this loader or even knowing any classes of this
> loader.
Yes, the injection of proxy classes and the like is mainly the same 
run-time package as an existing class and these are the use-cases that 
Lookup.defineClass and Lookup.defineHiddenClass are intended for. There 
has been a few requests for defining proxy classes into "new/empty 
packages" but has a few challenges, like extending the set of packages 
in a named module. In general I wouldn't expect Java agents, which was 
intending for tools, to be using Lookup objects.


> I have never heard about a 'discussion [that] will eventually lead into
> putting at least some restrictions on agents loaded into a running VM' and
> as a heavy user and someone who has helped to write a long row of
> commercial agents and followed them into their use in production and who
> has seen how helpful they are in reducing deployment complexity, I can only
> hope that you will change your mind on this.
> :
>
> That said, even if it was restricted in the future, this would mean that
> some of the Instrumentation API methods will throw exceptions in the
> future. There would not be much difference if an introduced defineClass
> method would do the same.
There was fuss on this topic during JDK 9. I'll try to find the mails in 
the archive, it would have been on serviceability-dev in 2016 or 2017. 
The compromise at the time was to introduce the 
-XX:EnableDynamicAgentLoading option with an initial value of "true" and 
re-visit it later. Flipping the default would mean that JVMTI and Java 
agents could not be loaded into a target VM without opt-in on the 
command line. No impact to agents specified on the command line with 
-javaagent, no impact to other usages of the attach mechanism so jcmd 
and the other diagnostic tools would continue to work.

To re-cap, the main concern is the Instrumentation object is 
all-powerful and is intended for tools and the instrumentation is 
intended to be benign to support use-cases such as monitoring and 
tracing. It was never intended to a back-door into JDK internals. 
Specifying an agent on the command line with -javaagent is the opt-in to 
trust that agent. A tool run by the same user that loads its agent into 
a target VM is the use-case we targeted when we added the attach 
mechanism and the late binding agent support in JDK 6. The issue with 
that (and it's a regret now) is that the mechanism doesn't distinguish 
usage by a tool from a library/application using the attach mechanism to 
load an agent into the current VM (directly or using an intermediate VM).

Time has moved on and maybe a better approach is to not change the XX 
option but instead load the agents with reduced capabilities. It would 
require opt-in on the command line to give these agents the same 
capabilities as agents specified on the command line with -javaagent. It 
would require exploration but it might be that unrecognized agents would 
not be allowed to redefine java.base or other core modules or instrument 
classes in those modules. The APIs are already specified to allow 
Unmodified{Module,Class}Exception be thrown as there have been cases in 
the past where some classes could not be transformed. Project Panama is 
currently exploring how to restrict and grant access to native code and 
maybe it should be the same mechanism or at least be consistent.

Hopefully this helps sets some context as to why we have to be cautious 
with this PR. If the proposal were a defineClass that was limited to 
agents specified on the command line then it might okay. This would 
serve use-cases with tool agents that are way more advanced that the 
use-cases that we envisaged back in Java 5/6. The previous exploration 
into allowing non-public auxiliary classes be defined in the same 
run-time package as the class being instrumented was also okay.

-Alan

From plevart at openjdk.java.net  Sun Apr 18 19:55:20 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 18 Apr 2021 19:55:20 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v3]
In-Reply-To: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
Message-ID: <daIGAcPTe4CCltEpNtYQcjVblHW8k9UXZHcl5H3TsdI=.522b8270-9430-470a-a450-5dd967ee67fa@github.com>

> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
> 
> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
> 
> The comparative results are here:
> 
> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
> 
> The jmh-result.json files are here:
> 
> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
> 
> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
> 
> So WDYT?

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  Fix overflow checking logic, add test for it, avoid branch in loop, add 1-char strings to JHM test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3501/files
  - new: https://git.openjdk.java.net/jdk/pull/3501/files/6160e5aa..a2d5e819

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=01-02

  Stats: 123 lines in 3 files changed: 110 ins; 4 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3501.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3501/head:pull/3501

PR: https://git.openjdk.java.net/jdk/pull/3501

From plevart at openjdk.java.net  Sun Apr 18 20:19:47 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 18 Apr 2021 20:19:47 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v3]
In-Reply-To: <daIGAcPTe4CCltEpNtYQcjVblHW8k9UXZHcl5H3TsdI=.522b8270-9430-470a-a450-5dd967ee67fa@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <daIGAcPTe4CCltEpNtYQcjVblHW8k9UXZHcl5H3TsdI=.522b8270-9430-470a-a450-5dd967ee67fa@github.com>
Message-ID: <duVFEvM5HHfybwMb7C-67rsZVTGupHd8j5TrZGISHIE=.a03e1955-d53e-4492-bf23-e498934f6756@github.com>

On Sun, 18 Apr 2021 19:55:20 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
>> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
>> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
>> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
>> 
>> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
>> 
>> The comparative results are here:
>> 
>> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
>> 
>> The jmh-result.json files are here:
>> 
>> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
>> 
>> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
>> 
>> So WDYT?
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix overflow checking logic, add test for it, avoid branch in loop, add 1-char strings to JHM test

So here's another iteration where I have taken into account all the suggestions:
- avoid the branch in the append loop by appending the 1st element outside the loop so that delimiter can unconditionally be appended inside the loop for rest of the elements.
- fixed overflow checking logic + added a test for it - previously it was possible to provoke wrong exception: IllegalArgumentException: size is negative. I added another test instead of extending existing one because it needs a 1GiB string and together with 2GiB string in existing test it would not fit in 4GiB heap any more when running with unpatched version. I wanted the tests to pass with unpatched version too.
- extended the parameters of JMH benchmark to include 1-character strings + re-run the benchmarks

The results are not that different from previous version (that used a conditional in the loop) as JIT is probably smart enough to unroll the loop and divide it into at least two parts (the way I did it manually now). What brings the most improvement in this version is the annotation to force in-lining of the String.join package-private method. Without it, it would happen that for one combination of JMH parameters, the results were a little worse compared to unpatched baseline - not for much: about 7%, but with the annotation, all combinations of parameters bring consistent improvement in range from 12% to 102%:

https://jmh.morethan.io/?gist=babf00a655d21ff784ede887af53ec31

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From rafael.wth at gmail.com  Sun Apr 18 20:28:23 2021
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Sun, 18 Apr 2021 22:28:23 +0200
Subject: RFC: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes
In-Reply-To: <A142A73F-5889-4A6E-86D8-6947D6D36CE1@oracle.com>
References: <CA+DM0AmS2phBdiwEhBM3eXpzZmTbnxN1B4a=Hk=+zz8RpSXxow@mail.gmail.com>
 <A142A73F-5889-4A6E-86D8-6947D6D36CE1@oracle.com>
Message-ID: <CA+DM0Amg8SNPeKaKFdZmvN4A2i8h4s2LNJhVB_73jgTnktk=xQ@mail.gmail.com>

'legitimate' is probably a poor choice of word. What I mean to express is
that libraries, other than agents, are able to address class loaders
explicitly in their APIs and can often expect to share a hierarchy with the
code they interact with. Using method handles and the defineClass method,
you can also require appropriate arguments or that modules are opened to
the library. I would not know of a use case that I was not able to cover
with the existing API, despite developing some of the more 'low level'
libraries for the JVM.

With agents on the other hand, there is no API that your targeted
application can be made aware of. You cannot require a lookup to be
provided to you, as an agent is supplementary and is not known to the
application. Furthermore, an agent cannot make assumptions, for example
about class loaders and it cannot require much from the application, as
they are normally developed separately and users often want to apply them
to a range of applications without rewriting their code. Anything else
would defeat their purpose. This often requires to establish some sort of
dispatcher logic across class loaders, which again requires injection. I do
not see this to be the case for a regular library. I do however believe
that this is already understood, I assume that is why the Instrumentation
API offers a way of injecting code into the boot and system loaders. My
point is that these APIs are dated as they cannot accept a byte array but
require writing to the file system and since they only allow targeting two
well-known class loaders.

As by 'we can do this anyway', I explicitly mean that it is possible to
emulate the API that I propose already today, without using unofficial
APIs. I have previously prototyped emulations, just to measure performance
impact which is normally inacceptable. If you wanted to define a class, you
can for example retransform a carrier class and inject classes from a known
method which you add to the constant pool as a base64 encoding:

class Carrier {
  void m() { }
}

can for example be retransformed into:

class Carrier {
  void m() {
    if (someGuard()) // some condition and maybe synchronization
      MethodHandles.lookup().defineClass("<base 64 class file>".getBytes());
  }
}

This would define the class in question anytime a "trigger method" is
invoked within a well-known pattern. Also, I already showed how you could
emulate general injection by offering a package-local injection using the
API that was proposed as an alternative in the previous mail. The real
difference is in the end of course convenience and performance, but I do
not find it intuitive to not offer a performant, reliable API if there is a
well founded requirement for it. As someone who is working with Java in the
enterprise as a day job, I cannot stress out enough how important the
tooling is for Java's use in the enterprise. Static and dynamic Java
agents, APM and security monitoring, are deployed in every production
environment I come across. And this tooling needs a way of class injection
as I outlined it.

Am So., 18. Apr. 2021 um 12:30 Uhr schrieb Ron Pressler <
ron.pressler at oracle.com>:

> Hi Rafael!
>
> The use cases you mention might be legitimate, but why are they legitimate
> *for
> agents*? For example, why can?t the Replacement class be defined in a
> regular library,
> not injected by the agent?
>
> As to the existence of Unsafe hacks and others, those are going away, so
> ?we can do
> this anyway,? is not an excuse. I think library authors need to accept
> that things
> they?re able to achieve with various hacks might not be possible to do as
> conveniently soon. The security and ecosystem maintenance philosophy is
> that certain
> things are allowed only when the *application* explicitly gives its
> consent by signifying
> it somehow on the command line. Libraries will not be able to take such
> permissions for
> themselves, and ?the application gives its consent by choosing my library?
> is insufficient.
>
> Yes, it will be less convenient, but convenience is not the only important
> concern.
> At this point, that capabilities that might compromise security or
> upgradability (i.e
> reliance on non-API elements) might require explicit consent on the
> command line, even
> when this might be less convenient, should be taken as an axiom for the
> discussion.
>
> ? Ron
>
>
>
> > On 16 Apr 2021, at 21:18, Rafael Winterhalter <rafael.wth at gmail.com>
> wrote:
> >
> > I am trying to revive issue 8200559 (
> > https://bugs.openjdk.java.net/browse/JDK-8200559) which was briefly
> > discussed on this mailing list over three years ago (
> > http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000405.html).
> I
> > am hopeful that a solution could be reached prior to releasing Java 17.
> > With the LTS label, JVMs of that version are likely to be seen for quite
> > some time and without a fix, many Java agents will still rely on unsafe
> API
> > to support that version. With the issue resolved, agents that aim to
> > support Java 17 as a baseline could be implemented using only official
> API
> > which I consider a desirable milestone. This would also allow me to
> remove
> > use of unsafe API from a range of popular open source projects that I
> > maintain once Java 17 becomes their baseline. I have proactively added a
> > pull request (https://github.com/openjdk/jdk/pull/3546) with what I
> > consider to be the most complete and satisfactory solution for agent
> > developers. I implemented this patch to test potential migration for my
> own
> > and customer projects and can confirm that this would indeed make any
> > unsafe API obsolete.
> >
> > I had already lined out why APIs such as
> MethodHandles.Lookup::defineClass
> > do not work for ClassFileTransformers in my original posting. I will try
> to
> > avoid reiterating on my original argument. As a result of this
> discussion,
> > an API was proposed where the ClassFileTransformer would be overloaded
> with
> > an additional parameter that receives an instance of ClassDefiner as its
> > argument. The instance would allow you to define a class but assert that
> > the auxiliary class is located in the same package as the class under
> > transformation. For example, if a class:
> >
> > package p;
> > class C {
> >  void m(A a) {
> >    a.callback(new Value());
> >  }
> > }
> >
> > would be instrumented to become:
> >
> > package p;
> > class C {
> >  void m(A a) {
> >    a.callback(new Replacement()); // changed
> >  }
> > }
> >
> > then ClassDefiner would assert that the auxiliary class Replacement is
> also
> > defined in package 'p'. In my eyes, this is not a very satisfying
> solution.
> > In some cases, a Java agent is for example using existing classes to
> carry
> > additional state between two instrumented classes. For instance, class
> > Replacement might be used as a carrier of additional state to pass to
> class
> > A which is itself instrumented as follows:
> >
> > package p2;
> > class A {
> >  void callback(Value v) {
> >    if (v instanceof Replacement) {
> >      // read data of v and process
> >    }
> >  }
> > }
> >
> > This example is far from constructed, but a common and effective strategy
> > to implement tracing, security monitoring or code intelligence.
> >
> > It is of course possible to implement this pattern by using the
> > package-restricted ClassDefiner. It is however rather costly and
> > complicated to implement. A ClassFileTransformer is a simple callback
> that
> > is not in control of the class loading order but is only invoked
> whenever a
> > class is loaded for the first time. The first class to be loaded might of
> > course be either C or A, it might not even be deterministic for the same
> > application. If the class Replacement was required to live in the package
> > of the class that is currently instrumented, Replacement would need to be
> > defined in either p or p2, depending on the materialized class loading
> > order. This would require some form of state management in the class file
> > transformer to keep track of the package that one would need to use when
> > instrumenting the second class. Due to parallel class loading and with
> > constellations that involve even more classes, this can get quite
> > complicated. Using a stable package name is however not only a
> convenience.
> > The name of a package can affect reflection-heavy frameworks, debugging
> > opportunities, logs, stacktraces and more.
> >
> > Furthermore, one should consider the costs of migrating an existing agent
> > in the light that an agent can easily open jdk.internal.misc.Unsafe by
> > using the instrumentation API or use a class file transformer to erase
> the
> > explicit package assertion of ClassDefiner. Current agents often use
> > sun.misc.Unsafe or jdk.internal.misc.Unsafe to invoke the defineClass
> > method of these types. This API is very performant and easy to use. To
> some
> > degree, it is even possible to emulate the Unsafe API using ClassDefiner
> by
> > strategically retransforming classes in the right package. The following
> > code allows to define a class using a witness class by using a
> > non-operational class file transformer:
> >
> > static Class<?> defineClass(Instrumentation inst, final Class<?> witness,
> > final byte[] classFile) throws Exception {
> >  AtomicReference<Class<?>> ref = new AtomicReference<>();
> >  ClassFileTransformer definer = new ClassFileTransformer() {
> >    @Override
> >    public byte[] transform(ClassDefiner classDefiner,
> >                            Module module,
> >                            ClassLoader loader,
> >                            String className,
> >                            Class<?> classBeingRedefined,
> >                            ProtectionDomain protectionDomain,
> >                            byte[] classfileBuffer) {
> >      if (classBeingRedefined == witness) {
> >        ref.set(classDefiner.define(classFile));
> >      }
> >      return null;
> >    }
> >  };
> >  inst.addTransformer(definer, true);
> >  try {
> >    inst.retransformClasses(witness);
> >  } finally {
> >    inst.removeTransformer(definer);
> >  }
> >  return ref.get();
> > }
> >
> > In this sense, Java agents already have the possibility to define new
> > classes within any package. The restriction that ClassDefiner introduces
> is
> > therefore merely cosmetic and does not really reduce the actual
> > capabilities of any owner of an instance of Instrumentation. Beyond that,
> > JNI already offers a similar API for defining a class which is also used
> as
> > there are wrappers that compile the method for any common platform and
> > architecture.
> >
> > Finally, many Java agents need to define general infrastructure classes
> to
> > function. A tracing framework might for example want to be notified of
> all
> > HTTP calls of known frameworks. To accomplish this, some form of common
> > callback is injected into a generally known class loader, often the
> > globally visible bootstrap loader:
> >
> > package com.acme.tracer;
> > public class AgentCallback {
> >  public static void callback(String framework) { ... }
> > }
> >
> > This is typically done before registering a first ClassFileTransformer
> > which is later instrumenting framework classes to invoke this callback,
> > none of which is defined by the boot loader which is only used to assure
> > that the counter can be seen from all application classes and the agent
> > framework alike. At the moment,
> > Instrumentation::appendToBootstrapClassLoaderSearch is the most feasible
> > approach to this. However, the API also has significant downsides. First
> of
> > all, it is of course restricted to the boot or system loader by the way
> the
> > API is set up. In some scenarios, another class loader would however be
> > more appropriate, for example if a JVM is segmented as in a JEE container
> > where the callback should only apply to a specific deployment area and
> > might therefore better be placed in a different class loader that is root
> > to the deployment. Additionally, it is rather inefficient to serialize
> > these auxiliary classes to the file system, only to pass it to the API
> > which then reads them back into memory to load the contained classes. In
> > some environments, a file system for such purposes is not even available.
> >
> > For all these reasons, I still believe that adding
> > Instrumentation::defineClass is the best solution to address all of these
> > legitimate needs. Java agents have created excellent tooling for the JVM
> > which make the platform successful in the enterprise. In my eyes it is
> > overdue that these legitimate use cases can start relying on a stable
> API.
> > Going this route would offer an easy path for migration and agents that
> > supported older versions than Java 17 could easily replace their usage of
> > Unsafe by this similar API which promises a quick adoption.
> Alternatively,
> > I am afraid many will find ways around, even by emulating unsafe using
> > official API as I demonstrated, the cost being decreased performance and
> > convenience.
> >
> > Thank you for your comments. I really hope this can be addressed before
> 17
> > is released, I am hopeful that this would make the use of unsafe API in
> > agents disappear sooner rather than later.
> >
> > Best regards, Rafael
>
>

From plevart at openjdk.java.net  Sun Apr 18 20:34:45 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 18 Apr 2021 20:34:45 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v2]
In-Reply-To: <DJ0r0M9Q__h_-LkXVcaWwcBpv-cuhJb4U4ThoPT1COk=.3d65dd56-c82b-4ad2-9b31-4721a0c23fb6@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <Q0KrFJ5y96KgNO15EOLFT6XU-0OkxjiA3ezBf0lujy8=.9e2d4b07-820c-4c86-9475-fa6b8696d3c3@github.com>
 <aA8_XzKvy7slrlD1D2IAtFjCVdCGJnrMM77XW87_Zzs=.c8fda6d1-ba0f-4dfe-8981-80b828b39468@github.com>
 <DJ0r0M9Q__h_-LkXVcaWwcBpv-cuhJb4U4ThoPT1COk=.3d65dd56-c82b-4ad2-9b31-4721a0c23fb6@github.com>
Message-ID: <pzhVRiQKaHgrzUiyxdHGkLTNJB5Bb6n8mtmh2hVI2LQ=.0038a7fa-38ad-43a8-a689-1dee157a2abf@github.com>

On Fri, 16 Apr 2021 23:02:33 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 3254:
>> 
>>> 3252: 
>>> 3253:         byte[] value = StringConcatHelper.newArray(((long) icoder << 32) | llen);
>>> 3254:         int off = 0;
>> 
>> StringConcatHelper.newArray() can double the length (based on the coder) and it is then truncated to 32 bits when passed to UNSAFE.allocatlUnitializedArray.
>> The test of length above only ensures llen can be truncated to 32 bits without loss of data.
>
> I thought about that, yes. And I think we have to do the check for the doubled length before calling the newArray. I checked the StringJoinerTest and it only deals with ascii strings unfortunately. Will have to add a test for that too...

I do the checks before calling `StringConcatHelper.newArray()` now and pass a long value to it that already holds the number of bytes needed and where the upper 32  bits (coder) is always 0.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From rafael.wth at gmail.com  Sun Apr 18 21:05:43 2021
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Sun, 18 Apr 2021 23:05:43 +0200
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxilary classes
In-Reply-To: <5eda4d71-362f-59f5-6053-1e176873dd91@oracle.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <G9kGpi5IXI1SSAPLSM14zOqMmHvlj5aWSZUrwWGk5qY=.8e21afe1-0d2a-48a0-86de-e3e5b6cdc73a@github.com>
 <5eda4d71-362f-59f5-6053-1e176873dd91@oracle.com>
Message-ID: <CA+DM0A=8F29TEsXaX0r5QJxAhW5w8_RpG+v3D4bfvZuaHNdi8g@mail.gmail.com>

As for the need to inject classes into 'new' packages, in Mockito we solve
this easily by 'claiming' a package by defining a static dummy class within
it which we then use as a hook for injection using a lookup. This works
well for us, and I do of course not know the explicit requirements of
others, but personally, I do not see a big need for this functionality
otherwise.

I remember the discussions about the dynamic agent attachment rather well,
it cuts into my line of work. The main (!) reason why dynamic attachment is
so popular is that it allows monitoring a JVM without additional
configuration. In this light, it does not make much of a difference if a
user has to set a special parameter to allow for dynamic attachment or if
the user has to set up the agent parameter itself, both add about the same
costs to operations. This is the cost you want to avoid by dynamic
attachment in the first place. Imagine an enterprise with thousands of JVM
deployments which are managed by different teams in different styles, with
different technical understanding relying on long chains of communication.
It can take years to roll out a tracing tool that requires explicit
configuration in an org like this. Thanks to dynamic attachment, all you
need is to drop an application per host which discovers all running JVMs
and attaches to them. A tracing tool that is missing only a few VMs by
misconfiguration will render a very incomplete picture of the tracing
state, making it an expensive toy. Easily avoiding such simple misses is an
important selling point for the JVM compared to other platforms where this
is not possible. I know this problem does not sound like much, it's
overcomeable, but orgs will not change, and reducing the capabilities of
dynamic agents would take much more out of the JVM's attractiveness than
the added security and consistency would bring to it.

As for the proposed API, I understand that it needs thought, my hope is
still that Java 17 would allow to write agents without Unsafe, since 17
will be a baseline for many years to come. I'd like to stress out that the
proposed API only encapsulates something that is already implicitly
possible today if one puts in the work.

I think that the problem you want to solve is rather that JVMs should not
attach to themselves to get hold of an instance of Instrumentation for
their own JVM. In this context, one would need to restrict the use of JNI
and prevent that a JVM starts new (Java) processes. I think it would be
better to tackle the issue from this angle rather than taking away a
feature that significantly adds to the JVMs attractiveness.

Am So., 18. Apr. 2021 um 18:24 Uhr schrieb Alan Bateman <
Alan.Bateman at oracle.com>:

> On 16/04/2021 21:09, Rafael Winterhalter wrote:
> > I have never seen a need for a non-agent to define a class in a
> > non-existing package. Injection is typically required if you want to work
> > with package-private types or methods which is really only relevant for
> the
> > Spring framework, but even there I do not think it's such a big area that
> > it cannot be addressed. Non-agent code generation is typically the use of
> > proxies where the code generation framework is sharing a class loader
> with
> > the user code and there is normally a way to weave it. Agents on the
> other
> > hand have to deal with unknown class loader hierarchies and it can be
> > necessary to inject code into a common class loader parent without
> > instrumenting classes in this loader or even knowing any classes of this
> > loader.
> Yes, the injection of proxy classes and the like is mainly the same
> run-time package as an existing class and these are the use-cases that
> Lookup.defineClass and Lookup.defineHiddenClass are intended for. There
> has been a few requests for defining proxy classes into "new/empty
> packages" but has a few challenges, like extending the set of packages
> in a named module. In general I wouldn't expect Java agents, which was
> intending for tools, to be using Lookup objects.
>
>
> > I have never heard about a 'discussion [that] will eventually lead into
> > putting at least some restrictions on agents loaded into a running VM'
> and
> > as a heavy user and someone who has helped to write a long row of
> > commercial agents and followed them into their use in production and who
> > has seen how helpful they are in reducing deployment complexity, I can
> only
> > hope that you will change your mind on this.
> > :
> >
> > That said, even if it was restricted in the future, this would mean that
> > some of the Instrumentation API methods will throw exceptions in the
> > future. There would not be much difference if an introduced defineClass
> > method would do the same.
> There was fuss on this topic during JDK 9. I'll try to find the mails in
> the archive, it would have been on serviceability-dev in 2016 or 2017.
> The compromise at the time was to introduce the
> -XX:EnableDynamicAgentLoading option with an initial value of "true" and
> re-visit it later. Flipping the default would mean that JVMTI and Java
> agents could not be loaded into a target VM without opt-in on the
> command line. No impact to agents specified on the command line with
> -javaagent, no impact to other usages of the attach mechanism so jcmd
> and the other diagnostic tools would continue to work.
>
> To re-cap, the main concern is the Instrumentation object is
> all-powerful and is intended for tools and the instrumentation is
> intended to be benign to support use-cases such as monitoring and
> tracing. It was never intended to a back-door into JDK internals.
> Specifying an agent on the command line with -javaagent is the opt-in to
> trust that agent. A tool run by the same user that loads its agent into
> a target VM is the use-case we targeted when we added the attach
> mechanism and the late binding agent support in JDK 6. The issue with
> that (and it's a regret now) is that the mechanism doesn't distinguish
> usage by a tool from a library/application using the attach mechanism to
> load an agent into the current VM (directly or using an intermediate VM).
>
> Time has moved on and maybe a better approach is to not change the XX
> option but instead load the agents with reduced capabilities. It would
> require opt-in on the command line to give these agents the same
> capabilities as agents specified on the command line with -javaagent. It
> would require exploration but it might be that unrecognized agents would
> not be allowed to redefine java.base or other core modules or instrument
> classes in those modules. The APIs are already specified to allow
> Unmodified{Module,Class}Exception be thrown as there have been cases in
> the past where some classes could not be transformed. Project Panama is
> currently exploring how to restrict and grant access to native code and
> maybe it should be the same mechanism or at least be consistent.
>
> Hopefully this helps sets some context as to why we have to be cautious
> with this PR. If the proposal were a defineClass that was limited to
> agents specified on the command line then it might okay. This would
> serve use-cases with tool agents that are way more advanced that the
> use-cases that we envisaged back in Java 5/6. The previous exploration
> into allowing non-public auxiliary classes be defined in the same
> run-time package as the class being instrumented was also okay.
>
> -Alan
>

From github.com+741251+turbanoff at openjdk.java.net  Sun Apr 18 21:19:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 18 Apr 2021 21:19:43 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results [v2]
In-Reply-To: <Nd6utSzkKOGc1ynbZ30UxckmgacySChXLBRT7DGlkA4=.5d00bb70-1150-42bf-8c64-145404c3aa89@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <Nd6utSzkKOGc1ynbZ30UxckmgacySChXLBRT7DGlkA4=.5d00bb70-1150-42bf-8c64-145404c3aa89@github.com>
Message-ID: <9FlgSi92kgB50gCkVQjR4dZd59ob3sl06xql9maRtrM=.fb02966a-b6ad-4a49-b2cc-1c0808fb7217@github.com>

On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 69:

> 67: 
> 68:     /* 10^(E_MIN - 1) <= MIN_VALUE < 10^E_MIN */
> 69:     static final int E_MIN = -323;

It seems that `E_MIN`/`E_MAX`/`K_MIN`/`K_MAX`  are not used in production code. 
I think it worth to move them to tests.

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 117:

> 115:      * where there are H digits d
> 116:      */
> 117:     public final int MAX_CHARS = H + 7;

Can it be made `static` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From winterhalter at openjdk.java.net  Mon Apr 19 09:07:36 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 19 Apr 2021 09:07:36 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <fZSZwg2GhyXAwgdUwTJCmk0MlRdMqpjy_D1GaQoOhGU=.c7fde64f-a906-4b9f-b5dc-fce96dec7a55@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

This won't work as agents are loaded by the system class loader, not the
boot loader.

Peter Levart ***@***.***> schrieb am Mo., 19. Apr. 2021,
11:02:

> From: Alan Bateman
>
> JDK-8200559 is about defining auxiliary classes in the same runtime
> package at load-time whereas I think the proposal in this PR is adding an
> unrestricted defineClass to the Instrumentation class. I think this will
> require a lot of discussion as there are significant issues and concerns
> here. An unrestricted defineClass might be okay for tool/java agents when
> started from the command line with -javaagent but only if the
> Instrumentation object is never ever leaked to library or application code.
> It could potentially be part of a large effort to reduce the capabilities
> of agents loaded via the attach mechanism. More generally I think we need
> clearer separation of the requirements of tool agents from the requirement
> of framework/libraries that want to inject proxy and other classes at
> runtime.
>
> I think it would be easy to limit the use of this Instrumentation method
> to the agent code as agent classes are loaded by the bootstrap classloader.
> Simply make the method implementation caller-sensitive and check the caller
> is from bootstrap class loader. This way Instrumentation instance escaped
> to application code would not give that code any ability to define
> arbitrary classes.
>
> Good enough?
>
> Peter
>
> Separately, the proposal in JEP 410 is to terminally deprecate
> ProtectionDomain.
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/3546#issuecomment-822302347>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABCIA4EYHK5OHTDAN3FKYULTJPWS5ANCNFSM43BSDEGQ>
> .
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From plevart at openjdk.java.net  Mon Apr 19 09:07:36 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 19 Apr 2021 09:07:36 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <z1BWO7tzVjmk5ncypOdZLPB940VWFv72ROQbxaUAUxQ=.37fca341-653c-4cad-a301-927d0bac4f01@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

From: Alan Bateman
> JDK-8200559 is about defining auxiliary classes in the same runtime package at load-time whereas I think the proposal in this PR is adding an unrestricted defineClass to the Instrumentation class. I think this will require a lot of discussion as there are significant issues and concerns here. An unrestricted defineClass might be okay for tool/java agents when started from the command line with -javaagent but only if the Instrumentation object is never ever leaked to library or application code. It could potentially be part of a large effort to reduce the capabilities of agents loaded via the attach mechanism. More generally I think we need clearer separation of the requirements of tool agents from the requirement of framework/libraries that want to inject proxy and other classes at runtime.

I think it would be easy to limit the use of this Instrumentation method to the agent code as agent classes are loaded by the bootstrap classloader. Simply make the method implementation caller-sensitive and check the caller is from bootstrap class loader. This way Instrumentation instance escaped to application code would not give that code any ability to define arbitrary classes.

Good enough?

Peter

> 
> Separately, the proposal in JEP 410 is to terminally deprecate ProtectionDomain.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From plevart at openjdk.java.net  Mon Apr 19 09:14:35 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 19 Apr 2021 09:14:35 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <SNTnP2qTm7kZhK_NZ7KwuFyDx9qHN8BhtLOPG5g0_zM=.d986db18-2d3e-4464-bd99-255438ad32a1@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

> This won't work as agents are loaded by the system class loader, not the boot loader. Peter Levart ***@***.***> schrieb am Mo., 19. Apr. 2021, 11:02:
> [?](#)
> From: Alan Bateman JDK-8200559 is about defining auxiliary classes in the same runtime package at load-time whereas I think the proposal in this PR is adding an unrestricted defineClass to the Instrumentation class. I think this will require a lot of discussion as there are significant issues and concerns here. An unrestricted defineClass might be okay for tool/java agents when started from the command line with -javaagent but only if the Instrumentation object is never ever leaked to library or application code. It could potentially be part of a large effort to reduce the capabilities of agents loaded via the attach mechanism. More generally I think we need clearer separation of the requirements of tool agents from the requirement of framework/libraries that want to inject proxy and other classes at runtime. I think it would be easy to limit the use of this Instrumentation method to the agent code as agent classes are loaded by the bootstrap classloader. Simply make the method imp
 lementation caller-sensitive and check the caller is from bootstrap class loader. This way Instrumentation instance escaped to application code would not give that code any ability to define arbitrary classes. Good enough? Peter Separately, the proposal in JEP 410 is to terminally deprecate ProtectionDomain. ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <[#3546 (comment)](https://github.com/openjdk/jdk/pull/3546#issuecomment-822302347)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCIA4EYHK5OHTDAN3FKYULTJPWS5ANCNFSM43BSDEGQ> .

Ah sorry, I didn't know that. So what about the following: agent is able to define (or load) a class from bootstrap loader. So it would be able to instantiate an intermediary class, loaded by bootstrap loader which would serve as an intermediary to call into this limited Instrumentation API point...
Or better: add a Lookup parameter to the Instrumentation method. The implementation would check that the Lookup is an unrestricted Lookup from a class loaded by bootstrap loader. Agent would just have to take the pain of obtaining such Lookup instance...

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From alanb at openjdk.java.net  Mon Apr 19 09:37:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 19 Apr 2021 09:37:38 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <SNTnP2qTm7kZhK_NZ7KwuFyDx9qHN8BhtLOPG5g0_zM=.d986db18-2d3e-4464-bd99-255438ad32a1@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <SNTnP2qTm7kZhK_NZ7KwuFyDx9qHN8BhtLOPG5g0_zM=.d986db18-2d3e-4464-bd99-255438ad32a1@github.com>
Message-ID: <Zpx5CHTf6tHAzI2koN8d62RHHJ3BUAwD4WtUxS9Rgas=.7458ec57-b243-47fa-9993-87885fb4acea@github.com>

On Mon, 19 Apr 2021 09:11:34 GMT, Peter Levart <plevart at openjdk.org> wrote:

> I think it would be easy to limit the use of this Instrumentation method to the agent code as agent classes are loaded by the bootstrap classloader. Simply make the method implementation caller-sensitive and check the caller is from bootstrap class loader. This way Instrumentation instance escaped to application code would not give that code any ability to define arbitrary classes.

The agent JAR file is added to application class path and is loaded using the system class loader. So almost always the defining loader will be the application class loader.

In general it's a hard problem to try to balance the integrity and security of the platform with the needs of agents that do arbitrary injection and instrumentation. Specifying an agent on the command line with -javaagent is the opt-in to trust that agent and a defineClass that allows arbitrary injection is plausible for that deployment. As Rafael's mentioned in one of the messages, there is enough power in the existing Instrumentation API to do that in a round about way already.

We don't have anything equivalent for agents that are loaded by tools into a target VM. I added the attach mechanism and the dynamic agent loading back in JDK 6 and regret not putting more restrictions around this. As it stands, it is open to mis-use in that an application or library can use the attach mechanism (directly or via the attach API in a child VM) to load an agent and leak the Instrumentation object. This is the genie that somehow needs to be put back in its bottle. One approach that I mentioned here to create is a less powerful Instrumentation object for untrusted agents. Trusted agents would continue to the full-power Instrumentation object.  A less powerful Instrumentation object would not be able to redefine java.base or other core modules and would not be able to retransform classes in those modules. The option on the table during JDK 9 was to disable dynamic loading of agents by default but that was kicked down the road. I don't particularly like that option and I th
 ink we can do better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From cgo at openjdk.java.net  Mon Apr 19 09:49:42 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 19 Apr 2021 09:49:42 GMT
Subject: RFR: 8265421: java/lang/String/StringRepeat.java test is missing a
 memory requirement
Message-ID: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>

Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows:


$ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test


I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available.

-------------

Commit messages:
 - Adds a second test instance which executes the huge repeat count.

Changes: https://git.openjdk.java.net/jdk/pull/3566/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3566&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265421
  Stats: 18 lines in 1 file changed: 13 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3566.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3566/head:pull/3566

PR: https://git.openjdk.java.net/jdk/pull/3566

From bourges.laurent at gmail.com  Mon Apr 19 10:21:38 2021
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Mon, 19 Apr 2021 12:21:38 +0200
Subject: How to know if cpu supports unaligned memory accesses ?
In-Reply-To: <e20df77e-019a-f47a-070c-a9aecf4976f7@oracle.com>
References: <CAKjRUT5S8aP_wve-Sxa0QB0RU093ZZwuQKUDE4y3g0iTaVq81Q@mail.gmail.com>
 <e20df77e-019a-f47a-070c-a9aecf4976f7@oracle.com>
Message-ID: <CAKjRUT4H6LXEC+TEzcsAdXFtBbWHQUZqCTV+it8oKb8k9izYLg@mail.gmail.com>

Thanks, Alan !

Probably I should adopt VarHandle and use their int / long views... (for
jdk11u).

Or adapt my arrays/off-heap buffers (struct like) using primitive objects
JEP 401 for jdk17 !

It looks very promising as the Marlin renderer uses arrays of structs,
packed in arrays or off-heap (edges, rle tile cache).

Cheers,
Laurent

Le dim. 18 avr. 2021 ? 09:11, Alan Bateman <Alan.Bateman at oracle.com> a
?crit :

>
> On 17/04/2021 19:02, Laurent Bourg?s wrote:
> > Hi,
> > In the Marlin renderer & in other Unsafe use cases (pixel tile
> processing)
> > for java2d pipelines, I do use putInt()/putLong() primitives even if the
> > address is not aligned (to 4 or 8 bytes) to get faster processing of byte
> > buffer or arrays...
> >
> > Is it possible in java (jdk internals) to query cpu capabilities like
> > endianness, unaligned support ?
> >
> Since Marlin is in the JDK and using Unsafe already then can't it just
> using the isBigEndian and unalignedAccess methods? The Buffer
> implementation and a few places do the same.
>
> -Alan.
>

From egahlin at openjdk.java.net  Mon Apr 19 10:33:01 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 19 Apr 2021 10:33:01 GMT
Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and
 -XX:FlightRecorderOptions=
Message-ID: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>

Hi,

Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc.

I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. 

Testing: jdk/jdk/jfr, tier 1-4.

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/3561/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3561&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265036
  Stats: 97 lines in 39 files changed: 0 ins; 0 del; 97 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3561/head:pull/3561

PR: https://git.openjdk.java.net/jdk/pull/3561

From pconcannon at openjdk.java.net  Mon Apr 19 10:38:17 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 19 Apr 2021 10:38:17 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v4]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <qcPDAqnJlx0EAJiNJ6cArn0SfaKleRNq8uTGVyJ8p40=.f2acc1ab-96e0-41f4-b8f0-941757fb08b7@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon 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 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 8263668: Update java.time to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/d7355049..6481346a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=02-03

  Stats: 69174 lines in 1873 files changed: 32339 ins; 31989 del; 4846 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170

PR: https://git.openjdk.java.net/jdk/pull/3170

From redestad at openjdk.java.net  Mon Apr 19 10:49:36 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 19 Apr 2021 10:49:36 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v3]
In-Reply-To: <daIGAcPTe4CCltEpNtYQcjVblHW8k9UXZHcl5H3TsdI=.522b8270-9430-470a-a450-5dd967ee67fa@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <daIGAcPTe4CCltEpNtYQcjVblHW8k9UXZHcl5H3TsdI=.522b8270-9430-470a-a450-5dd967ee67fa@github.com>
Message-ID: <uHZyVkG1xFc8w4K0Z0h2EOZ06Pz0BgvdpbDKhcBbCV0=.099d86f9-0f3b-40d9-8409-dc6042f22697@github.com>

On Sun, 18 Apr 2021 19:55:20 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
>> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
>> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
>> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
>> 
>> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
>> 
>> The comparative results are here:
>> 
>> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
>> 
>> The jmh-result.json files are here:
>> 
>> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
>> 
>> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
>> 
>> So WDYT?
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix overflow checking logic, add test for it, avoid branch in loop, add 1-char strings to JHM test

Looks good!

test/micro/org/openjdk/bench/java/util/StringJoinerBenchmark.java line 48:

> 46: @Warmup(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> 47: @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> 48: @Fork(value = 1, jvmArgsAppend = {"-Xms1g", "-Xmx1g"})

In general I think it's prudent to default to at least 3 forks, to catch issues with run-to-run variance.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3501

From jvernee at openjdk.java.net  Mon Apr 19 11:12:57 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 19 Apr 2021 11:12:57 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching [v4]
In-Reply-To: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
Message-ID: <r74LcuV2pcGEXqLDGOI6RgQG_ipoZoXNro9WipVh-6k=.0be194a6-d070-400b-a0ed-c0fdeb991966@github.com>

> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
> 
> This piggybacks on the existing mechanism for method handle invoker caching.
> 
> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Remove manual -ea -esa test flags

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3439/files
  - new: https://git.openjdk.java.net/jdk/pull/3439/files/fa5a721f..0c73b875

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3439&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3439&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3439/head:pull/3439

PR: https://git.openjdk.java.net/jdk/pull/3439

From jvernee at openjdk.java.net  Mon Apr 19 11:12:58 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 19 Apr 2021 11:12:58 GMT
Subject: RFR: 8265079: Implement VarHandle invoker caching [v3]
In-Reply-To: <XD2RSANCtS6j2s1ZP5M3No17N2rc-RaWnmRjSIaPzzE=.f5f47756-8093-42f7-891a-edabdd80ad09@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
 <8YiE6q8ttulbS9HkRmp6YyGgm4yCssfVcMgUASKaIME=.06050e95-3fe0-4456-a4fd-74435be1ac60@github.com>
 <XD2RSANCtS6j2s1ZP5M3No17N2rc-RaWnmRjSIaPzzE=.f5f47756-8093-42f7-891a-edabdd80ad09@github.com>
Message-ID: <wcVjlJCO6AeLu4b2vFcmEgrwPuYV2tJ5hbsGklElJpQ=.74903997-795d-4beb-aa8e-6f58cda37717@github.com>

On Wed, 14 Apr 2021 22:57:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment: simplify test
>
> test/jdk/java/lang/invoke/TestVHInvokerCaching.java line 26:
> 
>> 24: /* @test
>> 25:  * @bug 8265079
>> 26:  * @run testng/othervm -Xverify:all -ea -esa TestVHInvokerCaching
> 
> Nit: the makefile to run jtreg set `-ea -esa`.   It's not strictly necessary in `@run`.  If you want to run it standalone, you can run with `jtreg -ea -esa` option.

Ok, I will remove them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3439

From jvernee at openjdk.java.net  Mon Apr 19 11:39:38 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 19 Apr 2021 11:39:38 GMT
Subject: Integrated: 8265079: Implement VarHandle invoker caching
In-Reply-To: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
References: <AFcxK73-8tm4lISkieyPzu3w_JcAXvYdemtJ7Vl_0xg=.6a77bcf5-600c-4f28-8d97-0bbe401e6cfa@github.com>
Message-ID: <ikYnvHiXIvezwi3bM94SV4pMplgRsqRn70E9DWeIAFY=.013643b1-c91a-424c-abc1-b05888cbbad2@github.com>

On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch implements 2 leftover TODOs for implementing var handle invoker MH caching (lambda forms for those were already shared/cached).
> 
> This piggybacks on the existing mechanism for method handle invoker caching.
> 
> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
> 
> Thanks,
> Jorn

This pull request has now been integrated.

Changeset: c8871487
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c8871487
Stats:     111 lines in 2 files changed: 106 ins; 0 del; 5 mod

8265079: Implement VarHandle invoker caching

Reviewed-by: redestad, vlivanov, psandoz, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/3439

From jlaskey at openjdk.java.net  Mon Apr 19 12:04:51 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 19 Apr 2021 12:04:51 GMT
Subject: RFR: 8265421: java/lang/String/StringRepeat.java test is missing
 a memory requirement
In-Reply-To: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
References: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
Message-ID: <zZvb9jUH_7sDon9nKzhcPPMTyu4saQ0edCwGQ7X3k4w=.dc1f4986-3314-4bae-a579-08c1f7503bf7@github.com>

On Mon, 19 Apr 2021 09:42:09 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows:
> 
> 
> $ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test
> 
> 
> I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3566

From shade at openjdk.java.net  Mon Apr 19 12:10:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 19 Apr 2021 12:10:34 GMT
Subject: RFR: 8265421: java/lang/String/StringRepeat.java test is missing
 a memory requirement
In-Reply-To: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
References: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
Message-ID: <MaOb_XMmh3BnX5zZtMVgR_ksnZ3AsYsdvR-KsIVuq6k=.cebe3bdf-04a2-4b00-9c42-9092cb9655cc@github.com>

On Mon, 19 Apr 2021 09:42:09 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows:
> 
> 
> $ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test
> 
> 
> I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available.

test/jdk/java/lang/String/StringRepeat.java line 27:

> 25:  * @test
> 26:  * @summary This exercises String#repeat patterns and limits.
> 27:  * @run main/othervm -Xmx2g StringRepeat

So, does `-Xmx2g` make sense in this configuration now?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3566

From cgo at openjdk.java.net  Mon Apr 19 12:50:07 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 19 Apr 2021 12:50:07 GMT
Subject: RFR: 8265421: java/lang/String/StringRepeat.java test is missing
 a memory requirement [v2]
In-Reply-To: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
References: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
Message-ID: <C4HSfgW-mgXI0-I8ohvSAaHfE7hyS4Za0tvIFPEbiSk=.8fad7187-b14f-4476-a8bc-09b77ed25c9b@github.com>

> Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows:
> 
> 
> $ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test
> 
> 
> I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available.

Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:

  Removes -Xmx2g for the first test case instance, which doesn't require a lot of memory.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3566/files
  - new: https://git.openjdk.java.net/jdk/pull/3566/files/e113ae08..4a2b04a7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3566&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3566&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3566.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3566/head:pull/3566

PR: https://git.openjdk.java.net/jdk/pull/3566

From cgo at openjdk.java.net  Mon Apr 19 12:50:08 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 19 Apr 2021 12:50:08 GMT
Subject: RFR: 8265421: java/lang/String/StringRepeat.java test is missing
 a memory requirement [v2]
In-Reply-To: <MaOb_XMmh3BnX5zZtMVgR_ksnZ3AsYsdvR-KsIVuq6k=.cebe3bdf-04a2-4b00-9c42-9092cb9655cc@github.com>
References: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
 <MaOb_XMmh3BnX5zZtMVgR_ksnZ3AsYsdvR-KsIVuq6k=.cebe3bdf-04a2-4b00-9c42-9092cb9655cc@github.com>
Message-ID: <14ObZA4mkzPkZxT2GdsWN-nCivKGxAkdE6cEVROzI0c=.abd43dca-6806-402b-bd36-fb7dc444c4b2@github.com>

On Mon, 19 Apr 2021 12:07:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes -Xmx2g for the first test case instance, which doesn't require a lot of memory.
>
> test/jdk/java/lang/String/StringRepeat.java line 27:
> 
>> 25:  * @test
>> 26:  * @summary This exercises String#repeat patterns and limits.
>> 27:  * @run main/othervm -Xmx2g StringRepeat
> 
> So, does `-Xmx2g` make sense in this configuration now?

No, not really. The first test case instance should require way less than 1G of memory, so I will just remove the heap configuration for that instance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3566

From herrick at openjdk.java.net  Mon Apr 19 12:55:45 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 19 Apr 2021 12:55:45 GMT
Subject: RFR: 8265152: jpackage cleanup fails on Windows with IOException
 deleting msi
In-Reply-To: <5kVIe79iAW3K6erYsi9jIGuzXQRTPtCSDZnEludo_z0=.8d766457-d8c8-4f1c-9813-c87165694edd@github.com>
References: <5kVIe79iAW3K6erYsi9jIGuzXQRTPtCSDZnEludo_z0=.8d766457-d8c8-4f1c-9813-c87165694edd@github.com>
Message-ID: <PNHLC2me6cfTe1O1B9xYc-3Pd96rh_RQWtkGLGOFzo8=.a7158e03-7b5d-40fa-8db3-8c46909ecb30@github.com>

On Sun, 18 Apr 2021 12:44:17 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When creating an "exe" installer on Windows, `AbstractBundler.cleanup()` calls `IOUtils.deleteRecursive()` to delete the tmp directory. It can intermittently fail trying to delete the msi file.
> 
> [JDK-8263135](https://bugs.openjdk.java.net/browse/JDK-8263135) removed `unique_ptr` from jpackage sources due to compiler warnings in VS 2019 (16.9.0), so we need to release the resource manually. However `DatabaseView` didn't do that.

thanks - works like a charm

-------------

Marked as reviewed by herrick (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3560

From jlaskey at openjdk.java.net  Mon Apr 19 12:59:38 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 19 Apr 2021 12:59:38 GMT
Subject: RFR: 8265421: java/lang/String/StringRepeat.java test is missing
 a memory requirement [v2]
In-Reply-To: <C4HSfgW-mgXI0-I8ohvSAaHfE7hyS4Za0tvIFPEbiSk=.8fad7187-b14f-4476-a8bc-09b77ed25c9b@github.com>
References: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
 <C4HSfgW-mgXI0-I8ohvSAaHfE7hyS4Za0tvIFPEbiSk=.8fad7187-b14f-4476-a8bc-09b77ed25c9b@github.com>
Message-ID: <Hm-9GSgjm7v-K0HAPkiTQOAS7YOQ7M_KYSTPJnTTIos=.83449910-9fa0-4fd2-8081-5557bdb29e0b@github.com>

On Mon, 19 Apr 2021 12:50:07 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows:
>> 
>> 
>> $ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test
>> 
>> 
>> I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available.
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes -Xmx2g for the first test case instance, which doesn't require a lot of memory.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3566

From herrick at openjdk.java.net  Mon Apr 19 13:21:35 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 19 Apr 2021 13:21:35 GMT
Subject: RFR: 8263154: [macos] DMG builds have finder errors
In-Reply-To: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
References: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
Message-ID: <gdYJff7wKR0PVbw5Q4nWeSM_MZsgpuST9v0Uo8Z-Hks=.da02021d-6e95-4096-b806-e7debf99a18d@github.com>

On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Issue was reproducible when install-dir points to some invalid location.
>  - Fixed by defaulting DMG drag and drop location to /Applications folder and --install-dir will be ignored with warning for DMG.
>  - I do not see any way to support other valid, but uncommon locations for drag and drop. For example: /Users/USERNAME/Applications is not possible to support since user name is not known. /usr/bin requires root privileges and should contain symbolic links. Locations which does not exist also not possible to support, since DMG cannot create paths. So /Applications/MyCompany is not possible for DMG.

It's my feeling that there should probably be no stdout/stderr from the jpackage tool other than what is specified (--help, --version, and hard errors).  If that is consensus we should also change the warnings about foreign app-image to Log.verbose, if not we can leave this Log.info() as is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3505

From shade at openjdk.java.net  Mon Apr 19 14:05:46 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 19 Apr 2021 14:05:46 GMT
Subject: RFR: 8265421: java/lang/String/StringRepeat.java test is missing
 a memory requirement [v2]
In-Reply-To: <C4HSfgW-mgXI0-I8ohvSAaHfE7hyS4Za0tvIFPEbiSk=.8fad7187-b14f-4476-a8bc-09b77ed25c9b@github.com>
References: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
 <C4HSfgW-mgXI0-I8ohvSAaHfE7hyS4Za0tvIFPEbiSk=.8fad7187-b14f-4476-a8bc-09b77ed25c9b@github.com>
Message-ID: <GRx1T2VtiLCskT5PNs9vjDG0rtT6UYB2JqifJ3rn5x4=.ea46dc80-e600-4792-ad4b-ea6b98aab12d@github.com>

On Mon, 19 Apr 2021 12:50:07 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows:
>> 
>> 
>> $ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test
>> 
>> 
>> I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available.
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes -Xmx2g for the first test case instance, which doesn't require a lot of memory.

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3566

From plevart at openjdk.java.net  Mon Apr 19 14:10:34 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 19 Apr 2021 14:10:34 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <Zpx5CHTf6tHAzI2koN8d62RHHJ3BUAwD4WtUxS9Rgas=.7458ec57-b243-47fa-9993-87885fb4acea@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <SNTnP2qTm7kZhK_NZ7KwuFyDx9qHN8BhtLOPG5g0_zM=.d986db18-2d3e-4464-bd99-255438ad32a1@github.com>
 <Zpx5CHTf6tHAzI2koN8d62RHHJ3BUAwD4WtUxS9Rgas=.7458ec57-b243-47fa-9993-87885fb4acea@github.com>
Message-ID: <WIkQOEKG9PGOWsQmSoxmpy6IhmgHdmUsrdGUBIvcuo4=.681882bb-3c78-4be7-bd5f-4d5c9392981d@github.com>

On Mon, 19 Apr 2021 09:34:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> an application or library can use the attach mechanism (directly or via the attach API in a child VM) to load an agent and leak the Instrumentation object. This is the genie that somehow needs to be put back in its bottle. One approach that I mentioned here to create is a less powerful Instrumentation object for untrusted agents. Trusted agents would continue to the full-power

I hear Rafael that dynamic attach is important to support monitoring and instrumenting large numbers of JVMs with no preparations (i.e. without issueing special command-line options to enable it). As I understand, current attach mechanism is designed to allow a process running under the same UID as the JVM or under root to attach to the JVM.

What if this dynamic attach mechanism was modified so that only a process running under root could dynamically attach to the JVM? Old behavior would be enabled by special command line option, so by default, dynamic attach would be limited to tools running under root. Rafael mentions discovery, monitoring and instrumenting large number of JVMs running on hosts, so if one such tool has to attach to different JVMs running under different UIDs, it has to run as root now anyway.

With such default "secure" dynamic attach and when the JVM is not running as root (which is a recommended security practice anyway), a library in such JVM could not attach back to the same JVM even through spawning sub-processes.

How to achieve such "secure" dynamic attach? One way that comes to mind is a modified handshake. Currently, I think at least on Linux, the tool that wishes to attach to the JVM searches for a special UNIX socket (`$PWD/.java_pid<vmid>`, `/tmp/.java_pid<vmid>`) and if not found, creates a special attach file (`$PWD/.attach_pid<vmid>`, `/tmp/.attach_pid<vmid>`) to signal the JVM to create a listening UNIX socket under mentioned special path, then it connects to the socket. The UNIX socket file has UID:GID set to effective UID:GID of the JVM process and permissions to 0600, so only a tool running under same UID or root can connect to such socket.

In modified handshake, JVM not running as root could not create a UNIX socket file with permissions to allow only root user to connect to it, but a tool running under root could create a listening UNIX socket with permission to allow JVM to connect to it in a way that the JVM connecting to such socket would know that the listening process is running as root. Simply by checking the owner of the listening UNIX socket file. Such socket file would have to have permission 0666 in order to allow JVMs running under any UID to connect to it, but otherwise be "hidden". This can be achieved by the tool creating a special directory and a UNIX socket in this directory, say: `/tmp/.attach_dir<tool pid>/<random string>`, The directory UID:GID would be 0:0 and have permission 0711. This means, any user could connect to the socket as long as it knows the `<random string>`, but no user but root can list the content of the directory to discover the name of the socket file. The last piece of the puzzle
  is how to signal to the JVM about the name of the socket file. Well, creating a file with the content holding the name of the socket file would be OK, as long as only target JVM could read it. File permissions could be set such that any process running under the same UID as the JVM could read the file. This would give a rouge library a chance to connect to the tool and pretend to be the monitoring JVM, but it could not connect to back to the JVM though...

WDYT?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From github.com+10835776+stsypanov at openjdk.java.net  Mon Apr 19 14:12:55 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 19 Apr 2021 14:12:55 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName()
Message-ID: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>

As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null.

-------------

Commit messages:
 - 8265418: Clean-up redundant null-checks of Class.getPackageName()

Changes: https://git.openjdk.java.net/jdk/pull/3571/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3571&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265418
  Stats: 19 lines in 7 files changed: 1 ins; 8 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3571.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3571/head:pull/3571

PR: https://git.openjdk.java.net/jdk/pull/3571

From redestad at openjdk.java.net  Mon Apr 19 14:39:36 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 19 Apr 2021 14:39:36 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
Message-ID: <tIFpa3SaShezNNGF8rcCh5VB_859OjHvmYnyVdplxzs=.b54dad85-d322-4bc9-b222-441e312de858@github.com>

On Mon, 19 Apr 2021 14:05:31 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null.

Looks good to me!

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3571

From redestad at openjdk.java.net  Mon Apr 19 14:44:36 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 19 Apr 2021 14:44:36 GMT
Subject: RFR: 8265135: Reduce work initializing VarForms [v5]
In-Reply-To: <ZpNBhw2mHzECAK_v7CXNHY1SEz6J7gKZXx-a7FQVpw4=.c242e98f-c465-4c65-b24c-292ef3a97875@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
 <ZpNBhw2mHzECAK_v7CXNHY1SEz6J7gKZXx-a7FQVpw4=.c242e98f-c465-4c65-b24c-292ef3a97875@github.com>
Message-ID: <OInQ8igOFNpsR1UQxmNQ5jVU5-VkivjPnz1AKS3esmk=.1b8330c8-5e29-4d31-a2fc-acca93cf2e76@github.com>

On Wed, 14 Apr 2021 21:26:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
>> 
>> - Lazily resolve MemberNames.
>> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
>> 
>> Net effect is a reduction in bytecode executed per VH class by 50-60%.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add resolveOrNull for exploded MemberName

Thanks for reviewing, Mandy and Paul

-------------

PR: https://git.openjdk.java.net/jdk/pull/3472

From redestad at openjdk.java.net  Mon Apr 19 14:44:36 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 19 Apr 2021 14:44:36 GMT
Subject: Integrated: 8265135: Reduce work initializing VarForms
In-Reply-To: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
References: <4GSs6OUxlVeo4GkU7gwVHtWa3VfSPwVAjKFtvk3IoHw=.a6c7169e-8787-4c06-b78b-d56b8ee8465e@github.com>
Message-ID: <13Gg9RhHaOqGxh4q_27OwtMWlQj8hnSkaaZP0Uyhl-Y=.e193a39d-c438-4bee-9350-86c6c1c126f0@github.com>

On Tue, 13 Apr 2021 18:11:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch reduces work done initializing VarForms - mostly observed when loading each VarHandle implementation class.
> 
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes created. 
> 
> Net effect is a reduction in bytecode executed per VH class by 50-60%.

This pull request has now been integrated.

Changeset: 5303ccb8
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5303ccb8
Stats:     103 lines in 3 files changed: 54 ins; 38 del; 11 mod

8265135: Reduce work initializing VarForms

Reviewed-by: psandoz, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/3472

From alanb at openjdk.java.net  Mon Apr 19 14:48:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 19 Apr 2021 14:48:38 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
Message-ID: <CNby1eR4i4aQoSuqcr5tgnePbh1jXUXDF28PdrPZQM8=.0b9404aa-276c-435b-a8e7-3a6fda21b2d8@github.com>

On Mon, 19 Apr 2021 14:05:31 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 458:

> 456:         private static boolean isSamePackage(Class<?> class1, Class<?> class2) {
> 457:             return class1.getClassLoader() == class2.getClassLoader()
> 458:                    && class1.getPackageName().equals(class2.getPackageName());

If the j.u.c.atomic code is changed then it will need to be coordinated with Doug Lea's repo. The rest of the changes are good and thanks for following up from the comments in the other issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3571

From github.com+10835776+stsypanov at openjdk.java.net  Mon Apr 19 15:06:40 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 19 Apr 2021 15:06:40 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <CNby1eR4i4aQoSuqcr5tgnePbh1jXUXDF28PdrPZQM8=.0b9404aa-276c-435b-a8e7-3a6fda21b2d8@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
 <CNby1eR4i4aQoSuqcr5tgnePbh1jXUXDF28PdrPZQM8=.0b9404aa-276c-435b-a8e7-3a6fda21b2d8@github.com>
Message-ID: <4rfI8EQpIjApUBQswdVRfz8M2kFUtx2hch0oYyiaXAc=.60e2638d-2de8-41c0-a695-11643d0432f3@github.com>

On Mon, 19 Apr 2021 14:45:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null.
>
> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 458:
> 
>> 456:         private static boolean isSamePackage(Class<?> class1, Class<?> class2) {
>> 457:             return class1.getClassLoader() == class2.getClassLoader()
>> 458:                    && class1.getPackageName().equals(class2.getPackageName());
> 
> If the j.u.c.atomic code is changed then it will need to be coordinated with Doug Lea's repo. The rest of the changes are good and thanks for following up from the comments in the other issue.

Hello, how should I do it? Maybe we can just mention him here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3571

From fguallini at openjdk.java.net  Mon Apr 19 15:13:04 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Mon, 19 Apr 2021 15:13:04 GMT
Subject: RFR: 8183374: Refactor java/lang/Runtime shell tests to java
Message-ID: <8RGdfm-WomCVRb2rHh4JJylflepR5_FC0zsMvMznlDc=.7cf373c7-9ecc-48b7-9ae8-033fc39d2527@github.com>

Refactor the following shell tests to java:
test/jdk/java/lang/RuntimeTests/shutdown/ShutdownHooks.sh
test/jdk/java/lang/Runtime/exec/SetCwd.java

In addition, the test SetCwd was running itself in separate java subprocesses in order to exercise Runtime.exec. It was creating a folder structure with multiple test class copies to distinguish between main and child processes to prevent an infinite recursion. That logic is simplified now, tests follow the testng annotations flow whereas the subprocesses entry point is a nested class main

-------------

Commit messages:
 - Merge branch 'master' of github.com:openjdk/jdk into 8183374
 - refactor ShutdownHooks and SetCwd

Changes: https://git.openjdk.java.net/jdk/pull/3572/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3572&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8183374
  Stats: 232 lines in 4 files changed: 67 ins; 121 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3572/head:pull/3572

PR: https://git.openjdk.java.net/jdk/pull/3572

From Alan.Bateman at oracle.com  Mon Apr 19 15:18:15 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 Apr 2021 16:18:15 +0100
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <WIkQOEKG9PGOWsQmSoxmpy6IhmgHdmUsrdGUBIvcuo4=.681882bb-3c78-4be7-bd5f-4d5c9392981d@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <SNTnP2qTm7kZhK_NZ7KwuFyDx9qHN8BhtLOPG5g0_zM=.d986db18-2d3e-4464-bd99-255438ad32a1@github.com>
 <Zpx5CHTf6tHAzI2koN8d62RHHJ3BUAwD4WtUxS9Rgas=.7458ec57-b243-47fa-9993-87885fb4acea@github.com>
 <WIkQOEKG9PGOWsQmSoxmpy6IhmgHdmUsrdGUBIvcuo4=.681882bb-3c78-4be7-bd5f-4d5c9392981d@github.com>
Message-ID: <9988c09f-2c0f-87e9-a936-32c878daf778@oracle.com>

On 19/04/2021 15:10, Peter Levart wrote:
> :
> I hear Rafael that dynamic attach is important to support monitoring and instrumenting large numbers of JVMs with no preparations (i.e. without issueing special command-line options to enable it). As I understand, current attach mechanism is designed to allow a process running under the same UID as the JVM or under root to attach to the JVM.
>
> What if this dynamic attach mechanism was modified so that only a process running under root could dynamically attach to the JVM? Old behavior would be enabled by special command line option, so by default, dynamic attach would be limited to tools running under root. Rafael mentions discovery, monitoring and instrumenting large number of JVMs running on hosts, so if one such tool has to attach to different JVMs running under different UIDs, it has to run as root now anyway.
>
> With such default "secure" dynamic attach and when the JVM is not running as root (which is a recommended security practice anyway), a library in such JVM could not attach back to the same JVM even through spawning sub-processes.
>
> How to achieve such "secure" dynamic attach? One way that comes to mind 
is a modified handshake. Currently, I think at least on Linux, the tool that wishes to attach to the JVM searches for a special UNIX socket (`$PWD/.java_pid<vmid>`, `/tmp/.java_pid<vmid>`) and if not found, creates a special attach file (`$PWD/.attach_pid<vmid>`, `/tmp/.attach_pid<vmid>`) to 
signal the JVM to create a listening UNIX socket under mentioned special path, then it connects to the socket. The UNIX socket file has UID:GID set to effective UID:GID of the JVM process and permissions to 0600, so only a tool running under same UID or root can connect to such socket.
>
> In modified handshake, JVM not running as root could not create a UNIX socket file with permissions to allow only root user to connect to it, but a tool running under root could create a listening UNIX socket with permission to allow JVM to connect to it in a way that the JVM connecting to 
such socket would know that the listening process is running as root. Simply by checking the owner of the listening UNIX socket file. Such socket file would have to have permission 0666 in order to allow JVMs running under any UID to connect to it, but otherwise be "hidden". This can be achieved by the tool creating a special directory and a UNIX socket in this directory, say: `/tmp/.attach_dir<tool pid>/<random string>`, The directory UID:GID would be 0:0 and have permission 0711. This means, any user could connect to the socket as long as it knows the `<random string>`, but no user but root can list the content of the directory to discover the name of the socket file. The last piece of the puzzle
>    is how to signal to the JVM about the name of the socket file. Well, 
creating a file with the content holding the name of the socket file would be OK, as long as only target JVM could read it. File permissions could 
be set such that any process running under the same UID as the JVM could read the file. This would give a rouge library a chance to connect to the 
tool and pretend to be the monitoring JVM, but it could not connect to back to the JVM though...
>

One initial comment is that the attach mechanism is also used for the 
troubleshooting tools (jcmd, jstack, jmap, ...). This is how tools start 
the JMX agent in the target VM, or request a stack trace or heap dump, 
to name a few. It's just the loading of JVMTI agents that would need to 
be restricted (Java agents use the JPLIS JVMTI agent).

A second comment is that the attach mechanism on Linux and macOS is 
based on Unix domain sockets and the effective uid/gid of the peer is 
available. So if you are exploring here then you should be able to just 
use that rather than changing the handshake. The Windows implementation 
injects a stub into the target VM to queue the command so there isn't 
the equivalent.

-Alan



From stuart.marks at oracle.com  Mon Apr 19 15:41:11 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 19 Apr 2021 08:41:11 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
Message-ID: <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>



On 4/17/21 9:49 AM, Remi Forax wrote:
> I think the analysis is spot on but I don't think the proposed solution is the right one.
> 
> Introducing a new interface (two in this case) has a really huge cost and in this case, i've trouble to see why i will want to write a method that takes a ReversibleCollection as parameter, ReversibleCollection as a type does not seem to be useful. About the cost of introducing a new collection interface, it means that we also have to update all emptyXXX, singleXXX, uncheckedXXX with a new interface, and that only for the JDK. Every libraries that proxy collections has also to be updated to take care of this new type, otherwise the integration with an application that uses this new type and the library is not seamless anymore.

Hi Remi,

Thanks for looking at this. There are several issues intertwined here, so let's try 
to break it down.

There are a bunch of factory methods emptyX, singletonX, etc. that give instances of 
particular types. As Tagir noted, List is a ReversibleCollection, so you can just 
use emptyList or List.of or whatever if you need an instance of 
ReversibleCollection. Also, SortedSet/NavigableSet are ReversibleSets, so if you 
need an empty ReversibleSet, you can use Collections.emptyNavigableSet. There's no 
singletonNavigableSet, but you could do

     Collections.unmodifiableNavigableSet(new TreeSet<>(List.of(x)))

which is a bit of a mouthful, but it's possible. (The fact that there's no 
Collections.singletonNavigableSet may mean this use case is so narrow that few 
people really needed it.)

As for the wrappers, synchronizedX and checkedX are mostly disused, so I don't see a 
need to provide those wrappers. Having unmodifiable RC and RS is probably useful, so 
I could see adding those. That's a certain amount of work, but not a tremendous cost.

> All these methods can be introduced has default methods on the existing collection interfaces, there is no need of a special interface (or two) for that.

Clearly it's possible to get by without new interfaces. After all the collections 
framework has gotten by without them for 20+ years already. It's certainly possible 
to fill out the individual interfaces (List, Deque, Sorted/NavSet) and classes 
(LinkedHashSet, LinkedHashMap) with methods that are all similar to each other, and 
that would be useful. Or as Peter Levart pointed out, we could push all of them up 
to Collection and write the specs in a loose enough way to encompass even unordered 
collections.

Any of those alternatives (do nothing, add individual methods, add loosely-spec'd 
methods to Collection) are *possible* to do. However, I think you know how minimal 
we are with the JDK APIs, and we wouldn't have proposed new interfaces without good 
cause. Thus, I think introducing new *types* here is useful, for the following reasons.

  * There's a useful clump of semantics here, combined with sensible operations that 
rely on those semantics. There are a lot of places in the spec where there is 
hedging of the form "if the collection has an ordering, then... otherwise the 
results are undefined". This is unnecessary in the context of a new type. 
Furthermore, the new operations fit well with the new types' semantics, with no 
hedging necessary.

  * These semantics appear across a broad range of existing collection types and 
implementations. It's quite valuable to have a type that unifies the common pieces 
of List, Deque, SortedSet, and LinkedHashSet into a single abstraction.

  * It's useful to have a new type for parameters in APIs. There are times when one 
wants to accept something like a List -or- a LinkedHashSet. Typically one would 
accept a Collection and then write a spec with hedging as above ("the argument 
collection must have a defined ordering"). But this also allows bugs, for example if 
somebody accidentally passes a HashSet. Having ReversibleCollection helps this problem.

  * It's useful to have a new type for return types in APIs. Consider 
LinkedHashMap's entrySet, keySet, and values views. While we clearly get by with 
having these return Set or Collection today, we need a place to put the new methods. 
Either they go on Collection (and have extremely weak semantics) or we define new 
interfaces.

  * It's a useful interface for new collection implementations. There are data 
structures that are ordered, double-ended, and reversible, but for which 
implementing List is too onerous. Supporting int indexes in various List APIs is 
where stumbling blocks usually occur. I note that the LinkedHashMap view collections 
are examples of this that already exist in the prototype code. (Other possibilities 
might be something like SpinedBuffer or chunked linked lists.)

In general, I agree that there should be strict criteria for introducing new 
interfaces into collections, but I think this proposal meets them.

s'marks

From rriggs at openjdk.java.net  Mon Apr 19 15:50:44 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 19 Apr 2021 15:50:44 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v4]
In-Reply-To: <qcPDAqnJlx0EAJiNJ6cArn0SfaKleRNq8uTGVyJ8p40=.f2acc1ab-96e0-41f4-b8f0-941757fb08b7@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <qcPDAqnJlx0EAJiNJ6cArn0SfaKleRNq8uTGVyJ8p40=.f2acc1ab-96e0-41f4-b8f0-941757fb08b7@github.com>
Message-ID: <5fRAroNJRKwOzQ_i7zcWDkDYJ2xcIVB-4p1tDtTHgKQ=.c82afb9a-d0a7-4915-a3f4-e1958253bb68@github.com>

On Mon, 19 Apr 2021 10:38:17 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon 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 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 8263668: Update java.time to use instanceof pattern variable

I generally concur with `forax` about avoiding the use of single letter variables.

src/java.base/share/classes/java/time/Duration.java line 1435:

> 1433:                 && this.seconds == other.seconds
> 1434:                 && this.nanos == other.nanos;
> 1435:     }

Perhaps rename the argument and use `otherDuration` as the refinement.
Otherwise, an inconsistency across various classes will creep in where the more specific variable has a more general name.  In this case, the argument type is Object, so the argument name `otherDuration` is not strictly true.

src/java.base/share/classes/java/time/Instant.java line 1306:

> 1304:                 && this.seconds == other.seconds
> 1305:                 && this.nanos == other.nanos;
> 1306:     }

Ditto, `otherInstance` is not strictly always an instant and it would be more consistent to swap the names.
`(other instanceof Instant otherInstant)`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From ryadav at openjdk.java.net  Mon Apr 19 16:13:53 2021
From: ryadav at openjdk.java.net (Rahul Yadav)
Date: Mon, 19 Apr 2021 16:13:53 GMT
Subject: RFR: 8265421: java/lang/String/StringRepeat.java test is missing
 a memory requirement [v2]
In-Reply-To: <C4HSfgW-mgXI0-I8ohvSAaHfE7hyS4Za0tvIFPEbiSk=.8fad7187-b14f-4476-a8bc-09b77ed25c9b@github.com>
References: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
 <C4HSfgW-mgXI0-I8ohvSAaHfE7hyS4Za0tvIFPEbiSk=.8fad7187-b14f-4476-a8bc-09b77ed25c9b@github.com>
Message-ID: <olzlMMipaBO6ZYfTHK27NaL-E7sGON_5MWa-oEkg10Y=.01a8c7c8-b325-4ee8-9bab-240df62dfb0b@github.com>

On Mon, 19 Apr 2021 12:50:07 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows:
>> 
>> 
>> $ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test
>> 
>> 
>> I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available.
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes -Xmx2g for the first test case instance, which doesn't require a lot of memory.

Marked as reviewed by ryadav (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3566

From raffaello.giulietti at gmail.com  Mon Apr 19 16:18:11 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 19 Apr 2021 18:18:11 +0200
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results [v2]
In-Reply-To: <9FlgSi92kgB50gCkVQjR4dZd59ob3sl06xql9maRtrM=.fb02966a-b6ad-4a49-b2cc-1c0808fb7217@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <Nd6utSzkKOGc1ynbZ30UxckmgacySChXLBRT7DGlkA4=.5d00bb70-1150-42bf-8c64-145404c3aa89@github.com>
 <9FlgSi92kgB50gCkVQjR4dZd59ob3sl06xql9maRtrM=.fb02966a-b6ad-4a49-b2cc-1c0808fb7217@github.com>
Message-ID: <04924c65-b22a-e452-f2a5-cec419b412f0@gmail.com>

Hi Andrey,

thanks for your careful reading.

I'll keep a note and collect yours with changes coming from other 
reviewers before committing a larger batch of small changes. I would 
like to avoid wasting a lot of energy right now just to rebuild 
everything and to run the automatic tests on GitHub :-)


Greetings
Raffaello


On 2021-04-18 23:19, Andrey Turbanov wrote:
> On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> 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
> 
> src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 69:
> 
>> 67:
>> 68:     /* 10^(E_MIN - 1) <= MIN_VALUE < 10^E_MIN */
>> 69:     static final int E_MIN = -323;
> 
> It seems that `E_MIN`/`E_MAX`/`K_MIN`/`K_MAX`  are not used in production code.
> I think it worth to move them to tests.
> 
> src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 117:
> 
>> 115:      * where there are H digits d
>> 116:      */
>> 117:     public final int MAX_CHARS = H + 7;
> 
> Can it be made `static` ?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3402
> 

From asemenyuk at openjdk.java.net  Mon Apr 19 17:04:34 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 19 Apr 2021 17:04:34 GMT
Subject: RFR: 8265152: jpackage cleanup fails on Windows with IOException
 deleting msi
In-Reply-To: <5kVIe79iAW3K6erYsi9jIGuzXQRTPtCSDZnEludo_z0=.8d766457-d8c8-4f1c-9813-c87165694edd@github.com>
References: <5kVIe79iAW3K6erYsi9jIGuzXQRTPtCSDZnEludo_z0=.8d766457-d8c8-4f1c-9813-c87165694edd@github.com>
Message-ID: <EXLJLhTQxx1DQPiG6pI1KN8YvonQpwc0EIIsxj8Wug8=.a09b94c5-93c5-47b9-8310-e993806ebc97@github.com>

On Sun, 18 Apr 2021 12:44:17 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When creating an "exe" installer on Windows, `AbstractBundler.cleanup()` calls `IOUtils.deleteRecursive()` to delete the tmp directory. It can intermittently fail trying to delete the msi file.
> 
> [JDK-8263135](https://bugs.openjdk.java.net/browse/JDK-8263135) removed `unique_ptr` from jpackage sources due to compiler warnings in VS 2019 (16.9.0), so we need to release the resource manually. However `DatabaseView` didn't do that.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3560

From herrick at openjdk.java.net  Mon Apr 19 17:29:36 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 19 Apr 2021 17:29:36 GMT
Subject: RFR: 8263154: [macos] DMG builds have finder errors
In-Reply-To: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
References: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
Message-ID: <xLay45KaEKHnDjWV7UKkhoV-0vCoUFQgae9CtkliiRY=.b43379d5-5074-4169-b2f2-dcae3387a593@github.com>

On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Issue was reproducible when install-dir points to some invalid location.
>  - Fixed by defaulting DMG drag and drop location to /Applications folder and --install-dir will be ignored with warning for DMG.
>  - I do not see any way to support other valid, but uncommon locations for drag and drop. For example: /Users/USERNAME/Applications is not possible to support since user name is not known. /usr/bin requires root privileges and should contain symbolic links. Locations which does not exist also not possible to support, since DMG cannot create paths. So /Applications/MyCompany is not possible for DMG.

Consensus is to leave as Log.info() - so all looks good.

-------------

Marked as reviewed by herrick (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3505

From asemenyuk at openjdk.java.net  Mon Apr 19 17:42:37 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 19 Apr 2021 17:42:37 GMT
Subject: RFR: 8263154: [macos] DMG builds have finder errors
In-Reply-To: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
References: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
Message-ID: <NMnuUVl-f4G5_vY58okDsNVLC11_pTWDxloevH1LBsA=.598aca9c-7555-4f18-be1d-4f00da21e76b@github.com>

On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Issue was reproducible when install-dir points to some invalid location.
>  - Fixed by defaulting DMG drag and drop location to /Applications folder and --install-dir will be ignored with warning for DMG.
>  - I do not see any way to support other valid, but uncommon locations for drag and drop. For example: /Users/USERNAME/Applications is not possible to support since user name is not known. /usr/bin requires root privileges and should contain symbolic links. Locations which does not exist also not possible to support, since DMG cannot create paths. So /Applications/MyCompany is not possible for DMG.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3505

From almatvee at openjdk.java.net  Mon Apr 19 18:21:24 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 19 Apr 2021 18:21:24 GMT
Subject: Integrated: 8263154: [macos] DMG builds have finder errors
In-Reply-To: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
References: <IScwvdL3nIO3_yi7vJ2KYWJK2l0KuqOU9jlTFsTtvXI=.a3dcb66c-8c28-43b5-8213-72b7f82b0032@github.com>
Message-ID: <pghKp0Q-FMZmVGjx4cCOT8vxzbpejgl9DEwaqrpC5GM=.676674eb-30f2-4306-9ad7-ea84a9525270@github.com>

On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Issue was reproducible when install-dir points to some invalid location.
>  - Fixed by defaulting DMG drag and drop location to /Applications folder and --install-dir will be ignored with warning for DMG.
>  - I do not see any way to support other valid, but uncommon locations for drag and drop. For example: /Users/USERNAME/Applications is not possible to support since user name is not known. /usr/bin requires root privileges and should contain symbolic links. Locations which does not exist also not possible to support, since DMG cannot create paths. So /Applications/MyCompany is not possible for DMG.

This pull request has now been integrated.

Changeset: 5b43b39e
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5b43b39e
Stats:     18 lines in 6 files changed: 7 ins; 0 del; 11 mod

8263154: [macos] DMG builds have finder errors

Reviewed-by: herrick, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/3505

From plevart at openjdk.java.net  Mon Apr 19 18:25:06 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 19 Apr 2021 18:25:06 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v3]
In-Reply-To: <uHZyVkG1xFc8w4K0Z0h2EOZ06Pz0BgvdpbDKhcBbCV0=.099d86f9-0f3b-40d9-8409-dc6042f22697@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <daIGAcPTe4CCltEpNtYQcjVblHW8k9UXZHcl5H3TsdI=.522b8270-9430-470a-a450-5dd967ee67fa@github.com>
 <uHZyVkG1xFc8w4K0Z0h2EOZ06Pz0BgvdpbDKhcBbCV0=.099d86f9-0f3b-40d9-8409-dc6042f22697@github.com>
Message-ID: <OWQ_wubcWbTy_8H5zoLw1_eBURuxuxLS68-jJJwEvqA=.7b3142cd-9eea-46cd-8270-bb71769e99a9@github.com>

On Mon, 19 Apr 2021 10:44:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix overflow checking logic, add test for it, avoid branch in loop, add 1-char strings to JHM test
>
> test/micro/org/openjdk/bench/java/util/StringJoinerBenchmark.java line 48:
> 
>> 46: @Warmup(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> 47: @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> 48: @Fork(value = 1, jvmArgsAppend = {"-Xms1g", "-Xmx1g"})
> 
> In general I think it's prudent to default to at least 3 forks, to catch issues with run-to-run variance.

Thanks, Claes. Will change that to 3 forks before pushing.
Any more comments? Will wait for a day, then push it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From rriggs at openjdk.java.net  Mon Apr 19 18:31:11 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 19 Apr 2021 18:31:11 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v3]
In-Reply-To: <daIGAcPTe4CCltEpNtYQcjVblHW8k9UXZHcl5H3TsdI=.522b8270-9430-470a-a450-5dd967ee67fa@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
 <daIGAcPTe4CCltEpNtYQcjVblHW8k9UXZHcl5H3TsdI=.522b8270-9430-470a-a450-5dd967ee67fa@github.com>
Message-ID: <LhEJbo2heNk3BdRgdfor2nSV12vHAWQejAD7ZXqlFtw=.96c17eb1-f333-45ce-a4cf-4dd03062dfc1@github.com>

On Sun, 18 Apr 2021 19:55:20 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
>> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
>> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
>> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
>> 
>> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
>> 
>> The comparative results are here:
>> 
>> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
>> 
>> The jmh-result.json files are here:
>> 
>> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
>> 
>> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
>> 
>> So WDYT?
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix overflow checking logic, add test for it, avoid branch in loop, add 1-char strings to JHM test

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3501

From skypencil at gmail.com  Sat Apr 17 00:51:50 2021
From: skypencil at gmail.com (Kengo TODA)
Date: Sat, 17 Apr 2021 08:51:50 +0800
Subject: ObjectMethods seems generating wrong methods for array-type field
In-Reply-To: <1638432481.2244346.1618395126510.JavaMail.zimbra@u-pem.fr>
References: <CAO1eWSDOhGqxmAy7FenUeBp8BkRboRuq+xs-7-A8VQ215rGyXg@mail.gmail.com>
 <CAO1eWSCEnoLPSTSq4Mg21EjELkhsnjg7hjR027+n3LfK-fHeMw@mail.gmail.com>
 <1638432481.2244346.1618395126510.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAO1eWSDXHZBv675cJq5339_TCKh725MAD2rtehpW52AaCH+KWg@mail.gmail.com>

Hello R?mi, Raffaello,


Thanks for your reply. I got it.
I knew that it's better to make Record classes immutable, and
now learn one more new thing :)

As suggested by R?mi, I'll read the amber-spec-experts mailing list.
I want to grasp the reason to use invokedynamic in these methods.
This is my first motivation to learn about the ObjectMethods class.
Hope that the mailing list will help me to find it.


Thank you very much!

***
Kengo TODA
skypencil at gmail.com


On Wed, Apr 14, 2021 at 6:12 PM Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Mail original -----
> > De: "Kengo TODA" <skypencil at gmail.com>
> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Mercredi 14 Avril 2021 11:03:14
> > Objet: Re: ObjectMethods seems generating wrong methods for array-type
> field
>
> Hello,
>
> > I found that the JLS 16 does not cover the array type record component:
> > https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10.3
> >
> > So it could be not a core-lib issue but a JLS issue.
>
> Nope, the implementation of a record is covered in the javadoc of
> java.lang.Record
> for equals, see
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Record.html#equals(java.lang.Object)
>
> As you can see the spec clearly says that for any fields which is an
> object (arrays are objects), it should be semantically equivalent to
> calling java.util.Objects.equals() on those fields.
>
> So it's not a bug, it's how record.equals() works, as Raffaello said,
> records are dumb containers, this is how we have specified them.
>
> Records have been specified as part of the project Amber, you can take a
> look to the mailing list [1] for more if you want.
>
> >
> > Do I need to forward this thread to another mailing list?
> > If so, please let me know which is the preferred one.
> > I've checked https://mail.openjdk.java.net/mailman/listinfo but not so
> sure.
> >
> >
> > Thank you very much.
>
> regards,
> R?mi
>
> [1] https://mail.openjdk.java.net/mailman/listinfo/amber-spec-experts
>
> >
> > ***
> > Kengo TODA
> > skypencil at gmail.com
> >
> >
> > On Wed, Apr 14, 2021 at 9:04 AM Kengo TODA <skypencil at gmail.com> wrote:
> >
> >> Hello there,
> >>
> >>
> >> I'm Kengo TODA, an engineer learning about the Record feature.
> >> Today I found a nonintentional behavior, and it seems that the bug
> >> database has no info about it.
> >> Let me ask here to confirm it's by-design or not. If it's a bug, I want
> to
> >> try to send a patch to OpenJDK.
> >>
> >> Here is the code reproducing the nonintentional behavior:
> >> https://gist.github.com/KengoTODA/4d7ef6a5226d347ad9385241fee6bc63
> >>
> >> In short, the ObjectMethods class in OpenJDK v16 generates code
> >> that invokes the fields' method, even when the field is an array.
> >>
> >> Please help me to understand this behavior, or
> >> make an entry in the bug database to propose a patch.
> >> Thanks in advance! :)
> >>
> >> ***
> >> Kengo TODA
> >> skypencil at gmail.com
>

From cjplummer at openjdk.java.net  Mon Apr 19 20:20:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 19 Apr 2021 20:20:07 GMT
Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and
 -XX:FlightRecorderOptions=
In-Reply-To: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>
References: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>
Message-ID: <abvknasswAEt6DvaqcdloxOI5hCg1blU2W5g-kV9Qt4=.a414c7bc-0458-4aa9-9681-f0acb062e631@github.com>

On Sun, 18 Apr 2021 15:17:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc.
> 
> I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. 
> 
> Testing: jdk/jdk/jfr, tier 1-4.
> 
> Thanks
> Erik

The changes look good. Have you considered doing a test run where the use of `=` and `XX:+FlightRecorder` are disallowed just to make sure you caught them all?

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3561

From igraves at openjdk.java.net  Mon Apr 19 20:51:28 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 19 Apr 2021 20:51:28 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in character
 classes
Message-ID: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>

Clarifying note on comments mode to explicitly note that whitespace within character classes is ignored.

-------------

Commit messages:
 - Note about comments mode and character class whitespace

Changes: https://git.openjdk.java.net/jdk/pull/3577/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3577&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8199594
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3577/head:pull/3577

PR: https://git.openjdk.java.net/jdk/pull/3577

From forax at univ-mlv.fr  Mon Apr 19 21:01:16 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 19 Apr 2021 23:01:16 +0200 (CEST)
Subject: ReversibleCollection proposal
In-Reply-To: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
Message-ID: <1423562894.899549.1618866076309.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 16 Avril 2021 19:40:55
> Objet: ReversibleCollection proposal

> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on detailed
> specifications and tests. Please send such comments as replies on this email
> thread.
> 
> Here's a link to a draft PR that contains the code diffs. It's prototype
> quality,
> but it should be good enough to build and try out:
> 
>     https://github.com/openjdk/jdk/pull/3533
> 
> And here's a link to a class diagram showing the proposed additions:
> 
> 
> https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollectionDiagram.pdf
> 
> Thanks,
> 
> s'marks

Thinking a little bit about your proposal,
introducing an interface right in the middle of a hierarchy is not a backward compatible change
(you have an issue when the compiler has to use the lowest upper bound).

By example
  void m(List<Collection<String>> list) { ... }

  var list = List.of(new LinkedHashSet<String>(), List.of("foo"));
  m(list);  // does not compile anymore

currently the type of list is List<Collection<String>> but with your proposal, the type will be List<ReversibleCollection<String>>

R?mi

From bpb at openjdk.java.net  Mon Apr 19 21:03:03 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 19 Apr 2021 21:03:03 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes
In-Reply-To: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
References: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
Message-ID: <XBPB7Nj2ijI_L3-MVXMCTJQYgtkMDtiPfR-1RErSDXI=.26b3748f-cff3-427a-9ba0-22d75152123b@github.com>

On Mon, 19 Apr 2021 20:43:26 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Clarifying note on comments mode to explicitly note that whitespace within character classes is ignored.

Looks all right. Probably a CSR is in order.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3577

From igraves at openjdk.java.net  Mon Apr 19 21:06:04 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 19 Apr 2021 21:06:04 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes
In-Reply-To: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
References: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
Message-ID: <7uruItF_iPmVuDYkwwgnD_aZe6szM1rbPMpv5v-HHXE=.ce360665-baaf-4fee-8fec-88cb3409709e@github.com>

On Mon, 19 Apr 2021 20:43:26 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Clarifying note on comments mode to explicitly note that whitespace within character classes is ignored.

Will put a /csr in to be safe.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3577

From cjplummer at openjdk.java.net  Mon Apr 19 21:16:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 19 Apr 2021 21:16:08 GMT
Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and
 -XX:FlightRecorderOptions=
In-Reply-To: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>
References: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>
Message-ID: <2-NewUlYrdJ7H67-xrLMo71CB-m2YPTrjJmYVPR7Hi4=.134d7e91-2d75-49f6-b3df-dfaec043fef7@github.com>

On Sun, 18 Apr 2021 15:17:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc.
> 
> I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. 
> 
> Testing: jdk/jdk/jfr, tier 1-4.
> 
> Thanks
> Erik

Sorry, I accidentally stuck an "integrate" label in this PR (was meant for my own PR). I immediately deleted it. Hopefully no harm done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3561

From winterhalter at openjdk.java.net  Mon Apr 19 21:20:06 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 19 Apr 2021 21:20:06 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <aWPRzuC0OalgL5f2XjoTUyxOdMA7g5XXg3HGWKmEgnw=.b46d6805-d49c-462a-9435-ac8d458f5b5b@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

At the moment, it is required for root to switch to the user that owns the
JVM process as the domain socket is only accessible to that user to avoid
that users without access to the JVM can inject themselves into a JVM. I am
not sure if operations teams would be thrilled to have a monitoring agent
required to run as root, even in these times of Kubernetes.

I mainly have two comments:

1. The problem is the possibility of self-attach. I think this is the
problem to solve, a library getting agent privileges without being an
agent. I think this should be prevented while dynamic attach should
continue to be possible in today's format. It has proven to be so useful,
it would be a shame if the current tooling convenience would disappear from
the JVM. As it's my understanding, JNI is supposed to be restricted in the
future, in line with Panama. Without this restriction, JNI already allows
for random class definition, for example, which similarly to an agent
offers surpassing the majority of JVM restrictions. The second restriction
would be a control to restrict how a JVM process starts new processes. I
think both are reasonable restrictions for a library to face which require
explicit enabling. Especially with the security manager on it's way out,
certain capabilities should be rethought to begin with. If both are no
longer freely available, self-attachment is no longer possible anyways and
dynamic agents could retain their capabilities.

2. The question of introducing an Instrumentation::defineClass method is
fully independent of that first question. If a dynamic agent was to be
restricted, the method could reject classloader/package combinations for
dynamically loaded agents the same way that
Instrumentation::retransformClasses would need to. At the same time,
introducing the method would allow agents to move to an official API with a
Java 17 baseline which will be the next long-standing base line. I fully
understand it needs a thorough discussion but it is a less complicated
problem then (1) and could therefore be decided prior to having found a
satisfactory solution for it.

Am Mo., 19. Apr. 2021 um 16:07 Uhr schrieb Peter Levart <
***@***.***>:

> an application or library can use the attach mechanism (directly or via
> the attach API in a child VM) to load an agent and leak the Instrumentation
> object. This is the genie that somehow needs to be put back in its bottle.
> One approach that I mentioned here to create is a less powerful
> Instrumentation object for untrusted agents. Trusted agents would continue
> to the full-power
>
> I hear Rafael that dynamic attach is important to support monitoring and
> instrumenting large numbers of JVMs with no preparations (i.e. without
> issueing special command-line options to enable it). As I understand,
> current attach mechanism is designed to allow a process running under the
> same UID as the JVM or under root to attach to the JVM.
>
> What if this dynamic attach mechanism was modified so that only a process
> running under root could dynamically attach to the JVM? Old behavior would
> be enabled by special command line option, so by default, dynamic attach
> would be limited to tools running under root. Rafael mentions discovery,
> monitoring and instrumenting large number of JVMs running on hosts, so if
> one such tool has to attach to different JVMs running under different UIDs,
> it has to run as root now anyway.
>
> With such default "secure" dynamic attach and when the JVM is not running
> as root (which is a recommended security practice anyway), a library in
> such JVM could not attach back to the same JVM even through spawning
> sub-processes.
>
> How to achieve such "secure" dynamic attach? One way that comes to mind is
> a modified handshake. Currently, I think at least on Linux, the tool that
> wishes to attach to the JVM searches for a special UNIX socket (
> $PWD/.java_pid<vmid>, /tmp/.java_pid<vmid>) and if not found, creates a
> special attach file ($PWD/.attach_pid<vmid>, /tmp/.attach_pid<vmid>) to
> signal the JVM to create a listening UNIX socket under mentioned special
> path, then it connects to the socket. The UNIX socket file has UID:GID set
> to effective UID:GID of the JVM process and permissions to 0600, so only a
> tool running under same UID or root can connect to such socket.
>
> In modified handshake, JVM not running as root could not create a UNIX
> socket file with permissions to allow only root user to connect to it, but
> a tool running under root could create a listening UNIX socket with
> permission to allow JVM to connect to it in a way that the JVM connecting
> to such socket would know that the listening process is running as root.
> Simply by checking the owner of the listening UNIX socket file. Such socket
> file would have to have permission 0666 in order to allow JVMs running
> under any UID to connect to it, but otherwise be "hidden". This can be
> achieved by the tool creating a special directory and a UNIX socket in this
> directory, say: /tmp/.attach_dir<tool pid>/<random string>, The directory
> UID:GID would be 0:0 and have permission 0711. This means, any user could
> connect to the socket as long as it knows the <random string>, but no
> user but root can list the content of the directory to discover the name of
> the socket file. The last piece of the puzzle is how to signal to the JVM
> about the name of the socket file. Well, creating a file with the content
> holding the name of the socket file would be OK, as long as only target JVM
> could read it. File permissions could be set such that any process running
> under the same UID as the JVM could read the file. This would give a rouge
> library a chance to connect to the tool and pretend to be the monitoring
> JVM, but it could not connect to back to the JVM though...
>
> WDYT?
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/3546#issuecomment-822495459>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABCIA4GPK73MWBRBICZS6Y3TJQ2LLANCNFSM43BSDEGQ>
> .
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From igraves at openjdk.java.net  Mon Apr 19 22:12:30 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 19 Apr 2021 22:12:30 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v2]
In-Reply-To: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
References: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
Message-ID: <ROd-lby2BgszUx7xsfo4lQSF82vFRyFPO_d8SaKuFDY=.7b72f90c-474a-464b-bd68-5d79650e4b40@github.com>

> Clarifying note on comments mode to explicitly note that whitespace within character classes is ignored.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Adding differences to Perl 5 note

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3577/files
  - new: https://git.openjdk.java.net/jdk/pull/3577/files/8ab051aa..f4507e3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3577&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3577&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3577/head:pull/3577

PR: https://git.openjdk.java.net/jdk/pull/3577

From forax at univ-mlv.fr  Mon Apr 19 23:05:32 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 20 Apr 2021 01:05:32 +0200 (CEST)
Subject: ReversibleCollection proposal
In-Reply-To: <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
Message-ID: <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 19 Avril 2021 17:41:11
> Objet: Re: ReversibleCollection proposal

> On 4/17/21 9:49 AM, Remi Forax wrote:
>> I think the analysis is spot on but I don't think the proposed solution is the
>> right one.
>> 
>> Introducing a new interface (two in this case) has a really huge cost and in
>> this case, i've trouble to see why i will want to write a method that takes a
>> ReversibleCollection as parameter, ReversibleCollection as a type does not seem
>> to be useful. About the cost of introducing a new collection interface, it
>> means that we also have to update all emptyXXX, singleXXX, uncheckedXXX with a
>> new interface, and that only for the JDK. Every libraries that proxy
>> collections has also to be updated to take care of this new type, otherwise the
>> integration with an application that uses this new type and the library is not
>> seamless anymore.
> 
> Hi Remi,
> 
> Thanks for looking at this. There are several issues intertwined here, so let's
> try
> to break it down.
> 
> There are a bunch of factory methods emptyX, singletonX, etc. that give
> instances of
> particular types. As Tagir noted, List is a ReversibleCollection, so you can
> just
> use emptyList or List.of or whatever if you need an instance of
> ReversibleCollection. Also, SortedSet/NavigableSet are ReversibleSets, so if you
> need an empty ReversibleSet, you can use Collections.emptyNavigableSet. There's
> no
> singletonNavigableSet, but you could do
> 
>     Collections.unmodifiableNavigableSet(new TreeSet<>(List.of(x)))
> 
> which is a bit of a mouthful, but it's possible. (The fact that there's no
> Collections.singletonNavigableSet may mean this use case is so narrow that few
> people really needed it.)
> 
> As for the wrappers, synchronizedX and checkedX are mostly disused, so I don't
> see a
> need to provide those wrappers. Having unmodifiable RC and RS is probably
> useful, so
> I could see adding those. That's a certain amount of work, but not a tremendous
> cost.

It's a shame that checkedX are not used more, at least in tests, because it's a simple way to know if a method will work with the new generics of Valhalla (it's the same semantics).

Anyway, the problem is not only for the JDK, but for all libraries like guava, eclipse collections, etc and also JVM languages that provides a collection interopt like Clojure or Scala. 

> 
>> All these methods can be introduced has default methods on the existing
>> collection interfaces, there is no need of a special interface (or two) for
>> that.
> 
> Clearly it's possible to get by without new interfaces. After all the
> collections
> framework has gotten by without them for 20+ years already. It's certainly
> possible
> to fill out the individual interfaces (List, Deque, Sorted/NavSet) and classes
> (LinkedHashSet, LinkedHashMap) with methods that are all similar to each other,
> and
> that would be useful. Or as Peter Levart pointed out, we could push all of them
> up
> to Collection and write the specs in a loose enough way to encompass even
> unordered
> collections.
> 
> Any of those alternatives (do nothing, add individual methods, add
> loosely-spec'd
> methods to Collection) are *possible* to do. However, I think you know how
> minimal
> we are with the JDK APIs, and we wouldn't have proposed new interfaces without
> good
> cause. Thus, I think introducing new *types* here is useful, for the following
> reasons.
> 
>  * There's a useful clump of semantics here, combined with sensible operations
>  that
> rely on those semantics. There are a lot of places in the spec where there is
> hedging of the form "if the collection has an ordering, then... otherwise the
> results are undefined". This is unnecessary in the context of a new type.
> Furthermore, the new operations fit well with the new types' semantics, with no
> hedging necessary.

You can only say that a reversible collection has an ordering. But usually you want the opposite, all collections that have an ordering are a reversible collection. But while this can be true for the implementations inside the JDK that will never be true in Java because there all already collection implementations with an ordering which do not implement ReversibleCollection.

Sadly, this ship has sailed.
The spec will still have to say "if the collection has an ordering", otherwise the new semantics is not a backward compatible.

> 
>  * These semantics appear across a broad range of existing collection types and
> implementations. It's quite valuable to have a type that unifies the common
> pieces
> of List, Deque, SortedSet, and LinkedHashSet into a single abstraction.

yes in term of documentation, but in Java, it also means that you can use that interface as a type.

For a List, a Deque or a Set, there are known algorithms that takes such type has parameter so it makes sense to have such type.
For a ReversibleCollection, i do not see many codes that will benefit taking a ReversibleCollection as parameter instead of using Collection.

> 
>  * It's useful to have a new type for parameters in APIs. There are times when
>  one
> wants to accept something like a List -or- a LinkedHashSet. Typically one would
> accept a Collection and then write a spec with hedging as above ("the argument
> collection must have a defined ordering"). But this also allows bugs, for
> example if
> somebody accidentally passes a HashSet. Having ReversibleCollection helps this
> problem.

As i said above, "a collection must have an ordering" is not equivalent to a ReversibleCollection and it will never be.

> 
>  * It's useful to have a new type for return types in APIs. Consider
> LinkedHashMap's entrySet, keySet, and values views. While we clearly get by with
> having these return Set or Collection today, we need a place to put the new
> methods.
> Either they go on Collection (and have extremely weak semantics) or we define
> new
> interfaces.

Even if you define a new interface, you can not change the return type of LinkedHashMap entrySet because it's not a backward compatible change. LinkedHashMap is not final so you have to update all subclasses of LinkedHashMap too.

> 
>  * It's a useful interface for new collection implementations. There are data
> structures that are ordered, double-ended, and reversible, but for which
> implementing List is too onerous. Supporting int indexes in various List APIs is
> where stumbling blocks usually occur. I note that the LinkedHashMap view
> collections
> are examples of this that already exist in the prototype code. (Other
> possibilities
> might be something like SpinedBuffer or chunked linked lists.)

yes, but at the same time, we can introduce SpinedBuffer without ResersibleCollection.

> 
> In general, I agree that there should be strict criteria for introducing new
> interfaces into collections, but I think this proposal meets them.

I agree that having such interface at day one may have been a great addition to the collection framework.
But as a late addition, it's a split change, it's a change that requires every implementations of a collection with an ordering to update itself so it will play nicely with the future JDKs and codes developed to target those JDKs. 

> 
> s'marks

R?mi

From ysuenaga at openjdk.java.net  Tue Apr 20 01:22:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 20 Apr 2021 01:22:07 GMT
Subject: Integrated: 8265152: jpackage cleanup fails on Windows with
 IOException deleting msi
In-Reply-To: <5kVIe79iAW3K6erYsi9jIGuzXQRTPtCSDZnEludo_z0=.8d766457-d8c8-4f1c-9813-c87165694edd@github.com>
References: <5kVIe79iAW3K6erYsi9jIGuzXQRTPtCSDZnEludo_z0=.8d766457-d8c8-4f1c-9813-c87165694edd@github.com>
Message-ID: <AC_FBC-j-Qff3_NpiijTh08rWGj5z7Nvf3qndXqTs8s=.c841b004-8268-403d-b67f-45aa8eae0a3b@github.com>

On Sun, 18 Apr 2021 12:44:17 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When creating an "exe" installer on Windows, `AbstractBundler.cleanup()` calls `IOUtils.deleteRecursive()` to delete the tmp directory. It can intermittently fail trying to delete the msi file.
> 
> [JDK-8263135](https://bugs.openjdk.java.net/browse/JDK-8263135) removed `unique_ptr` from jpackage sources due to compiler warnings in VS 2019 (16.9.0), so we need to release the resource manually. However `DatabaseView` didn't do that.

This pull request has now been integrated.

Changeset: 142edd3a
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/142edd3a
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8265152: jpackage cleanup fails on Windows with IOException deleting msi

Reviewed-by: herrick, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/3560

From plevart at openjdk.java.net  Tue Apr 20 07:14:36 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 20 Apr 2021 07:14:36 GMT
Subject: RFR: 8265237: String.join and StringJoiner can be improved
 further [v4]
In-Reply-To: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
Message-ID: <3MFxU0MmrJ7g46uNxHONHYRHsyyPPT-oDthLJe_8bbE=.6f9371f6-5d25-4caa-846d-c37731e9881e@github.com>

> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
> 
> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
> 
> The comparative results are here:
> 
> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
> 
> The jmh-result.json files are here:
> 
> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
> 
> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
> 
> So WDYT?

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  Fork JVM 3 times in JMH test to smooth out variance in a particular fork

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3501/files
  - new: https://git.openjdk.java.net/jdk/pull/3501/files/a2d5e819..84af9e6c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3501.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3501/head:pull/3501

PR: https://git.openjdk.java.net/jdk/pull/3501

From egahlin at openjdk.java.net  Tue Apr 20 07:43:36 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 20 Apr 2021 07:43:36 GMT
Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and
 -XX:FlightRecorderOptions= [v2]
In-Reply-To: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>
References: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>
Message-ID: <Q6zXvffNYthA7iPh4FU--1YVP5Q7pi9pwk4QyAZVcuM=.40e27f51-b9f1-41ae-bfa4-02d086b46063@github.com>

> Hi,
> 
> Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc.
> 
> I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. 
> 
> Testing: jdk/jdk/jfr, tier 1-4.
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Replace '=' in jfrOptionsSet.cpp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3561/files
  - new: https://git.openjdk.java.net/jdk/pull/3561/files/4ce08939..138bac16

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3561&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3561&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3561/head:pull/3561

PR: https://git.openjdk.java.net/jdk/pull/3561

From egahlin at openjdk.java.net  Tue Apr 20 07:55:08 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 20 Apr 2021 07:55:08 GMT
Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and
 -XX:FlightRecorderOptions= [v2]
In-Reply-To: <abvknasswAEt6DvaqcdloxOI5hCg1blU2W5g-kV9Qt4=.a414c7bc-0458-4aa9-9681-f0acb062e631@github.com>
References: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>
 <abvknasswAEt6DvaqcdloxOI5hCg1blU2W5g-kV9Qt4=.a414c7bc-0458-4aa9-9681-f0acb062e631@github.com>
Message-ID: <Wtn0T2JAuq4bH1xt4IafATP129rMya6RhKoXdFBrmGE=.66419331-f2a1-4480-9b40-0426deec1abd@github.com>

On Mon, 19 Apr 2021 20:16:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The changes look good. Have you considered doing a test run where the use of `=` and `XX:+FlightRecorder` are disallowed just to make sure you caught them all?

It's a good idea, but it requires changes outside OpenJDK which I rather not do now. I'm sure somebody will reintroduce '=', so this is not so much about getting rid of them all, but to avoid them being propagated, when code is copy pasted for new tests etc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3561

From Alan.Bateman at oracle.com  Tue Apr 20 13:35:52 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 20 Apr 2021 14:35:52 +0100
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <aWPRzuC0OalgL5f2XjoTUyxOdMA7g5XXg3HGWKmEgnw=.b46d6805-d49c-462a-9435-ac8d458f5b5b@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <aWPRzuC0OalgL5f2XjoTUyxOdMA7g5XXg3HGWKmEgnw=.b46d6805-d49c-462a-9435-ac8d458f5b5b@github.com>
Message-ID: <fe705503-0d42-c3d2-8977-be9a6f83addf@oracle.com>

On 19/04/2021 22:20, Rafael Winterhalter wrote:
> :
> At the moment, it is required for root to switch to the user that owns the
> JVM process as the domain socket is only accessible to that user to avoid
> that users without access to the JVM can inject themselves into a JVM. I am
> not sure if operations teams would be thrilled to have a monitoring agent
> required to run as root, even in these times of Kubernetes.
>
> I mainly have two comments:
>
> 1. The problem is the possibility of self-attach. I think this is the
> problem to solve, a library getting agent privileges without being an
> agent. I think this should be prevented while dynamic attach should
> continue to be possible in today's format. It has proven to be so useful,
> it would be a shame if the current tooling convenience would disappear from
> the JVM. As it's my understanding, JNI is supposed to be restricted in the
> future, in line with Panama. Without this restriction, JNI already allows
> for random class definition, for example, which similarly to an agent
> offers surpassing the majority of JVM restrictions. The second restriction
> would be a control to restrict how a JVM process starts new processes. I
> think both are reasonable restrictions for a library to face which require
> explicit enabling. Especially with the security manager on it's way out,
> certain capabilities should be rethought to begin with. If both are no
> longer freely available, self-attachment is no longer possible anyways and
> dynamic agents could retain their capabilities.
>
> 2. The question of introducing an Instrumentation::defineClass method is
> fully independent of that first question. If a dynamic agent was to be
> restricted, the method could reject classloader/package combinations for
> dynamically loaded agents the same way that
> Instrumentation::retransformClasses would need to. At the same time,
> introducing the method would allow agents to move to an official API with a
> Java 17 baseline which will be the next long-standing base line. I fully
> understand it needs a thorough discussion but it is a less complicated
> problem then (1) and could therefore be decided prior to having found a
> satisfactory solution for it.
I should have been clearer, it's the combination of the two that creates 
the attractive nuisance. I don't think there are any objections to a 
defineClass for agents specified on the command line with -javaagent. 
However we have to be cautious about extending that capability to agents 
that are loaded into a running VM with the attach mechanism.

ByteBuddy looks great for code generation and transforming classes but 
ByteBuddyAgent makes me nervous. It looks like I can deploy 
byte-buddy-agent-<version>.jar on my class path and invoke the public 
static ByteBuddyAgent.install() method to get the Instrumentation object 
for the current VM. That may be convenient for some but this is the 
all-powerful Instrumentation object that shouldn't be leaked to library 
or application code. Now combine this with the proposed defineClass and 
it means that any code on the class path could inject a class into 
java.lang or any run-time package without any agent voodoo or opt-in via 
the command line. That would be difficult genie to re-bottle if it were 
to get traction.

You mentioned restricting JNI in the future. I'm not aware of a definite 
plan or time-frame. Project Panama is pioneering restricting access to 
native operations as a bug or mis-use with the linker API can easily 
crash the VM or breakage in other ways. Extending this to JNI would be a 
logical next step but I could imagine it taking a long time and many 
releases to get there.

As regards this PR then I would be happy to work with you on a revised 
proposed that would limit it to agents specified with -javaagent. That 
would not preclude extending the capability, maybe in a more restricted 
form, to agents loaded into a running VM in the future.

-Alan.

From github.com+10835776+stsypanov at openjdk.java.net  Tue Apr 20 15:24:04 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 20 Apr 2021 15:24:04 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <4rfI8EQpIjApUBQswdVRfz8M2kFUtx2hch0oYyiaXAc=.60e2638d-2de8-41c0-a695-11643d0432f3@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
 <CNby1eR4i4aQoSuqcr5tgnePbh1jXUXDF28PdrPZQM8=.0b9404aa-276c-435b-a8e7-3a6fda21b2d8@github.com>
 <4rfI8EQpIjApUBQswdVRfz8M2kFUtx2hch0oYyiaXAc=.60e2638d-2de8-41c0-a695-11643d0432f3@github.com>
Message-ID: <Wm3QBUPMBrGTAP22ZFgUBvVYjFdIIBbnaogjELeYtXU=.dc71b1c2-bb38-4d2c-881c-ec5d48fc31eb@github.com>

On Mon, 19 Apr 2021 15:03:44 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 458:
>> 
>>> 456:         private static boolean isSamePackage(Class<?> class1, Class<?> class2) {
>>> 457:             return class1.getClassLoader() == class2.getClassLoader()
>>> 458:                    && class1.getPackageName().equals(class2.getPackageName());
>> 
>> If the j.u.c.atomic code is changed then it will need to be coordinated with Doug Lea's repo. The rest of the changes are good and thanks for following up from the comments in the other issue.
>
> Hello, how should I do it? Maybe we can just mention him here?

@DougLea could you have a look into the part of this PR related to java.util.concurrent package?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3571

From pconcannon at openjdk.java.net  Tue Apr 20 15:35:40 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 15:35:40 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v5]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <Nw3mk6ouTa6ti4a4OetqMNdBit3OgIjuXQna6zeq0Cw=.71e62d26-5bfe-45a5-b5ac-01e56efc095c@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 8263668: Update java.time to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/6481346a..2dca4a09

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=03-04

  Stats: 3821 lines in 79 files changed: 2021 ins; 1604 del; 196 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170

PR: https://git.openjdk.java.net/jdk/pull/3170

From egahlin at openjdk.java.net  Tue Apr 20 15:58:06 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 20 Apr 2021 15:58:06 GMT
Subject: Integrated: 8265036: JFR: Remove use of -XX:StartFlightRecording= and
 -XX:FlightRecorderOptions=
In-Reply-To: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>
References: <UdfQ042ySpZl335-Y0-779E31_yYrPiDG87F4qO1Pow=.12d827b4-3653-48f1-ba9e-8626d701ec0d@github.com>
Message-ID: <-SX_kKhJgQjALbNUDSfjyWa5IETaK5rUHwewSUm7zhg=.9c50555e-5afc-4499-a39a-d6ff860cfd6c@github.com>

On Sun, 18 Apr 2021 15:17:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc.
> 
> I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. 
> 
> Testing: jdk/jdk/jfr, tier 1-4.
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 4dcaac1f
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4dcaac1f
Stats:     104 lines in 40 files changed: 0 ins; 0 del; 104 mod

8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions=

Reviewed-by: cjplummer

-------------

PR: https://git.openjdk.java.net/jdk/pull/3561

From lapo at lapo.it  Tue Apr 20 16:58:49 2021
From: lapo at lapo.it (Lapo Luchini)
Date: Tue, 20 Apr 2021 18:58:49 +0200
Subject: Image parsing spams stack traces to System.err
Message-ID: <s5n18a$7h0$1@ciao.gmane.io>

In both OpenJDK 8, 11 and 15 I verified that:

sun/awt/image/InputStreamImageSource.java

has "e.printStackTrace()" commands that might better be converted to 
java.util.logging in order to be able to configure/redirect them to the 
proper log file each application might decide to use.

A little bit of more details as reported here (where they suggested this 
was the proper place):
https://github.com/AdoptOpenJDK/openjdk-jdk11u/issues/21

cheers,

-- 
Lapo Luchini
lapo at lapo.it


From pconcannon at openjdk.java.net  Tue Apr 20 17:38:07 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 17:38:07 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v5]
In-Reply-To: <wnSAgogvub7uNdnY8-w7gtbWP_G7_Fmto3S2yxFQWm0=.fbc2ded4-61d4-4340-b142-c63c0f673a48@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <wnSAgogvub7uNdnY8-w7gtbWP_G7_Fmto3S2yxFQWm0=.fbc2ded4-61d4-4340-b142-c63c0f673a48@github.com>
Message-ID: <bG1E9ja_MbcdHydLK1by-ykObZkeWDWvglMcEHvZTZI=.9ecbd890-6ad2-4ca1-b00c-e52ab06f7a6b@github.com>

On Wed, 24 Mar 2021 13:57:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In addition to the other suggestions, java.time could use a round of cleanup to use switch expressions.

Hi Roger, I plan to introduce switch expressions in a follow up issue/PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From smarks at openjdk.java.net  Tue Apr 20 17:45:04 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 20 Apr 2021 17:45:04 GMT
Subject: RFR: 8265356: need code example for getting canonical constructor
 of a Record
In-Reply-To: <YIXReZGwfOekkWodThE2ofggNC1vMVPEoUu9PohR7QA=.3fc2f794-2b4f-4f85-ac41-3f7af9b880d4@github.com>
References: <YIXReZGwfOekkWodThE2ofggNC1vMVPEoUu9PohR7QA=.3fc2f794-2b4f-4f85-ac41-3f7af9b880d4@github.com>
Message-ID: <VO44tMXfQN3o_SP98WFF_J06D9mRb66VgOS_uqEII2o=.aac2e431-b616-4f08-9223-eacf5f68f657@github.com>

On Sat, 17 Apr 2021 08:55:59 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static <T extends Record>\nConstructor<T> getCanonicalConstructor(Class<T> cls)` is unnecessary.
> 
> ---
> Aside from this PR, I've found a couple of things to clean up in `java.lang.Class`:
> 1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by @jddarcy in #3038). It should be `#isArray()` instead of `isArray()`.
> 2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused type parameters `<T>`.
> 3. Probably too much but AnnotationData can be nicely converted to a record! Not sure, probably nobody wants to have `java.lang.Record` initialized too early or increasing the footprint of such a basic class in the metaspace, so I don't insist on this.
> 
> 
>     private record AnnotationData(
>         Map<Class<? extends Annotation>, Annotation> annotations,
>         Map<Class<? extends Annotation>, Annotation> declaredAnnotations,
>         // Value of classRedefinedCount when we created this AnnotationData instance
>         int redefinedCount) {
>     }
> 
> 
> Please tell me if it's ok to fix 1 and 2 along with this PR.

Thanks for writing this example.

I think that the example lines can be longer. I'd suggest putting the main part of the method declaration on the same line as `static <T extends Record>`, but leaving the `throws` clause on the next line.

I think including the small cleanups (1) and (2) in this PR is fine. Changing `AnnotationData` to be a record seems like it might have other effects, so I'd leave that one out.

One other thing I'd like to see is a link to this example code from places where people are likely to look for it. The class doc for `java.lang.Record` has a definition for "canonical constructor" so it would be nice to link to the example here. Something like "For further information about how to find the canonical constructor reflectively, see Class::getRecordComponents." (With appropriate javadoc markup.) This could either be a parenthetical comment somewhere in the "canonical constructor" discussion, or possibly a separate paragraph in the `@apiNote` section below.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3556

From pconcannon at openjdk.java.net  Tue Apr 20 17:46:46 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 17:46:46 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v4]
In-Reply-To: <5fRAroNJRKwOzQ_i7zcWDkDYJ2xcIVB-4p1tDtTHgKQ=.c82afb9a-d0a7-4915-a3f4-e1958253bb68@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <qcPDAqnJlx0EAJiNJ6cArn0SfaKleRNq8uTGVyJ8p40=.f2acc1ab-96e0-41f4-b8f0-941757fb08b7@github.com>
 <5fRAroNJRKwOzQ_i7zcWDkDYJ2xcIVB-4p1tDtTHgKQ=.c82afb9a-d0a7-4915-a3f4-e1958253bb68@github.com>
Message-ID: <dKayuHyBJE9eRsK4iUx1CRCTB6BOurLpF-pfTGxND8U=.9a074a36-77eb-4178-81d2-d328ed4c9700@github.com>

On Mon, 19 Apr 2021 15:37:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Patrick Concannon 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 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - 8263668: Update java.time to use instanceof pattern variable
>
> src/java.base/share/classes/java/time/Duration.java line 1435:
> 
>> 1433:                 && this.seconds == other.seconds
>> 1434:                 && this.nanos == other.nanos;
>> 1435:     }
> 
> Perhaps rename the argument and use `otherDuration` as the refinement.
> Otherwise, an inconsistency across various classes will creep in where the more specific variable has a more general name.  In this case, the argument type is Object, so the argument name `otherDuration` is not strictly true.

Parameter and pattern variable names swapped, as suggested. See 647bd6b

> src/java.base/share/classes/java/time/Instant.java line 1306:
> 
>> 1304:                 && this.seconds == other.seconds
>> 1305:                 && this.nanos == other.nanos;
>> 1306:     }
> 
> Ditto, `otherInstance` is not strictly always an instant and it would be more consistent to swap the names.
> `(other instanceof Instant otherInstant)`.

Parameter and pattern variable names swapped, as suggested. See 647bd6b

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From pconcannon at openjdk.java.net  Tue Apr 20 17:46:38 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 17:46:38 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v6]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  Updated single letter pattern variable names

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/2dca4a09..647bd6b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=04-05

  Stats: 51 lines in 14 files changed: 0 ins; 0 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170

PR: https://git.openjdk.java.net/jdk/pull/3170

From pconcannon at openjdk.java.net  Tue Apr 20 17:46:49 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 17:46:49 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v6]
In-Reply-To: <Dpzk0f63E8tPAC1zjmQ29kGopHHsyjozKI3AP_EpWCg=.079e6cda-ad0f-4b80-a254-5b3f2888a2eb@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <Dpzk0f63E8tPAC1zjmQ29kGopHHsyjozKI3AP_EpWCg=.079e6cda-ad0f-4b80-a254-5b3f2888a2eb@github.com>
Message-ID: <ALVe6r-PBZ4etyOYsM3aqIcOj3GFjP8cursdSAWm89k=.975f052a-4852-4531-8543-d627216b311d@github.com>

On Wed, 24 Mar 2021 10:57:11 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated single letter pattern variable names
>
> src/java.base/share/classes/java/time/LocalDateTime.java line 1686:
> 
>> 1684:     public long until(Temporal endExclusive, TemporalUnit unit) {
>> 1685:         LocalDateTime end = LocalDateTime.from(endExclusive);
>> 1686:         if (unit instanceof ChronoUnit u) {
> 
> `chronoUnit` is perhaps a better variable name than `u`

Thanks for your comments, @forax, and apologizes for the delay in getting back to you. I was waiting for the boot JDK version to be updated to 16. Certain files changed in the PR are shared between the build tool and the JDK runtime, and were causing build issues.
I've addressed the changes you suggested, and you can find them in commit 647bd6b

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From rriggs at openjdk.java.net  Tue Apr 20 19:58:12 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 20 Apr 2021 19:58:12 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v6]
In-Reply-To: <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
Message-ID: <XnnEo4lzumJLSiGui7nFG7kxpQT4z2z1d-ekLhKbiz8=.57737046-9ebe-4024-99ba-5ea05dab20c0@github.com>

On Tue, 20 Apr 2021 17:46:38 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated single letter pattern variable names

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From darcy at openjdk.java.net  Tue Apr 20 20:04:16 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 20 Apr 2021 20:04:16 GMT
Subject: RFR: 8228988: AnnotationParser throws NullPointerException on
 incompatible member type
In-Reply-To: <Zylg9nIkBHVXyHvMWMr6OI2LcX0OY8RZ_9YVcx61DJE=.17aa18df-62d9-4009-9f23-fe3aabe9d990@github.com>
References: <Zylg9nIkBHVXyHvMWMr6OI2LcX0OY8RZ_9YVcx61DJE=.17aa18df-62d9-4009-9f23-fe3aabe9d990@github.com>
Message-ID: <0u2hMdsTsfhAmYdzWKQx5sT4fAc9VCZ9woDOWDvukFw=.942c4139-63b5-429e-bc97-9bd1d6517c68@github.com>

On Fri, 5 Feb 2021 21:24:34 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> When a class is compiled against a version of an annotation that is later loaded in an incompatible manner where an enum-typed member is changed into an annotation or vice versa, the reflection API currently throws a `NullPointerException` upon accessing the member. Instead an `AnnotationTypeMismatchException` should be thrown.
> 
> This change adjusts the parsing to trigger the correct exception.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2439

From winterhalter at openjdk.java.net  Tue Apr 20 20:26:04 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Tue, 20 Apr 2021 20:26:04 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <-fco_my21rYwE8RlEaFlsc-g0WL_rPzbLBWllNqY2rw=.9782b940-c827-4dad-bba8-6901f75fdcf8@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

I fully understand your concerns about ByteBuddyAgent.install(). It is
simply a convenience for something that can be meaningful in some contexts
where I prefer offering a simple API. I use it mainly for two purposes:

a) For testing Java agents and integrations against Instrumentation within
the current VM when tests are triggered by tools that do not support
javaagents, also because builds do not bundle jars until after tests are
executed.

b) For purposefully "hacky" test libraries like Mockito that need agent
capabilities without this being meant to be used in production
environments. I have earlier proposed to offer a "jdk.test" module that
offers the  Instrumentation instance via a simple API similar to Byte
Buddy's. The JVM would not load this module unless requested on the command
line. Build tools like Maven's surefire or Gradle's testrunner could then
standardize on loading this module as a convention to give access to this
test module by default such that libraries like Mockito could continue to
function out of the box without the libraries functioning on a standard VM
without extra configuration. As far as I know, mainly test libraries need
this API. This would also emphasise that Mockito and others are meant for
testing and fewer people would abuse it for production applications. People
would also have an explicit means of running a JVM for a production
application or for executing a test.

As for adding the API, my thought is that if the Instrumentation API were
to throw exceptions on some methods/arguments for dynamic agents in the
future, for example for retransformClasses(Object.class), this breaking
change would then simply extend to the proposed "defineClass" method. In
this sense, the Instrumentation API already assumes full power, I find it
not problematic to add the missing bit to this API even if it was
restricted in the future in the same spirit as other methods of the API
would be.

I mentioned JNI as it is a well-known approach to defining a class today,
using a minimal native binding to an interface that directly calls down to
JNI's:

jclass DefineClass(JNIEnv *env, const char *name, jobject loader, const
jbyte *buf, jsize bufLen);

This interface can then simply be used to define any class just as I
propse, even when not writing an agent or attaching. This method makes
class definitions also already trivial for JVMTI agents compared to Java
agents. Unless restricting JNI, the defineClass method is already a low
hanging fruit, but at the cost of having to maintain a tiny bit of native
code. I'd rather see this avoided and a standard API being offered to
agents up to the time that Panama is in place and a JNI restriction is
possibly also included. As a bonus: Once JNI is restricted, Byte Buddy's
"install" would no longer work unless self-attachment (or JNI) is
explicitly allowed. The emulation already requires to run native code while
the Virtual Machine API explicitly checks for the process id of the current
VM against the one that is targeted. With both disabled, self-attachment
would no longer be practically be possible without needing to prune the
capabilities of dynamic agents which is what I understand would be the
desired effect.

>From this viewpoint, I think that adding Instrumentation::defineClass
method does no harm compared to the status quo. And on the upside, it gives
agents an API to migrate to, avoiding the last need of using unsafe. To
make the JVM a safe platform, binding native code would anyways need
restriction and this would then also solve the problem of dynamic agents
attaching from the same VM being used in libraries. This would in my eyes
be the cleanest solution to the self-attachment problem without disturbing
the existing landscape of dynamic agents. To run Mockito, one would then
instead configure Maven surefire or Gradle to run the JVM with
-Djdk.attach.allowAttachSelf=true. Ideally, some "jdk.test" module would be
added at some point, to avoid the overhead of self-attachment, but I think
this better fits into separate debate.

Am Di., 20. Apr. 2021 um 15:38 Uhr schrieb mlbridge[bot] <
***@***.***>:

> *Mailing list message from Alan Bateman ***@***.***> on
> core-libs-dev ***@***.***>:*
>
> On 19/04/2021 22:20, Rafael Winterhalter wrote:
>
> :
> At the moment, it is required for root to switch to the user that owns the
> JVM process as the domain socket is only accessible to that user to avoid
> that users without access to the JVM can inject themselves into a JVM. I am
> not sure if operations teams would be thrilled to have a monitoring agent
> required to run as root, even in these times of Kubernetes.
>
> I mainly have two comments:
>
> 1. The problem is the possibility of self-attach. I think this is the
> problem to solve, a library getting agent privileges without being an
> agent. I think this should be prevented while dynamic attach should
> continue to be possible in today's format. It has proven to be so useful,
> it would be a shame if the current tooling convenience would disappear from
> the JVM. As it's my understanding, JNI is supposed to be restricted in the
> future, in line with Panama. Without this restriction, JNI already allows
> for random class definition, for example, which similarly to an agent
> offers surpassing the majority of JVM restrictions. The second restriction
> would be a control to restrict how a JVM process starts new processes. I
> think both are reasonable restrictions for a library to face which require
> explicit enabling. Especially with the security manager on it's way out,
> certain capabilities should be rethought to begin with. If both are no
> longer freely available, self-attachment is no longer possible anyways and
> dynamic agents could retain their capabilities.
>
> 2. The question of introducing an Instrumentation::defineClass method is
> fully independent of that first question. If a dynamic agent was to be
> restricted, the method could reject classloader/package combinations for
> dynamically loaded agents the same way that
> Instrumentation::retransformClasses would need to. At the same time,
> introducing the method would allow agents to move to an official API with a
> Java 17 baseline which will be the next long-standing base line. I fully
> understand it needs a thorough discussion but it is a less complicated
> problem then (1) and could therefore be decided prior to having found a
> satisfactory solution for it.
>
> I should have been clearer, it's the combination of the two that creates
> the attractive nuisance. I don't think there are any objections to a
> defineClass for agents specified on the command line with -javaagent.
> However we have to be cautious about extending that capability to agents
> that are loaded into a running VM with the attach mechanism.
>
> ByteBuddy looks great for code generation and transforming classes but
> ByteBuddyAgent makes me nervous. It looks like I can deploy
> byte-buddy-agent-<version>.jar on my class path and invoke the public
> static ByteBuddyAgent.install() method to get the Instrumentation object
> for the current VM. That may be convenient for some but this is the
> all-powerful Instrumentation object that shouldn't be leaked to library
> or application code. Now combine this with the proposed defineClass and
> it means that any code on the class path could inject a class into
> java.lang or any run-time package without any agent voodoo or opt-in via
> the command line. That would be difficult genie to re-bottle if it were
> to get traction.
>
> You mentioned restricting JNI in the future. I'm not aware of a definite
> plan or time-frame. Project Panama is pioneering restricting access to
> native operations as a bug or mis-use with the linker API can easily
> crash the VM or breakage in other ways. Extending this to JNI would be a
> logical next step but I could imagine it taking a long time and many
> releases to get there.
>
> As regards this PR then I would be happy to work with you on a revised
> proposed that would limit it to agents specified with -javaagent. That
> would not preclude extending the capability, maybe in a more restricted
> form, to agents loaded into a running VM in the future.
>
> -Alan.
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/3546#issuecomment-823281169>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABCIA4FE2B4DGBZS4QO6SM3TJV7T5ANCNFSM43BSDEGQ>
> .
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From brian.burkhalter at oracle.com  Tue Apr 20 20:38:33 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 20 Apr 2021 20:38:33 +0000
Subject: Image parsing spams stack traces to System.err
In-Reply-To: <s5n18a$7h0$1@ciao.gmane.io>
References: <s5n18a$7h0$1@ciao.gmane.io>
Message-ID: <6DD29BB3-96AB-4B49-8074-459A4741B5B8@oracle.com>

I think this post needs to go to 2d-dev (copied).

> On Apr 20, 2021, at 9:58 AM, Lapo Luchini <lapo at lapo.it> wrote:
> 
> In both OpenJDK 8, 11 and 15 I verified that:
> 
> sun/awt/image/InputStreamImageSource.java
> 
> has "e.printStackTrace()" commands that might better be converted to java.util.logging in order to be able to configure/redirect them to the proper log file each application might decide to use.
> 
> A little bit of more details as reported here (where they suggested this was the proper place):
> https://github.com/AdoptOpenJDK/openjdk-jdk11u/issues/21
> 
> cheers,
> 
> -- 
> Lapo Luchini
> lapo at lapo.it
> 


From naoto at openjdk.java.net  Tue Apr 20 21:19:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 20 Apr 2021 21:19:08 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v6]
In-Reply-To: <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
Message-ID: <ISBMUHz11kgI1vyd6c8RNYuUSGsioi4U57QN5xFLzbw=.82fbc316-f714-4888-b618-feb8702b39aa@github.com>

On Tue, 20 Apr 2021 17:46:38 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated single letter pattern variable names

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From winterhalter at openjdk.java.net  Tue Apr 20 21:36:30 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Tue, 20 Apr 2021 21:36:30 GMT
Subject: Integrated: 8228988: AnnotationParser throws NullPointerException on
 incompatible member type
In-Reply-To: <Zylg9nIkBHVXyHvMWMr6OI2LcX0OY8RZ_9YVcx61DJE=.17aa18df-62d9-4009-9f23-fe3aabe9d990@github.com>
References: <Zylg9nIkBHVXyHvMWMr6OI2LcX0OY8RZ_9YVcx61DJE=.17aa18df-62d9-4009-9f23-fe3aabe9d990@github.com>
Message-ID: <9LAiXvV0J37KT2vz1E_g8cE0awxkRwUGzRkYqHzu4jU=.741af7f5-534e-4a10-aec0-e7e09eae51a4@github.com>

On Fri, 5 Feb 2021 21:24:34 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> When a class is compiled against a version of an annotation that is later loaded in an incompatible manner where an enum-typed member is changed into an annotation or vice versa, the reflection API currently throws a `NullPointerException` upon accessing the member. Instead an `AnnotationTypeMismatchException` should be thrown.
> 
> This change adjusts the parsing to trigger the correct exception.

This pull request has now been integrated.

Changeset: f47faf28
Author:    Rafael Winterhalter <winterhalter at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f47faf28
Stats:     182 lines in 3 files changed: 178 ins; 0 del; 4 mod

8228988: AnnotationParser throws NullPointerException on incompatible member type

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/2439

From naoto at openjdk.java.net  Tue Apr 20 22:35:00 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 20 Apr 2021 22:35:00 GMT
Subject: RFR: 8264208: Console charset API [v11]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <txrEQhraCE8y7d_LfMyIn2kt-HOiN3wfIaizQpwGZtk=.d3d6d695-b9b7-495e-9e25-f8e4e203ed50@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Refined the test case.
 - Merge branch 'master' into JDK-8264208
 - Changed shell based test into java based
 - Added link to Charset#defaultChaset() in InputStreamReader.
 - Modified javadocs per suggestions.
 - Added @see links.
 - Added Console::charset() relation with System.in
 - Added comment to System.out/err init.
 - Reflected further review comments.
 - Reverted PrintStream changes
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/8cc07521...e585d16f

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/238dbb42..e585d16f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=09-10

  Stats: 72701 lines in 1955 files changed: 33448 ins; 34099 del; 5154 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

PR: https://git.openjdk.java.net/jdk/pull/3419

From darcy at openjdk.java.net  Tue Apr 20 23:44:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 20 Apr 2021 23:44:12 GMT
Subject: RFR: 8265591: Remove vestiages of intermediate JSR 175 annotation
 format
Message-ID: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>

During the recent review of JDK-8228988, I noticed again the comments in the annotation parser about support for the pre-GA annotation format used before JDK 5.0 shipped. During the development of annotations, there was a late change to correct a flaw in the annotation encoding, JDK-5020908.

I don't think it is necessary to carry forward support for this transient format any longer and this changeset removes support from both core reflection and javac.

Clean runs of relevant test; I gauge this fix as no-reg hard.

-------------

Commit messages:
 - 8265591: Remove vestiages of intermediate JSR 175 annotation format

Changes: https://git.openjdk.java.net/jdk/pull/3597/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3597&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265591
  Stats: 24 lines in 2 files changed: 0 ins; 19 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3597.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3597/head:pull/3597

PR: https://git.openjdk.java.net/jdk/pull/3597

From darcy at openjdk.java.net  Tue Apr 20 23:52:04 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 20 Apr 2021 23:52:04 GMT
Subject: RFR: 8265591: Remove vestiages of intermediate JSR 175 annotation
 format
In-Reply-To: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
References: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
Message-ID: <v0dGNw055-MiQxZdAYP3z56LTcHcMRzuZCHUdYQJHQE=.4a6cf0b6-06cc-418c-a16e-28aeae3fdbfc@github.com>

On Tue, 20 Apr 2021 23:37:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> During the recent review of JDK-8228988, I noticed again the comments in the annotation parser about support for the pre-GA annotation format used before JDK 5.0 shipped. During the development of annotations, there was a late change to correct a flaw in the annotation encoding, JDK-5020908.
> 
> I don't think it is necessary to carry forward support for this transient format any longer and this changeset removes support from both core reflection and javac.
> 
> Clean runs of relevant test; I gauge this fix as no-reg hard.

PS CSR for the behavioral change: https://bugs.openjdk.java.net/browse/JDK-8265608

-------------

PR: https://git.openjdk.java.net/jdk/pull/3597

From smarks at openjdk.java.net  Wed Apr 21 02:23:09 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 21 Apr 2021 02:23:09 GMT
Subject: RFR: 8262744: Formatter '%g' conversion uses wrong format for
 BigDecimal rounding up to limits [v3]
In-Reply-To: <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
Message-ID: <_elqbinfPX1hdlCpOW7qas6U9NsqcusGkz9sQvyUOQ4=.a0d00170-863e-4422-be00-c5fdb76228b5@github.com>

On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inlining some single use variables

src/java.base/share/classes/java/util/Formatter.java line 3827:

> 3825:                 if ((value.equals(BigDecimal.ZERO))
> 3826:                     || ((value.compareTo(BigDecimal.valueOf(1, 4)) != -1)
> 3827:                         && (value.compareTo(BigDecimal.valueOf(1, -prec)) == -1))) {

Note that `compareTo` in general specifies a negative, zero, or positive return value, but BigDecimal and BigInteger specify a return value of -1, 0, and 1. So the code here that compares against -1 is strictly correct. However, the BigDecimal/BigInteger.compareTo docs say "The suggested idiom..." is a relative comparison against zero.

Indeed, the BigDecimal::compareTo method does always seem to return -1, 0, or 1 so this code is not incorrect. Well, maybe. I checked quickly and the BigDecimal comparison logic is fairly intricate (and also runs through BigInteger) so I might have missed something. Also, BigDecimal is subclassable, so an override of `compareTo` might return something other than -1, 0, or 1, even though strictly speaking this would violate the BigDecimal spec.

I'm wondering if there should be a followup bug that changes these tests to `>= 0` and `< 0`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3363

From smarks at openjdk.java.net  Wed Apr 21 02:59:04 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 21 Apr 2021 02:59:04 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v2]
In-Reply-To: <ROd-lby2BgszUx7xsfo4lQSF82vFRyFPO_d8SaKuFDY=.7b72f90c-474a-464b-bd68-5d79650e4b40@github.com>
References: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
 <ROd-lby2BgszUx7xsfo4lQSF82vFRyFPO_d8SaKuFDY=.7b72f90c-474a-464b-bd68-5d79650e4b40@github.com>
Message-ID: <HlL4VcNx15u9upfRuTujus4H139Mt8d-WRmRWQSIbJc=.e561f91c-2006-443c-8cd4-97d32258a700@github.com>

On Mon, 19 Apr 2021 22:12:30 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Clarifying note on comments mode to explicitly note that whitespace within character classes is ignored.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding differences to Perl 5 note

A few minor wording adjustments. Please update the CSR accordingly and I'll review it too.

src/java.base/share/classes/java/util/regex/Pattern.java line 762:

> 760:  *    character classes. In this class, whitespace inside of character classes
> 761:  *    must be escaped to be considered as part of the regular expression when in
> 762:  *    comments mode.  </p></li>

Editorial: the run of italicized words makes this a bit hard to follow. Suggest:

    In Perl, <i>free-spacing mode</i> (which is called <i>comments mode</i> in this class)

src/java.base/share/classes/java/util/regex/Pattern.java line 832:

> 830:      * <p> Note that comments mode ignores whitespace within a character class
> 831:      * contained in a pattern string. Such whitespace needs to be escaped
> 832:      * in order to be treated as if comments mode were not enabled. </p>

I think this is good, but 1) it would probably be better placed in the "In this mode" paragraph above, around line 825; and 2) it's normative so it shouldn't say "Note that" (which makes it sound informative).

I'd also reword the second sentence a bit, something like

    Such whitespace needs to be escaped in order to be considered significant.

-------------

Changes requested by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3577

From cgo at openjdk.java.net  Wed Apr 21 07:08:06 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 21 Apr 2021 07:08:06 GMT
Subject: RFR: 8265421: java/lang/String/StringRepeat.java test is missing
 a memory requirement [v2]
In-Reply-To: <C4HSfgW-mgXI0-I8ohvSAaHfE7hyS4Za0tvIFPEbiSk=.8fad7187-b14f-4476-a8bc-09b77ed25c9b@github.com>
References: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
 <C4HSfgW-mgXI0-I8ohvSAaHfE7hyS4Za0tvIFPEbiSk=.8fad7187-b14f-4476-a8bc-09b77ed25c9b@github.com>
Message-ID: <cX01UUK8BNSfEJ-Bi4JWbbz9KZ1m-m5yerjPJ3zzQJk=.21e1c8ea-260f-4ead-a4e5-191652032cf1@github.com>

On Mon, 19 Apr 2021 12:50:07 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows:
>> 
>> 
>> $ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test
>> 
>> 
>> I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available.
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes -Xmx2g for the first test case instance, which doesn't require a lot of memory.

Thanks a lot for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3566

From cgo at openjdk.java.net  Wed Apr 21 07:16:03 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 21 Apr 2021 07:16:03 GMT
Subject: Integrated: 8265421: java/lang/String/StringRepeat.java test is
 missing a memory requirement
In-Reply-To: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
References: <7HNsu4W_Vjc7XLoYLHO7JgYh0kxsiRU0Lgm8mrHasvU=.18b50517-7d8f-45ac-9071-a1b4defd8333@github.com>
Message-ID: <lKDM5vS22pMIftvfMhFKlCBkuFihWKQvGPf2vISMAM4=.928f8f39-1a3a-4674-95b3-bc2d6af4938c@github.com>

On Mon, 19 Apr 2021 09:42:09 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Please review the following patch, which fixes the mentioned test case for memory constrained devices. This can be tested on a linux based development machine, using systemd as follows:
> 
> 
> $ systemd-run --user --scope -p MemoryMax=800M -p MemorySwapMax=0 /usr/bin/make TEST="test/jdk/java/lang/String/StringRepeat.java" run-test
> 
> 
> I split up the test case in a part which only executes the small repeat counts, and in one part which executes the huge repeat count. The second part is guarded by a requirement, so it is only executed if enough memory is available.

This pull request has now been integrated.

Changeset: 7146104f
Author:    Christoph G?ttschkes <cgo at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7146104f
Stats:     19 lines in 1 file changed: 13 ins; 1 del; 5 mod

8265421: java/lang/String/StringRepeat.java test is missing a memory requirement

Reviewed-by: jlaskey, shade, ryadav

-------------

PR: https://git.openjdk.java.net/jdk/pull/3566

From dfuchs at openjdk.java.net  Wed Apr 21 09:24:17 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 21 Apr 2021 09:24:17 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v6]
In-Reply-To: <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
Message-ID: <HuY_a_SFC1Pliway8FqR3KnJ2ek8Ar91Cxi4BTK7SsY=.35fb7617-312c-412a-910b-37bd87d82989@github.com>

On Tue, 20 Apr 2021 17:46:38 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated single letter pattern variable names

src/java.base/share/classes/java/time/Duration.java line 723:

> 721:         }
> 722:         if (unit instanceof ChronoUnit u) {
> 723:             switch (u) {

Maybe `u` could be replaced with `chronoUnit` here too

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From plevart at openjdk.java.net  Wed Apr 21 10:34:38 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 21 Apr 2021 10:34:38 GMT
Subject: Integrated: 8265237: String.join and StringJoiner can be improved
 further
In-Reply-To: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
References: <flZpSNSaVq2opLuYsh09eDEnH82ApDqKEEpSuOA5kbo=.d48579f1-8ceb-4604-9c11-2c57ec997e30@github.com>
Message-ID: <VutLWnOIwHNI76XqSd7xDHrWxptzHL67et2BesgNZOE=.55a52f72-9bd8-42b7-84c1-6cbc9f9f95b6@github.com>

On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart <plevart at openjdk.org> wrote:

> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation.
> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package.
> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner.
> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark:
> 
> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce
> 
> The comparative results are here:
> 
> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15
> 
> The jmh-result.json files are here:
> 
> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15
> 
> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation.
> 
> So WDYT?

This pull request has now been integrated.

Changeset: 98cb81b3
Author:    Peter Levart <plevart at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/98cb81b3
Stats:     214 lines in 6 files changed: 174 ins; 17 del; 23 mod

8265237: String.join and StringJoiner can be improved further

Reviewed-by: rriggs, redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/3501

From pconcannon at openjdk.java.net  Wed Apr 21 10:58:34 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 21 Apr 2021 10:58:34 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v6]
In-Reply-To: <QHBgB4c8fVfPhihJFROw2JI0osAegG8lgeggKUhSKtE=.ea2029d7-cc1b-4a75-a8d1-cb3d6efca5a5@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <QHBgB4c8fVfPhihJFROw2JI0osAegG8lgeggKUhSKtE=.ea2029d7-cc1b-4a75-a8d1-cb3d6efca5a5@github.com>
Message-ID: <4TBFMGUFpV1Gf3TmyGUds5mX37fnWQyB07ar6CttkNc=.f174f0f6-639b-402d-88fe-7e4a50f9f678@github.com>

On Wed, 24 Mar 2021 11:06:38 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated single letter pattern variable names
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 168:
> 
>> 166:     private static final TemporalQuery<ZoneId> QUERY_REGION_ONLY = (temporal) -> {
>> 167:         ZoneId zone = temporal.query(TemporalQueries.zoneId());
>> 168:         return (zone != null && (!(zone instanceof ZoneOffset)) ? zone : null);
> 
> i find this code hard to read
> `return (zone != null && (!(zone instanceof ZoneOffset))) ? zone : null;`
> seems better`

Updated in 647bd6b as suggested by Michael Kuhlmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From pconcannon at openjdk.java.net  Wed Apr 21 11:06:20 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 21 Apr 2021 11:06:20 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v6]
In-Reply-To: <HuY_a_SFC1Pliway8FqR3KnJ2ek8Ar91Cxi4BTK7SsY=.35fb7617-312c-412a-910b-37bd87d82989@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
 <HuY_a_SFC1Pliway8FqR3KnJ2ek8Ar91Cxi4BTK7SsY=.35fb7617-312c-412a-910b-37bd87d82989@github.com>
Message-ID: <jVlhvbqiGQxIenMfpUU2dCFbGlPgp38G_C72N06pxR4=.0ff1ef12-c7ce-4b2b-abe5-2701873dacbe@github.com>

On Wed, 21 Apr 2021 09:06:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated single letter pattern variable names
>
> src/java.base/share/classes/java/time/Duration.java line 723:
> 
>> 721:         }
>> 722:         if (unit instanceof ChronoUnit u) {
>> 723:             switch (u) {
> 
> Maybe `u` could be replaced with `chronoUnit` here too

Variable name updated as suggested in 3dc1e07

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From pconcannon at openjdk.java.net  Wed Apr 21 11:06:16 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 21 Apr 2021 11:06:16 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Updated single letter pattern variable name in java/time/Duration
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Updated single letter pattern variable names
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 8263668: Update java.time to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/647bd6b1..3dc1e075

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=05-06

  Stats: 2549 lines in 111 files changed: 1748 ins; 362 del; 439 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170

PR: https://git.openjdk.java.net/jdk/pull/3170

From dfuchs at openjdk.java.net  Wed Apr 21 11:42:41 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 21 Apr 2021 11:42:41 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <aAPU384PiHRK7tcpVWx1U80gImlldjmdwWf9ORr60kc=.33edb9c4-e542-4011-b35c-034284a0a4c6@github.com>

On Wed, 21 Apr 2021 11:06:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 8263668: Update java.time to use instanceof pattern variable

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From egahlin at openjdk.java.net  Wed Apr 21 11:53:33 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 21 Apr 2021 11:53:33 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <Dgx1j0XYG0RYwTa1Hpbg80ETOqU4xhSQB_DiQnfJQKw=.410be2e5-8525-44c3-aab0-c251720ade91@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
 <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
 <Dgx1j0XYG0RYwTa1Hpbg80ETOqU4xhSQB_DiQnfJQKw=.410be2e5-8525-44c3-aab0-c251720ade91@github.com>
Message-ID: <FMxrN5rDKBcTXRfVr1Oh0nUAxXG_mSbSRT_8wgmPZSA=.11d561d9-93a5-49a3-a2f6-1117b48bc728@github.com>

On Wed, 14 Apr 2021 12:14:33 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerCPUThrottlingEvent.java line 44:
>> 
>>> 42: @Category({"Operating System", "Container", "Processor"})
>>> 43: @Description("Container CPU throttling related information.")
>>> 44: public class ContainerCPUThrottlingEvent extends AbstractJDKEvent {
>> 
>> I wonder if we should put all the container events in the same category {"Operating System", "Container"}, Or possibly add them under the already existing categories under "Operating System"?
>
> I guess we could fit those events under `Operating System/Memory` and `Operating System/Processor` categories.
> What about I/O? Currently, there is only `Operating System/Network` category. The options are:
> * Add `Operating System/IO` category and move `Network` to `Operating System/IO/Network`
> * Add `Operation System/FileSystem` category and move the container IO event there
> 
> What would you prefer?

I prefer adding File System (or having separate container category).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From egahlin at openjdk.java.net  Wed Apr 21 11:53:34 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 21 Apr 2021 11:53:34 GMT
Subject: RFR: 8203359: Container level resources events [v7]
In-Reply-To: <e6Z4rBbM_waVNgqs9NQYVG5EZiSAV5s8cOqtdOe6Q9g=.068fc057-98bc-4192-91a1-dcc5a6e1c1b9@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <VfQQscAw_gy6to6NS4kUlABJ_ErFH4_9denWYtB9zE0=.ff5ad719-110a-46c2-97d2-b2641b065949@github.com>
 <ejPb-pIuXnItPJfNsuEqQ3u54Nu38GeN7RYf4ftrapo=.5b71e65c-399f-4933-8490-b897564aa325@github.com>
 <e6Z4rBbM_waVNgqs9NQYVG5EZiSAV5s8cOqtdOe6Q9g=.068fc057-98bc-4192-91a1-dcc5a6e1c1b9@github.com>
Message-ID: <ZtkqOnfGiSZlgEzOjB2kx9k_koY4-BLkUi8BMUJCWV4=.8e4e51f5-9cb7-42d6-ad7c-5482ff838bb5@github.com>

On Wed, 14 Apr 2021 08:28:01 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/jdk.jfr/share/conf/jfr/default.jfc line 1051:
>> 
>>> 1049:       <flag name="class-loading-enabled" label="Class Loading">false</flag>
>>> 1050: 
>>> 1051:       <flag name="container-events-enabled" label="Container Events">true</flag>
>> 
>> I don't think we should create "flag" for "Container Events". Instead we should treat them like CPU and other OS events, always on. Since JFR can be used outside a container, it seems wrong to have this as an option.
>
> Ok. So what would be a good rule-of-thumb for when one should introduce a flag?

I think we want to limit the number flags/options There are already too many, preferably we would have none, but some of the ones we have today, like gc and exception, are necessary, because the impact of have them on by default would be catastrophic (long stop the world pauses and possibly million of events per second).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From egahlin at openjdk.java.net  Wed Apr 21 11:58:35 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 21 Apr 2021 11:58:35 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <hNZI-flA6UWphaEyK3MHZ_oXnV8qWkYNkEC7O17o0Bs=.40e6b763-3600-4352-bfad-487309043d98@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
 <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
 <ZJz55cGDYSoIVUVwjhD_FnF3CMhlEz2URhLCrlYVtno=.0d2ed24f-29c3-4218-bc28-b2177302ee77@github.com>
 <hNZI-flA6UWphaEyK3MHZ_oXnV8qWkYNkEC7O17o0Bs=.40e6b763-3600-4352-bfad-487309043d98@github.com>
Message-ID: <y6mc-tMGPwQ4vlIQscjjRWdqiiNODUt3csXc11yDT1Y=.99296076-0ee5-4a1b-bdd9-ecdecd3ec104@github.com>

On Wed, 14 Apr 2021 14:32:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is taken as reported by cgroups - I didn't want to change the semantics so it does not confuse people familiar with cgroups.
>
> I don't see this event field being set anywhere? Which Metrics API call is this using?

How does it look in proc?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From duke at openjdk.java.net  Wed Apr 21 12:52:34 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 21 Apr 2021 12:52:34 GMT
Subject: Withdrawn: 8013527: calling MethodHandles.lookup on itself leads to
 errors
In-Reply-To: <dHuVwbgOOpmSlQwLoshl9vVAHpkh1scCPNGSdXhasv4=.ec98561a-779f-455a-8476-c07ab02620c9@github.com>
References: <dHuVwbgOOpmSlQwLoshl9vVAHpkh1scCPNGSdXhasv4=.ec98561a-779f-455a-8476-c07ab02620c9@github.com>
Message-ID: <sN8-MMhBl1iROQq7i0kDsO4GyhDr-ba1nV3EpLzlO6c=.2234902a-f7c3-47ac-9558-7be4bc050f53@github.com>

On Wed, 3 Feb 2021 01:50:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> JDK-8013527: calling MethodHandles.lookup on itself leads to errors
> JDK-8257874: MethodHandle injected invoker doesn't have necessary private access
> 
> Johannes Kuhn is also a contributor to this patch.
> 
> A caller-sensitive method can behave differently depending on the identity
> of its immediate caller.  If a method handle for a caller-sensitive method is
> requested, this resulting method handle behaves as if it were called from an
> instruction contained in the lookup class.  The current implementation injects
> a trampoline class (aka the invoker class) which is the caller class invoking
> such caller-sensitive method handle.  It works in all CSMs except `MethodHandles::lookup`
> because the caller-sensitive behavior depends on the module of the caller class,
> the class loader of the caller class, the accessibility of the caller class, or
> the protection domain of the caller class.  The invoker class is a hidden class
> defined in the same runtime package with the same protection domain as the
> lookup class, which is why the current implementation works for all CSMs except
> `MethodHandles::lookup` which uses the caller class as the lookup class.
> 
> Two issues with current implementation:
> 1.  The invoker class only has the package access as the lookup class.  It cannot
>     access private members of the lookup class and its nest members.
> 
>     The fix is to make the invoker class as a nestmate of the lookup class.
> 
> 2.  `MethodHandles::lookup` if invoked via a method handle produces a `Lookup`
>     object of an injected invoker class which is a bug.
> 
> There are two alternatives:
> - define the invoker class with the lookup class as the class data such that
>   `MethodHandles::lookup` will get the caller class from the class data if
>   it's the injected invoker
> - Johannes' proposal [1]: detect if an alternate implementation with an additional
>   trailing caller class parameter is present, use the alternate implementation
>   and bind the method handle with the lookup class as the caller class argument.
> 
> There has been several discussions on the improvement to support caller sensitive
> methods for example the calling sequences and security implication.   I have
> looked at how each CSM uses the caller class.  The second approach (i.e. 
> defining an alternate implementation for a caller-sensitive method taking
> an additional caller class parameter) does not work for non-static non-final
> caller-sensitive method.  In addition, it is not ideal to pollute the source
> code to provide an alternatve implementation for all 120+ caller-sensitive methods
> whereas the injected invoker works for all except `MethodHandles::lookup`.
> 
> I propose to use both approaches.   We can add an alternative implementation for
> a caller-sensitive method when desirable such as `MethodHandles::lookup` in
> this PR.  For the injected invoker case, one could extract the original lookup
> class from class data if needed.
> 
> test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSM.java ensures that
> no new non-static non-final caller-sensitive method will be added to the JDK.
> I extend this test to catch that non-static non-final caller-sensitive method
> cannot have the alternate implementation taking the additional caller class
> parameter.
> 
> This fix for JDK-8013527 is needed by the prototype for JDK-6824466 I'm working on.
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.html

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2367

From github.com+741251+turbanoff at openjdk.java.net  Wed Apr 21 13:04:36 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 21 Apr 2021 13:04:36 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>

On Wed, 21 Apr 2021 11:06:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 8263668: Update java.time to use instanceof pattern variable

I was able to find (with IntelliJ IDEA help) few more places to improve

    java.time   27 warnings 
        class Clock   2 warnings 
            class FixedClock   1 warning 
                method equals(Object)   1 warning 
                    WARNING Variable 'other' can be replaced with pattern variable 
            class OffsetClock   1 warning 
                method equals(Object)   1 warning 
                    WARNING Variable 'other' can be replaced with pattern variable 
        class Instant   2 warnings 
            method until(Temporal, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class LocalDate   5 warnings 
            method minus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
            method plus(long, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method plus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToAdd' can be replaced with pattern variable 
            method range(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class LocalDateTime   8 warnings 
            method get(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method getLong(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method isSupported(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method minus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
            method plus(long, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method plus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToAdd' can be replaced with pattern variable 
            method range(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class LocalTime   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class OffsetDateTime   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class Year   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class YearMonth   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class ZonedDateTime   6 warnings 
            method equals(Object)   1 warning 
                WARNING Variable 'other' can be replaced with pattern variable 
            method minus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
            method plus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToAdd' can be replaced with pattern variable 
            method with(TemporalAdjuster)   2 warnings 
                WARNING Variable 'odt' can be replaced with pattern variable 
                WARNING Variable 'instant' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
    java.time.chrono   13 warnings 
        class ChronoLocalDateImpl   1 warning 
            method plus(long, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class ChronoLocalDateTimeImpl   6 warnings 
            method get(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method getLong(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method isSupported(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method plus(long, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method range(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class ChronoPeriodImpl   1 warning 
            method validateAmount(TemporalAmount)   1 warning 
                WARNING Variable 'period' can be replaced with pattern variable 
        class ChronoZonedDateTimeImpl   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class HijrahDate   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class JapaneseDate   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class MinguoDate   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class ThaiBuddhistDate   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
    java.time.format   3 warnings 
        class DecimalStyle   1 warning 
            method equals(Object)   1 warning 
                WARNING Variable 'other' can be replaced with pattern variable 
        class Parsed   2 warnings 
            method resolveFields()   2 warnings 
                WARNING Variable 'czdt' can be replaced with pattern variable 
                WARNING Variable 'cldt' can be replaced with pattern variable 
    java.time.zone   1 warning 
        class TzdbZoneRulesProvider   1 warning 
            method provideRules(String, boolean)   1 warning 
                WARNING Variable 'bytes' can be replaced with pattern variable 

Do you have plans to adjust them too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From jlaskey at openjdk.java.net  Wed Apr 21 13:13:16 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 21 Apr 2021 13:13:16 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v6]
In-Reply-To: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
Message-ID: <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>

> Move makeXXXSpilterator from public (@hidden) to protected. No API ch

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 eight additional commits since the last revision:

 - Merge branch 'master' into 8265137
 - Remove @hidden
 - Correct the hierarchy of Random
 - Remove extraneous references to makeXXXSpliterator
 - Move makeXXXSpliterator methods to RandomSupport
 - change static final from 'proxy' to 'PROXY'
 - Make makeXXXSpliterator final
 - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3469/files
  - new: https://git.openjdk.java.net/jdk/pull/3469/files/d72575d5..3381f008

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=04-05

  Stats: 39799 lines in 1366 files changed: 8333 ins; 26676 del; 4790 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3469.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469

PR: https://git.openjdk.java.net/jdk/pull/3469

From jbachorik at openjdk.java.net  Wed Apr 21 13:24:34 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 21 Apr 2021 13:24:34 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <y6mc-tMGPwQ4vlIQscjjRWdqiiNODUt3csXc11yDT1Y=.99296076-0ee5-4a1b-bdd9-ecdecd3ec104@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
 <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
 <ZJz55cGDYSoIVUVwjhD_FnF3CMhlEz2URhLCrlYVtno=.0d2ed24f-29c3-4218-bc28-b2177302ee77@github.com>
 <hNZI-flA6UWphaEyK3MHZ_oXnV8qWkYNkEC7O17o0Bs=.40e6b763-3600-4352-bfad-487309043d98@github.com>
 <y6mc-tMGPwQ4vlIQscjjRWdqiiNODUt3csXc11yDT1Y=.99296076-0ee5-4a1b-bdd9-ecdecd3ec104@github.com>
Message-ID: <42WjammIoZ99JVaAnFVEw_eY4OY2M0Px8-wUeJcOStw=.d004d6f9-18cf-457b-94e4-6d545ba6dee5@github.com>

On Wed, 21 Apr 2021 11:55:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I don't see this event field being set anywhere? Which Metrics API call is this using?
>
> How does it look in proc?

This was based on https://github.com/openjdk/jdk/blob/da860290c2657c0fb1de8c77c8dffdb35f1cf938/src/java.base/linux/classes/jdk/internal/platform/CgroupV1Metrics.java#L149

However, that metric is  'internal'  only so it really does not make sense to keep it here and is there only by mistake.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From jbachorik at openjdk.java.net  Wed Apr 21 13:34:29 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 21 Apr 2021 13:34:29 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <FMxrN5rDKBcTXRfVr1Oh0nUAxXG_mSbSRT_8wgmPZSA=.11d561d9-93a5-49a3-a2f6-1117b48bc728@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
 <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
 <Dgx1j0XYG0RYwTa1Hpbg80ETOqU4xhSQB_DiQnfJQKw=.410be2e5-8525-44c3-aab0-c251720ade91@github.com>
 <FMxrN5rDKBcTXRfVr1Oh0nUAxXG_mSbSRT_8wgmPZSA=.11d561d9-93a5-49a3-a2f6-1117b48bc728@github.com>
Message-ID: <Sti3WgBHH023ue7KANqiobDwHLSCDkW9o_h7vRzMbNU=.b4c0a5df-3cfd-4a7b-b242-c1407f05a1e1@github.com>

On Wed, 21 Apr 2021 11:50:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I guess we could fit those events under `Operating System/Memory` and `Operating System/Processor` categories.
>> What about I/O? Currently, there is only `Operating System/Network` category. The options are:
>> * Add `Operating System/IO` category and move `Network` to `Operating System/IO/Network`
>> * Add `Operation System/FileSystem` category and move the container IO event there
>> 
>> What would you prefer?
>
> I prefer adding File System (or having separate container category).

Added `Operating System/File System` category

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From jbachorik at openjdk.java.net  Wed Apr 21 13:34:28 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 21 Apr 2021 13:34:28 GMT
Subject: RFR: 8203359: Container level resources events [v9]
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <jGPUMTr4BuKk_7hI067HqZ_x8DnTIqq_qUw9wVbEz0U=.e4f82b2e-8280-4162-80ff-5c15e0d50538@github.com>

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Fix event metadata

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3126/files
  - new: https://git.openjdk.java.net/jdk/pull/3126/files/67a61bd7..f766faf0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=07-08

  Stats: 36 lines in 5 files changed: 0 ins; 5 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126

PR: https://git.openjdk.java.net/jdk/pull/3126

From jbachorik at openjdk.java.net  Wed Apr 21 13:34:36 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 21 Apr 2021 13:34:36 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
 <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
Message-ID: <yJja5Z05TnEgHTq0moy5gG3eLIPsECYlT7ZVUO9uCo8=.7705fc24-104e-49b0-aadb-56aaab127fc6@github.com>

On Wed, 14 Apr 2021 10:26:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Roll back conditional registration of container events
>>  - Remove container events flag
>>  - Remove trailing spaces
>>  - Doh
>>  - Report container type and register events conditionally
>>  - Remove unused test files
>>  - Initial test support for JFR container events
>>  - Update the JFR control files
>>  - Split off the CPU throttling metrics
>>  - Formatting spaces
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/e80012ed...67a61bd7
>
> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerCPUThrottlingEvent.java line 46:
> 
>> 44: public class ContainerCPUThrottlingEvent extends AbstractJDKEvent {
>> 45:   @Label("CPU Elapsed Slices")
>> 46:   @Description("Number of time-slice periods that have elapsed if a CPU quota has been setup for the container.")
> 
> If the description is one sentence, period should not be included.

Fixed in all locations

> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerCPUUsageEvent.java line 46:
> 
>> 44: public class ContainerCPUUsageEvent extends AbstractJDKEvent {
>> 45:   @Label("CPU Time")
>> 46:   @Description("Aggregate time, in nanoseconds, consumed by all tasks in the container.")
> 
> We usually skip the unit "nanoseconds" in descriptions when the field has a content type that describes the unit.

Gone

> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerConfigurationEvent.java line 45:
> 
>> 43: @Description("A set of container specific attributes.")
>> 44: public final class ContainerConfigurationEvent extends AbstractJDKEvent {
>> 45:     @Label("Container type")
> 
> Capitalize "type" in the label

Done

> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerConfigurationEvent.java line 78:
> 
>> 76: 
>> 77:     @Label("Memory and Swap Limit")
>> 78:     @Description("Maximum amount of physical memory and swap space, in bytes, that can be allocated in the container.")
> 
> No need to mention bytes in the description when the field has DataAmount annotation.

Yep. Done.

> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerIOUsageEvent.java line 47:
> 
>> 45: public class ContainerIOUsageEvent extends AbstractJDKEvent {
>> 46: 
>> 47:   @Label("BlkIO Request Count")
> 
> Change to "Block IO"

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From jbachorik at openjdk.java.net  Wed Apr 21 13:34:36 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 21 Apr 2021 13:34:36 GMT
Subject: RFR: 8203359: Container level resources events [v8]
In-Reply-To: <42WjammIoZ99JVaAnFVEw_eY4OY2M0Px8-wUeJcOStw=.d004d6f9-18cf-457b-94e4-6d545ba6dee5@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <PEgjB5PpHrDwYtDoegx47cfbKrzGu7QnJ11uUfUTiCM=.e342420b-e627-4839-a5ee-d3be6450cd5b@github.com>
 <8wCe1gbUdIgT2YwR0UnvxeffOCTGgwvzhUnVx3qD5eo=.064af4e1-cdf3-4c87-9022-3a2d9c1aa115@github.com>
 <ZJz55cGDYSoIVUVwjhD_FnF3CMhlEz2URhLCrlYVtno=.0d2ed24f-29c3-4218-bc28-b2177302ee77@github.com>
 <hNZI-flA6UWphaEyK3MHZ_oXnV8qWkYNkEC7O17o0Bs=.40e6b763-3600-4352-bfad-487309043d98@github.com>
 <y6mc-tMGPwQ4vlIQscjjRWdqiiNODUt3csXc11yDT1Y=.99296076-0ee5-4a1b-bdd9-ecdecd3ec104@github.com>
 <42WjammIoZ99JVaAnFVEw_eY4OY2M0Px8-wUeJcOStw=.d004d6f9-18cf-457b-94e4-6d545ba6dee5@github.com>
Message-ID: <2VqYXcbzZuoH_knhppAvuB9Rej38DqwKk_3COHUhwA4=.6803eb45-791f-492d-8095-4979069c8137@github.com>

On Wed, 21 Apr 2021 13:21:32 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> How does it look in proc?
>
> This was based on https://github.com/openjdk/jdk/blob/da860290c2657c0fb1de8c77c8dffdb35f1cf938/src/java.base/linux/classes/jdk/internal/platform/CgroupV1Metrics.java#L149
> 
> However, that metric is  'internal'  only so it really does not make sense to keep it here and is there only by mistake.

Removed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From jbachorik at openjdk.java.net  Wed Apr 21 13:34:37 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 21 Apr 2021 13:34:37 GMT
Subject: RFR: 8203359: Container level resources events [v7]
In-Reply-To: <ZtkqOnfGiSZlgEzOjB2kx9k_koY4-BLkUi8BMUJCWV4=.8e4e51f5-9cb7-42d6-ad7c-5482ff838bb5@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <VfQQscAw_gy6to6NS4kUlABJ_ErFH4_9denWYtB9zE0=.ff5ad719-110a-46c2-97d2-b2641b065949@github.com>
 <ejPb-pIuXnItPJfNsuEqQ3u54Nu38GeN7RYf4ftrapo=.5b71e65c-399f-4933-8490-b897564aa325@github.com>
 <e6Z4rBbM_waVNgqs9NQYVG5EZiSAV5s8cOqtdOe6Q9g=.068fc057-98bc-4192-91a1-dcc5a6e1c1b9@github.com>
 <ZtkqOnfGiSZlgEzOjB2kx9k_koY4-BLkUi8BMUJCWV4=.8e4e51f5-9cb7-42d6-ad7c-5482ff838bb5@github.com>
Message-ID: <eANmuJbmiUF1-ld4yJVRWGnoOmnSgzg2pYGWBw4BJ2Q=.a1e126da-8243-4e61-ba7b-e4bc429db464@github.com>

On Wed, 21 Apr 2021 11:49:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Ok. So what would be a good rule-of-thumb for when one should introduce a flag?
>
> I think we want to limit the number flags/options There are already too many, preferably we would have none, but some of the ones we have today, like gc and exception, are necessary, because the impact of have them on by default would be catastrophic (long stop the world pauses and possibly million of events per second).

Thanks!
Removed the flag.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From duke at openjdk.java.net  Wed Apr 21 13:38:41 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 21 Apr 2021 13:38:41 GMT
Subject: Withdrawn: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <pDP5xeFMzByh8WRd5O5mePAKLL8iQl1fsbrjzbOz-AQ=.ce5414cf-66ca-4c58-b49e-4e52df238b71@github.com>

On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611

From rriggs at openjdk.java.net  Wed Apr 21 14:13:37 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 21 Apr 2021 14:13:37 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <Owozh-k2ldLp4iB1sNOo-ExOtPg8icaSENwW_fMF4vs=.7c7d9591-4c70-4c1d-8a52-1e919416039b@github.com>

On Wed, 21 Apr 2021 11:06:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 8263668: Update java.time to use instanceof pattern variable

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From pconcannon at openjdk.java.net  Wed Apr 21 14:37:37 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 21 Apr 2021 14:37:37 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
 <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
Message-ID: <qt4ydRX6jyAGi4BhIh4NDH_6hOaTclEbeiAusq3ociI=.9f3f206d-bd62-451c-9774-42914d86b8ab@github.com>

On Wed, 21 Apr 2021 13:02:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I was able to find (with IntelliJ IDEA help) few more places to improve
> 
> ```
>     java.time   27 warnings 
>         class Clock   2 warnings 
>             class FixedClock   1 warning 
>                 method equals(Object)   1 warning 
>                     WARNING Variable 'other' can be replaced with pattern variable 
>             class OffsetClock   1 warning 
>                 method equals(Object)   1 warning 
>                     WARNING Variable 'other' can be replaced with pattern variable 
>         class Instant   2 warnings 
>             method until(Temporal, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalDate   5 warnings 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalDateTime   8 warnings 
>             method get(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method getLong(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method isSupported(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalTime   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class OffsetDateTime   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class Year   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class YearMonth   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ZonedDateTime   6 warnings 
>             method equals(Object)   1 warning 
>                 WARNING Variable 'other' can be replaced with pattern variable 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method with(TemporalAdjuster)   2 warnings 
>                 WARNING Variable 'odt' can be replaced with pattern variable 
>                 WARNING Variable 'instant' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>     java.time.chrono   13 warnings 
>         class ChronoLocalDateImpl   1 warning 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ChronoLocalDateTimeImpl   6 warnings 
>             method get(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method getLong(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method isSupported(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ChronoPeriodImpl   1 warning 
>             method validateAmount(TemporalAmount)   1 warning 
>                 WARNING Variable 'period' can be replaced with pattern variable 
>         class ChronoZonedDateTimeImpl   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class HijrahDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class JapaneseDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class MinguoDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ThaiBuddhistDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>     java.time.format   3 warnings 
>         class DecimalStyle   1 warning 
>             method equals(Object)   1 warning 
>                 WARNING Variable 'other' can be replaced with pattern variable 
>         class Parsed   2 warnings 
>             method resolveFields()   2 warnings 
>                 WARNING Variable 'czdt' can be replaced with pattern variable 
>                 WARNING Variable 'cldt' can be replaced with pattern variable 
>     java.time.zone   1 warning 
>         class TzdbZoneRulesProvider   1 warning 
>             method provideRules(String, boolean)   1 warning 
>                 WARNING Variable 'bytes' can be replaced with pattern variable 
> ```
> 
> Do you have plans to adjust them too?

Hi @turbanoff, thanks for finding these. Will take a look shortly!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From mcimadamore at openjdk.java.net  Wed Apr 21 14:45:34 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 21 Apr 2021 14:45:34 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v3]
In-Reply-To: <G43LId0M-ZZiM447iIsG4geyGogSR7HryckiLcXDj6I=.82585196-9db7-45fc-9688-b9ef9d2507ab@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <G43LId0M-ZZiM447iIsG4geyGogSR7HryckiLcXDj6I=.82585196-9db7-45fc-9688-b9ef9d2507ab@github.com>
Message-ID: <W7UzRgAEJWfnbHO1cwpg7V0Cf4rns4dDZIQocylhkmc=.812c007c-c8ab-4d0d-b644-f88c9866c854@github.com>

On Fri, 16 Apr 2021 03:35:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>> 
>> Thanks
>> 
>> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating comment after review feedback

Compiler changes look good (I have not checked SymbolGenerator).

Why were some tests removed?

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3526

From github.com+1059453+fleshgrinder at openjdk.java.net  Wed Apr 21 14:55:37 2021
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Wed, 21 Apr 2021 14:55:37 GMT
Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz
 variant
In-Reply-To: <NfEhSpKiiOh0bt2ociNETgE8wpvJDbxna_y5dwKY4_k=.cd887be7-2684-4508-9f04-a706af928f1e@github.com>
References: <NfEhSpKiiOh0bt2ociNETgE8wpvJDbxna_y5dwKY4_k=.cd887be7-2684-4508-9f04-a706af928f1e@github.com>
Message-ID: <Sq-gpB83KVeQavytr9F1szFzaXzoKCduWdE4021CFVU=.43e6343d-352b-40e1-9f71-3e54048234e7@github.com>

On Thu, 26 Nov 2020 18:51:10 GMT, Richard Fussenegger <github.com+1059453+Fleshgrinder at openjdk.org> wrote:

> 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant

Active

-------------

PR: https://git.openjdk.java.net/jdk/pull/1467

From github.com+1059453+fleshgrinder at openjdk.java.net  Wed Apr 21 14:55:39 2021
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Wed, 21 Apr 2021 14:55:39 GMT
Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and
 write to DataOutput [v3]
In-Reply-To: <iAEAGHn8OGv0fHyvwdA1jQGMMmWifapE-df692ao3ik=.92b80822-7bbc-43ec-a926-525f01f4109e@github.com>
References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>
 <iAEAGHn8OGv0fHyvwdA1jQGMMmWifapE-df692ao3ik=.92b80822-7bbc-43ec-a926-525f01f4109e@github.com>
Message-ID: <JQ-3NMJ0r6rl8_Z3marGeufMvLBxKi2rsEYB3_q4UHA=.76fbe532-9eb1-493e-a29f-476415403e67@github.com>

On Sat, 28 Nov 2020 10:12:10 GMT, Richard Fussenegger <github.com+1059453+Fleshgrinder at openjdk.org> wrote:

>> Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set.
>> 
>> Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request.
>
> Richard Fussenegger has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Active

-------------

PR: https://git.openjdk.java.net/jdk/pull/1465

From scolebourne at openjdk.java.net  Wed Apr 21 15:06:38 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 21 Apr 2021 15:06:38 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <LLSYYGCT-Pk_vgJczrWs8PxurUz2ogf6E5pMtldA1OA=.77cb7c98-6382-42fe-9568-6f7d78a3f261@github.com>

On Wed, 21 Apr 2021 11:06:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 8263668: Update java.time to use instanceof pattern variable

Marked as reviewed by scolebourne (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From vromero at openjdk.java.net  Wed Apr 21 15:13:33 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 21 Apr 2021 15:13:33 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v3]
In-Reply-To: <W7UzRgAEJWfnbHO1cwpg7V0Cf4rns4dDZIQocylhkmc=.812c007c-c8ab-4d0d-b644-f88c9866c854@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <G43LId0M-ZZiM447iIsG4geyGogSR7HryckiLcXDj6I=.82585196-9db7-45fc-9688-b9ef9d2507ab@github.com>
 <W7UzRgAEJWfnbHO1cwpg7V0Cf4rns4dDZIQocylhkmc=.812c007c-c8ab-4d0d-b644-f88c9866c854@github.com>
Message-ID: <2gJQiuoDTZDgr62xRlnZLCoL1-EFjUCSHsKBrSpPV2U=.1918b494-34bb-4f1a-939b-9a931b583117@github.com>

On Wed, 21 Apr 2021 14:42:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Compiler changes look good (I have not checked SymbolGenerator).
> 
> Why were some tests removed?

thanks for the review. The removed tests were already covered in langtools regression tests, so I only removed duplicated tests

-------------

PR: https://git.openjdk.java.net/jdk/pull/3526

From naoto at openjdk.java.net  Wed Apr 21 15:30:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 21 Apr 2021 15:30:40 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <2gU2LhTY7XSoyzaNjLa7NWDWsZ-EJHYlQ-vpwoLg9Jk=.ba87d778-be86-44b8-a20b-d47e457ae389@github.com>

On Wed, 21 Apr 2021 11:06:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 8263668: Update java.time to use instanceof pattern variable

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From github.com+4312191+fmeum at openjdk.java.net  Wed Apr 21 15:40:53 2021
From: github.com+4312191+fmeum at openjdk.java.net (Fabian Meumertzheim)
Date: Wed, 21 Apr 2021 15:40:53 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw undocumented
 ArithmeticException
Message-ID: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>

Adds missing @throws declarations for ArithmeticException to the public
function
java.math.BigDecimal#stripTrailingZeros
as well as the private helper functions
java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long)
java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long)

stripTrailingZeros calls one of the two helper functions, both of which
can repeatedly decrease the scale by 1 until it underflows. If it does,
the call to checkScale will result in an ArithmeticException (overflow).

-------------

Commit messages:
 - 8264161: ArithmeticException not declared for BigDecimal#stripTrailingZeros

Changes: https://git.openjdk.java.net/jdk/pull/3189/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3189&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264161
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3189.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3189/head:pull/3189

PR: https://git.openjdk.java.net/jdk/pull/3189

From robilad at openjdk.java.net  Wed Apr 21 15:40:53 2021
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Wed, 21 Apr 2021 15:40:53 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
Message-ID: <mbuO6Xk-i_LOu1sMUOcgp1tLhkXpEV6fhDIEmv6CVHY=.ae0c2d63-edea-4e60-9a13-1625fa9b8cf1@github.com>

On Thu, 25 Mar 2021 08:19:24 GMT, Fabian Meumertzheim <github.com+4312191+fmeum at openjdk.org> wrote:

> Adds missing @throws declarations for ArithmeticException to the public
> function
> java.math.BigDecimal#stripTrailingZeros
> as well as the private helper functions
> java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long)
> java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long)
> 
> stripTrailingZeros calls one of the two helper functions, both of which
> can repeatedly decrease the scale by 1 until it underflows. If it does,
> the call to checkScale will result in an ArithmeticException (overflow).

Hi, please send me an e-mail at Dalibor.topic at oracle.com so that I can verify your account.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3189

From chegar at openjdk.java.net  Wed Apr 21 15:41:40 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 21 Apr 2021 15:41:40 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <mlfuFl9YvwTdMkyEHFDLEyaRfXIlI3V8M6ZbNe4J9xs=.631d2bd4-6706-4d67-ab6e-4d7a46f48dc8@github.com>

On Wed, 21 Apr 2021 11:06:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 8263668: Update java.time to use instanceof pattern variable

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From igraves at openjdk.java.net  Wed Apr 21 15:48:35 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 21 Apr 2021 15:48:35 GMT
Subject: Integrated: 8037397: RegEx pattern matching loses character class
 after intersection (&&) operator
In-Reply-To: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
Message-ID: <ZwYULTuLSTNvE7mqBYhVp3zUy-syjz48DNzPC3tvLxw=.ec10b832-f927-447d-b52a-cfd92a5d47fe@github.com>

On Wed, 31 Mar 2021 20:38:33 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones.

This pull request has now been integrated.

Changeset: b337f633
Author:    Ian Graves <igraves at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b337f633
Stats:     41 lines in 2 files changed: 38 ins; 0 del; 3 mod

8037397: RegEx pattern matching loses character class after intersection (&&) operator

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/3291

From ron.pressler at oracle.com  Wed Apr 21 15:53:43 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 21 Apr 2021 15:53:43 +0000
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <-fco_my21rYwE8RlEaFlsc-g0WL_rPzbLBWllNqY2rw=.9782b940-c827-4dad-bba8-6901f75fdcf8@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <-fco_my21rYwE8RlEaFlsc-g0WL_rPzbLBWllNqY2rw=.9782b940-c827-4dad-bba8-6901f75fdcf8@github.com>
Message-ID: <50F9CB87-C727-440B-82BE-D282B308B7A2@oracle.com>

I think you?re coming to this discussion with a very different perspective from us, which
makes understanding what is or isn?t on the table unclear, and also steers the ideas in
directions that are different from the one we?re going.

Our goal is not to maintain some status quo until such time we decide to restrict it. We?ve
started on a long process of strengthening the platform?s integrity, both to increase security
and to help with the ecosystem?s maintenance. Making some things that are possible today
less ?convenient? is intentional. Locked doors are less convenient than unlocked ones, but 
sometimes you can only strive to increase convenience under the hard constraint that doors
must be locked. This is where we are: we?ve decided doors will be locked unless explicitly 
unlocked.

But this is a process. As long as there are gaps in the garden fence ? Unsafe, self-attach, JNI ? 
the locks can be circumvented. Rather than fixing all those loopholes at once, we?re doing it 
gradually one at a time. This does mean that a motivated developer can circumvent the locks up 
until the point the last loophole is closed, but the hope is that, knowing where we?re headed, library 
developers will gradually accept the reality of this direction (or not prepare their users for the coming
changes, keep using those gaps that are still open to them, and then surprise their users when the
last of them is closed).

Suggestions should, therefore, focus on ideas compatible with this vision. To be more constructive
and  less frustrating, the discussion should proceed under this assumption, even if it means 
accepting that some things will be less convenient than they are today.

For example, self-attach is not the only issue. Leaking powerful Instrumentation objects to libraries
circumvents encapsulation barriers without there being a key placed in the lock through the command
line. That this can be circumvented today is irrelevant, as these workarounds will be *gradually*
removed. I hope the operations people will be thrilled with the platform?s increased security and 
reduced maintenance pain when upgrading JDK versions, but either way, they should start 
preparing for the new reality sooner rather than later. Our goal, then, should be to make people?s life 
easier, but only under these constraints, that, at this point, should be taken as an axiom for the purpose 
of discussion.

? Ron

> On 20 Apr 2021, at 21:26, Rafael Winterhalter <winterhalter at openjdk.java.net> wrote:
> 
> On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:
> 
>>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>> 
>> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>  8200559: Java agents doing instrumentation need a means to define auxiliary classes
> 
> I fully understand your concerns about ByteBuddyAgent.install(). It is
> simply a convenience for something that can be meaningful in some contexts
> where I prefer offering a simple API. I use it mainly for two purposes:
> 
> a) For testing Java agents and integrations against Instrumentation within
> the current VM when tests are triggered by tools that do not support
> javaagents, also because builds do not bundle jars until after tests are
> executed.
> 
> b) For purposefully "hacky" test libraries like Mockito that need agent
> capabilities without this being meant to be used in production
> environments. I have earlier proposed to offer a "jdk.test" module that
> offers the  Instrumentation instance via a simple API similar to Byte
> Buddy's. The JVM would not load this module unless requested on the command
> line. Build tools like Maven's surefire or Gradle's testrunner could then
> standardize on loading this module as a convention to give access to this
> test module by default such that libraries like Mockito could continue to
> function out of the box without the libraries functioning on a standard VM
> without extra configuration. As far as I know, mainly test libraries need
> this API. This would also emphasise that Mockito and others are meant for
> testing and fewer people would abuse it for production applications. People
> would also have an explicit means of running a JVM for a production
> application or for executing a test.
> 
> As for adding the API, my thought is that if the Instrumentation API were
> to throw exceptions on some methods/arguments for dynamic agents in the
> future, for example for retransformClasses(Object.class), this breaking
> change would then simply extend to the proposed "defineClass" method. In
> this sense, the Instrumentation API already assumes full power, I find it
> not problematic to add the missing bit to this API even if it was
> restricted in the future in the same spirit as other methods of the API
> would be.
> 
> I mentioned JNI as it is a well-known approach to defining a class today,
> using a minimal native binding to an interface that directly calls down to
> JNI's:
> 
> jclass DefineClass(JNIEnv *env, const char *name, jobject loader, const
> jbyte *buf, jsize bufLen);
> 
> This interface can then simply be used to define any class just as I
> propse, even when not writing an agent or attaching. This method makes
> class definitions also already trivial for JVMTI agents compared to Java
> agents. Unless restricting JNI, the defineClass method is already a low
> hanging fruit, but at the cost of having to maintain a tiny bit of native
> code. I'd rather see this avoided and a standard API being offered to
> agents up to the time that Panama is in place and a JNI restriction is
> possibly also included. As a bonus: Once JNI is restricted, Byte Buddy's
> "install" would no longer work unless self-attachment (or JNI) is
> explicitly allowed. The emulation already requires to run native code while
> the Virtual Machine API explicitly checks for the process id of the current
> VM against the one that is targeted. With both disabled, self-attachment
> would no longer be practically be possible without needing to prune the
> capabilities of dynamic agents which is what I understand would be the
> desired effect.
> 
> From this viewpoint, I think that adding Instrumentation::defineClass
> method does no harm compared to the status quo. And on the upside, it gives
> agents an API to migrate to, avoiding the last need of using unsafe. To
> make the JVM a safe platform, binding native code would anyways need
> restriction and this would then also solve the problem of dynamic agents
> attaching from the same VM being used in libraries. This would in my eyes
> be the cleanest solution to the self-attachment problem without disturbing
> the existing landscape of dynamic agents. To run Mockito, one would then
> instead configure Maven surefire or Gradle to run the JVM with
> -Djdk.attach.allowAttachSelf=true. Ideally, some "jdk.test" module would be
> added at some point, to avoid the overhead of self-attachment, but I think
> this better fits into separate debate.
> 
> Am Di., 20. Apr. 2021 um 15:38 Uhr schrieb mlbridge[bot] <
> ***@***.***>:
> 
>> *Mailing list message from Alan Bateman ***@***.***> on
>> core-libs-dev ***@***.***>:*
>> 
>> On 19/04/2021 22:20, Rafael Winterhalter wrote:
>> 
>> :
>> At the moment, it is required for root to switch to the user that owns the
>> JVM process as the domain socket is only accessible to that user to avoid
>> that users without access to the JVM can inject themselves into a JVM. I am
>> not sure if operations teams would be thrilled to have a monitoring agent
>> required to run as root, even in these times of Kubernetes.
>> 
>> I mainly have two comments:
>> 
>> 1. The problem is the possibility of self-attach. I think this is the
>> problem to solve, a library getting agent privileges without being an
>> agent. I think this should be prevented while dynamic attach should
>> continue to be possible in today's format. It has proven to be so useful,
>> it would be a shame if the current tooling convenience would disappear from
>> the JVM. As it's my understanding, JNI is supposed to be restricted in the
>> future, in line with Panama. Without this restriction, JNI already allows
>> for random class definition, for example, which similarly to an agent
>> offers surpassing the majority of JVM restrictions. The second restriction
>> would be a control to restrict how a JVM process starts new processes. I
>> think both are reasonable restrictions for a library to face which require
>> explicit enabling. Especially with the security manager on it's way out,
>> certain capabilities should be rethought to begin with. If both are no
>> longer freely available, self-attachment is no longer possible anyways and
>> dynamic agents could retain their capabilities.
>> 
>> 2. The question of introducing an Instrumentation::defineClass method is
>> fully independent of that first question. If a dynamic agent was to be
>> restricted, the method could reject classloader/package combinations for
>> dynamically loaded agents the same way that
>> Instrumentation::retransformClasses would need to. At the same time,
>> introducing the method would allow agents to move to an official API with a
>> Java 17 baseline which will be the next long-standing base line. I fully
>> understand it needs a thorough discussion but it is a less complicated
>> problem then (1) and could therefore be decided prior to having found a
>> satisfactory solution for it.
>> 
>> I should have been clearer, it's the combination of the two that creates
>> the attractive nuisance. I don't think there are any objections to a
>> defineClass for agents specified on the command line with -javaagent.
>> However we have to be cautious about extending that capability to agents
>> that are loaded into a running VM with the attach mechanism.
>> 
>> ByteBuddy looks great for code generation and transforming classes but
>> ByteBuddyAgent makes me nervous. It looks like I can deploy
>> byte-buddy-agent-<version>.jar on my class path and invoke the public
>> static ByteBuddyAgent.install() method to get the Instrumentation object
>> for the current VM. That may be convenient for some but this is the
>> all-powerful Instrumentation object that shouldn't be leaked to library
>> or application code. Now combine this with the proposed defineClass and
>> it means that any code on the class path could inject a class into
>> java.lang or any run-time package without any agent voodoo or opt-in via
>> the command line. That would be difficult genie to re-bottle if it were
>> to get traction.
>> 
>> You mentioned restricting JNI in the future. I'm not aware of a definite
>> plan or time-frame. Project Panama is pioneering restricting access to
>> native operations as a bug or mis-use with the linker API can easily
>> crash the VM or breakage in other ways. Extending this to JNI would be a
>> logical next step but I could imagine it taking a long time and many
>> releases to get there.
>> 
>> As regards this PR then I would be happy to work with you on a revised
>> proposed that would limit it to agents specified with -javaagent. That
>> would not preclude extending the capability, maybe in a more restricted
>> form, to agents loaded into a running VM in the future.
>> 
>> -Alan.
>> 
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/openjdk/jdk/pull/3546#issuecomment-823281169>, or
>> unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/ABCIA4FE2B4DGBZS4QO6SM3TJV7T5ANCNFSM43BSDEGQ>
>> .
>> 
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3546


From rriggs at openjdk.java.net  Wed Apr 21 16:08:34 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 21 Apr 2021 16:08:34 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
Message-ID: <tPYbcXByI3I_IZMwj7PBKf5n4_fCNJqYNQbtxrGgh5Q=.b5650f82-9c3a-4db3-a759-5a3619176081@github.com>

On Thu, 25 Mar 2021 08:19:24 GMT, Fabian Meumertzheim <github.com+4312191+fmeum at openjdk.org> wrote:

> Adds missing @throws declarations for ArithmeticException to the public
> function
> java.math.BigDecimal#stripTrailingZeros
> as well as the private helper functions
> java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long)
> java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long)
> 
> stripTrailingZeros calls one of the two helper functions, both of which
> can repeatedly decrease the scale by 1 until it underflows. If it does,
> the call to checkScale will result in an ArithmeticException (overflow).

Please note the issue [8264161](https://bugs.openjdk.java.net/browse/JDK-8264161) has already been addressed by: 
https://github.com/openjdk/jdk/pull/3204

-------------

PR: https://git.openjdk.java.net/jdk/pull/3189

From github.com+4312191+fmeum at openjdk.java.net  Wed Apr 21 16:14:35 2021
From: github.com+4312191+fmeum at openjdk.java.net (Fabian Meumertzheim)
Date: Wed, 21 Apr 2021 16:14:35 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
Message-ID: <1fJLHkPkxAHLRAEQO7MNd_ZnUCHd3sQXIIsaXbYMhAA=.db266eb9-46b8-41e8-81da-9a6a4554a939@github.com>

On Thu, 25 Mar 2021 08:19:24 GMT, Fabian Meumertzheim <github.com+4312191+fmeum at openjdk.org> wrote:

> Adds missing @throws declarations for ArithmeticException to the public
> function
> java.math.BigDecimal#stripTrailingZeros
> as well as the private helper functions
> java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long)
> java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long)
> 
> stripTrailingZeros calls one of the two helper functions, both of which
> can repeatedly decrease the scale by 1 until it underflows. If it does,
> the call to checkScale will result in an ArithmeticException (overflow).

> Please note the issue [8264161](https://bugs.openjdk.java.net/browse/JDK-8264161) has already been addressed by:
> #3204

@RogerRiggs The fix in #3204 remains incomplete as it does not update the `@throws` declarations. I could open a new bug for that, but unfortunately the form at https://bugreport.java.com/bugreport/start_form.do appears to be down: There is no server response when clicking "Submit", the request to https://bugreport.java.com/bugreport/submit_start.do just hangs forever.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3189

From brian.burkhalter at oracle.com  Wed Apr 21 16:23:05 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 21 Apr 2021 16:23:05 +0000
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <1fJLHkPkxAHLRAEQO7MNd_ZnUCHd3sQXIIsaXbYMhAA=.db266eb9-46b8-41e8-81da-9a6a4554a939@github.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
 <1fJLHkPkxAHLRAEQO7MNd_ZnUCHd3sQXIIsaXbYMhAA=.db266eb9-46b8-41e8-81da-9a6a4554a939@github.com>
Message-ID: <3C78E0BF-A8B1-4A4D-9872-045D919B9866@oracle.com>


On Apr 21, 2021, at 9:14 AM, Fabian Meumertzheim <github.com+4312191+fmeum at openjdk.java.net<mailto:github.com+4312191+fmeum at openjdk.java.net>> wrote:

On Thu, 25 Mar 2021 08:19:24 GMT, Fabian Meumertzheim <github.com+4312191+fmeum at openjdk.org<mailto:github.com+4312191+fmeum at openjdk.org>> wrote:

Adds missing @throws declarations for ArithmeticException to the public
function
java.math.BigDecimal#stripTrailingZeros
as well as the private helper functions
java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long)
java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long)

stripTrailingZeros calls one of the two helper functions, both of which
can repeatedly decrease the scale by 1 until it underflows. If it does,
the call to checkScale will result in an ArithmeticException (overflow).

Please note the issue [8264161](https://bugs.openjdk.java.net/browse/JDK-8264161) has already been addressed by:
#3204

@RogerRiggs The fix in #3204 remains incomplete as it does not update the `@throws` declarations. I could open a new bug for that, but unfortunately the form at https://bugreport.java.com/bugreport/start_form.do appears to be down: There is no server response when clicking "Submit", the request to https://bugreport.java.com/bugreport/submit_start.do just hangs forever.

There is in fact some system maintenance which should be completed this morning, Pacific Time. After that a new issue for this should be filed as we cannot reuse issue IDs.

Thanks.

From brian.burkhalter at oracle.com  Wed Apr 21 16:23:56 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 21 Apr 2021 16:23:56 +0000
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <3C78E0BF-A8B1-4A4D-9872-045D919B9866@oracle.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
 <1fJLHkPkxAHLRAEQO7MNd_ZnUCHd3sQXIIsaXbYMhAA=.db266eb9-46b8-41e8-81da-9a6a4554a939@github.com>
 <3C78E0BF-A8B1-4A4D-9872-045D919B9866@oracle.com>
Message-ID: <6DC17F06-870E-4A0E-A2BF-AA3F51F3D1B5@oracle.com>



On Apr 21, 2021, at 9:23 AM, Brian Burkhalter <brian.burkhalter at oracle.com<mailto:brian.burkhalter at oracle.com>> wrote:

There is in fact some system maintenance which should be completed this morning, Pacific Time. After that a new issue for this should be filed as we cannot reuse issue IDs.

Correction: not sure about system maintenance (dates confused). Sorry.

From joe.darcy at oracle.com  Wed Apr 21 16:25:39 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 21 Apr 2021 09:25:39 -0700
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <1fJLHkPkxAHLRAEQO7MNd_ZnUCHd3sQXIIsaXbYMhAA=.db266eb9-46b8-41e8-81da-9a6a4554a939@github.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
 <1fJLHkPkxAHLRAEQO7MNd_ZnUCHd3sQXIIsaXbYMhAA=.db266eb9-46b8-41e8-81da-9a6a4554a939@github.com>
Message-ID: <a38b7865-f2a6-8a8d-2bd9-c3e956b38b0a@oracle.com>


On 4/21/2021 9:14 AM, Fabian Meumertzheim wrote:
> On Thu, 25 Mar 2021 08:19:24 GMT, Fabian Meumertzheim <github.com+4312191+fmeum at openjdk.org> wrote:
>
>> Adds missing @throws declarations for ArithmeticException to the public
>> function
>> java.math.BigDecimal#stripTrailingZeros
>> as well as the private helper functions
>> java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long)
>> java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long)
>>
>> stripTrailingZeros calls one of the two helper functions, both of which
>> can repeatedly decrease the scale by 1 until it underflows. If it does,
>> the call to checkScale will result in an ArithmeticException (overflow).
>> Please note the issue [8264161](https://bugs.openjdk.java.net/browse/JDK-8264161) has already been addressed by:
>> #3204
> @RogerRiggs The fix in #3204 remains incomplete as it does not update the `@throws` declarations. I could open a new bug for that, but unfortunately the form at https://bugreport.java.com/bugreport/start_form.do appears to be down: There is no server response when clicking "Submit", the request to https://bugreport.java.com/bugreport/submit_start.do just hangs forever.

Just was we don't think it is helpful to put an explicit

@throws NullPointerException if a argument is null

on every method that throws a NPE for a null argument, I don't think it 
is helpful or necessary to explicitly note in every BigDecimal method 
with rounding that it could throw ArithmeticException. The general 
class-level statement


 ?* <p>As a 32-bit integer, the set of values for the scale is large,
 ?* but bounded. If the scale of a result would exceed the range of a
 ?* 32-bit integer, either by overflow or underflow, the operation may
 ?* throw an {@code ArithmeticException}.

in meant to capture the needed information.

-Joe


From github.com+4312191+fmeum at openjdk.java.net  Wed Apr 21 16:54:30 2021
From: github.com+4312191+fmeum at openjdk.java.net (Fabian Meumertzheim)
Date: Wed, 21 Apr 2021 16:54:30 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <a38b7865-f2a6-8a8d-2bd9-c3e956b38b0a@oracle.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
 <a38b7865-f2a6-8a8d-2bd9-c3e956b38b0a@oracle.com>
Message-ID: <uI59E61PMj-qxl8lhRH1-6tPiLVWTvtDTB6q6WRx-3U=.74429fb4-5040-41e7-bd3d-89d531e254a0@github.com>

On Wed, 21 Apr 2021 16:27:14 GMT, Joe Darcy <joe.darcy at oracle.com> wrote:

> Just was we don't think it is helpful to put an explicit
> 
> @throws NullPointerException if a argument is null
> 
> on every method that throws a NPE for a null argument, I don't think it
> is helpful or necessary to explicitly note in every BigDecimal method
> with rounding that it could throw ArithmeticException. The general
> class-level statement
> 
> ?* <p>As a 32-bit integer, the set of values for the scale is large,
> ?* but bounded. If the scale of a result would exceed the range of a
> ?* 32-bit integer, either by overflow or underflow, the operation may
> ?* throw an {@code ArithmeticException}.
> 
> in meant to capture the needed information.
> 
> -Joe

I do agree with this in general, but I think that the situation at hand is a bit different from your example for two reasons:

* The `BigDecimal` class already contains many explicit `@throws` annotations for `RuntimeException`s. The absence of such an annotation from a particular method would thus naturally be interpreted as saying that the method does not throw.
* For someone not intimately familiar with the internal representation of `BigDecimal`s, it is probably quite unexpected that a function called `stripTrailingZeros` would perform rounding and thus be liable to scale overflows. (This is what happened to the maintainers of jackson-core, where this lead to an unexpected RuntimeException that was only discovered via fuzzing. They simply took this function to perform some kind of "harmless" canonicalization.)

That is why I do see value in adding these annotations in this particular case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3189

From stuart.marks at oracle.com  Wed Apr 21 17:38:23 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 21 Apr 2021 10:38:23 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
Message-ID: <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>



On 4/19/21 4:05 PM, forax at univ-mlv.fr wrote:
>>   * There's a useful clump of semantics here, combined with sensible operations
>>   that
>> rely on those semantics. There are a lot of places in the spec where there is
>> hedging of the form "if the collection has an ordering, then... otherwise the
>> results are undefined". This is unnecessary in the context of a new type.
>> Furthermore, the new operations fit well with the new types' semantics, with no
>> hedging necessary.
> 
> You can only say that a reversible collection has an ordering. But usually you want the opposite, all collections that have an ordering are a reversible collection. But while this can be true for the implementations inside the JDK that will never be true in Java because there all already collection implementations with an ordering which do not implement ReversibleCollection.
> 
> Sadly, this ship has sailed.
> The spec will still have to say "if the collection has an ordering", otherwise the new semantics is not a backward compatible.

The value being provided here is that the ReversibleCollection interface provides a 
context within which specs no longer need to hedge about "if the collection has an 
ordering". APIs that produce or consume ReversibleCollection no longer need to 
include this hedge, or have disclaimers about ordering. Potential new 
ReversibleCollection implementations also need not worry about this issue in the 
same way they did when they were forced to implement Collection directly.

Of course there will always be ordered collections that don't implement 
ReversibleCollection. (Examples of this are the Queue-but-not-Deque implementations 
in the JDK and 3rd party ordered collections that implement Collection directly.) 
Existing APIs that produce or consume Collection but have stipulations about 
ordering may need to remain, although some could be adjusted depending on the context.

You rightly point out that this problem can never be solved in general. However, 
it's not a goal for ReversibleCollection to represent *all* ordered collections, so 
it's hardly a criticism that it doesn't solve a problem that cannot be solved.

>>   * These semantics appear across a broad range of existing collection types and
>> implementations. It's quite valuable to have a type that unifies the common
>> pieces
>> of List, Deque, SortedSet, and LinkedHashSet into a single abstraction.
> 
> yes in term of documentation, but in Java, it also means that you can use that interface as a type.
> 
> For a List, a Deque or a Set, there are known algorithms that takes such type has parameter so it makes sense to have such type.
> For a ReversibleCollection, i do not see many codes that will benefit taking a ReversibleCollection as parameter instead of using Collection.

It seems likely that many public APIs (both in the JDK and in external libraries) 
will continue to use Collection, for compatibility reasons.

In certain cases (such as LinkedHashMap, see below) the APIs could be adjusted, if 
the compatibility impact is small or can be mitigated.

ReversibleCollection unifies a broad set of existing collections without requiring 
any retrofitting at all. Many applications and libraries don't have their own 
collection implementations; they just use the ones in the JDK. They can benefit from 
the new APIs in ReversibleCollection immediately, without the need for any 
retrofitting at all.

ReversibleCollection also provide opportunities for new code and for existing APIs 
that don't have stringent compatibility constraints. Consider an application that 
has a method wants to consume an ordered collection; a reasonable API would take a 
List as a parameter.

Suppose a caller happened to have a LinkedHashSet in the right order (for example, 
because it wanted to deduplicate the elements). Either the caller would be forced to 
copy the LHS into a List before passing it, or the callee could adjust its parameter 
to be Collection -- but this creates the possibility of bugs if a HashSet is passed 
by accident. Using ReversibleCollection as a parameter type fixes this problem.

>>   * It's useful to have a new type for return types in APIs. Consider
>> LinkedHashMap's entrySet, keySet, and values views. While we clearly get by with
>> having these return Set or Collection today, we need a place to put the new
>> methods.
>> Either they go on Collection (and have extremely weak semantics) or we define
>> new
>> interfaces.
> 
> Even if you define a new interface, you can not change the return type of LinkedHashMap entrySet because it's not a backward compatible change. LinkedHashMap is not final so you have to update all subclasses of LinkedHashMap too.

As I've mentioned, introducing the covariant overrides for LinkedHashMap views is a 
compatibility *risk* but by itself this is not dispositive.

In the past we had no way to assess this risk, so we simply avoided ever making such 
changes. This might be why NavigableMap introduced navigableKeySet to return a 
NavigableSet instead of providing a covariant override for keySet.

If we can ascertain (via code searching) that introducing covariant overrides to 
LinkedHashMap introduces minimal incompatibilities, we might decide to go ahead with 
the change. (What's considered "minimal" is of course up for discussion.)

If however we decide the incompatibilities are too great, a fallback plan would be 
to introduce new methods reversibleEntrySet() et al for the reversible views. This 
would be a little bit disappointing, but it doesn't invalidate the 
ReversibleCollection/ReversibleSet concept.

s'marks


From rafael.wth at gmail.com  Wed Apr 21 18:38:32 2021
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Wed, 21 Apr 2021 20:38:32 +0200
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <50F9CB87-C727-440B-82BE-D282B308B7A2@oracle.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <-fco_my21rYwE8RlEaFlsc-g0WL_rPzbLBWllNqY2rw=.9782b940-c827-4dad-bba8-6901f75fdcf8@github.com>
 <50F9CB87-C727-440B-82BE-D282B308B7A2@oracle.com>
Message-ID: <CA+DM0AkBfNvdGwZaPbT941wOgwFm6nmgSy-=7nvENs7x_sdb3w@mail.gmail.com>

Hi Ron,

we certainly do come from different backgrounds and therefore perspectives,
I find this exchange of perspective to be the main advantage of this open
mailing list.

I do believe that I have an understanding of your angle, I tried to give my
feedback since before Java 9 introduced the module system and so long I
feel like it always helped to find a good compromise. In the end, if a
library like Mockito or the large set of agents would no longer work, this
would be significantly more impactful to the JVM ecosystem then any minor
API change that gets carefully reviewed for good reason. That's why I am
trying to preserve them. The lack of a class definition utility for Java
agents is, in my opinion, one of the last bits within "unsafe migration"
that has not been addressed. And it seems to me that this view is agreed
upon, Oracle already proposed an API to potentially tackle this issue, I
just disagree with the scope, given my extensive experience in agent
development, and try to revive the hibernated debate at the same time.

I am very much aware that this metaphoric fence between Java agents and
regular libraries pretending to be one is being built. I also think this is
necessary, it's a good step forward. And as a matter of fact, expecting
this is at the core of my argument. With the fence being completed at some
point, the Instrumentation instance would be shielded off from regular
libraries, therefore the restriction to emulate being an agent would imply
a restriction to define classes using this instance. At the same time, Java
agents could use a facility that they certainly require, I hopefully lined
out why this is needed. Today most Java agents are using Unsafe, but I
would hope that they could migrate to an official API for Java 17. This way
agents could disregard this fence and continue to function when building
the fence is completed, even if a user upgrades the JVM.

My second argument is that restricting dynamic agents would require to stub
some API of Instrumentation for some arguments already. I do not see any
(additional) harm in stubbing the defineClass API in a similar manner as it
would require stubbing retransformClasses. I think it would therefore be
best to keep this argument out of the consideration of what the best API
would be for "favored agents", where arguments in favor of my proposal were
made by not only me.

Therefore, I hope this API can be considered. Agent developers would
certainly want to migrate to stable, supported API. But as of today no such
API is offered. Since Java agents are often supplementary and need to
support unmaintained software, their baseline moves slower then that of
other Java code which is why I hoped that Java 17 could be the first
release to offer such API as it gets the LTS label attached.

Best regards, Rafael


Am Mi., 21. Apr. 2021 um 19:00 Uhr schrieb Ron Pressler <
ron.pressler at oracle.com>:

> I think you?re coming to this discussion with a very different perspective
> from us, which
> makes understanding what is or isn?t on the table unclear, and also steers
> the ideas in
> directions that are different from the one we?re going.
>
> Our goal is not to maintain some status quo until such time we decide to
> restrict it. We?ve
> started on a long process of strengthening the platform?s integrity, both
> to increase security
> and to help with the ecosystem?s maintenance. Making some things that are
> possible today
> less ?convenient? is intentional. Locked doors are less convenient than
> unlocked ones, but
> sometimes you can only strive to increase convenience under the hard
> constraint that doors
> must be locked. This is where we are: we?ve decided doors will be locked
> unless explicitly
> unlocked.
>
> But this is a process. As long as there are gaps in the garden fence ?
> Unsafe, self-attach, JNI ?
> the locks can be circumvented. Rather than fixing all those loopholes at
> once, we?re doing it
> gradually one at a time. This does mean that a motivated developer can
> circumvent the locks up
> until the point the last loophole is closed, but the hope is that, knowing
> where we?re headed, library
> developers will gradually accept the reality of this direction (or not
> prepare their users for the coming
> changes, keep using those gaps that are still open to them, and then
> surprise their users when the
> last of them is closed).
>
> Suggestions should, therefore, focus on ideas compatible with this vision.
> To be more constructive
> and  less frustrating, the discussion should proceed under this
> assumption, even if it means
> accepting that some things will be less convenient than they are today.
>
> For example, self-attach is not the only issue. Leaking powerful
> Instrumentation objects to libraries
> circumvents encapsulation barriers without there being a key placed in the
> lock through the command
> line. That this can be circumvented today is irrelevant, as these
> workarounds will be *gradually*
> removed. I hope the operations people will be thrilled with the platform?s
> increased security and
> reduced maintenance pain when upgrading JDK versions, but either way, they
> should start
> preparing for the new reality sooner rather than later. Our goal, then,
> should be to make people?s life
> easier, but only under these constraints, that, at this point, should be
> taken as an axiom for the purpose
> of discussion.
>
> ? Ron
>
> > On 20 Apr 2021, at 21:26, Rafael Winterhalter <
> winterhalter at openjdk.java.net> wrote:
> >
> > On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <
> winterhalter at openjdk.org> wrote:
> >
> >>> To allow agents the definition of auxiliary classes, an API is needed
> to allow this. Currently, this is often achieved by using `sun.misc.Unsafe`
> or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was
> removed from `sun.misc.Unsafe`.
> >>
> >> Rafael Winterhalter has refreshed the contents of this pull request,
> and previous commits have been removed. The incremental views will show
> differences compared to the previous content of the PR. The pull request
> contains one new commit since the last revision:
> >>
> >>  8200559: Java agents doing instrumentation need a means to define
> auxiliary classes
> >
> > I fully understand your concerns about ByteBuddyAgent.install(). It is
> > simply a convenience for something that can be meaningful in some
> contexts
> > where I prefer offering a simple API. I use it mainly for two purposes:
> >
> > a) For testing Java agents and integrations against Instrumentation
> within
> > the current VM when tests are triggered by tools that do not support
> > javaagents, also because builds do not bundle jars until after tests are
> > executed.
> >
> > b) For purposefully "hacky" test libraries like Mockito that need agent
> > capabilities without this being meant to be used in production
> > environments. I have earlier proposed to offer a "jdk.test" module that
> > offers the  Instrumentation instance via a simple API similar to Byte
> > Buddy's. The JVM would not load this module unless requested on the
> command
> > line. Build tools like Maven's surefire or Gradle's testrunner could then
> > standardize on loading this module as a convention to give access to this
> > test module by default such that libraries like Mockito could continue to
> > function out of the box without the libraries functioning on a standard
> VM
> > without extra configuration. As far as I know, mainly test libraries need
> > this API. This would also emphasise that Mockito and others are meant for
> > testing and fewer people would abuse it for production applications.
> People
> > would also have an explicit means of running a JVM for a production
> > application or for executing a test.
> >
> > As for adding the API, my thought is that if the Instrumentation API were
> > to throw exceptions on some methods/arguments for dynamic agents in the
> > future, for example for retransformClasses(Object.class), this breaking
> > change would then simply extend to the proposed "defineClass" method. In
> > this sense, the Instrumentation API already assumes full power, I find it
> > not problematic to add the missing bit to this API even if it was
> > restricted in the future in the same spirit as other methods of the API
> > would be.
> >
> > I mentioned JNI as it is a well-known approach to defining a class today,
> > using a minimal native binding to an interface that directly calls down
> to
> > JNI's:
> >
> > jclass DefineClass(JNIEnv *env, const char *name, jobject loader, const
> > jbyte *buf, jsize bufLen);
> >
> > This interface can then simply be used to define any class just as I
> > propse, even when not writing an agent or attaching. This method makes
> > class definitions also already trivial for JVMTI agents compared to Java
> > agents. Unless restricting JNI, the defineClass method is already a low
> > hanging fruit, but at the cost of having to maintain a tiny bit of native
> > code. I'd rather see this avoided and a standard API being offered to
> > agents up to the time that Panama is in place and a JNI restriction is
> > possibly also included. As a bonus: Once JNI is restricted, Byte Buddy's
> > "install" would no longer work unless self-attachment (or JNI) is
> > explicitly allowed. The emulation already requires to run native code
> while
> > the Virtual Machine API explicitly checks for the process id of the
> current
> > VM against the one that is targeted. With both disabled, self-attachment
> > would no longer be practically be possible without needing to prune the
> > capabilities of dynamic agents which is what I understand would be the
> > desired effect.
> >
> > From this viewpoint, I think that adding Instrumentation::defineClass
> > method does no harm compared to the status quo. And on the upside, it
> gives
> > agents an API to migrate to, avoiding the last need of using unsafe. To
> > make the JVM a safe platform, binding native code would anyways need
> > restriction and this would then also solve the problem of dynamic agents
> > attaching from the same VM being used in libraries. This would in my eyes
> > be the cleanest solution to the self-attachment problem without
> disturbing
> > the existing landscape of dynamic agents. To run Mockito, one would then
> > instead configure Maven surefire or Gradle to run the JVM with
> > -Djdk.attach.allowAttachSelf=true. Ideally, some "jdk.test" module would
> be
> > added at some point, to avoid the overhead of self-attachment, but I
> think
> > this better fits into separate debate.
> >
> > Am Di., 20. Apr. 2021 um 15:38 Uhr schrieb mlbridge[bot] <
> > ***@***.***>:
> >
> >> *Mailing list message from Alan Bateman ***@***.***> on
> >> core-libs-dev ***@***.***>:*
> >>
> >> On 19/04/2021 22:20, Rafael Winterhalter wrote:
> >>
> >> :
> >> At the moment, it is required for root to switch to the user that owns
> the
> >> JVM process as the domain socket is only accessible to that user to
> avoid
> >> that users without access to the JVM can inject themselves into a JVM.
> I am
> >> not sure if operations teams would be thrilled to have a monitoring
> agent
> >> required to run as root, even in these times of Kubernetes.
> >>
> >> I mainly have two comments:
> >>
> >> 1. The problem is the possibility of self-attach. I think this is the
> >> problem to solve, a library getting agent privileges without being an
> >> agent. I think this should be prevented while dynamic attach should
> >> continue to be possible in today's format. It has proven to be so
> useful,
> >> it would be a shame if the current tooling convenience would disappear
> from
> >> the JVM. As it's my understanding, JNI is supposed to be restricted in
> the
> >> future, in line with Panama. Without this restriction, JNI already
> allows
> >> for random class definition, for example, which similarly to an agent
> >> offers surpassing the majority of JVM restrictions. The second
> restriction
> >> would be a control to restrict how a JVM process starts new processes. I
> >> think both are reasonable restrictions for a library to face which
> require
> >> explicit enabling. Especially with the security manager on it's way out,
> >> certain capabilities should be rethought to begin with. If both are no
> >> longer freely available, self-attachment is no longer possible anyways
> and
> >> dynamic agents could retain their capabilities.
> >>
> >> 2. The question of introducing an Instrumentation::defineClass method is
> >> fully independent of that first question. If a dynamic agent was to be
> >> restricted, the method could reject classloader/package combinations for
> >> dynamically loaded agents the same way that
> >> Instrumentation::retransformClasses would need to. At the same time,
> >> introducing the method would allow agents to move to an official API
> with a
> >> Java 17 baseline which will be the next long-standing base line. I fully
> >> understand it needs a thorough discussion but it is a less complicated
> >> problem then (1) and could therefore be decided prior to having found a
> >> satisfactory solution for it.
> >>
> >> I should have been clearer, it's the combination of the two that creates
> >> the attractive nuisance. I don't think there are any objections to a
> >> defineClass for agents specified on the command line with -javaagent.
> >> However we have to be cautious about extending that capability to agents
> >> that are loaded into a running VM with the attach mechanism.
> >>
> >> ByteBuddy looks great for code generation and transforming classes but
> >> ByteBuddyAgent makes me nervous. It looks like I can deploy
> >> byte-buddy-agent-<version>.jar on my class path and invoke the public
> >> static ByteBuddyAgent.install() method to get the Instrumentation object
> >> for the current VM. That may be convenient for some but this is the
> >> all-powerful Instrumentation object that shouldn't be leaked to library
> >> or application code. Now combine this with the proposed defineClass and
> >> it means that any code on the class path could inject a class into
> >> java.lang or any run-time package without any agent voodoo or opt-in via
> >> the command line. That would be difficult genie to re-bottle if it were
> >> to get traction.
> >>
> >> You mentioned restricting JNI in the future. I'm not aware of a definite
> >> plan or time-frame. Project Panama is pioneering restricting access to
> >> native operations as a bug or mis-use with the linker API can easily
> >> crash the VM or breakage in other ways. Extending this to JNI would be a
> >> logical next step but I could imagine it taking a long time and many
> >> releases to get there.
> >>
> >> As regards this PR then I would be happy to work with you on a revised
> >> proposed that would limit it to agents specified with -javaagent. That
> >> would not preclude extending the capability, maybe in a more restricted
> >> form, to agents loaded into a running VM in the future.
> >>
> >> -Alan.
> >>
> >> ?
> >> You are receiving this because you were mentioned.
> >> Reply to this email directly, view it on GitHub
> >> <https://github.com/openjdk/jdk/pull/3546#issuecomment-823281169>, or
> >> unsubscribe
> >> <
> https://github.com/notifications/unsubscribe-auth/ABCIA4FE2B4DGBZS4QO6SM3TJV7T5ANCNFSM43BSDEGQ
> >
> >> .
> >>
> >
> > -------------
> >
> > PR: https://git.openjdk.java.net/jdk/pull/3546
>
>

From Alan.Bateman at oracle.com  Wed Apr 21 18:40:44 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Apr 2021 19:40:44 +0100
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <-fco_my21rYwE8RlEaFlsc-g0WL_rPzbLBWllNqY2rw=.9782b940-c827-4dad-bba8-6901f75fdcf8@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <-fco_my21rYwE8RlEaFlsc-g0WL_rPzbLBWllNqY2rw=.9782b940-c827-4dad-bba8-6901f75fdcf8@github.com>
Message-ID: <f270b7e3-2c33-168e-6ae7-6c9f81ee900e@oracle.com>

On 20/04/2021 21:26, Rafael Winterhalter wrote:
> I have earlier proposed to offer a "jdk.test" module that
> offers the  Instrumentation instance via a simple API similar to Byte
> Buddy's. The JVM would not load this module unless requested on the command
> line. Build tools like Maven's surefire or Gradle's testrunner could then
> standardize on loading this module as a convention to give access to this
> test module by default such that libraries like Mockito could continue to
> function out of the box without the libraries functioning on a standard VM
> without extra configuration. As far as I know, mainly test libraries need
> this API. This would also emphasise that Mockito and others are meant for
> testing and fewer people would abuse it for production applications. People
> would also have an explicit means of running a JVM for a production
> application or for executing a test.
Helping testing is good but a jdk.test module that hands out the 
Instrumentation object could be problematic. Is there a reason why the 
runner for Mockito and other mocking frameworks can't specify -javaagent 
when launching? I would expect at least some mocking scenarios to 
require load time transformations (to drop the final modifier from some 
API elements for example) so important to have the transformer set 
before classes are loaded.

> As for adding the API, my thought is that if the Instrumentation API were
> to throw exceptions on some methods/arguments for dynamic agents in the
> future, for example for retransformClasses(Object.class), this breaking
> change would then simply extend to the proposed "defineClass" method. In
> this sense, the Instrumentation API already assumes full power, I find it
> not problematic to add the missing bit to this API even if it was
> restricted in the future in the same spirit as other methods of the API
> would be.
I think it would really hard to put this genie back into a bottle. It's 
way more attractive to use that than the very agent oriented 
redefineModule and retransformClasses.


>
> I mentioned JNI as it is a well-known approach to defining a class today,
> using a minimal native binding to an interface that directly calls down to
> JNI's:
>
> jclass DefineClass(JNIEnv *env, const char *name, jobject loader, const
> jbyte *buf, jsize bufLen);
>
> This interface can then simply be used to define any class just as I
> propse, even when not writing an agent or attaching. This method makes
> class definitions also already trivial for JVMTI agents compared to Java
> agents. Unless restricting JNI, the defineClass method is already a low
> hanging fruit, but at the cost of having to maintain a tiny bit of native
> code.
Sure, if you are using native code then you have the full power of JVM 
TI and JNI available. Project Panama is exploring how to restrict access 
to native code, I think too early to say how this might extend to JNI.

-Alan

From stuart.marks at oracle.com  Wed Apr 21 18:53:25 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 21 Apr 2021 11:53:25 -0700
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <1423562894.899549.1618866076309.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <1423562894.899549.1618866076309.JavaMail.zimbra@u-pem.fr>
Message-ID: <65b94309-517b-7ea6-bf01-bea83802606c@oracle.com>



On 4/19/21 2:01 PM, Remi Forax wrote:
> ----- Mail original -----
> Thinking a little bit about your proposal,
> introducing an interface right in the middle of a hierarchy is not a backward compatible change
> (you have an issue when the compiler has to use the lowest upper bound).
> 
> By example
>    void m(List<Collection<String>> list) { ... }
> 
>    var list = List.of(new LinkedHashSet<String>(), List.of("foo"));
>    m(list);  // does not compile anymore
> 
> currently the type of list is List<Collection<String>> but with your proposal, the type will be List<ReversibleCollection<String>>

Yes, interesting. Not too difficult to fix though. Either change the method 
declaration to

     void m(List<? extends Collection<String>> list)

or change the 'var' to an explicit declaration of List<Collection<String>>.

s'marks

From rriggs at openjdk.java.net  Wed Apr 21 19:40:33 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 21 Apr 2021 19:40:33 GMT
Subject: RFR: 8264514: HexFormat implementation tweaks
In-Reply-To: <wV2FdN2pRDkE8M0EEKnvM5En47NyMBfCy9ISZqi0WrA=.83d77737-9b80-4840-a5c7-0409ef1e14ce@github.com>
References: <wV2FdN2pRDkE8M0EEKnvM5En47NyMBfCy9ISZqi0WrA=.83d77737-9b80-4840-a5c7-0409ef1e14ce@github.com>
Message-ID: <l3px9V7n4-08Z89lAtDHxmtDd4nIcf9tdRfhxiIhBsE=.fb5742be-6ef6-48e8-b572-ff88c7952d82@github.com>

On Wed, 7 Apr 2021 18:49:36 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

> (Changed to new branch in personal fork)
> 
> Please review these small tweaks.
> For background information see [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)
> 
> Greetings
> Raffaello

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3381

From darcy at openjdk.java.net  Wed Apr 21 21:12:50 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 21 Apr 2021 21:12:50 GMT
Subject: RFR: 8265700: Regularize throws clauses in BigDecimal
Message-ID: <UnTGGfcdSmEtjFc60a_JtVxhtRhRmv7zvYgp-_fzJAY=.75ad6e48-cc18-4915-86d0-c94c21300c0b@github.com>

Some throws clauses in BigDecimal are uninformative and could be eliminated. A few explicit throws clauses for surprising exceptions could be added.

These are spec clarifications rather than spec changes.

Follow-up work to https://github.com/openjdk/jdk/pull/3189.

-------------

Commit messages:
 - Add missing space.
 - 8265700: Regularize throws clauses in BigDecimal

Changes: https://git.openjdk.java.net/jdk/pull/3608/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3608&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265700
  Stats: 19 lines in 1 file changed: 7 ins; 12 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3608.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3608/head:pull/3608

PR: https://git.openjdk.java.net/jdk/pull/3608

From darcy at openjdk.java.net  Wed Apr 21 21:27:40 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 21 Apr 2021 21:27:40 GMT
Subject: RFR: 8265700: Regularize throws clauses in BigDecimal [v2]
In-Reply-To: <UnTGGfcdSmEtjFc60a_JtVxhtRhRmv7zvYgp-_fzJAY=.75ad6e48-cc18-4915-86d0-c94c21300c0b@github.com>
References: <UnTGGfcdSmEtjFc60a_JtVxhtRhRmv7zvYgp-_fzJAY=.75ad6e48-cc18-4915-86d0-c94c21300c0b@github.com>
Message-ID: <zUgbs5K00Kil5zVZfMmPUTlrKNF_3xc9b7bYUWcNvoo=.65d1a375-9b1d-4705-810d-a1e871d22fef@github.com>

> Some throws clauses in BigDecimal are uninformative and could be eliminated. A few explicit throws clauses for surprising exceptions could be added.
> 
> These are spec clarifications rather than spec changes.
> 
> Follow-up work to https://github.com/openjdk/jdk/pull/3189.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Include constructors.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3608/files
  - new: https://git.openjdk.java.net/jdk/pull/3608/files/676ea4c5..1829b08c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3608&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3608&range=00-01

  Stats: 22 lines in 1 file changed: 1 ins; 19 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3608.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3608/head:pull/3608

PR: https://git.openjdk.java.net/jdk/pull/3608

From darcy at openjdk.java.net  Wed Apr 21 20:51:21 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 21 Apr 2021 20:51:21 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
Message-ID: <l3WxA-Lr4pBrO0lwmBcyNGI5CFjclJQPd1kU2qS29Fg=.b34b601e-52e7-466a-b2a7-1f118199e4c9@github.com>

On Thu, 25 Mar 2021 08:19:24 GMT, Fabian Meumertzheim <github.com+4312191+fmeum at openjdk.org> wrote:

> Adds missing @throws declarations for ArithmeticException to the public
> function
> java.math.BigDecimal#stripTrailingZeros
> as well as the private helper functions
> java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long)
> java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long)
> 
> stripTrailingZeros calls one of the two helper functions, both of which
> can repeatedly decrease the scale by 1 until it underflows. If it does,
> the call to checkScale will result in an ArithmeticException (overflow).

> 
> 
> > Just was we don't think it is helpful to put an explicit
> > @throws NullPointerException if a argument is null
> > on every method that throws a NPE for a null argument, I don't think it
> > is helpful or necessary to explicitly note in every BigDecimal method
> > with rounding that it could throw ArithmeticException. The general
> > class-level statement
> > ?* As a 32-bit integer, the set of values for the scale is large,
> > ?* but bounded. If the scale of a result would exceed the range of a
> > ?* 32-bit integer, either by overflow or underflow, the operation may
> > ?* throw an {@code ArithmeticException}.
> > in meant to capture the needed information.
> > -Joe
> 
> I do agree with this in general, but I think that the situation at hand is a bit different from your example for two reasons:
> 
>     * The `BigDecimal` class already contains many explicit `@throws` annotations for `RuntimeException`s. The absence of such an annotation from a particular method would thus naturally be interpreted as saying that the method does not throw.
> 
>     * For someone not intimately familiar with the internal representation of `BigDecimal`s, it is probably quite unexpected that a function called `stripTrailingZeros` would perform rounding and thus be liable to scale overflows. (This is what happened to the maintainers of jackson-core, where this lead to an unexpected RuntimeException that was only discovered via fuzzing. They simply took this function to perform some kind of "harmless" canonicalization.)
> 
> 
> That is why I do see value in adding these annotations in this particular case.

Thanks for the additional context. Fuzzers would be likely to run into an exception from stripTrailingZeros as they would be likely to start with extreme exponent values.

Looking over BigDecimal's throws clauses more closely, I've filed

    JDK-8265700: Regularize throws clauses in BigDecimal

and will send out a PR shortly. This change will add a throws clause for the unexpected exception from stripTrailingZeros and remove several "throws ArithmeticException when rounding occurs and the rounding mode is UNNECESSARY" clauses.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3189

From bpb at openjdk.java.net  Wed Apr 21 21:58:23 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 21 Apr 2021 21:58:23 GMT
Subject: RFR: 8265700: Regularize throws clauses in BigDecimal [v2]
In-Reply-To: <zUgbs5K00Kil5zVZfMmPUTlrKNF_3xc9b7bYUWcNvoo=.65d1a375-9b1d-4705-810d-a1e871d22fef@github.com>
References: <UnTGGfcdSmEtjFc60a_JtVxhtRhRmv7zvYgp-_fzJAY=.75ad6e48-cc18-4915-86d0-c94c21300c0b@github.com>
 <zUgbs5K00Kil5zVZfMmPUTlrKNF_3xc9b7bYUWcNvoo=.65d1a375-9b1d-4705-810d-a1e871d22fef@github.com>
Message-ID: <JENbpQCuKKGdm-9JtYq8O7DSZVnb_Pj-fXrOCfmwNzY=.97dfa278-3204-4020-a519-409b1d62a86b@github.com>

On Wed, 21 Apr 2021 21:27:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Some throws clauses in BigDecimal are uninformative and could be eliminated. A few explicit throws clauses for surprising exceptions could be added.
>> 
>> These are spec clarifications rather than spec changes.
>> 
>> Follow-up work to https://github.com/openjdk/jdk/pull/3189.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include constructors.

Less is more. Approved.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3608

From darcy at openjdk.java.net  Wed Apr 21 22:07:22 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 21 Apr 2021 22:07:22 GMT
Subject: Integrated: 8265700: Regularize throws clauses in BigDecimal
In-Reply-To: <UnTGGfcdSmEtjFc60a_JtVxhtRhRmv7zvYgp-_fzJAY=.75ad6e48-cc18-4915-86d0-c94c21300c0b@github.com>
References: <UnTGGfcdSmEtjFc60a_JtVxhtRhRmv7zvYgp-_fzJAY=.75ad6e48-cc18-4915-86d0-c94c21300c0b@github.com>
Message-ID: <IbSK_nir_mjXsvZql18fFRIkW8xxTW6TbOj-Ay3U9zk=.54a4be98-19fa-4258-b859-71e107fa7212@github.com>

On Wed, 21 Apr 2021 21:05:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Some throws clauses in BigDecimal are uninformative and could be eliminated. A few explicit throws clauses for surprising exceptions could be added.
> 
> These are spec clarifications rather than spec changes.
> 
> Follow-up work to https://github.com/openjdk/jdk/pull/3189.

This pull request has now been integrated.

Changeset: 9e7c748d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9e7c748d
Stats:     39 lines in 1 file changed: 8 ins; 31 del; 0 mod

8265700: Regularize throws clauses in BigDecimal

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3608

From darcy at openjdk.java.net  Wed Apr 21 22:09:31 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 21 Apr 2021 22:09:31 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v6]
In-Reply-To: <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
Message-ID: <JOzazdZ1K0CZFqlcdCcWOa6cxF4MEewpvmFrjf4bFe8=.6faec018-f782-4bd0-b02c-9569c58ec9f1@github.com>

On Wed, 21 Apr 2021 13:13:16 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8265137
>  - Remove @hidden
>  - Correct the hierarchy of Random
>  - Remove extraneous references to makeXXXSpliterator
>  - Move makeXXXSpliterator methods to RandomSupport
>  - change static final from 'proxy' to 'PROXY'
>  - Make makeXXXSpliterator final
>  - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From mik3hall at gmail.com  Wed Apr 21 22:15:25 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 21 Apr 2021 17:15:25 -0500
Subject: Jpackage Mac entitlements
Message-ID: <AE84B27D-E347-498A-A55B-E631D8567F23@gmail.com>

Reverted to Jdk 16 and temporarily couldn?t figure out why AppleScript wasn?t working again.

I needed to provide an entitlement. At jpackage 16 I found I needed to do this differently with a <app.name>.entitlements file in the resources directory, as I noticed in the verbose command output.

I had previously noticed that jpackage 17 now includes a parameter to provide this. 

Will both options continue to be supported, resource dir and parm, or will parm become the only supported way at or after 17?

From egahlin at openjdk.java.net  Wed Apr 21 22:41:22 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 21 Apr 2021 22:41:22 GMT
Subject: RFR: 8203359: Container level resources events [v9]
In-Reply-To: <jGPUMTr4BuKk_7hI067HqZ_x8DnTIqq_qUw9wVbEz0U=.e4f82b2e-8280-4162-80ff-5c15e0d50538@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <jGPUMTr4BuKk_7hI067HqZ_x8DnTIqq_qUw9wVbEz0U=.e4f82b2e-8280-4162-80ff-5c15e0d50538@github.com>
Message-ID: <X8hGPKIwYg0bcYkktxwO5yZ0KNlW4ZY2mNLrFdKVKCo=.4436ef8a-8c00-4dda-ac68-1416a8ea970f@github.com>

On Wed, 21 Apr 2021 13:34:28 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
>> 
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
>> * CPU related metrics
>> * Memory related metrics
>> * I/O related metrics
>> 
>> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
>> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix event metadata

I wonder if something similar to below could be added to jdk.jfr.internal.Utils:

    private static Metrics[] metrics;
    public static Metrics getMetrics() {
        if (metrics == null) {
            metrics = new Metrics[] { Metrics.systemMetrics() };
        }
        return metrics[0];
    }

    public static boolean shouldSkipBytecode(String eventName, Class<?> superClass) {
        if (superClass.getClassLoader() != null) {
            return false;
        }
        if (!eventName.startsWith("jdk.Container")) {
            return false;
        }
        return getMetrics() == null;
    }

Then we could add checks to jdk.jfr.internal.JVMUpcalls::bytesForEagerInstrumentation(...)

    eventName = ei.getEventName();
    if (Utils.shouldSkipBytecode(eventName, superClass))) {
        return oldBytes;
    }

and jdk.jfr.internal.JVMUpcalls:onRetransform(...)

    if (jdk.internal.event.Event.class.isAssignableFrom(clazz) && !Modifier.isAbstract(clazz.getModifiers())) {
        if (Utils.shouldSkipBytecode(clazz.getName(), clazz.getSuperclass())) {
            return oldBytes;
        }

This way we would not pay for generating bytecode for events in a non-container environment. 

Not sure if it works, but could perhaps make startup faster? We would still pay for generating the event handlers during registration, but it's much trickier to avoid since we need to store the event type somewhere.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From scolebourne at joda.org  Wed Apr 21 22:14:10 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 21 Apr 2021 23:14:10 +0100
Subject: ReversibleCollection proposal
In-Reply-To: <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
Message-ID: <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>

On Wed, 21 Apr 2021 at 18:39, Stuart Marks <stuart.marks at oracle.com> wrote:
> The value being provided here is that the ReversibleCollection interface provides a
> context within which specs no longer need to hedge about "if the collection has an
> ordering". APIs that produce or consume ReversibleCollection no longer need to
> include this hedge, or have disclaimers about ordering. Potential new
> ReversibleCollection implementations also need not worry about this issue in the
> same way they did when they were forced to implement Collection directly.

Having thought about this for a few days my "interesting thought" is
that adding a `ReversibleCollection` interface and adding additional
methods can be orthogonal choices.

Specifically, I do rather like Peter's suggestion of adding more
methods to Collection. Adding these methods would be pretty useful in
general and give the proposed change much greater reach:

public interface Collection<E> .... {
         default void addFirst(E e) { throw new
UnsupportedOperationException(); }
         default E getFirst() { return iterator().next(); }
         default E removeFirst() { var i = iterator(); i.next();
i.remove(); }
}

My view being that every collection has some notion of "first", even
if that notion is "undefined". If that was the only change made, I
think that would be a good move forward.

These would be the various options:

- 7 new methods on ReversibleCollection (Stuart's suggestion)
- 7 new methods on Collection, no ReversibleCollection (Peter's suggestion)
- 3 new methods on Collection, no ReversibleCollection (my suggestion #1)
- 3 new methods on Collection, 4 methods on ReversibleCollection (my
suggestion #2)
- 7 new methods on Collection, 0 methods on ReversibleCollection (my
suggestion #3)

FWIW, I think I prefer my suggestion #2

Stephen

From igraves at openjdk.java.net  Thu Apr 22 02:46:42 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 22 Apr 2021 02:46:42 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v3]
In-Reply-To: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
References: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
Message-ID: <NSJBgbeaL1FxNnN7eSp1gDJHoxZT5tN1YRsiPLsN_kY=.909f0951-c137-4c3e-86f3-010c1731ab6e@github.com>

> Clarifying note on comments mode to explicitly note that whitespace within character classes is ignored.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking wording and placement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3577/files
  - new: https://git.openjdk.java.net/jdk/pull/3577/files/f4507e3a..79390124

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3577&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3577&range=01-02

  Stats: 11 lines in 1 file changed: 2 ins; 3 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3577/head:pull/3577

PR: https://git.openjdk.java.net/jdk/pull/3577

From igraves at openjdk.java.net  Thu Apr 22 02:46:43 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 22 Apr 2021 02:46:43 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v2]
In-Reply-To: <HlL4VcNx15u9upfRuTujus4H139Mt8d-WRmRWQSIbJc=.e561f91c-2006-443c-8cd4-97d32258a700@github.com>
References: <fl72Y_TbxUE-D2NHgiH_wb0dt5LolU6v20JmTnt_wPw=.82aee18b-7d64-4bd5-a9aa-329cb0cbebc3@github.com>
 <ROd-lby2BgszUx7xsfo4lQSF82vFRyFPO_d8SaKuFDY=.7b72f90c-474a-464b-bd68-5d79650e4b40@github.com>
 <HlL4VcNx15u9upfRuTujus4H139Mt8d-WRmRWQSIbJc=.e561f91c-2006-443c-8cd4-97d32258a700@github.com>
Message-ID: <02yNcmhbPwFCsuk60PsbZlJuXTywsPqfq2y4v6_Task=.fb529554-9bf9-4d22-98b8-37b73ea792b3@github.com>

On Wed, 21 Apr 2021 02:56:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding differences to Perl 5 note
>
> A few minor wording adjustments. Please update the CSR accordingly and I'll review it too.

Wording updated per @stuart-marks's suggestions. Thanks! CSR updated accordingly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3577

From peter.levart at gmail.com  Thu Apr 22 05:50:18 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 22 Apr 2021 07:50:18 +0200
Subject: ReversibleCollection proposal
In-Reply-To: <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
Message-ID: <256c3991-654e-358f-7f29-f10aa7cee2d5@gmail.com>


On 4/22/21 12:14 AM, Stephen Colebourne wrote:
> public interface Collection<E> .... {
>
>           default E getFirst() { return iterator().next(); }


Searching for ".iterator().next()" yields 74 matches in JDK sources...


Peter



From ngasson at openjdk.java.net  Thu Apr 22 08:25:47 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 22 Apr 2021 08:25:47 GMT
Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions
 from invoke_native
Message-ID: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>

macOS on Apple silicon uses slightly different ABI conventions to the
standard AArch64 ABI.  The differences are outlined in [1].  In
particular in the standard (AAPCS) ABI, variadic arguments may be passed
in either registers or on the stack following the normal calling
convention.  To handle this, va_list is a struct containing separate
pointers for arguments located in integer registers, floating point
registers, and on the stack.  Apple's ABI simplifies this by passing all
variadic arguments on the stack and the va_list type becomes a simple
char* pointer.

This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to
represent the new ABI variant on macOS.  StackVaList is based on
WinVaList lightly modified to handle the different TypeClasses on
AArch64.  The original AArch64Linker is renamed to AapcsLinker and is
currently used for all non-Mac platforms.  I think we also need to add a
WinAArch64 CABI but I haven't yet been able to test on a Windows system
so will do that later.

The macOS ABI also uses a different method of spilling arguments to the
stack (the standard ABI pads each argument to a multiple of 8 byte stack
slots, but the Mac ABI packs arguments according to their natural
alignment).  None of the existing tests exercise this so I'll open a new
JBS issue and work on that separately.

Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64.

-------------

Commit messages:
 - 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

Changes: https://git.openjdk.java.net/jdk/pull/3617/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3617&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263512
  Stats: 770 lines in 12 files changed: 568 ins; 112 del; 90 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3617.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3617/head:pull/3617

PR: https://git.openjdk.java.net/jdk/pull/3617

From ngasson at openjdk.java.net  Thu Apr 22 08:30:21 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 22 Apr 2021 08:30:21 GMT
Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args
 functions from invoke_native
In-Reply-To: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>
References: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>
Message-ID: <X3OiTYV3criVQcMoXfNVsg64vZya281rrnMtHZv475A=.2fc99d48-9f0e-4d56-941a-839e8d136fdb@github.com>

On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI.  The differences are outlined in [1].  In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either registers or on the stack following the normal calling
> convention.  To handle this, va_list is a struct containing separate
> pointers for arguments located in integer registers, floating point
> registers, and on the stack.  Apple's ABI simplifies this by passing all
> variadic arguments on the stack and the va_list type becomes a simple
> char* pointer.
> 
> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to
> represent the new ABI variant on macOS.  StackVaList is based on
> WinVaList lightly modified to handle the different TypeClasses on
> AArch64.  The original AArch64Linker is renamed to AapcsLinker and is
> currently used for all non-Mac platforms.  I think we also need to add a
> WinAArch64 CABI but I haven't yet been able to test on a Windows system
> so will do that later.
> 
> The macOS ABI also uses a different method of spilling arguments to the
> stack (the standard ABI pads each argument to a multiple of 8 byte stack
> slots, but the Mac ABI packs arguments according to their natural
> alignment).  None of the existing tests exercise this so I'll open a new
> JBS issue and work on that separately.
> 
> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64.

@mcimadamore @JornVernee could you take a look? Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3617

From pconcannon at openjdk.java.net  Thu Apr 22 10:21:07 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 22 Apr 2021 10:21:07 GMT
Subject: Integrated: 8263668: Update java.time to use instanceof pattern
 variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <hLGmqexizmUamOI7ZrTe3AeeioAXu3Ql7KAhYnz2jxI=.2672c833-26c2-49ed-97bf-0d509422753e@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 28af31db
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/28af31db
Stats:     176 lines in 34 files changed: 0 ins; 47 del; 129 mod

8263668: Update java.time to use instanceof pattern variable

Reviewed-by: lancea, ryadav, naoto, rriggs, dfuchs, scolebourne, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From pconcannon at openjdk.java.net  Thu Apr 22 10:21:02 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 22 Apr 2021 10:21:02 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v8]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <teAMJj4QvpxnpoenobR1PrYcWJz75mmZkX00McRCZUM=.e4a2b799-1d71-4a59-95f5-8555fa67f9f2@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Updated single letter pattern variable name in java/time/Duration
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Updated single letter pattern variable names
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/88c33d40...db6e9bb7

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/3dc1e075..db6e9bb7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=06-07

  Stats: 522 lines in 75 files changed: 254 ins; 160 del; 108 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170

PR: https://git.openjdk.java.net/jdk/pull/3170

From pconcannon at openjdk.java.net  Thu Apr 22 10:21:06 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 22 Apr 2021 10:21:06 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
 <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
Message-ID: <iwTyLcKd5oHsec1Wmj1TfsSUb9EsC8aLSAKtN8LRucc=.74f15679-4785-48f8-8c1a-8b6e6e8b2e10@github.com>

On Wed, 21 Apr 2021 13:02:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Updated single letter pattern variable name in java/time/Duration
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Updated single letter pattern variable names
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - 8263668: Update java.time to use instanceof pattern variable
>
> I was able to find (with IntelliJ IDEA help) few more places to improve
> 
>     java.time   27 warnings 
>         class Clock   2 warnings 
>             class FixedClock   1 warning 
>                 method equals(Object)   1 warning 
>                     WARNING Variable 'other' can be replaced with pattern variable 
>             class OffsetClock   1 warning 
>                 method equals(Object)   1 warning 
>                     WARNING Variable 'other' can be replaced with pattern variable 
>         class Instant   2 warnings 
>             method until(Temporal, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalDate   5 warnings 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalDateTime   8 warnings 
>             method get(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method getLong(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method isSupported(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalTime   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class OffsetDateTime   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class Year   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class YearMonth   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ZonedDateTime   6 warnings 
>             method equals(Object)   1 warning 
>                 WARNING Variable 'other' can be replaced with pattern variable 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method with(TemporalAdjuster)   2 warnings 
>                 WARNING Variable 'odt' can be replaced with pattern variable 
>                 WARNING Variable 'instant' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>     java.time.chrono   13 warnings 
>         class ChronoLocalDateImpl   1 warning 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ChronoLocalDateTimeImpl   6 warnings 
>             method get(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method getLong(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method isSupported(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ChronoPeriodImpl   1 warning 
>             method validateAmount(TemporalAmount)   1 warning 
>                 WARNING Variable 'period' can be replaced with pattern variable 
>         class ChronoZonedDateTimeImpl   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class HijrahDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class JapaneseDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class MinguoDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ThaiBuddhistDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>     java.time.format   3 warnings 
>         class DecimalStyle   1 warning 
>             method equals(Object)   1 warning 
>                 WARNING Variable 'other' can be replaced with pattern variable 
>         class Parsed   2 warnings 
>             method resolveFields()   2 warnings 
>                 WARNING Variable 'czdt' can be replaced with pattern variable 
>                 WARNING Variable 'cldt' can be replaced with pattern variable 
>     java.time.zone   1 warning 
>         class TzdbZoneRulesProvider   1 warning 
>             method provideRules(String, boolean)   1 warning 
>                 WARNING Variable 'bytes' can be replaced with pattern variable 
> 
> Do you have plans to adjust them too?

> Hi @turbanoff, thanks for finding these. Will take a look shortly!

As this PR is already quite large, I will create a second issue to track these further changes. Thanks again for your help

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From aleksei.voitylov at bell-sw.com  Thu Apr 22 11:21:38 2021
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Thu, 22 Apr 2021 14:21:38 +0300
Subject: RFC: jdeps output - "jdk8internals" vs "JDK removed internal API"
 after JDK-8213909
Message-ID: <b072c9e0-2cb3-fec3-74ad-c312e78a8d77@bell-sw.com>

Hi,

JDK-8213909 [1] (since JDK 12, backported into 11.0.11), aside from
bringing great additions to transitive module analysis, introduced a
slight change in output of jdeps:

jdk-11.0.11/bin/jdeps -s reactor-core-3.4.5.jar
reactor-core-3.4.5.jar -> jdk8internals
reactor-core-3.4.5.jar -> java.base
reactor-core-3.4.5.jar -> java.logging
reactor-core-3.4.5.jar -> not found

jdk-11.0.10/bin/jdeps -s reactor-core-3.4.5.jar
reactor-core-3.4.5.jar -> JDK removed internal API
reactor-core-3.4.5.jar -> java.base
reactor-core-3.4.5.jar -> java.logging
reactor-core-3.4.5.jar -> not found

Note the difference "jdk8internals" vs "JDK removed internal API", not
discussed in the relevant CSR [2] or the review thread [3]. This change
is likely to affect some automation systems built around jdeps. Since
the change has already landed, I wanted to check if there is a reason
behind this naming change, and if "jdk8internals" should be the naming
convention the users are expected to standardize their automation on
going forward?

I would assume most now are used to parsing for "JDK removed internal
API" to determine if the project uses any removed APIs (and should
probably be using --print-module-deps to feed jlink input), but I also
see merit in having a single convention for mainline and CPU releases.

-Aleksei

[1] https://bugs.openjdk.java.net/browse/JDK-8213909
[2] https://bugs.openjdk.java.net/browse/JDK-8213915
[3]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056660.html



From forax at univ-mlv.fr  Thu Apr 22 12:23:51 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 22 Apr 2021 14:23:51 +0200 (CEST)
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <65b94309-517b-7ea6-bf01-bea83802606c@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <1423562894.899549.1618866076309.JavaMail.zimbra@u-pem.fr>
 <65b94309-517b-7ea6-bf01-bea83802606c@oracle.com>
Message-ID: <1310681418.369163.1619094231089.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 21 Avril 2021 20:53:25
> Objet: Re: [External] : Re: ReversibleCollection proposal

> On 4/19/21 2:01 PM, Remi Forax wrote:
>> ----- Mail original -----
>> Thinking a little bit about your proposal,
>> introducing an interface right in the middle of a hierarchy is not a backward
>> compatible change
>> (you have an issue when the compiler has to use the lowest upper bound).
>> 
>> By example
>>    void m(List<Collection<String>> list) { ... }
>> 
>>    var list = List.of(new LinkedHashSet<String>(), List.of("foo"));
>>    m(list);  // does not compile anymore
>> 
>> currently the type of list is List<Collection<String>> but with your proposal,
>> the type will be List<ReversibleCollection<String>>
> 
> Yes, interesting. Not too difficult to fix though. Either change the method
> declaration to
> 
>     void m(List<? extends Collection<String>> list)
> 
> or change the 'var' to an explicit declaration of List<Collection<String>>.


or specify the type argument in between '.' and 'of'
  var list = List.<Collection<String>>of(new LinkedHashSet<String>(), List.of("foo"));

anyway, the issue here is that adding ReversibleCollection is a source breaking change,
which significantly raises the bar to add this interface.

> 
> s'marks

R?mi

From andy.herrick at oracle.com  Thu Apr 22 12:41:14 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 22 Apr 2021 08:41:14 -0400
Subject: Jpackage Mac entitlements
In-Reply-To: <AE84B27D-E347-498A-A55B-E631D8567F23@gmail.com>
References: <AE84B27D-E347-498A-A55B-E631D8567F23@gmail.com>
Message-ID: <495569d6-4b95-0925-a00f-ab6723fafcf9@oracle.com>


On 4/21/2021 6:15 PM, Michael Hall wrote:
> Reverted to Jdk 16 and temporarily couldn?t figure out why AppleScript wasn?t working again.
>
> I needed to provide an entitlement. At jpackage 16 I found I needed to do this differently with a <app.name>.entitlements file in the resources directory, as I noticed in the verbose command output.
>
> I had previously noticed that jpackage 17 now includes a parameter to provide this.
>
> Will both options continue to be supported, resource dir and parm, or will parm become the only supported way at or after 17?

Yes, if --mac-entitlement options exists, it will use it, otherwise , 
the previous behavior is maintained, the default resource 
entitlements.plist in the source code will be used unless overridden by 
<app name>.entitlements in the resource directory.

/Andy


From forax at univ-mlv.fr  Thu Apr 22 12:58:37 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 22 Apr 2021 14:58:37 +0200 (CEST)
Subject: ReversibleCollection proposal
In-Reply-To: <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
Message-ID: <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Jeudi 22 Avril 2021 00:14:10
> Objet: Re: ReversibleCollection proposal

> On Wed, 21 Apr 2021 at 18:39, Stuart Marks <stuart.marks at oracle.com> wrote:
>> The value being provided here is that the ReversibleCollection interface
>> provides a
>> context within which specs no longer need to hedge about "if the collection has
>> an
>> ordering". APIs that produce or consume ReversibleCollection no longer need to
>> include this hedge, or have disclaimers about ordering. Potential new
>> ReversibleCollection implementations also need not worry about this issue in the
>> same way they did when they were forced to implement Collection directly.
> 
> Having thought about this for a few days my "interesting thought" is
> that adding a `ReversibleCollection` interface and adding additional
> methods can be orthogonal choices.
> 
> Specifically, I do rather like Peter's suggestion of adding more
> methods to Collection. Adding these methods would be pretty useful in
> general and give the proposed change much greater reach:
> 
> public interface Collection<E> .... {
>         default void addFirst(E e) { throw new
> UnsupportedOperationException(); }
>         default E getFirst() { return iterator().next(); }
>         default E removeFirst() { var i = iterator(); i.next();
> i.remove(); }
> }
> 
> My view being that every collection has some notion of "first", even
> if that notion is "undefined". If that was the only change made, I
> think that would be a good move forward.
> 
> These would be the various options:
> 
> - 7 new methods on ReversibleCollection (Stuart's suggestion)
> - 7 new methods on Collection, no ReversibleCollection (Peter's suggestion)
> - 3 new methods on Collection, no ReversibleCollection (my suggestion #1)
> - 3 new methods on Collection, 4 methods on ReversibleCollection (my
> suggestion #2)
> - 7 new methods on Collection, 0 methods on ReversibleCollection (my
> suggestion #3)
> 
> FWIW, I think I prefer my suggestion #2

I would like to preserve the invariant that, when calling a method on a Collection/iterator, an UnsupportedOperationException only occurs when trying to mutate that collection.
If we are ok with that, this means that addFirst can not be a default method of Collection.

getFirst() on Collection is a nice addition has I already said.

And i'm not a big fan of removeFirst() on Collection, mostly because i think that the sequence this.iterator + next() + remove() is pretty rare on a Collection or a Set
(i would also like to keep the invariant that Set and Collection have the same set of methods).

So addFirst/addLast/removeFirst/removeLast should be added to SortedSet/NavigableSet, Deque, List and LinkedHashMap (if there are not already present).

For reverse/descending, I still prefer to have descendingSet() on Set and descendingList() on List, the same way we have keySet() or subList() (the method names have the resulting interface has suffix).
This also solve the issue with LinkedList implementing both List and Deque.

I believe that the cost of introducing ReversibleCollection is too high
- it's not source backward compatible change
- replacing Collection/Set by ReversibleCollection/ReversibleSet has return type of an existing interface/class is not a source backward compatible change
- to be able to use ReversibleCollection parameter of a public method of a library, we have to wait the whole Java ecosystem to have been updated to implement ReversibleCollection (Python 2/3 like migration).

> 
> Stephen

R?mi

From jfranck at openjdk.java.net  Thu Apr 22 13:02:28 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Thu, 22 Apr 2021 13:02:28 GMT
Subject: RFR: 8265591: Remove vestiages of intermediate JSR 175 annotation
 format
In-Reply-To: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
References: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
Message-ID: <VxGOdmvMsGalUCqqrjZb_vkE6_o6wMh9tXTowodDM8M=.008876cc-90f9-4ae0-92e3-d9969511e7e8@github.com>

On Tue, 20 Apr 2021 23:37:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> During the recent review of JDK-8228988, I noticed again the comments in the annotation parser about support for the pre-GA annotation format used before JDK 5.0 shipped. During the development of annotations, there was a late change to correct a flaw in the annotation encoding, JDK-5020908.
> 
> I don't think it is necessary to carry forward support for this transient format any longer and this changeset removes support from both core reflection and javac.
> 
> Clean runs of relevant test; I gauge this fix as no-reg hard.

Marked as reviewed by jfranck (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3597

From forax at univ-mlv.fr  Thu Apr 22 13:30:12 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 22 Apr 2021 15:30:12 +0200 (CEST)
Subject: ReversibleCollection proposal
In-Reply-To: <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
Message-ID: <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 21 Avril 2021 19:38:23
> Objet: Re: ReversibleCollection proposal

> On 4/19/21 4:05 PM, forax at univ-mlv.fr wrote:
>>>   * There's a useful clump of semantics here, combined with sensible operations
>>>   that
>>> rely on those semantics. There are a lot of places in the spec where there is
>>> hedging of the form "if the collection has an ordering, then... otherwise the
>>> results are undefined". This is unnecessary in the context of a new type.
>>> Furthermore, the new operations fit well with the new types' semantics, with no
>>> hedging necessary.
>> 
>> You can only say that a reversible collection has an ordering. But usually you
>> want the opposite, all collections that have an ordering are a reversible
>> collection. But while this can be true for the implementations inside the JDK
>> that will never be true in Java because there all already collection
>> implementations with an ordering which do not implement ReversibleCollection.
>> 
>> Sadly, this ship has sailed.
>> The spec will still have to say "if the collection has an ordering", otherwise
>> the new semantics is not a backward compatible.
> 
> The value being provided here is that the ReversibleCollection interface
> provides a
> context within which specs no longer need to hedge about "if the collection has
> an
> ordering". APIs that produce or consume ReversibleCollection no longer need to
> include this hedge, or have disclaimers about ordering. Potential new
> ReversibleCollection implementations also need not worry about this issue in the
> same way they did when they were forced to implement Collection directly.

An API can not use ReversibleCollection as parameter before all the implementations of Collection that have an ordering are updated to implement ReversibleCollection instead of Collection.

By example, if I add a method
  public void foo(ReversibleCollection c)  
in my library, people that want to be able to use foo with an existing collection with an ordering have to wait that collection implementation to be updated.

So i will not add a method like foo in my API until enough (whatever enough means) implementation of Collection with an ordering have migrated.

This is a similar issue as the migration from Python 2 to Python 3, it takes at least 10 years, so in 10 years, I will be able to had a public method that takes a ReversibleCollection in my API,
without people not be able to using it.


> 
> Of course there will always be ordered collections that don't implement
> ReversibleCollection. (Examples of this are the Queue-but-not-Deque
> implementations
> in the JDK and 3rd party ordered collections that implement Collection
> directly.)
> Existing APIs that produce or consume Collection but have stipulations about
> ordering may need to remain, although some could be adjusted depending on the
> context.
> 
> You rightly point out that this problem can never be solved in general. However,
> it's not a goal for ReversibleCollection to represent *all* ordered collections,
> so
> it's hardly a criticism that it doesn't solve a problem that cannot be solved.
> 
>>>   * These semantics appear across a broad range of existing collection types and
>>> implementations. It's quite valuable to have a type that unifies the common
>>> pieces
>>> of List, Deque, SortedSet, and LinkedHashSet into a single abstraction.
>> 
>> yes in term of documentation, but in Java, it also means that you can use that
>> interface as a type.
>> 
>> For a List, a Deque or a Set, there are known algorithms that takes such type
>> has parameter so it makes sense to have such type.
>> For a ReversibleCollection, i do not see many codes that will benefit taking a
>> ReversibleCollection as parameter instead of using Collection.
> 
> It seems likely that many public APIs (both in the JDK and in external
> libraries)
> will continue to use Collection, for compatibility reasons.
> 
> In certain cases (such as LinkedHashMap, see below) the APIs could be adjusted,
> if
> the compatibility impact is small or can be mitigated.
> 
> ReversibleCollection unifies a broad set of existing collections without
> requiring
> any retrofitting at all. Many applications and libraries don't have their own
> collection implementations; they just use the ones in the JDK. They can benefit
> from
> the new APIs in ReversibleCollection immediately, without the need for any
> retrofitting at all.

nope, many applications do not use *only* the collection from the JDK,
but also collections that comes from other libraries than msut to be upgraded to use ReversibleCollection.

> 
> ReversibleCollection also provide opportunities for new code and for existing
> APIs
> that don't have stringent compatibility constraints. Consider an application
> that
> has a method wants to consume an ordered collection; a reasonable API would take
> a List as a parameter.
> 
> Suppose a caller happened to have a LinkedHashSet in the right order (for
> example,
> because it wanted to deduplicate the elements). Either the caller would be
> forced to
> copy the LHS into a List before passing it, or the callee could adjust its
> parameter
> to be Collection -- but this creates the possibility of bugs if a HashSet is
> passed
> by accident. Using ReversibleCollection as a parameter type fixes this problem.

ReversibleCollection can be a solution, it's also not the best way to say that you want a collection with an ordering,
any collections with zero or one element is also a valid ordered collection, so by example a HashSet with only one element is a valid argument.

> 
>>>   * It's useful to have a new type for return types in APIs. Consider
>>> LinkedHashMap's entrySet, keySet, and values views. While we clearly get by with
>>> having these return Set or Collection today, we need a place to put the new
>>> methods.
>>> Either they go on Collection (and have extremely weak semantics) or we define
>>> new
>>> interfaces.
>> 
>> Even if you define a new interface, you can not change the return type of
>> LinkedHashMap entrySet because it's not a backward compatible change.
>> LinkedHashMap is not final so you have to update all subclasses of
>> LinkedHashMap too.
> 
> As I've mentioned, introducing the covariant overrides for LinkedHashMap views
> is a
> compatibility *risk* but by itself this is not dispositive.
> 
> In the past we had no way to assess this risk, so we simply avoided ever making
> such
> changes. This might be why NavigableMap introduced navigableKeySet to return a
> NavigableSet instead of providing a covariant override for keySet.
> 
> If we can ascertain (via code searching) that introducing covariant overrides to
> LinkedHashMap introduces minimal incompatibilities, we might decide to go ahead
> with
> the change. (What's considered "minimal" is of course up for discussion.)
> 
> If however we decide the incompatibilities are too great, a fallback plan would
> be
> to introduce new methods reversibleEntrySet() et al for the reversible views.
> This
> would be a little bit disappointing, but it doesn't invalidate the
> ReversibleCollection/ReversibleSet concept.

It shows that the concept ReversibleCollection/ReversibleSet concept while useful out of the blue, needs to be shoehorned in the JDK, making it not worth it because the cost vs reward has changed. 

> 
> s'marks

R?mi

From github.com+828220+forax at openjdk.java.net  Thu Apr 22 13:48:38 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 22 Apr 2021 13:48:38 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v6]
In-Reply-To: <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
Message-ID: <LuLsj0JB7ITs8Qmi_qiFR2h7kkyX7paoo2ergetWYN4=.51671b0a-e00b-475a-a1c3-f35e565ac9ee@github.com>

On Wed, 21 Apr 2021 13:13:16 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8265137
>  - Remove @hidden
>  - Correct the hierarchy of Random
>  - Remove extraneous references to makeXXXSpliterator
>  - Move makeXXXSpliterator methods to RandomSupport
>  - change static final from 'proxy' to 'PROXY'
>  - Make makeXXXSpliterator final
>  - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

Looks good

+1

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From github.com+70726043+rgiulietti at openjdk.java.net  Thu Apr 22 13:57:22 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 22 Apr 2021 13:57:22 GMT
Subject: Integrated: 8264514: HexFormat implementation tweaks
In-Reply-To: <wV2FdN2pRDkE8M0EEKnvM5En47NyMBfCy9ISZqi0WrA=.83d77737-9b80-4840-a5c7-0409ef1e14ce@github.com>
References: <wV2FdN2pRDkE8M0EEKnvM5En47NyMBfCy9ISZqi0WrA=.83d77737-9b80-4840-a5c7-0409ef1e14ce@github.com>
Message-ID: <Sau44mLyM7SiRVzI7IbUHlaIOGXf2x2Dj8sXPWULd_w=.ed59b6e7-5f0e-4287-8b1d-6f607357a54a@github.com>

On Wed, 7 Apr 2021 18:49:36 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

> (Changed to new branch in personal fork)
> 
> Please review these small tweaks.
> For background information see [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)
> 
> Greetings
> Raffaello

This pull request has now been integrated.

Changeset: fa82d475
Author:    Raffaello Giulietti <raffaello.giulietti at gmail.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fa82d475
Stats:     67 lines in 1 file changed: 10 ins; 26 del; 31 mod

8264514: HexFormat implementation tweaks

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/3381

From mik3hall at gmail.com  Thu Apr 22 14:33:52 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 22 Apr 2021 09:33:52 -0500
Subject: Jpackage Mac entitlements
In-Reply-To: <495569d6-4b95-0925-a00f-ab6723fafcf9@oracle.com>
References: <AE84B27D-E347-498A-A55B-E631D8567F23@gmail.com>
 <495569d6-4b95-0925-a00f-ab6723fafcf9@oracle.com>
Message-ID: <919692B0-4A9E-4515-8B13-85F12FC68FE6@gmail.com>



> On Apr 22, 2021, at 7:41 AM, Andy Herrick <andy.herrick at oracle.com> wrote:
> 
> 
> On 4/21/2021 6:15 PM, Michael Hall wrote:
>> Reverted to Jdk 16 and temporarily couldn?t figure out why AppleScript wasn?t working again.
>> 
>> I needed to provide an entitlement. At jpackage 16 I found I needed to do this differently with a <app.name>.entitlements file in the resources directory, as I noticed in the verbose command output.
>> 
>> I had previously noticed that jpackage 17 now includes a parameter to provide this.
>> 
>> Will both options continue to be supported, resource dir and parm, or will parm become the only supported way at or after 17?
> 
> Yes, if --mac-entitlement options exists, it will use it, otherwise , the previous behavior is maintained, the default resource entitlements.plist in the source code will be used unless overridden by <app name>.entitlements in the resource directory.
> 
> /Andy
> 

Ok so in order?

?mac-entitlement
    <app name>.entitlements
	jpackage provided default

If at some point after the ?mac-entitlement parameter has been in place for a while and it is decided to eliminate the resource dir option a warning message might be an idea.

I still think possibly including a verify error exception or warning might also be helpful if that has issues

I figured out that when I was trying different things with signing I must of deleted my Developer ID Application: certificate from keychain. Which is what must of been being found by the jpackage /usr/bin/security find-certificate. Hard coding my fully qualified ?3rd Party? cert was working fine.

After putting my Developer ID Application cert back in the keychain signing again worked by just using my name - but once more the app doesn?t verify. 
This time if I codesign -v it seems ok. But for some reason the Taccy application shows?

App signature check:
?? spctl error 3
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: <me>

For what I am doing this is not a problem but could be a concern for someone trying to get an application into the App Store. 

So, if you do not currently have plans to do something or there is already a RFE in place that you know of. I will submit one to include a verify on signed applications.



From github.com+4312191+fmeum at openjdk.java.net  Thu Apr 22 15:20:25 2021
From: github.com+4312191+fmeum at openjdk.java.net (Fabian Meumertzheim)
Date: Thu, 22 Apr 2021 15:20:25 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
Message-ID: <YiC_7gaBiehanACunTIGy770DgrT1rlJEuQcceRzzA4=.1647577d-edc0-4a4a-a022-8808b3baa5de@github.com>

On Thu, 25 Mar 2021 08:19:24 GMT, Fabian Meumertzheim <github.com+4312191+fmeum at openjdk.org> wrote:

> Adds missing @throws declarations for ArithmeticException to the public
> function
> java.math.BigDecimal#stripTrailingZeros
> as well as the private helper functions
> java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long)
> java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long)
> 
> stripTrailingZeros calls one of the two helper functions, both of which
> can repeatedly decrease the scale by 1 until it underflows. If it does,
> the call to checkScale will result in an ArithmeticException (overflow).

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3189

From github.com+4312191+fmeum at openjdk.java.net  Thu Apr 22 15:20:25 2021
From: github.com+4312191+fmeum at openjdk.java.net (Fabian Meumertzheim)
Date: Thu, 22 Apr 2021 15:20:25 GMT
Subject: Withdrawn: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
References: <IdQDemR4gbEKHCloRj1ulQ9aUiH5xS9hflaEuF2B0uE=.799785f7-41f6-46b5-896a-5523cc109aac@github.com>
Message-ID: <pnYUBfQVcpCIM15vBWVjLbSV9yA49VkhV6vXAptRg2I=.55e8553b-f02f-4b2e-bf07-8f7f5cc8fff5@github.com>

On Thu, 25 Mar 2021 08:19:24 GMT, Fabian Meumertzheim <github.com+4312191+fmeum at openjdk.org> wrote:

> Adds missing @throws declarations for ArithmeticException to the public
> function
> java.math.BigDecimal#stripTrailingZeros
> as well as the private helper functions
> java.math.BigDecimal#createAndStripZerosToMatchScale(long, int, long)
> java.math.BigDecimal#createAndStripZerosToMatchScale(BigInteger, int, long)
> 
> stripTrailingZeros calls one of the two helper functions, both of which
> can repeatedly decrease the scale by 1 until it underflows. If it does,
> the call to checkScale will result in an ArithmeticException (overflow).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3189

From rriggs at openjdk.java.net  Thu Apr 22 15:21:45 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 22 Apr 2021 15:21:45 GMT
Subject: RFR: 8264208: Console charset API [v11]
In-Reply-To: <txrEQhraCE8y7d_LfMyIn2kt-HOiN3wfIaizQpwGZtk=.d3d6d695-b9b7-495e-9e25-f8e4e203ed50@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <txrEQhraCE8y7d_LfMyIn2kt-HOiN3wfIaizQpwGZtk=.d3d6d695-b9b7-495e-9e25-f8e4e203ed50@github.com>
Message-ID: <z1c1nkEi6g8hABuvoHAVLoB2k349HFilLWzDXQJhRj8=.4ecc26d2-ecb5-4b5d-bb97-f01acd8fbe28@github.com>

On Tue, 20 Apr 2021 22:35:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Refined the test case.
>  - Merge branch 'master' into JDK-8264208
>  - Changed shell based test into java based
>  - Added link to Charset#defaultChaset() in InputStreamReader.
>  - Modified javadocs per suggestions.
>  - Added @see links.
>  - Added Console::charset() relation with System.in
>  - Added comment to System.out/err init.
>  - Reflected further review comments.
>  - Reverted PrintStream changes
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/72f17eb7...e585d16f

src/java.base/share/classes/java/io/Console.java line 597:

> 595:                 return null;
> 596:             }
> 597:         });

Please keep the charset() method and return CHARSET.

I'm looking at a use case that needs to know the platform charset regardless of whether the console exists.
When a process is launched it may be redirected to /dev/tty or a pseudo tty and in that case
a Reader from that stream should be able to use the encoding of the platform.
Its still a work in progress, but it would save some refactoring or duplication later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From scolebourne at joda.org  Thu Apr 22 15:36:56 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 22 Apr 2021 16:36:56 +0100
Subject: ReversibleCollection proposal
In-Reply-To: <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
 <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
Message-ID: <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>

On Thu, 22 Apr 2021 at 13:58, Remi Forax <forax at univ-mlv.fr> wrote:
> I would like to preserve the invariant that, when calling a method on a Collection/iterator, an UnsupportedOperationException only occurs when trying to mutate that collection.
> If we are ok with that, this means that addFirst can not be a default method of Collection.

This implementation meets the invariant:

 public interface Collection<E> .... {
   default void addFirst(E e) { add(e); }
   default E getFirst() { return iterator().next(); }
   default E removeFirst() {
     var i = iterator(); i.next();
     i.remove();
   }
 }

This is what I intended anyway, ie that its OK for "first" to work on
an unordered collection, just that addFirst() has very weak semantics
wrt first-ness.

"Ensures that this collection contains the specified element(optional
operation). This has the same basic behaviour as add(E), but
implementations may choose to add the element in first position if
they have some kind of guarantee of ordering. An exception should not
be thrown unless add(E) would also have thrown the exception."

Stephen

From naoto at openjdk.java.net  Thu Apr 22 15:45:32 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 22 Apr 2021 15:45:32 GMT
Subject: RFR: 8264208: Console charset API [v11]
In-Reply-To: <z1c1nkEi6g8hABuvoHAVLoB2k349HFilLWzDXQJhRj8=.4ecc26d2-ecb5-4b5d-bb97-f01acd8fbe28@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <txrEQhraCE8y7d_LfMyIn2kt-HOiN3wfIaizQpwGZtk=.d3d6d695-b9b7-495e-9e25-f8e4e203ed50@github.com>
 <z1c1nkEi6g8hABuvoHAVLoB2k349HFilLWzDXQJhRj8=.4ecc26d2-ecb5-4b5d-bb97-f01acd8fbe28@github.com>
Message-ID: <bOcKJT_23ddCNzgi86jQH7CoqZ2ktZ5a771NpPSNDhI=.38a1458f-133b-4022-bf29-5195f6ad5bcc@github.com>

On Thu, 22 Apr 2021 15:18:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
>> 
>>  - Refined the test case.
>>  - Merge branch 'master' into JDK-8264208
>>  - Changed shell based test into java based
>>  - Added link to Charset#defaultChaset() in InputStreamReader.
>>  - Modified javadocs per suggestions.
>>  - Added @see links.
>>  - Added Console::charset() relation with System.in
>>  - Added comment to System.out/err init.
>>  - Reflected further review comments.
>>  - Reverted PrintStream changes
>>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/51627555...e585d16f
>
> src/java.base/share/classes/java/io/Console.java line 597:
> 
>> 595:                 return null;
>> 596:             }
>> 597:         });
> 
> Please keep the charset() method and return CHARSET.
> 
> I'm looking at a use case that needs to know the platform charset regardless of whether the console exists.
> When a process is launched it may be redirected to /dev/tty or a pseudo tty and in that case
> a Reader from that stream should be able to use the encoding of the platform.
> Its still a work in progress, but it would save some refactoring or duplication later.

Would the singleton `Console.cons` be instantiated in your use case? It is created only when isatty() (or Windows' equivalent) in the native code returns true.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From jbachorik at openjdk.java.net  Thu Apr 22 16:00:32 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 22 Apr 2021 16:00:32 GMT
Subject: RFR: 8203359: Container level resources events [v10]
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <r5gSFDRqdBOmjl3bmVNoHb1klfdKpd5tlYWEXOW8GuA=.026f4b58-9beb-4737-aba9-eed37f264501@github.com>

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Prevent event container bytecode generation if no container present
 - Fix event metadata
 - Roll back conditional registration of container events
 - Remove container events flag
 - Remove trailing spaces
 - Doh
 - Report container type and register events conditionally
 - Remove unused test files
 - Initial test support for JFR container events
 - Update the JFR control files
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/7babcb00...04c3f092

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3126/files
  - new: https://git.openjdk.java.net/jdk/pull/3126/files/f766faf0..04c3f092

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=08-09

  Stats: 36024 lines in 1257 files changed: 5443 ins; 26264 del; 4317 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126

PR: https://git.openjdk.java.net/jdk/pull/3126

From adinn at openjdk.java.net  Thu Apr 22 16:04:27 2021
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 22 Apr 2021 16:04:27 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <RdI5__V73s17GuzxFu44JrLKKief1-5oInnHrvTQwcc=.74636972-0bb4-4c5f-962b-f8b1def39433@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Sorry to be late to this party. I've been wanting to read this thread for a while but have bene too busy up to now. I have just a few comments

I too was party to the discussions about agent capabilities and recall well the decision to gradually impose restrictions, the first one being to control dynamic agent loading. I was happy to accept that general decision and the specific one to limit the opportunity for an agent self-hoisting into the current JVM. However, a key part of the plan to move forward on restrictions was to provide an override switch. I'd very much like to see that retained as an option. I know that in some uses self-hoisting is much preferable to having to install the agent on the command line and I'd expect he same to be true for any other capabilities for which restrictions were adopted.

Although it is true -- as Ron said - -that configuring -javaagent on the command line is always /possible/ there are actually many scenarios for agent use where deployment of an agent after startup is pragmatically much more desirable. An obvious use is trouble shooting, where you only want an agent in place when something goes wrong. That turns out to be critical to solving some seriously difficult support cases. The interesting use cases also fall under testing where self-hoisting of a test agent by a test framework can result in an enormous simplification of test configuration. Usage of Byteman for testing went through the roof with this capability in place. Never underestimate the degree to which even the most minimal configuration complexity puts off Enterprise java developers when it is multiplied by the test suite size of a large project.

So, likewise with other restrictions on behaviour, I'm very happy to see them put in place for dynamically hoisted agents so long as there is still a command line override along the lines of the agent attach property that allows a dynamic agent to do all that a command line agent can.

One other thing I'd like to correct is a point made in the discussion about agent code residing in the system loader. It is true that the main agent class gets loaded by the system loader.  However, it is perfectly possible to ensure that all the rest of the agent code is loaded by the bootstrap loader. A Main class can add the agent jar to the bootstrap path and then load and use reflection to invoke an effective main routine on a bootstrap loaded SubMain class.

Byteman uses this trick on request in order to allow it to instrument bootstrap classes. Because all the Byteman classes except for the original Main shell class are loaded by the bootstrap loader Byteman can safely inject references to the Byteman rule engine and Byteman exception classes into bootstrap code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From rriggs at openjdk.java.net  Thu Apr 22 16:06:23 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 22 Apr 2021 16:06:23 GMT
Subject: RFR: 8264208: Console charset API [v11]
In-Reply-To: <bOcKJT_23ddCNzgi86jQH7CoqZ2ktZ5a771NpPSNDhI=.38a1458f-133b-4022-bf29-5195f6ad5bcc@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <txrEQhraCE8y7d_LfMyIn2kt-HOiN3wfIaizQpwGZtk=.d3d6d695-b9b7-495e-9e25-f8e4e203ed50@github.com>
 <z1c1nkEi6g8hABuvoHAVLoB2k349HFilLWzDXQJhRj8=.4ecc26d2-ecb5-4b5d-bb97-f01acd8fbe28@github.com>
 <bOcKJT_23ddCNzgi86jQH7CoqZ2ktZ5a771NpPSNDhI=.38a1458f-133b-4022-bf29-5195f6ad5bcc@github.com>
Message-ID: <fDjkBOMkzTZOD7wZ4kyNsOL-I9xzcaT19M7Yi_deCOQ=.3191e35f-5990-4a65-832f-e169b208c685@github.com>

On Thu, 22 Apr 2021 15:42:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 597:
>> 
>>> 595:                 return null;
>>> 596:             }
>>> 597:         });
>> 
>> Please keep the charset() method and return CHARSET.
>> 
>> I'm looking at a use case that needs to know the platform charset regardless of whether the console exists.
>> When a process is launched it may be redirected to /dev/tty or a pseudo tty and in that case
>> a Reader from that stream should be able to use the encoding of the platform.
>> Its still a work in progress, but it would save some refactoring or duplication later.
>
> Would the singleton `Console.cons` be instantiated in your use case? It is created only when isatty() (or Windows' equivalent) in the native code returns true.

Not always, for example, if stderr was redirected to a terminal but not stdin and stdout.
The istty check is only true if both stdin and stdout are ttys.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From jbachorik at openjdk.java.net  Thu Apr 22 15:12:23 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 22 Apr 2021 15:12:23 GMT
Subject: RFR: 8203359: Container level resources events [v9]
In-Reply-To: <X8hGPKIwYg0bcYkktxwO5yZ0KNlW4ZY2mNLrFdKVKCo=.4436ef8a-8c00-4dda-ac68-1416a8ea970f@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <jGPUMTr4BuKk_7hI067HqZ_x8DnTIqq_qUw9wVbEz0U=.e4f82b2e-8280-4162-80ff-5c15e0d50538@github.com>
 <X8hGPKIwYg0bcYkktxwO5yZ0KNlW4ZY2mNLrFdKVKCo=.4436ef8a-8c00-4dda-ac68-1416a8ea970f@github.com>
Message-ID: <S0fGjdjgqlYMST-XYxOtBIzzEFmsnTuqWxqoVw6hWEc=.0614abbf-51ad-4080-87f1-a6d847ada645@github.com>

On Wed, 21 Apr 2021 22:38:32 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix event metadata
>
> I wonder if something similar to below could be added to jdk.jfr.internal.Utils:
> 
>     private static Metrics[] metrics;
>     public static Metrics getMetrics() {
>         if (metrics == null) {
>             metrics = new Metrics[] { Metrics.systemMetrics() };
>         }
>         return metrics[0];
>     }
> 
>     public static boolean shouldSkipBytecode(String eventName, Class<?> superClass) {
>         if (superClass != AbstractJDKEvent.class) {
>             return false;
>         }
>         if (!eventName.startsWith("jdk.Container")) {
>             return false;
>         }
>         return getMetrics() == null;
>     }
> 
> Then we could add checks to jdk.jfr.internal.JVMUpcalls::bytesForEagerInstrumentation(...)
> 
>     eventName = ei.getEventName();
>     if (Utils.shouldSkipBytecode(eventName, superClass))) {
>         return oldBytes;
>     }
> 
> and jdk.jfr.internal.JVMUpcalls:onRetransform(...)
> 
>     if (jdk.internal.event.Event.class.isAssignableFrom(clazz) && !Modifier.isAbstract(clazz.getModifiers())) {
>         if (Utils.shouldSkipBytecode(clazz.getName(), clazz.getSuperclass())) {
>             return oldBytes;
>         }
> 
> This way we would not pay for generating bytecode for events in a non-container environment. 
> 
> Not sure if it works, but could perhaps make startup faster? We would still pay for generating the event handlers during registration, but it's much trickier to avoid since we need to store the event type somewhere.

@egahlin Sounds good.
Any particular reason you are using `Metrics[]` array?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From naoto at openjdk.java.net  Thu Apr 22 16:14:22 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 22 Apr 2021 16:14:22 GMT
Subject: RFR: 8264208: Console charset API [v11]
In-Reply-To: <fDjkBOMkzTZOD7wZ4kyNsOL-I9xzcaT19M7Yi_deCOQ=.3191e35f-5990-4a65-832f-e169b208c685@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <txrEQhraCE8y7d_LfMyIn2kt-HOiN3wfIaizQpwGZtk=.d3d6d695-b9b7-495e-9e25-f8e4e203ed50@github.com>
 <z1c1nkEi6g8hABuvoHAVLoB2k349HFilLWzDXQJhRj8=.4ecc26d2-ecb5-4b5d-bb97-f01acd8fbe28@github.com>
 <bOcKJT_23ddCNzgi86jQH7CoqZ2ktZ5a771NpPSNDhI=.38a1458f-133b-4022-bf29-5195f6ad5bcc@github.com>
 <fDjkBOMkzTZOD7wZ4kyNsOL-I9xzcaT19M7Yi_deCOQ=.3191e35f-5990-4a65-832f-e169b208c685@github.com>
Message-ID: <3_4lsGTfiYoi0PIeeiMFl1dLF0kaHHHldCBXilpWn78=.8a39f16c-9d57-4354-a89a-2356e537d465@github.com>

On Thu, 22 Apr 2021 16:03:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Would the singleton `Console.cons` be instantiated in your use case? It is created only when isatty() (or Windows' equivalent) in the native code returns true.
>
> Not always, for example, if stderr was redirected to a terminal but not stdin and stdout.
> The istty check is only true if both stdin and stdout are ttys.

Then `charset()` in the shared secret would return `null`. Would that suffice your case?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From smarks at openjdk.java.net  Thu Apr 22 16:21:39 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 22 Apr 2021 16:21:39 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v6]
In-Reply-To: <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
Message-ID: <_2aufF2MfsLS8BKzxEXo01EB8sqjg61HeDXZI_lwXyo=.bba0a3a8-2512-4207-86d1-36fb94d5cc65@github.com>

On Wed, 21 Apr 2021 13:13:16 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8265137
>  - Remove @hidden
>  - Correct the hierarchy of Random
>  - Remove extraneous references to makeXXXSpliterator
>  - Move makeXXXSpliterator methods to RandomSupport
>  - change static final from 'proxy' to 'PROXY'
>  - Make makeXXXSpliterator final
>  - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

Overall looks good.

AbstractSpliteratorGenerator now is a bit weird because it's a utility class that has static methods, _and_ it's an abstract superclass that has instance methods that mostly just call the static methods. Seems to me that additional cleanup is possible. It might not be worth it right now, since the main point of this PR -- to remove "leakage" of these helper methods into the public API -- has been achieved.

The RandomXXXSpliterator nested classes could also stand some scrutiny. The constructors consume a RandomGenerator, which is stored in an instance variable. Various comments still refer to this as an AbstractSpliteratorGenerator. (See line 961 for example; can't comment directly because it's not part of this commit.)

But it's not clear to me that the RandomXXXSpliterator classes really need a full RandomGenerator. For example, as far as I can see, RandomIntSpliterator _only_ needs `nextInt` to generate int values; therefore it could be `IntSupplier`. Similar for long and double. (I'm applying the Interface Segregation Principle here.) But again this is probably a cleanup for another day.

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1433:

> 1431:         private AbstractSpliteratorGenerator() {
> 1432:         }
> 1433: 

This comment is wrong now since there are instances of this class (really, subclasses). The constructor should probably simply be removed.

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3469

From darcy at openjdk.java.net  Thu Apr 22 16:25:21 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 22 Apr 2021 16:25:21 GMT
Subject: Integrated: 8265591: Remove vestiages of intermediate JSR 175
 annotation format
In-Reply-To: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
References: <DcaEA7DwgAzUQUa57_7RWK11Db_-VWEsw4PzHwtXIJA=.b4601df5-a4cc-46b6-b167-768072dc9df5@github.com>
Message-ID: <xswxuZoO_BOgIanHKzv1RYc9PzyKPo5BlyXthPEcdWM=.9f4571b6-1145-4077-b106-7fdd0861d34b@github.com>

On Tue, 20 Apr 2021 23:37:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> During the recent review of JDK-8228988, I noticed again the comments in the annotation parser about support for the pre-GA annotation format used before JDK 5.0 shipped. During the development of annotations, there was a late change to correct a flaw in the annotation encoding, JDK-5020908.
> 
> I don't think it is necessary to carry forward support for this transient format any longer and this changeset removes support from both core reflection and javac.
> 
> Clean runs of relevant test; I gauge this fix as no-reg hard.

This pull request has now been integrated.

Changeset: 8758b554
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8758b554
Stats:     24 lines in 2 files changed: 0 ins; 19 del; 5 mod

8265591: Remove vestiages of intermediate JSR 175 annotation format

Reviewed-by: jfranck

-------------

PR: https://git.openjdk.java.net/jdk/pull/3597

From rriggs at openjdk.java.net  Thu Apr 22 16:32:31 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 22 Apr 2021 16:32:31 GMT
Subject: RFR: 8264208: Console charset API [v11]
In-Reply-To: <3_4lsGTfiYoi0PIeeiMFl1dLF0kaHHHldCBXilpWn78=.8a39f16c-9d57-4354-a89a-2356e537d465@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <txrEQhraCE8y7d_LfMyIn2kt-HOiN3wfIaizQpwGZtk=.d3d6d695-b9b7-495e-9e25-f8e4e203ed50@github.com>
 <z1c1nkEi6g8hABuvoHAVLoB2k349HFilLWzDXQJhRj8=.4ecc26d2-ecb5-4b5d-bb97-f01acd8fbe28@github.com>
 <bOcKJT_23ddCNzgi86jQH7CoqZ2ktZ5a771NpPSNDhI=.38a1458f-133b-4022-bf29-5195f6ad5bcc@github.com>
 <fDjkBOMkzTZOD7wZ4kyNsOL-I9xzcaT19M7Yi_deCOQ=.3191e35f-5990-4a65-832f-e169b208c685@github.com>
 <3_4lsGTfiYoi0PIeeiMFl1dLF0kaHHHldCBXilpWn78=.8a39f16c-9d57-4354-a89a-2356e537d465@github.com>
Message-ID: <IEtmZ1_zoCHZvUTrvkwDPa2bAtnuIHf4IuVvoJ5xBK8=.9e0771f8-00b6-4853-9505-6c094a945527@github.com>

On Thu, 22 Apr 2021 16:11:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Not always, for example, if stderr was redirected to a terminal but not stdin and stdout.
>> The istty check is only true if both stdin and stdout are ttys.
>
> Then `charset()` in the shared secret would return `null`. Would that suffice your case?

I read lines 575-587 as initializing CHARSET regardless of whether the Console was created.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From mandy.chung at oracle.com  Thu Apr 22 17:00:13 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 22 Apr 2021 10:00:13 -0700
Subject: RFC: jdeps output - "jdk8internals" vs "JDK removed internal API"
 after JDK-8213909
In-Reply-To: <b072c9e0-2cb3-fec3-74ad-c312e78a8d77@bell-sw.com>
References: <b072c9e0-2cb3-fec3-74ad-c312e78a8d77@bell-sw.com>
Message-ID: <ea9013fb-3e0a-2e1a-1073-5caf54d4cc1d@oracle.com>

Hi Aleksei,

Looks like is a bug.? "JDK removed internal API" is the intended 
description as it indicates that a non-existent API is referenced.

I created https://bugs.openjdk.java.net/browse/JDK-8265773 to fix this.

thanks
Mandy

On 4/22/21 4:21 AM, Aleksei Voitylov wrote:
> Hi,
>
> JDK-8213909 [1] (since JDK 12, backported into 11.0.11), aside from
> bringing great additions to transitive module analysis, introduced a
> slight change in output of jdeps:
>
> jdk-11.0.11/bin/jdeps -s reactor-core-3.4.5.jar
> reactor-core-3.4.5.jar -> jdk8internals
> reactor-core-3.4.5.jar -> java.base
> reactor-core-3.4.5.jar -> java.logging
> reactor-core-3.4.5.jar -> not found
>
> jdk-11.0.10/bin/jdeps -s reactor-core-3.4.5.jar
> reactor-core-3.4.5.jar -> JDK removed internal API
> reactor-core-3.4.5.jar -> java.base
> reactor-core-3.4.5.jar -> java.logging
> reactor-core-3.4.5.jar -> not found
>
> Note the difference "jdk8internals" vs "JDK removed internal API", not
> discussed in the relevant CSR [2] or the review thread [3]. This change
> is likely to affect some automation systems built around jdeps. Since
> the change has already landed, I wanted to check if there is a reason
> behind this naming change, and if "jdk8internals" should be the naming
> convention the users are expected to standardize their automation on
> going forward?
>
> I would assume most now are used to parsing for "JDK removed internal
> API" to determine if the project uses any removed APIs (and should
> probably be using --print-module-deps to feed jlink input), but I also
> see merit in having a single convention for mainline and CPU releases.
>
> -Aleksei
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8213909
> [2] https://bugs.openjdk.java.net/browse/JDK-8213915
> [3]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056660.html
>
>


From aleksei.voitylov at bell-sw.com  Thu Apr 22 17:09:56 2021
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Thu, 22 Apr 2021 20:09:56 +0300
Subject: RFC: jdeps output - "jdk8internals" vs "JDK removed internal API"
 after JDK-8213909
In-Reply-To: <ea9013fb-3e0a-2e1a-1073-5caf54d4cc1d@oracle.com>
References: <b072c9e0-2cb3-fec3-74ad-c312e78a8d77@bell-sw.com>
 <ea9013fb-3e0a-2e1a-1073-5caf54d4cc1d@oracle.com>
Message-ID: <bd457a08-7966-5efa-bf25-15c0ac85630f@bell-sw.com>

Mandy,

thanks for the confirmation we'll not have follow-up jdkXXinternals :)
Let me know if you have a spare minute to fix it some time soon,
otherwise I'll be happy to assist.

-Aleksei

On 22/04/2021 20:00, Mandy Chung wrote:
> Hi Aleksei,
>
> Looks like is a bug.? "JDK removed internal API" is the intended
> description as it indicates that a non-existent API is referenced.
>
> I created https://bugs.openjdk.java.net/browse/JDK-8265773 to fix this.
>
> thanks
> Mandy
>
> On 4/22/21 4:21 AM, Aleksei Voitylov wrote:
>> Hi,
>>
>> JDK-8213909 [1] (since JDK 12, backported into 11.0.11), aside from
>> bringing great additions to transitive module analysis, introduced a
>> slight change in output of jdeps:
>>
>> jdk-11.0.11/bin/jdeps -s reactor-core-3.4.5.jar
>> reactor-core-3.4.5.jar -> jdk8internals
>> reactor-core-3.4.5.jar -> java.base
>> reactor-core-3.4.5.jar -> java.logging
>> reactor-core-3.4.5.jar -> not found
>>
>> jdk-11.0.10/bin/jdeps -s reactor-core-3.4.5.jar
>> reactor-core-3.4.5.jar -> JDK removed internal API
>> reactor-core-3.4.5.jar -> java.base
>> reactor-core-3.4.5.jar -> java.logging
>> reactor-core-3.4.5.jar -> not found
>>
>> Note the difference "jdk8internals" vs "JDK removed internal API", not
>> discussed in the relevant CSR [2] or the review thread [3]. This change
>> is likely to affect some automation systems built around jdeps. Since
>> the change has already landed, I wanted to check if there is a reason
>> behind this naming change, and if "jdk8internals" should be the naming
>> convention the users are expected to standardize their automation on
>> going forward?
>>
>> I would assume most now are used to parsing for "JDK removed internal
>> API" to determine if the project uses any removed APIs (and should
>> probably be using --print-module-deps to feed jlink input), but I also
>> see merit in having a single convention for mainline and CPU releases.
>>
>> -Aleksei
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8213909
>> [2] https://bugs.openjdk.java.net/browse/JDK-8213915
>> [3]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056660.html
>>
>>
>>
>

From naoto at openjdk.java.net  Thu Apr 22 17:38:43 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 22 Apr 2021 17:38:43 GMT
Subject: RFR: 8264208: Console charset API [v12]
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <qpGVFkTn8o9gjOJp11t_s2uNcCkTQLgsdcYMPKHeJnE=.4b38a4da-42a4-4c54-a179-d79ea1fa5207@github.com>

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Revived charset() in JavaIOAccess interface.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/e585d16f..2d90f8df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=10-11

  Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

PR: https://git.openjdk.java.net/jdk/pull/3419

From naoto at openjdk.java.net  Thu Apr 22 17:38:46 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 22 Apr 2021 17:38:46 GMT
Subject: RFR: 8264208: Console charset API [v11]
In-Reply-To: <IEtmZ1_zoCHZvUTrvkwDPa2bAtnuIHf4IuVvoJ5xBK8=.9e0771f8-00b6-4853-9505-6c094a945527@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <txrEQhraCE8y7d_LfMyIn2kt-HOiN3wfIaizQpwGZtk=.d3d6d695-b9b7-495e-9e25-f8e4e203ed50@github.com>
 <z1c1nkEi6g8hABuvoHAVLoB2k349HFilLWzDXQJhRj8=.4ecc26d2-ecb5-4b5d-bb97-f01acd8fbe28@github.com>
 <bOcKJT_23ddCNzgi86jQH7CoqZ2ktZ5a771NpPSNDhI=.38a1458f-133b-4022-bf29-5195f6ad5bcc@github.com>
 <fDjkBOMkzTZOD7wZ4kyNsOL-I9xzcaT19M7Yi_deCOQ=.3191e35f-5990-4a65-832f-e169b208c685@github.com>
 <3_4lsGTfiYoi0PIeeiMFl1dLF0kaHHHldCBXilpWn78=.8a39f16c-9d57-4354-a89a-2356e537d465@github.com>
 <IEtmZ1_zoCHZvUTrvkwDPa2bAtnuIHf4IuVvoJ5xBK8=.9e0771f8-00b6-4853-9505-6c094a945527@github.com>
Message-ID: <DHFe-Osdal1BwJs2PAINEIB5RKm9SI_sqA0UNkiu1Yg=.e89d6148-9d14-4f90-95c1-cf763f00fe81@github.com>

On Thu, 22 Apr 2021 16:29:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Then `charset()` in the shared secret would return `null`. Would that suffice your case?
>
> I read lines 575-587 as initializing CHARSET regardless of whether the Console was created.

OK, revived the charset() method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From rriggs at openjdk.java.net  Thu Apr 22 19:22:25 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 22 Apr 2021 19:22:25 GMT
Subject: RFR: 8264208: Console charset API [v12]
In-Reply-To: <qpGVFkTn8o9gjOJp11t_s2uNcCkTQLgsdcYMPKHeJnE=.4b38a4da-42a4-4c54-a179-d79ea1fa5207@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <qpGVFkTn8o9gjOJp11t_s2uNcCkTQLgsdcYMPKHeJnE=.4b38a4da-42a4-4c54-a179-d79ea1fa5207@github.com>
Message-ID: <_D7PFttIHJzn2sKkV23A86PNGc2briMw9XxLyJ1AGuY=.551cc460-3b90-4979-bb6a-db228a12f884@github.com>

On Thu, 22 Apr 2021 17:38:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revived charset() in JavaIOAccess interface.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From github.com+18174180+yassinhajaj at openjdk.java.net  Thu Apr 22 20:44:27 2021
From: github.com+18174180+yassinhajaj at openjdk.java.net (YassinHajaj)
Date: Thu, 22 Apr 2021 20:44:27 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v7]
In-Reply-To: <iwTyLcKd5oHsec1Wmj1TfsSUb9EsC8aLSAKtN8LRucc=.74f15679-4785-48f8-8c1a-8b6e6e8b2e10@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
 <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
 <iwTyLcKd5oHsec1Wmj1TfsSUb9EsC8aLSAKtN8LRucc=.74f15679-4785-48f8-8c1a-8b6e6e8b2e10@github.com>
Message-ID: <sd3WpwIiOQihXieLKLZYVhV3PFhZvlGqF8okqc_YPoc=.1ffd4290-c716-4df6-bdac-ad42d713a113@github.com>

On Thu, 22 Apr 2021 10:13:32 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> I was able to find (with IntelliJ IDEA help) few more places to improve
>> 
>>     java.time   27 warnings 
>>         class Clock   2 warnings 
>>             class FixedClock   1 warning 
>>                 method equals(Object)   1 warning 
>>                     WARNING Variable 'other' can be replaced with pattern variable 
>>             class OffsetClock   1 warning 
>>                 method equals(Object)   1 warning 
>>                     WARNING Variable 'other' can be replaced with pattern variable 
>>         class Instant   2 warnings 
>>             method until(Temporal, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class LocalDate   5 warnings 
>>             method minus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>>             method plus(long, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method plus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>>             method range(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class LocalDateTime   8 warnings 
>>             method get(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method getLong(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method isSupported(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method minus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>>             method plus(long, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method plus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>>             method range(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class LocalTime   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class OffsetDateTime   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class Year   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class YearMonth   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class ZonedDateTime   6 warnings 
>>             method equals(Object)   1 warning 
>>                 WARNING Variable 'other' can be replaced with pattern variable 
>>             method minus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>>             method plus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>>             method with(TemporalAdjuster)   2 warnings 
>>                 WARNING Variable 'odt' can be replaced with pattern variable 
>>                 WARNING Variable 'instant' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>     java.time.chrono   13 warnings 
>>         class ChronoLocalDateImpl   1 warning 
>>             method plus(long, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class ChronoLocalDateTimeImpl   6 warnings 
>>             method get(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method getLong(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method isSupported(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method plus(long, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method range(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class ChronoPeriodImpl   1 warning 
>>             method validateAmount(TemporalAmount)   1 warning 
>>                 WARNING Variable 'period' can be replaced with pattern variable 
>>         class ChronoZonedDateTimeImpl   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class HijrahDate   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class JapaneseDate   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class MinguoDate   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class ThaiBuddhistDate   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>     java.time.format   3 warnings 
>>         class DecimalStyle   1 warning 
>>             method equals(Object)   1 warning 
>>                 WARNING Variable 'other' can be replaced with pattern variable 
>>         class Parsed   2 warnings 
>>             method resolveFields()   2 warnings 
>>                 WARNING Variable 'czdt' can be replaced with pattern variable 
>>                 WARNING Variable 'cldt' can be replaced with pattern variable 
>>     java.time.zone   1 warning 
>>         class TzdbZoneRulesProvider   1 warning 
>>             method provideRules(String, boolean)   1 warning 
>>                 WARNING Variable 'bytes' can be replaced with pattern variable 
>> 
>> Do you have plans to adjust them too?
>
>> Hi @turbanoff, thanks for finding these. Will take a look shortly!
> 
> As this PR is already quite large, I will create a second issue to track these further changes. Thanks again for your help

Hi @pconcannon , good job !

However, is there a reason why you're not using `chronoUnit` in `LocalDateTime:1687` ?


    @Override
    public long until(Temporal endExclusive, TemporalUnit unit) {
        LocalDateTime end = LocalDateTime.from(endExclusive);
        if (unit instanceof ChronoUnit chronoUnit) {
            if (unit.isTimeBased()) { <-- HERE
                long amount = date.daysUntil(end.date);

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From erikj at openjdk.java.net  Thu Apr 22 21:10:33 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 22 Apr 2021 21:10:33 GMT
Subject: RFR: 8265793: Remove duplicate jtreg TEST.groups references for
 some client tests
In-Reply-To: <WE9G4A7uQb-abyj6LYPAW3Qi8VY2YsvZHMwWYd1JOtw=.dfbfd8b3-fb33-4289-8617-deec0e961061@github.com>
References: <WE9G4A7uQb-abyj6LYPAW3Qi8VY2YsvZHMwWYd1JOtw=.dfbfd8b3-fb33-4289-8617-deec0e961061@github.com>
Message-ID: <5-ZOFbOmkWLDHL0HcoWj9YbppTn0hyqBiz3q1UtT01s=.3e1bb699-ae70-4f3a-8f8a-3541dbc25145@github.com>

On Thu, 22 Apr 2021 20:59:22 GMT, Phil Race <prr at openjdk.org> wrote:

> Delete some duplicates

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3642

From prr at openjdk.java.net  Thu Apr 22 21:10:33 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 22 Apr 2021 21:10:33 GMT
Subject: RFR: 8265793: Remove duplicate jtreg TEST.groups references for some
 client tests
Message-ID: <WE9G4A7uQb-abyj6LYPAW3Qi8VY2YsvZHMwWYd1JOtw=.dfbfd8b3-fb33-4289-8617-deec0e961061@github.com>

Delete some duplicates

-------------

Commit messages:
 - 8265793: Remove duplicate jtreg TEST.groups references for some client tests

Changes: https://git.openjdk.java.net/jdk/pull/3642/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3642&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265793
  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3642/head:pull/3642

PR: https://git.openjdk.java.net/jdk/pull/3642

From prr at openjdk.java.net  Thu Apr 22 21:28:24 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 22 Apr 2021 21:28:24 GMT
Subject: Integrated: 8265793: Remove duplicate jtreg TEST.groups references
 for some client tests
In-Reply-To: <WE9G4A7uQb-abyj6LYPAW3Qi8VY2YsvZHMwWYd1JOtw=.dfbfd8b3-fb33-4289-8617-deec0e961061@github.com>
References: <WE9G4A7uQb-abyj6LYPAW3Qi8VY2YsvZHMwWYd1JOtw=.dfbfd8b3-fb33-4289-8617-deec0e961061@github.com>
Message-ID: <RfRSYyCCX_NQOOIZkvCbShG2CfRX8euOsygBqTtpkMw=.e6f6391e-b7fc-4599-95f4-a592b19fda9c@github.com>

On Thu, 22 Apr 2021 20:59:22 GMT, Phil Race <prr at openjdk.org> wrote:

> Delete some duplicates

This pull request has now been integrated.

Changeset: b84f6901
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b84f6901
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8265793: Remove duplicate jtreg TEST.groups references for some client tests

Reviewed-by: erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/3642

From winterhalter at openjdk.java.net  Thu Apr 22 21:53:25 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Thu, 22 Apr 2021 21:53:25 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Setting '-javaagent' is mainly an operations problem. Many build tools do
not allow to declare a test dependency this way as the life cycles are not
laid out for it, the internal repository location might be machine
dependent, for example, and it's difficult to point to a specific folder
and file reliably. In this case, I'd say it would be easier to specify a
parameter in the sense of '-Djdk.attach.allowAttachSelf=true' as it is a
static value. This would however only work for build tools that initiate a
new VM for running tests which is not overly attractive for simple builds
due to the overhead. Of course, Maven, Gradle and similar tools could set
this parameter by default for their own JVM, that part is likely
overcomeable but it will certainly create confusion about how to run
libraries that are omnipresent today and make the JVM ecosystem less
approachable.

What bothers me more is the tooling perspective for non-self-attached
agents. For example, Aaeron offers a Java agent that adds plenty of debug
logging to relevant lines of code. This affects method size and so forth,
with Aaeron as a high-performance tool for banking and finance which is
written very consciously with regards to the JIT, adding it directly was
not feasible. Normally this logging is therefore thrown into a VM in
retrospect, once an application starts failing and is already taken off the
load balancer. For such a post-mortem, it would be rather annoying to
realize that a JVM cannot be attached to with full capabilities if you
forgot to set some flag. And often you did of course not consider the VM
instance to fail, sometimes it takes months to get a JVM into this buggy
state. This would be fairly inconvenient to face.

Therefore, I really hope that the dynamic attach from 'outside' the VM will
survive without imposing limits and that rather the self-attachment problem
will be targeted as such. When I mention a 'jdk.test' module in the Mockito
context, I am also rather hoping to improve performance compared to
convenience. The problem with '-Djdk.attach.allowAttachSelf=true' is that
you still need to start a new VM etc. Since Java 9, running single tests
with Mockito has for example become much slower compared to Java 8. Despite
the startup performance improvements in the JVM. If one could avoid the
location-bound '-javaagent:...', but get the Instrumentation instance
directly, I think this would render a real performance improvement in
actual execution scenarios.

Am Mi., 21. Apr. 2021 um 20:42 Uhr schrieb mlbridge[bot] <
***@***.***>:

> *Mailing list message from Alan Bateman ***@***.***> on
> core-libs-dev ***@***.***>:*
>
> On 20/04/2021 21:26, Rafael Winterhalter wrote:
>
> I have earlier proposed to offer a "jdk.test" module that
> offers the Instrumentation instance via a simple API similar to Byte
> Buddy's. The JVM would not load this module unless requested on the command
> line. Build tools like Maven's surefire or Gradle's testrunner could then
> standardize on loading this module as a convention to give access to this
> test module by default such that libraries like Mockito could continue to
> function out of the box without the libraries functioning on a standard VM
> without extra configuration. As far as I know, mainly test libraries need
> this API. This would also emphasise that Mockito and others are meant for
> testing and fewer people would abuse it for production applications. People
> would also have an explicit means of running a JVM for a production
> application or for executing a test.
>
> Helping testing is good but a jdk.test module that hands out the
> Instrumentation object could be problematic. Is there a reason why the
> runner for Mockito and other mocking frameworks can't specify -javaagent
> when launching? I would expect at least some mocking scenarios to
> require load time transformations (to drop the final modifier from some
> API elements for example) so important to have the transformer set
> before classes are loaded.
>
> As for adding the API, my thought is that if the Instrumentation API were
> to throw exceptions on some methods/arguments for dynamic agents in the
> future, for example for retransformClasses(Object.class), this breaking
> change would then simply extend to the proposed "defineClass" method. In
> this sense, the Instrumentation API already assumes full power, I find it
> not problematic to add the missing bit to this API even if it was
> restricted in the future in the same spirit as other methods of the API
> would be.
>
> I think it would really hard to put this genie back into a bottle. It's
> way more attractive to use that than the very agent oriented
> redefineModule and retransformClasses.
>
> I mentioned JNI as it is a well-known approach to defining a class today,
> using a minimal native binding to an interface that directly calls down to
> JNI's:
>
> jclass DefineClass(JNIEnv *env, const char *name, jobject loader, const
> jbyte *buf, jsize bufLen);
>
> This interface can then simply be used to define any class just as I
> propse, even when not writing an agent or attaching. This method makes
> class definitions also already trivial for JVMTI agents compared to Java
> agents. Unless restricting JNI, the defineClass method is already a low
> hanging fruit, but at the cost of having to maintain a tiny bit of native
> code.
>
> Sure, if you are using native code then you have the full power of JVM
> TI and JNI available. Project Panama is exploring how to restrict access
> to native code, I think too early to say how this might extend to JNI.
>
> -Alan
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/3546#issuecomment-824277041>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABCIA4HHMA67R24GWUPFVATTJ4MBRANCNFSM43BSDEGQ>
> .
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From sviswanathan at openjdk.java.net  Thu Apr 22 22:27:50 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 22 Apr 2021 22:27:50 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly
 intrinsics
Message-ID: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>

Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.

The following changes are made:
   The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
   The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
   The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
   Changes are made to build system to support dependency tracking for assembly files with includes.
   The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
   The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.

Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).

This work is part of second round of incubation of the Vector API.
JEP: https://bugs.openjdk.java.net/browse/JDK-8261663

Please review.

Performance:
Micro benchmark Base Optimized Unit Gain(Optimized/Base)
Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
Double128Vector.COS 49.94 245.89 ops/ms 4.92
Double128Vector.COSH 26.91 126.00 ops/ms 4.68
Double128Vector.EXP 71.64 379.65 ops/ms 5.30
Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
Double128Vector.LOG 61.95 279.84 ops/ms 4.52
Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
Double128Vector.SIN 49.36 240.79 ops/ms 4.88
Double128Vector.SINH 26.59 103.75 ops/ms 3.90
Double128Vector.TAN 41.05 152.39 ops/ms 3.71
Double128Vector.TANH 45.29 169.53 ops/ms 3.74
Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
Double256Vector.COS 58.26 389.77 ops/ms 6.69
Double256Vector.COSH 29.44 151.11 ops/ms 5.13
Double256Vector.EXP 86.67 564.68 ops/ms 6.52
Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
Double256Vector.LOG 71.52 394.90 ops/ms 5.52
Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
Double256Vector.SIN 57.06 380.98 ops/ms 6.68
Double256Vector.SINH 29.40 117.37 ops/ms 3.99
Double256Vector.TAN 44.90 279.90 ops/ms 6.23
Double256Vector.TANH 54.08 274.71 ops/ms 5.08
Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
Double512Vector.COS 59.88 837.04 ops/ms 13.98
Double512Vector.COSH 30.34 172.76 ops/ms 5.70
Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
Double512Vector.LOG 74.84 996.00 ops/ms 13.31
Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
Double512Vector.POW 37.42 384.13 ops/ms 10.26
Double512Vector.SIN 59.74 728.45 ops/ms 12.19
Double512Vector.SINH 29.47 143.38 ops/ms 4.87
Double512Vector.TAN 46.20 587.21 ops/ms 12.71
Double512Vector.TANH 57.36 495.42 ops/ms 8.64
Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
Double64Vector.COS 23.42 152.01 ops/ms 6.49
Double64Vector.COSH 17.34 113.34 ops/ms 6.54
Double64Vector.EXP 27.08 203.53 ops/ms 7.52
Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
Double64Vector.LOG 26.75 142.63 ops/ms 5.33
Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
Double64Vector.SIN 23.28 146.91 ops/ms 6.31
Double64Vector.SINH 17.62 88.59 ops/ms 5.03
Double64Vector.TAN 21.00 86.43 ops/ms 4.12
Double64Vector.TANH 23.75 111.35 ops/ms 4.69
Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
Float128Vector.COS 42.82 803.02 ops/ms 18.75
Float128Vector.COSH 31.44 118.34 ops/ms 3.76
Float128Vector.EXP 72.43 855.33 ops/ms 11.81
Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
Float128Vector.LOG 52.95 877.94 ops/ms 16.58
Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
Float128Vector.SIN 43.38 745.31 ops/ms 17.18
Float128Vector.SINH 31.11 112.91 ops/ms 3.63
Float128Vector.TAN 37.25 332.13 ops/ms 8.92
Float128Vector.TANH 57.63 453.77 ops/ms 7.87
Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
Float256Vector.COS 43.75 926.69 ops/ms 21.18
Float256Vector.COSH 33.52 130.46 ops/ms 3.89
Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
Float256Vector.SIN 44.07 911.04 ops/ms 20.67
Float256Vector.SINH 33.16 122.50 ops/ms 3.69
Float256Vector.TAN 37.85 497.75 ops/ms 13.15
Float256Vector.TANH 64.27 537.20 ops/ms 8.36
Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
Float512Vector.COS 40.92 1567.93 ops/ms 38.32
Float512Vector.COSH 33.42 138.36 ops/ms 4.14
Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
Float512Vector.POW 32.73 1015.85 ops/ms 31.04
Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
Float512Vector.SINH 33.05 129.39 ops/ms 3.91
Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
Float64Vector.COS 44.28 394.33 ops/ms 8.91
Float64Vector.COSH 28.35 95.27 ops/ms 3.36
Float64Vector.EXP 65.80 486.37 ops/ms 7.39
Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
Float64Vector.LOG 51.93 163.25 ops/ms 3.14
Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
Float64Vector.SIN 44.41 382.09 ops/ms 8.60
Float64Vector.SINH 28.20 90.68 ops/ms 3.22
Float64Vector.TAN 36.29 160.89 ops/ms 4.43
Float64Vector.TANH 47.65 214.04 ops/ms 4.49

-------------

Commit messages:
 - remove whitespace
 - Merge master
 - Small fix
 - cleanup
 - x86 short vector math optimization for Vector API

Changes: https://git.openjdk.java.net/jdk/pull/3638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265783
  Stats: 417153 lines in 124 files changed: 416959 ins; 126 del; 68 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From joehw at openjdk.java.net  Fri Apr 23 00:47:49 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 23 Apr 2021 00:47:49 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties
Message-ID: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>

Update module summary, add a few existing properties and features into the tables.

-------------

Commit messages:
 - 8265248: Implementation Specific Properties: change prefix, plus add existing properties

Changes: https://git.openjdk.java.net/jdk/pull/3644/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265248
  Stats: 873 lines in 14 files changed: 640 ins; 66 del; 167 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3644/head:pull/3644

PR: https://git.openjdk.java.net/jdk/pull/3644

From vromero at openjdk.java.net  Fri Apr 23 02:16:04 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 23 Apr 2021 02:16:04 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v4]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <d2S1kXjoYHbf5udn5apKvZynDITGCFg8wWzD1OWfAmE=.97cd30bb-f133-4f81-b55c-a031c4c5a386@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into JDK-8260517
 - updating comment after review feedback
 - removing javax.lang.model changes
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - fixing failing regression tests
 - JVM related changes
 - 8260517: Compiler implementation for Sealed Classes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/8ebe56fd..43e9cb5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=02-03

  Stats: 40790 lines in 1391 files changed: 8730 ins; 27464 del; 4596 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526

PR: https://git.openjdk.java.net/jdk/pull/3526

From yyang at openjdk.java.net  Fri Apr 23 03:50:54 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 23 Apr 2021 03:50:54 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  remove java_nio_Buffer in javaClasses.hpp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/a6affc54..7f30dc48

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=00-01

  Stats: 27 lines in 2 files changed: 0 ins; 27 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From stuart.marks at oracle.com  Fri Apr 23 06:33:21 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 22 Apr 2021 23:33:21 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
 <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
 <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>
Message-ID: <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>



On 4/22/21 8:36 AM, Stephen Colebourne wrote:
> On Thu, 22 Apr 2021 at 13:58, Remi Forax <forax at univ-mlv.fr> wrote:
>> I would like to preserve the invariant that, when calling a method on a Collection/iterator, an UnsupportedOperationException only occurs when trying to mutate that collection.
>> If we are ok with that, this means that addFirst can not be a default method of Collection.
> 
> This implementation meets the invariant:
> 
>   public interface Collection<E> .... {
>     default void addFirst(E e) { add(e); }
>     default E getFirst() { return iterator().next(); }
>     default E removeFirst() {
>       var i = iterator(); i.next();
>       i.remove();
>     }
>   }
> 
> This is what I intended anyway, ie that its OK for "first" to work on
> an unordered collection, just that addFirst() has very weak semantics
> wrt first-ness.
> 
> "Ensures that this collection contains the specified element(optional
> operation). This has the same basic behaviour as add(E), but
> implementations may choose to add the element in first position if
> they have some kind of guarantee of ordering. An exception should not
> be thrown unless add(E) would also have thrown the exception."

What seems to be going on here is that people want to add generality by promoting 
this set of methods from ReversibleCollection up to Collection. Unfortunately, the 
only way to do so is to make the specification so loose that the semantics are 
destroyed.

Having these methods on Collection could lead to a situation where calling addFirst 
and then getFirst might result in getFirst returning a different element from what 
was passed to addFirst. This doesn't make any sense for methods that have "first" in 
the name.

It seems like there's some other use case that people have in mind, such as "get an 
arbitrary element from this collection". The obvious way to implement this is 
iterator().next() which gets the "first" element from the iteration and so people 
are latching onto the name "getFirst". But let's not confuse the "first" element in 
a semantic ordering with the "first" element returned by an iterator. They're distinct.

s'marks

From stuart.marks at oracle.com  Fri Apr 23 06:56:53 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 22 Apr 2021 23:56:53 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr>
Message-ID: <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>

> An API can not use ReversibleCollection as parameter before all the implementations of Collection that have an ordering are updated to implement ReversibleCollection instead of Collection.
> 
> By example, if I add a method
>    public void foo(ReversibleCollection c)
> in my library, people that want to be able to use foo with an existing collection with an ordering have to wait that collection implementation to be updated.
> 
> So i will not add a method like foo in my API until enough (whatever enough means) implementation of Collection with an ordering have migrated.
> 
> This is a similar issue as the migration from Python 2 to Python 3, it takes at least 10 years, so in 10 years, I will be able to had a public method that takes a ReversibleCollection in my API,
> without people not be able to using it.

This is a gigantic overstatement of the issue.

It is true that an API *in the JDK* as a practical matter cannot change a Collection 
parameter to ReversibleCollection, because it will break any callers that are 
currently passing Collection. The same is true of any library APIs where 
compatibility is a concern.

However, it can be quite useful in many contexts to use ReversibleCollection as a 
parameter. Newly introduced APIs can use ReversibleCollection. Certain APIs that 
consume List could reasonably be adjusted to consume a ReversibleCollection instead. 
(More likely an overload would probably be added in order to preserve binary 
compatibility.) In contexts where compatibility across maintenance boundaries is not 
an issue -- that is, where APIs can be changed incompatibly by updating all callers 
-- it's easy to imagine a variety of scenarios where a List or Collection parameter 
can usefully be adjusted to ReversibleCollection.

>> ReversibleCollection unifies a broad set of existing collections without
>> requiring
>> any retrofitting at all. Many applications and libraries don't have their own
>> collection implementations; they just use the ones in the JDK. They can benefit
>> from
>> the new APIs in ReversibleCollection immediately, without the need for any
>> retrofitting at all.
> 
> nope, many applications do not use *only* the collection from the JDK,
> but also collections that comes from other libraries than msut to be upgraded to use ReversibleCollection.

We're not actually disagreeing. Many applications and libraries *do* use only the 
collections in the JDK. It is probably also true that other collection libraries are 
popular and are *also* used in many places.

Non-JDK collections libraries benefit, because any List, SortedSet, and Deque 
implementations provided by these libraries are automatically retrofitted to 
implement ReversibleCollection.

> ReversibleCollection can be a solution, it's also not the best way to say that you want a collection with an ordering,
> any collections with zero or one element is also a valid ordered collection, so by example a HashSet with only one element is a valid argument.

Sure, this is vacuously true. It doesn't seem to be an argument against 
ReversibleCollection.

>> If we can ascertain (via code searching) that introducing covariant overrides to
>> LinkedHashMap introduces minimal incompatibilities, we might decide to go ahead
>> with
>> the change. (What's considered "minimal" is of course up for discussion.)
>>
>> If however we decide the incompatibilities are too great, a fallback plan would
>> be
>> to introduce new methods reversibleEntrySet() et al for the reversible views.
>> This
>> would be a little bit disappointing, but it doesn't invalidate the
>> ReversibleCollection/ReversibleSet concept.
> 
> It shows that the concept ReversibleCollection/ReversibleSet concept while useful out of the blue, needs to be shoehorned in the JDK, making it not worth it because the cost vs reward has changed.

Ah, now you're talking about cost vs. benefit. Thus, you must agree that 
ReversibleCollection/ReversibleSet is a valid concept!

It's premature to make a decision based on costs and benefits -- really, risks of 
incompatibilities. I've done some preliminary searching and what I've found so far 
is promising; the risk of incompatibilities seems low. Additional searching might 
reveal information that changes the situation.

s'marks

From scolebourne at joda.org  Fri Apr 23 09:16:49 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 23 Apr 2021 10:16:49 +0100
Subject: ReversibleCollection proposal
In-Reply-To: <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
 <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
 <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>
 <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>
Message-ID: <CACzrW9AfByf=NdrXLnjupqpTY24QVRMxTn5H=zUMw_QZ-+Pkrw@mail.gmail.com>

On Fri, 23 Apr 2021 at 07:33, Stuart Marks <stuart.marks at oracle.com> wrote:
> On 4/22/21 8:36 AM, Stephen Colebourne wrote:
> Having these methods on Collection could lead to a situation where calling addFirst
> and then getFirst might result in getFirst returning a different element from what
> was passed to addFirst. This doesn't make any sense for methods that have "first" in
> the name.

FWIW, I'm comfortable with that weirdness. The method could be called
addPreferFirst() but that is a bit of a mouthful.

I'd also note that it is much easier for developers of other
Collection implementations to add a method with a matching name than
it is to implement a new interface. Even libraries maintaining
compatibility with Java 5 could do that.

Your proposal has a similar issue BTW - addFirst() on a SortedSet.
Your proposal is to throw UnsupportedOperationException, but I (like
Remi) think that isn't a good answer when
UnsupportedOperationException in collections is usually about
immutability. It is a natural problem of the domain that adding first
when the implementation is sorted is going to be confusing. I am
simply suggesting embracing the weirdness, rather than trying to
exception your way out of it.

Stephen

From scolebourne at joda.org  Fri Apr 23 09:23:03 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 23 Apr 2021 10:23:03 +0100
Subject: New Collections interface - Sized
Message-ID: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>

Hi all,
While a discussion on ReversibleCollection is going on, I'd like to
raise the interface I've always found most missing from the framework
- Sized

 public interface Sized {
   int size();
   default boolean isEmpty() {
     return size() == 0;
   }
   default boolean isNotEmpty() {
     return !isEmpty();
   }
}

This would be applied to Collection and Map, providing a missing
unification. Anything else that has a size could also be retrofitted,
such as String. Ideally arrays too, but that could come later. Note
that Iterable would not implement it.

WDYT?

Stephen

From pconcannon at openjdk.java.net  Fri Apr 23 10:49:40 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 23 Apr 2021 10:49:40 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II)
Message-ID: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>

Hi,

Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?

This PR was split into two parts due to the large number of files affected.

Kind regards,

Patrick

-------------

Commit messages:
 - 8265746: Update java.time to use instanceof pattern variable (part II)

Changes: https://git.openjdk.java.net/jdk/pull/3650/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3650&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265746
  Stats: 152 lines in 20 files changed: 0 ins; 48 del; 104 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3650.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3650/head:pull/3650

PR: https://git.openjdk.java.net/jdk/pull/3650

From dfuchs at openjdk.java.net  Fri Apr 23 11:00:31 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Apr 2021 11:00:31 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <oMqd9uG4qIwI92kNWhuMv1i0AWx1VJVbDo3dWeXai8g=.f4a0bb23-62c4-4835-994c-efe0c63b9cf0@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

LGTM!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3650

From lancea at openjdk.java.net  Fri Apr 23 11:12:33 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 23 Apr 2021 11:12:33 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <-1CxVPydMSiKTyd274URT4xzMlfa-KLiyr5J52aqUKM=.99488ec2-f770-4657-a62b-6dfc7cfc8854@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Looks good.  Thank you for the updates

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3650

From rriggs at openjdk.java.net  Fri Apr 23 13:35:33 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 23 Apr 2021 13:35:33 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <IPetXjlloeaIx3PAnZFaLWNPHOE9hUPh9uaRhHjPAMM=.b5b33a59-44db-4507-aa42-f5548297c6c4@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3650

From uschindler at openjdk.java.net  Fri Apr 23 13:57:33 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 23 Apr 2021 13:57:33 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v6]
In-Reply-To: <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
Message-ID: <YJSIidVG7rdx_j-OCJYdVlKEphWmQetnzTXkjtLrKiw=.ead720bb-c303-4ba5-b978-64e8f2167852@github.com>

On Wed, 21 Apr 2021 13:13:16 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8265137
>  - Remove @hidden
>  - Correct the hierarchy of Random
>  - Remove extraneous references to makeXXXSpliterator
>  - Move makeXXXSpliterator methods to RandomSupport
>  - change static final from 'proxy' to 'PROXY'
>  - Make makeXXXSpliterator final
>  - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

Hi,
the overall setup is mch better than before! This also makes the problem we have seen in https://github.com/policeman-tools/forbidden-apis/issues/177 go away, because Random/ThreadLocalRandom no longer extend a public, but internal/hidden class (forbiddenapis is a classfile analyzer that tries to prevent user's from extending internal JDK APIs in one of its checks). When looking into superclasses of Random, it detected a "bad superclass from an internal package".

So this alone makes me very happy with this.

In addition, it no longer changes APIs of Random/ThreadLocalRandom, only the new interface is added.

+1 to merge

-------------

Marked as reviewed by uschindler (Author).

PR: https://git.openjdk.java.net/jdk/pull/3469

From chegar at openjdk.java.net  Fri Apr 23 14:34:25 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 23 Apr 2021 14:34:25 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <frmXbSglJBsqm0AYpbnD7U64zNbqwlTMHNT09HmGDUk=.7f1d7910-e335-45e4-af24-d58efdb7ea4d@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Marked as reviewed by chegar (Reviewer).

src/java.base/share/classes/java/time/Clock.java line 623:

> 621:             return (obj instanceof FixedClock other
> 622:                     && instant.equals(other.instant)
> 623:                     && zone.equals(other.zone));

The outer set of braces is redundant.

src/java.base/share/classes/java/time/Clock.java line 673:

> 671:             return (obj instanceof OffsetClock other
> 672:                     && baseClock.equals(other.baseClock)
> 673:                     && offset.equals(other.offset));

The outer set of braces is redundant.

src/java.base/share/classes/java/time/ZonedDateTime.java line 2191:

> 2189:             && dateTime.equals(other.dateTime)
> 2190:             && offset.equals(other.offset)
> 2191:             && zone.equals(other.zone));

same here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3650

From pconcannon at openjdk.java.net  Fri Apr 23 15:38:53 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 23 Apr 2021 15:38:53 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II) [v2]
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Patrick Concannon 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:

 - Removed redundant braces
 - Merge remote-tracking branch 'origin/master' into JDK-8265746
 - 8265746: Update java.time to use instanceof pattern variable (part II)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3650/files
  - new: https://git.openjdk.java.net/jdk/pull/3650/files/974ccbf0..7f32ddbe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3650&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3650&range=00-01

  Stats: 519 lines in 11 files changed: 275 ins; 177 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3650.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3650/head:pull/3650

PR: https://git.openjdk.java.net/jdk/pull/3650

From chegar at openjdk.java.net  Fri Apr 23 15:50:32 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 23 Apr 2021 15:50:32 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II) [v2]
In-Reply-To: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
Message-ID: <peAcwyy7z98-wHpFEWWk7ZeHVkXkDLvolvg8wJtfyDg=.82bbd7e0-aed2-4cbe-aa38-9e67e6aed943@github.com>

On Fri, 23 Apr 2021 15:38:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon 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:
> 
>  - Removed redundant braces
>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>  - 8265746: Update java.time to use instanceof pattern variable (part II)

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3650

From brian.goetz at oracle.com  Fri Apr 23 16:07:56 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 23 Apr 2021 12:07:56 -0400
Subject: New Collections interface - Sized
In-Reply-To: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
References: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
Message-ID: <4a6b648c-ddc5-8ab5-4274-9463ffac7850@oracle.com>

This has come up before.? For example, during an early iteration of the 
Stream design, before parallelism entered the picture.? The first 
scrawled-on-a-napkin prototype for streams was based on Iterator, and it 
took about a minute to realize that we could do a much better job if we 
had a slightly broader interface to work with, essentially Iterator+Sized.

When you pull on this string, you end up with a lot of new interfaces, 
such as SizedIterator, SizedIterable, etc, in part because ... we have 
no intersection types.? Having lots of fine-grained interfaces for "has 
X" and "has Y" is nice from a "bucket of lego bricks" library-design 
perspective, but when the user goes to express "I need an aggregate that 
has sizes, iterators, and encounter order", you end up with code like:

 ??? <T, X extends Iterable<T>&Sized> void foo(X x) { ... }

and then you run into the wall of "but I can only use intersection types 
in these places in the language."? The idiom of having fine-grained 
mix-in-ish interfaces really wants a language with intersection types.

Additionally, I am having a hard time imagining how Sized would be 
usable by a client; no method will *take* a Sized (it's just not broad 
enough), and I can't immediately imagine what would even *return* a 
Sized.? If the type is not suitable for use by clients, then it serves 
only to organize the library itself, and that's a weaker motivation.

Is there a compelling example of where this would be used by clients?


On 4/23/2021 5:23 AM, Stephen Colebourne wrote:
> Hi all,
> While a discussion on ReversibleCollection is going on, I'd like to
> raise the interface I've always found most missing from the framework
> - Sized
>
>   public interface Sized {
>     int size();
>     default boolean isEmpty() {
>       return size() == 0;
>     }
>     default boolean isNotEmpty() {
>       return !isEmpty();
>     }
> }
>
> This would be applied to Collection and Map, providing a missing
> unification. Anything else that has a size could also be retrofitted,
> such as String. Ideally arrays too, but that could come later. Note
> that Iterable would not implement it.
>
> WDYT?
>
> Stephen


From naoto at openjdk.java.net  Fri Apr 23 16:07:24 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Apr 2021 16:07:24 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II) [v2]
In-Reply-To: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
Message-ID: <kqykhuV_Ybdiv1Llz_9jzIgcKNx_BZwxD1Aiz-bCb9w=.9f8e807b-419a-4d36-971c-62b3204dcd9b@github.com>

On Fri, 23 Apr 2021 15:38:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon 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:
> 
>  - Removed redundant braces
>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>  - 8265746: Update java.time to use instanceof pattern variable (part II)

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3650

From rriggs at openjdk.java.net  Fri Apr 23 16:41:27 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 23 Apr 2021 16:41:27 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II) [v2]
In-Reply-To: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
Message-ID: <2MUSw9rrhD8ohPlIEG2YG7J9ZkFgCix7KtfdbTCkqiI=.4e181182-5837-4884-9dc7-5c3acf753923@github.com>

On Fri, 23 Apr 2021 15:38:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon 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:
> 
>  - Removed redundant braces
>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>  - 8265746: Update java.time to use instanceof pattern variable (part II)

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3650

From lancea at openjdk.java.net  Fri Apr 23 16:53:28 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 23 Apr 2021 16:53:28 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II) [v2]
In-Reply-To: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
Message-ID: <-FIE6L9Jy52RAQtypdFndpdrSUl1UVmhQFR8cAwHQAg=.aaa1465b-102d-43b3-b4c9-4914cc77bec2@github.com>

On Fri, 23 Apr 2021 15:38:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon 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:
> 
>  - Removed redundant braces
>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>  - 8265746: Update java.time to use instanceof pattern variable (part II)

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3650

From alanb at openjdk.java.net  Fri Apr 23 18:41:27 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Apr 2021 18:41:27 GMT
Subject: RFR: 8264208: Console charset API [v12]
In-Reply-To: <qpGVFkTn8o9gjOJp11t_s2uNcCkTQLgsdcYMPKHeJnE=.4b38a4da-42a4-4c54-a179-d79ea1fa5207@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
 <qpGVFkTn8o9gjOJp11t_s2uNcCkTQLgsdcYMPKHeJnE=.4b38a4da-42a4-4c54-a179-d79ea1fa5207@github.com>
Message-ID: <rrRaDrY2Ogy-MT12qzluMpl9JvfD6jOjM4z3d0t_dDk=.95366be5-7402-4ab4-ae61-69e98813660a@github.com>

On Thu, 22 Apr 2021 17:38:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revived charset() in JavaIOAccess interface.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From naoto at openjdk.java.net  Fri Apr 23 19:00:42 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Apr 2021 19:00:42 GMT
Subject: Integrated: 8264208: Console charset API
In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>
Message-ID: <1iJ4QzneevQxxAkO5kDUwjmhzolU0rXBd3hrte6Vy0g=.e61cdd55-fa9b-4678-ae21-8fee0aae3b72@github.com>

On Fri, 9 Apr 2021 16:47:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes for the subject issue.  This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

This pull request has now been integrated.

Changeset: bebfae48
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bebfae48
Stats:     214 lines in 10 files changed: 184 ins; 12 del; 18 mod

8264208: Console charset API

Reviewed-by: joehw, rriggs, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3419

From bpb at openjdk.java.net  Fri Apr 23 19:36:29 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 23 Apr 2021 19:36:29 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]
In-Reply-To: <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
Message-ID: <zx326Q0GrwLntDbIGljztGHQwzIMLxutYj1WEzCsXOE=.a9730cc0-30ce-4e61-aefc-a9eabf190270@github.com>

On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge master
>  - Fix bug in CharArrayReader and add unit test
>  - Clean up unit tests
>  - Revert off-heap code path
>  - Replace c-style array declarations
>  - Share work buffer between #skip and #read
>  - Update copyright year
>  - Implement review comment
>  - Revert StreamDecoder changes
>  - Implement CharArrayReader#read(CharBuffer)
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0

This PR is on hold pending the author's issuing the `/integrate` command.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1915

From javalists at cbfiddle.com  Fri Apr 23 19:57:53 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 23 Apr 2021 12:57:53 -0700
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <f270b7e3-2c33-168e-6ae7-6c9f81ee900e@oracle.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <-fco_my21rYwE8RlEaFlsc-g0WL_rPzbLBWllNqY2rw=.9782b940-c827-4dad-bba8-6901f75fdcf8@github.com>
 <f270b7e3-2c33-168e-6ae7-6c9f81ee900e@oracle.com>
Message-ID: <85FD6F38-71A6-4055-AB02-76DF7BC08A5B@cbfiddle.com>

On Apr 21, 2021, at 11:40 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> Sure, if you are using native code then you have the full power of JVM TI and JNI available. Project Panama is exploring how to restrict access to native code, I think too early to say how this might extend to JNI.

I looked at some of the Panama documents and saw no hint that it might be extended to JNI. It seems to be positioned as an (partial) alternative to JNI.

What I do see is that native code has no direct access to the JDK via Panama, only the ability to invoke provided upcalls, which can only access objects and methods that the caller has access to. That is indeed much more restricted than JNI.

Even though it is ?too early?, can you explain why you think Panama?s restrictions might apply to JNI?

As a library developer, I have often made use of JNI to work around limitations in current and older JDKs. I would hate to lose that ability.

   Alan


From scolebourne at joda.org  Fri Apr 23 21:14:40 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 23 Apr 2021 22:14:40 +0100
Subject: New Collections interface - Sized
In-Reply-To: <4a6b648c-ddc5-8ab5-4274-9463ffac7850@oracle.com>
References: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
 <4a6b648c-ddc5-8ab5-4274-9463ffac7850@oracle.com>
Message-ID: <CACzrW9A+KVG0sbJ48XV7L+tXFid7GaFomouYyTB0otNs5zKAhw@mail.gmail.com>

On Fri, 23 Apr 2021 at 17:08, Brian Goetz <brian.goetz at oracle.com> wrote:
> This has come up before.  For example, during an early iteration of the Stream design, before parallelism entered the picture.  The first scrawled-on-a-napkin prototype for streams was based on Iterator, and it took about a minute to realize that we could do a much better job if we had a slightly broader interface to work with, essentially Iterator+Sized.
>
> When you pull on this string, you end up with a lot of new interfaces, such as SizedIterator, SizedIterable, etc, in part because ... we have no intersection types.  Having lots of fine-grained interfaces for "has X" and "has Y" is nice from a "bucket of lego bricks" library-design perspective, but when the user goes to express "I need an aggregate that has sizes, iterators, and encounter order", you end up with code like:
>
>     <T, X extends Iterable<T>&Sized> void foo(X x) { ... }
>
> and then you run into the wall of "but I can only use intersection types in these places in the language."  The idiom of having fine-grained mix-in-ish interfaces really wants a language with intersection types.
>
> Additionally, I am having a hard time imagining how Sized would be usable by a client; no method will *take* a Sized (it's just not broad enough), and I can't immediately imagine what would even *return* a Sized.  If the type is not suitable for use by clients, then it serves only to organize the library itself, and that's a weaker motivation.
>
> Is there a compelling example of where this would be used by clients?

Here are some examples:
https://stackoverflow.com/questions/10988634/java-global-isempty-method
https://github.com/OpenGamma/Strata/blob/main/modules/collect/src/main/java/com/opengamma/strata/collect/ArgChecker.java#L404

ie. the ability to spot an "empty" object, or ensure input is
non-empty. Use cases are generally in low-level/framework code like
this, where the actual input data type is not known.

Stephen

From brian.goetz at oracle.com  Fri Apr 23 22:07:43 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 23 Apr 2021 18:07:43 -0400
Subject: New Collections interface - Sized
In-Reply-To: <CACzrW9A+KVG0sbJ48XV7L+tXFid7GaFomouYyTB0otNs5zKAhw@mail.gmail.com>
References: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
 <4a6b648c-ddc5-8ab5-4274-9463ffac7850@oracle.com>
 <CACzrW9A+KVG0sbJ48XV7L+tXFid7GaFomouYyTB0otNs5zKAhw@mail.gmail.com>
Message-ID: <40150d5b-d7da-83cb-d071-3e75afddd6d8@oracle.com>


>> Is there a compelling example of where this would be used by clients?
> Here are some examples:
> https://stackoverflow.com/questions/10988634/java-global-isempty-method
Without passing judgment on the sort of dynamically typed programs that 
need a method like this, or wondering what monstrosities such code uses 
to actually _get_ the data out of this weird ad-hoc union, note that 
this code becomes dramatically simpler with pattern matching:

 ??? return switch (c) {
 ??????? case null -> true;
 ??????? case CharSequence cs -> cs.length() == 0;
 ??????? case Collection c -> c.isEmpty();
 ??????? case Object[] os -> os.length == 0;
 ??????? default -> { weird reflective thingy }
 ??? }

Note also that a Sized abstraction only addresses two of these five 
cases -- CharSequence and Collection.? The others would still require 
such ad-hoc treatment.

And while it may seem like I have pattern matching on the brain, there's 
a point to bringing up pattern matching -- which is that real code often 
ends up dealing with ad-hoc unions, and a linguistic mechanism for 
abstracting computations over ad-hoc unions is often a better solution 
if you find yourself in ad-hoc land than trying to partially unify it.

But again, if you are treating these things as containers, then a Sized 
doesn't get you very far, because if you conclude the thing isn't empty, 
you're going to want to get stuff out, and Sized has no methods for 
that.? So presumably there's some companion to Sized for accessing 
elements by index:

 ??? interface HasStuff<T> extends Sized {
 ??????? T get(int index);
 ??? }

And note that in order for HasStuff to be useful, it has to extend 
Sized, because, no intersection types.? Which suggests Sized is not the 
abstraction you are looking for.

And again, pattern matching:

 ??? Object getElement(Object thingWithStuff, int index) {
 ??????? return switch (thingWithStuff) {
 ??????????? case null -> null;
 ??????????? case Object[] os -> os[index];
 ??????????? case Collection<?> c -> c.get(index);
 ??????????? ... more if you can think of them ...
 ?????? };



From scolebourne at joda.org  Fri Apr 23 22:14:51 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 23 Apr 2021 23:14:51 +0100
Subject: New Collections interface - Sized
In-Reply-To: <40150d5b-d7da-83cb-d071-3e75afddd6d8@oracle.com>
References: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
 <4a6b648c-ddc5-8ab5-4274-9463ffac7850@oracle.com>
 <CACzrW9A+KVG0sbJ48XV7L+tXFid7GaFomouYyTB0otNs5zKAhw@mail.gmail.com>
 <40150d5b-d7da-83cb-d071-3e75afddd6d8@oracle.com>
Message-ID: <CACzrW9Dc5tvwMdVXkuWSfQbbP8rbfHE0FNaxckN=G2ZCzv18Eg@mail.gmail.com>

On Fri, 23 Apr 2021 at 23:07, Brian Goetz <brian.goetz at oracle.com> wrote:
> >> Is there a compelling example of where this would be used by clients?
> > Here are some examples:
> > https://stackoverflow.com/questions/10988634/java-global-isempty-method
> Without passing judgment on the sort of dynamically typed programs that
> need a method like this

The other example is better as it benefits from declaring an API that
only accepts instances of `Sized` and does not need to get the
contents.

> But again, if you are treating these things as containers, then a Sized
> doesn't get you very far, because if you conclude the thing isn't empty,
> you're going to want to get stuff out, and Sized has no methods for
> that.  So presumably there's some companion to Sized for accessing
> elements by index:
>
>      interface HasStuff<T> extends Sized {
>          T get(int index);
>      }

I don't think there has to be. the more useful interface would be this
one, but to date there has been strong resistance in unifying the
Collection and Map interfaces:

     interface Stuff<T> extends Sized {
         int size();
         int isEmpty();
         int isNotEmpty();
        Iterator<t> iterator();
     }

Stephen

From forax at univ-mlv.fr  Fri Apr 23 22:38:05 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 24 Apr 2021 00:38:05 +0200 (CEST)
Subject: New Collections interface - Sized
In-Reply-To: <CACzrW9Dc5tvwMdVXkuWSfQbbP8rbfHE0FNaxckN=G2ZCzv18Eg@mail.gmail.com>
References: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
 <4a6b648c-ddc5-8ab5-4274-9463ffac7850@oracle.com>
 <CACzrW9A+KVG0sbJ48XV7L+tXFid7GaFomouYyTB0otNs5zKAhw@mail.gmail.com>
 <40150d5b-d7da-83cb-d071-3e75afddd6d8@oracle.com>
 <CACzrW9Dc5tvwMdVXkuWSfQbbP8rbfHE0FNaxckN=G2ZCzv18Eg@mail.gmail.com>
Message-ID: <2144890353.1471828.1619217485210.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Samedi 24 Avril 2021 00:14:51
> Objet: Re: New Collections interface - Sized

> On Fri, 23 Apr 2021 at 23:07, Brian Goetz <brian.goetz at oracle.com> wrote:
>> >> Is there a compelling example of where this would be used by clients?
>> > Here are some examples:
>> > https://stackoverflow.com/questions/10988634/java-global-isempty-method
>> Without passing judgment on the sort of dynamically typed programs that
>> need a method like this
> 
> The other example is better as it benefits from declaring an API that
> only accepts instances of `Sized` and does not need to get the
> contents.
> 
>> But again, if you are treating these things as containers, then a Sized
>> doesn't get you very far, because if you conclude the thing isn't empty,
>> you're going to want to get stuff out, and Sized has no methods for
>> that.  So presumably there's some companion to Sized for accessing
>> elements by index:
>>
>>      interface HasStuff<T> extends Sized {
>>          T get(int index);
>>      }
> 
> I don't think there has to be. the more useful interface would be this
> one, but to date there has been strong resistance in unifying the
> Collection and Map interfaces:
> 
>     interface Stuff<T> extends Sized {
>         int size();
>         int isEmpty();
>         int isNotEmpty();
>        Iterator<t> iterator();
>     }

This is basically Spliterator, an iterator + a size, with the iterator is "push" instead of "pull" because it's more efficient.

In details a Spliterator is either
- an Iterable (with no SIZED characteristic)
- an Iterable + size (if SIZED and estimateSize() != Long.MAX_VALUE)
- an Iterable + comparator (if SORTED and comparator != null)
- an Iterable + split (if trySplit != null)

and all combinations of the above.

> 
> Stephen

R?mi

From brian.goetz at oracle.com  Fri Apr 23 22:40:54 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 23 Apr 2021 18:40:54 -0400
Subject: New Collections interface - Sized
In-Reply-To: <2144890353.1471828.1619217485210.JavaMail.zimbra@u-pem.fr>
References: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
 <4a6b648c-ddc5-8ab5-4274-9463ffac7850@oracle.com>
 <CACzrW9A+KVG0sbJ48XV7L+tXFid7GaFomouYyTB0otNs5zKAhw@mail.gmail.com>
 <40150d5b-d7da-83cb-d071-3e75afddd6d8@oracle.com>
 <CACzrW9Dc5tvwMdVXkuWSfQbbP8rbfHE0FNaxckN=G2ZCzv18Eg@mail.gmail.com>
 <2144890353.1471828.1619217485210.JavaMail.zimbra@u-pem.fr>
Message-ID: <f738f286-a74f-5b08-0689-b972d47bd755@oracle.com>


> This is basically Spliterator, an iterator + a size, with the iterator is "push" instead of "pull" because it's more efficient.
>
> In details a Spliterator is either
> - an Iterable (with no SIZED characteristic)
> - an Iterable + size (if SIZED and estimateSize() != Long.MAX_VALUE)
> - an Iterable + comparator (if SORTED and comparator != null)
> - an Iterable + split (if trySplit != null)
>
> and all combinations of the above.
>
So, you're asking for Spliterable<T>, no??? :)


From forax at univ-mlv.fr  Fri Apr 23 22:51:13 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 24 Apr 2021 00:51:13 +0200 (CEST)
Subject: New Collections interface - Sized
In-Reply-To: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
References: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
Message-ID: <1897506859.1473433.1619218273416.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 23 Avril 2021 11:23:03
> Objet: New Collections interface - Sized

> Hi all,
> While a discussion on ReversibleCollection is going on, I'd like to
> raise the interface I've always found most missing from the framework
> - Sized
> 
> public interface Sized {
>   int size();
>   default boolean isEmpty() {
>     return size() == 0;
>   }
>   default boolean isNotEmpty() {
>     return !isEmpty();
>   }
> }
> 
> This would be applied to Collection and Map, providing a missing
> unification. Anything else that has a size could also be retrofitted,
> such as String. Ideally arrays too, but that could come later. Note
> that Iterable would not implement it.
> 
> WDYT?

There are 3 ways to have instances of different classes to have a common behavior in Java,
- either thy implement a common super-type
- or you use a structural type conversion (a method ref on an instance)
  here:
    Sized sized = list::size;
- or you use pattern matching (or a cascade of if/else if you are like the old fashion)
    int size(Object o) {
      return switch(o) {
        case List<?> list -> list.size();
        case Object[] array -> array.length();
        case String s -> s.length();
        default -> throw ...
      };
    }

The advantage of pattern matching is that it does not have a global impact, out of where you want to use it,
by example, here, you can use s.length() instead of s.codepoints().count() without having to think what the default size of a String means for all program that can be written. 

> 
> Stephen

R?mi

From forax at univ-mlv.fr  Fri Apr 23 22:56:12 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sat, 24 Apr 2021 00:56:12 +0200 (CEST)
Subject: New Collections interface - Sized
In-Reply-To: <f738f286-a74f-5b08-0689-b972d47bd755@oracle.com>
References: <CACzrW9Ae5Turtkv4fYusyajqovujGcTZW2F8n0rmVfV6VPgWkg@mail.gmail.com>
 <4a6b648c-ddc5-8ab5-4274-9463ffac7850@oracle.com>
 <CACzrW9A+KVG0sbJ48XV7L+tXFid7GaFomouYyTB0otNs5zKAhw@mail.gmail.com>
 <40150d5b-d7da-83cb-d071-3e75afddd6d8@oracle.com>
 <CACzrW9Dc5tvwMdVXkuWSfQbbP8rbfHE0FNaxckN=G2ZCzv18Eg@mail.gmail.com>
 <2144890353.1471828.1619217485210.JavaMail.zimbra@u-pem.fr>
 <f738f286-a74f-5b08-0689-b972d47bd755@oracle.com>
Message-ID: <1384909097.1473707.1619218572808.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>, "Stephen Colebourne" <scolebourne at joda.org>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Samedi 24 Avril 2021 00:40:54
> Objet: Re: New Collections interface - Sized

>> This is basically Spliterator, an iterator + a size, with the iterator is "push"
>> instead of "pull" because it's more efficient.
>>
>> In details a Spliterator is either
>> - an Iterable (with no SIZED characteristic)
>> - an Iterable + size (if SIZED and estimateSize() != Long.MAX_VALUE)
>> - an Iterable + comparator (if SORTED and comparator != null)
>> - an Iterable + split (if trySplit != null)
>>
>> and all combinations of the above.

oops, i've written Iterable instead of Iterator. 

>>
> So, you're asking for Spliterable<T>, no??? :)

a Supplier<Spliterator<T>> is a Spliterable<T>, as in StreamSupport.stream() [1].

R?mi

[1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/StreamSupport.html#stream(java.util.function.Supplier,int,boolean)


From tvaleev at openjdk.java.net  Sat Apr 24 01:32:45 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sat, 24 Apr 2021 01:32:45 GMT
Subject: RFR: 8265356: need code example for getting canonical constructor
 of a Record [v2]
In-Reply-To: <YIXReZGwfOekkWodThE2ofggNC1vMVPEoUu9PohR7QA=.3fc2f794-2b4f-4f85-ac41-3f7af9b880d4@github.com>
References: <YIXReZGwfOekkWodThE2ofggNC1vMVPEoUu9PohR7QA=.3fc2f794-2b4f-4f85-ac41-3f7af9b880d4@github.com>
Message-ID: <CjQ-pKQqGcsJiVQ6Sx8-PHoqCskEXQ5-uWiJAguzlYo=.4737c4f2-96d4-4ee4-aebc-96e332d9fcff@github.com>

> I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static <T extends Record>\nConstructor<T> getCanonicalConstructor(Class<T> cls)` is unnecessary.
> 
> ---
> Aside from this PR, I've found a couple of things to clean up in `java.lang.Class`:
> 1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by @jddarcy in #3038). It should be `#isArray()` instead of `isArray()`.
> 2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused type parameters `<T>`.
> 3. Probably too much but AnnotationData can be nicely converted to a record! Not sure, probably nobody wants to have `java.lang.Record` initialized too early or increasing the footprint of such a basic class in the metaspace, so I don't insist on this.
> 
> 
>     private record AnnotationData(
>         Map<Class<? extends Annotation>, Annotation> annotations,
>         Map<Class<? extends Annotation>, Annotation> declaredAnnotations,
>         // Value of classRedefinedCount when we created this AnnotationData instance
>         int redefinedCount) {
>     }
> 
> 
> Please tell me if it's ok to fix 1 and 2 along with this PR.

Tagir F. Valeev has updated the pull request incrementally with three additional commits since the last revision:

 - Trailing space removed
 - Add a reference from java.lang.Record to related Class methods
 - Fix cosmetic issues

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3556/files
  - new: https://git.openjdk.java.net/jdk/pull/3556/files/5b631cfe..1133ab7d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3556&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3556&range=00-01

  Stats: 13 lines in 2 files changed: 4 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3556.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3556/head:pull/3556

PR: https://git.openjdk.java.net/jdk/pull/3556

From tvaleev at openjdk.java.net  Sat Apr 24 01:36:24 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Sat, 24 Apr 2021 01:36:24 GMT
Subject: RFR: 8265356: need code example for getting canonical constructor
 of a Record
In-Reply-To: <VO44tMXfQN3o_SP98WFF_J06D9mRb66VgOS_uqEII2o=.aac2e431-b616-4f08-9223-eacf5f68f657@github.com>
References: <YIXReZGwfOekkWodThE2ofggNC1vMVPEoUu9PohR7QA=.3fc2f794-2b4f-4f85-ac41-3f7af9b880d4@github.com>
 <VO44tMXfQN3o_SP98WFF_J06D9mRb66VgOS_uqEII2o=.aac2e431-b616-4f08-9223-eacf5f68f657@github.com>
Message-ID: <uBvJcwj7qGUjB_oGiZGWG1t7n7jGZ4AT1CJEO8I0MxY=.253318a7-c79d-46a6-8adc-50cd14c8f94c@github.com>

On Tue, 20 Apr 2021 17:42:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static <T extends Record>\nConstructor<T> getCanonicalConstructor(Class<T> cls)` is unnecessary.
>> 
>> ---
>> Aside from this PR, I've found a couple of things to clean up in `java.lang.Class`:
>> 1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by @jddarcy in #3038). It should be `#isArray()` instead of `isArray()`.
>> 2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused type parameters `<T>`.
>> 3. Probably too much but AnnotationData can be nicely converted to a record! Not sure, probably nobody wants to have `java.lang.Record` initialized too early or increasing the footprint of such a basic class in the metaspace, so I don't insist on this.
>> 
>> 
>>     private record AnnotationData(
>>         Map<Class<? extends Annotation>, Annotation> annotations,
>>         Map<Class<? extends Annotation>, Annotation> declaredAnnotations,
>>         // Value of classRedefinedCount when we created this AnnotationData instance
>>         int redefinedCount) {
>>     }
>> 
>> 
>> Please tell me if it's ok to fix 1 and 2 along with this PR.
>
> Thanks for writing this example.
> 
> I think that the example lines can be longer. I'd suggest putting the main part of the method declaration on the same line as `static <T extends Record>`, but leaving the `throws` clause on the next line.
> 
> I think including the small cleanups (1) and (2) in this PR is fine. Changing `AnnotationData` to be a record seems like it might have other effects, so I'd leave that one out.
> 
> One other thing I'd like to see is a link to this example code from places where people are likely to look for it. The class doc for `java.lang.Record` has a definition for "canonical constructor" so it would be nice to link to the example here. Something like "For further information about how to find the canonical constructor reflectively, see Class::getRecordComponents." (With appropriate javadoc markup.) This could either be a parenthetical comment somewhere in the "canonical constructor" discussion, or possibly a separate paragraph in the `@apiNote` section below.

@stuart-marks thank you for review. How about this note in Record class? I wrote it in a more general manner, without mentioning canonical constructors explicitly. Is it enough?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3556

From kbarrett at openjdk.java.net  Sat Apr 24 19:38:23 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 24 Apr 2021 19:38:23 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
Message-ID: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>

Please review this change to the String Deduplication facility.  It is being
changed to use OopStorage to hold weak references to relevant objects,
rather than bespoke data structures requiring dedicated processing phases by
supporting GCs.

(The Shenandoah update was contributed by Zhengyu Gu.)

This change significantly simplifies the interface between a given GC and
the String Deduplication facility, which should make it much easier for
other GCs to opt in.  However, this change does not alter the set of GCs
providing support; currently only G1 and Shenandoah support string
deduplication.  Adding support by other GCs will be in followup RFEs.

Reviewing via the diffs might not be all that useful for some parts, as
several files have been essentially completely replaced, and a number of
files have been added or eliminated.  The full webrev might be a better
place to look.

The major changes are in gc/shared/stringdedup/* and in the supporting
collectors, but there are also some smaller changes in other places, most
notably classfile/{stringTable,javaClasses}.

This change is additionally labeled for review by core-libs, although there
are no source changes there.  This change injects a byte field of bits into
java.lang.String, using one of the previously unused padding bytes in that
class.  (There were two unused bytes, now only one.)

Testing:
mach5 tier1-2 with and without -XX:+UseStringDeduplication

Locally (linux-x64) ran all of the existing tests that use string
deduplication with both G1 and Shenandoah.  Note that
TestStringDeduplicationInterned.java is disabled for shenandoah, as it
currently fails, for reasons I haven't figured out but suspect are test
related.

- gc/stringdedup/   -- these used to be in gc/g1
- runtime/cds/SharedStringsDedup.java
- runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
- runtime/cds/appcds/sharedStrings/*

shenandoah-only:
- gc/shenandoah/jvmti/TestHeapDump.java
- gc/shenandoah/TestStringDedup.java
- gc/shenandoah/TestStringDedupStress.java

Performance tested baseline, baseline + stringdedup, new with stringdedup,
finding no significant differences.

-------------

Commit messages:
 - New string deduplication

Changes: https://git.openjdk.java.net/jdk/pull/3662/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254598
  Stats: 6185 lines in 105 files changed: 2361 ins; 3202 del; 622 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662

PR: https://git.openjdk.java.net/jdk/pull/3662

From 93q62q at gmail.com  Sat Apr 24 21:59:59 2021
From: 93q62q at gmail.com (Andrew Oliver)
Date: Sat, 24 Apr 2021 14:59:59 -0700
Subject: Proposal to add JavaScript platform to jpackage
Message-ID: <CADCvFPacpOzwVcbwZ9Xbsx=88p=16+FfzWOZQzVdCZab=4LC_g@mail.gmail.com>

Below is a Java Enhancement Proposal for your consideration to add
JavaScript to jpackage as a new target platform.  I would appreciate
feedback on the proposal contents.  I am also interested in learning about
the process, specifically what approvals are required prior to start of
implementation, should sufficient consensus be reached.

( To view this proposal as a web page, please visit:
https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html )

Thank you!

  -Andrew Oliver

Title: Add JavaScript platform to jpackage
Author: Andrew Oliver
Created: 2021/04/24
Type: Feature
State: Draft
Exposure: Open
Component: tools/jpackage
Scope: JDK
Discussion: core-libs-dev at openjdk.java.net
Template: 1.0

Summary
-------

jpackage already allows packaging Java applications for several platforms.
This proposal adds a new platform: JavaScript.

This effort will enable jpackage to convert bytecode from the provided
classes into JavaScript, and generate the required HTML to invoke the
specified main method when opened in a web browser. These files will be
bundled into a WAR file for easy deployment.

Goals
-----

*   Enabling JVM languages to build client-side web applications
*   Allow easy generation of JavaScript from JVM bytecode
*   Allow easy deployment and execution of generated JavaScript in web
browsers
*   Allow easy deployment of the generated JavaScript in all web server
environments
    *   Java web application container (like Tomcat)
    *   Static file web servers
    *   Static file web hosting services

Non-Goals
---------

*   Allowing execution of JavaScript server-side. (Java already has
numerous options for executing bytecode server-side.)

Motivation
----------

Java was once used to create client-side web applications via applets that
could be launched by visiting a web page. Applets could draw on an area of
the screen (like HTML5 Canvas) or manipulate the page DOM to create dynamic
front-end applications (like JS single-page apps).

However, as evident in JEP 398 ([
https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)),
applets are no longer feasible due to the actions of browser vendors. While
browsers have lost the ability to execute Java bytecode or invoke methods
from the Java class libraries, they do have mature engines for executing a
different sort of code (JavaScript) and an extensive list of useful APIs.
By converting class files to JavaScript, and providing mechanisms to invoke
browser APIs, Java can again be used to create in-browser applications.
[TeaVM](https://teavm.org) has demonstrated that this is feasible and has
numerous benefits:

*   Provides a strongly-typed language for client-side web development
*   Provides a wealth of IDEs, build tools, and testing tools for
client-side web development
*   Allows teams with Java experience to produce apps with familiar
technology
*   Allows sharing of POJO and business logic classes, simplifying
development
*   Allows options for porting applet- and JNLP-based systems to
present-day browsers

Details
-------

An additional jpackage option for type will be added: `js`

jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
code to JavaScript, with the main class compiled to a JavaScript method
called 'main()'.

jpackage bundles application code, runtime, and resources into a
platform-specific format. For this new JavaScript type, the layout will be
either a ZIP file or a standard WAR file. The ZIP format will contain the
files ready to be extracted to a static file webserver or HTML hosting
service. Generated WARs will have the required structure to be deployable
in a Java web application container.

### WAR layout

*   HelloApp.war
    *   index.html (Main application page, loads classes.js and invokes
main())
    *   teavm
        *   classes.js (Class files, templates, and resources compiled to
JavaScript)
    *   css
        *   (CSS files from application)
    *   META-INF
        *   MANIFEST.MF
    *   WEB-INF
        *   web.xml

### ZIP Layout

*   HelloApp.zip
    *   index.html (Main application page, loads classes.js and invokes
main())
    *   teavm
        *   classes.js (Class files, templates, and resources compiled to
JavaScript)
    *   css
        *   (CSS files from application)

Basic usage: Non-modular applications
-------------------------------------

Command-line usage is similar to jpackage today, except you use the `--type
js`. For example, if you have your application JARs in a folder called
`lib` and the JAR with the declared `main()` method is `main.jar`, you
could use this command:

```
$ jpackage --type js --name myapp --input lib --main-jar main.jar
```

This will produce `myapp.war` in the current directory. This is a standard
WAR file ready for deployment in any web application container (like
Tomcat). When myapp/index.html is opened in a browser, the code in main()
will be executed, in-browser. A typical Hello World main() method like

```
    public static void main(String args\[\]) {
        System.out.println("Hello, Browser!");
    }
```

will print the message on the browser developer console.

Processing
----------

Conversion of the input JAR files to the classes.js file will be done by
TeaVM. It will

*   Convert provided class files to JavaScript
*   Expose the specified main method as main()
*   Provide implementation of selected core Java classes that function in a
browser environment
*   Bundle resources into the generated JavaScript
*   Include images, css, and web.xml in the generated package, if provided
*   Provide default index.html if omitted
*   Provide default web.xml if omitted and WAR format specified
*   Optionally minify the generated JavaScript

### js-specific options

1.  `--minify`: Perform a minification pass after generating JavaScript,
renaming classes and methods to short, generated names to reduce download
sizes and provide some obfuscation.
2.  `--debug`: Enable generation of source maps.
3.  `--debug-full`: Enable generation of source maps and bundled source
files.
4.  `--optimization`: Choose simple, advanced, or full.
    *   simple: Perform only basic optimizations
    *   advanced: Perform more optimizations. Recommended for production.
    *   full: Perform aggressive optimizations. Increases compilation time.
5.  `--timezone-support`: Enables timezone support, at the cost of
increased application size
6.  `--locale-list`: Add extra locales via a list, at the cost of increased
application size. Format: comma-separated list of locale IDs like "en\_US,
ru\_RU"

### Unsupported options for the JavaScript type

These options are unsupported for `--type js`

*   `--file-associations`: Not yet meaningful for a web-based app, though
it may be in the future once PWAs support file types: [
https://github.com/WICG/file-handling](https://github.com/WICG/file-handling)
*   `--app-version, --copyright, --description, --license-file, --vendor`:
jpackage will only support --name initially. Users can customize index.html
(and the rest of the application) to show branding and metadata as desired.
*   `--java-options`: Not yet supported, use `--arguments` instead.

Caveats
-------

Certain Java classes are not feasible to implement in a browser setting.
Socket, for example, is not useful in a browser since JavaScript cannot
open arbitrary socket connections. Code using unavailable classes will fail
during packaging time with warnings about the missing classes.

Testing
-------

Since TeaVM is Java-based, tests will be able to run on any platform.

Testing will focus on the new jpackage code and added functionality. Tests
will confirm that when valid parameters are provided, that output is
generated with the right name and in the right folder. Contents of the
generated ZIP and WAR files will be checked for the presence of expected
files. Testing generated files in a browser will be done manually.

A thorough test of TeaVM itself is out of scope for the jpackage testing.
This is in line with jpackage testing for other platforms, in which the
external packaging tool (like Wix on Windows) isn't exhaustively tested.

Dependencies
------------

The jpackage `js` type will require TeaVM binaries to be present.

Implementation options:

*   Download TeaVM on-demand and cache it. (This is the likely option.)
    *   Look for TeaVM in local repositories for popular build tools like
Maven and Gradle
    *   If not found locally, download TeaVM binaries from the read-only
central repository and store in the cache folder
    *   Invoke TeaVM from the local repository or cache
*   Require that TeaVM binaries be installed locally
    *   Provide the path to TeaVM binaries on the command line
*   Bundle TeaVM
    *   Challenging due to incompatible licenses (Apache v2 vs. GPL v2 with
CPE)
    *   Probably unnecessary given the options above. Other jpackage
options require pre-installed tools, this will be no different.

High-Level Design
-----------------

A new bundler will be added to the jpackage Java source code.

It will first ensure that TeaVM binaries (JAR files) are available locally,
as described in the section above.

The new bundler will use TeaVM's TeaVMRunner ([
https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java](https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java)),
which conveniently accepts options similar to jpackage itself. TeaVMRunner
will do the heavy lifting of converting the application JAR files and
resources into `classes.js`.

The bundler will provide additional files required to make a web
application, including an `index.html` to launch the `main()` method. The
bundler will create the final archive (ZIP or WAR) using Java's
ZipOutputStream. For the WAR format, the bundler will also add `web.xml`
and `MANIFEST.MF` if not present to create a deployable, standard WAR file.

From swpalmer at gmail.com  Sun Apr 25 05:39:28 2021
From: swpalmer at gmail.com (Scott Palmer)
Date: Sun, 25 Apr 2021 01:39:28 -0400
Subject: Proposal to add JavaScript platform to jpackage
In-Reply-To: <CADCvFPacpOzwVcbwZ9Xbsx=88p=16+FfzWOZQzVdCZab=4LC_g@mail.gmail.com>
References: <CADCvFPacpOzwVcbwZ9Xbsx=88p=16+FfzWOZQzVdCZab=4LC_g@mail.gmail.com>
Message-ID: <99221D16-7066-495F-8AA8-E828F31EB831@gmail.com>

This doesn?t seem like something that should be the job of jpackage.  The jpackage tool is currently used for producing platform-specific packages or installers targeted at end-users that include native launchers and a JRE.  Web-based applications are an entirely different beast. This seems like more of a job for a Maven or Gradle plugin.

Regards,

Scott


> On Apr 24, 2021, at 5:59 PM, Andrew Oliver <93q62q at gmail.com> wrote:
> 
> Below is a Java Enhancement Proposal for your consideration to add
> JavaScript to jpackage as a new target platform.  I would appreciate
> feedback on the proposal contents.  I am also interested in learning about
> the process, specifically what approvals are required prior to start of
> implementation, should sufficient consensus be reached.
> 
> ( To view this proposal as a web page, please visit:
> https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html )
> 
> Thank you!
> 
>  -Andrew Oliver
> 
> Title: Add JavaScript platform to jpackage
> Author: Andrew Oliver
> Created: 2021/04/24
> Type: Feature
> State: Draft
> Exposure: Open
> Component: tools/jpackage
> Scope: JDK
> Discussion: core-libs-dev at openjdk.java.net
> Template: 1.0
> 
> Summary
> -------
> 
> jpackage already allows packaging Java applications for several platforms.
> This proposal adds a new platform: JavaScript.
> 
> This effort will enable jpackage to convert bytecode from the provided
> classes into JavaScript, and generate the required HTML to invoke the
> specified main method when opened in a web browser. These files will be
> bundled into a WAR file for easy deployment.
> 
> Goals
> -----
> 
> *   Enabling JVM languages to build client-side web applications
> *   Allow easy generation of JavaScript from JVM bytecode
> *   Allow easy deployment and execution of generated JavaScript in web
> browsers
> *   Allow easy deployment of the generated JavaScript in all web server
> environments
>    *   Java web application container (like Tomcat)
>    *   Static file web servers
>    *   Static file web hosting services
> 
> Non-Goals
> ---------
> 
> *   Allowing execution of JavaScript server-side. (Java already has
> numerous options for executing bytecode server-side.)
> 
> Motivation
> ----------
> 
> Java was once used to create client-side web applications via applets that
> could be launched by visiting a web page. Applets could draw on an area of
> the screen (like HTML5 Canvas) or manipulate the page DOM to create dynamic
> front-end applications (like JS single-page apps).
> 
> However, as evident in JEP 398 ([
> https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)),
> applets are no longer feasible due to the actions of browser vendors. While
> browsers have lost the ability to execute Java bytecode or invoke methods
> from the Java class libraries, they do have mature engines for executing a
> different sort of code (JavaScript) and an extensive list of useful APIs.
> By converting class files to JavaScript, and providing mechanisms to invoke
> browser APIs, Java can again be used to create in-browser applications.
> [TeaVM](https://teavm.org) has demonstrated that this is feasible and has
> numerous benefits:
> 
> *   Provides a strongly-typed language for client-side web development
> *   Provides a wealth of IDEs, build tools, and testing tools for
> client-side web development
> *   Allows teams with Java experience to produce apps with familiar
> technology
> *   Allows sharing of POJO and business logic classes, simplifying
> development
> *   Allows options for porting applet- and JNLP-based systems to
> present-day browsers
> 
> Details
> -------
> 
> An additional jpackage option for type will be added: `js`
> 
> jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
> code to JavaScript, with the main class compiled to a JavaScript method
> called 'main()'.
> 
> jpackage bundles application code, runtime, and resources into a
> platform-specific format. For this new JavaScript type, the layout will be
> either a ZIP file or a standard WAR file. The ZIP format will contain the
> files ready to be extracted to a static file webserver or HTML hosting
> service. Generated WARs will have the required structure to be deployable
> in a Java web application container.
> 
> ### WAR layout
> 
> *   HelloApp.war
>    *   index.html (Main application page, loads classes.js and invokes
> main())
>    *   teavm
>        *   classes.js (Class files, templates, and resources compiled to
> JavaScript)
>    *   css
>        *   (CSS files from application)
>    *   META-INF
>        *   MANIFEST.MF
>    *   WEB-INF
>        *   web.xml
> 
> ### ZIP Layout
> 
> *   HelloApp.zip
>    *   index.html (Main application page, loads classes.js and invokes
> main())
>    *   teavm
>        *   classes.js (Class files, templates, and resources compiled to
> JavaScript)
>    *   css
>        *   (CSS files from application)
> 
> Basic usage: Non-modular applications
> -------------------------------------
> 
> Command-line usage is similar to jpackage today, except you use the `--type
> js`. For example, if you have your application JARs in a folder called
> `lib` and the JAR with the declared `main()` method is `main.jar`, you
> could use this command:
> 
> ```
> $ jpackage --type js --name myapp --input lib --main-jar main.jar
> ```
> 
> This will produce `myapp.war` in the current directory. This is a standard
> WAR file ready for deployment in any web application container (like
> Tomcat). When myapp/index.html is opened in a browser, the code in main()
> will be executed, in-browser. A typical Hello World main() method like
> 
> ```
>    public static void main(String args\[\]) {
>        System.out.println("Hello, Browser!");
>    }
> ```
> 
> will print the message on the browser developer console.
> 
> Processing
> ----------
> 
> Conversion of the input JAR files to the classes.js file will be done by
> TeaVM. It will
> 
> *   Convert provided class files to JavaScript
> *   Expose the specified main method as main()
> *   Provide implementation of selected core Java classes that function in a
> browser environment
> *   Bundle resources into the generated JavaScript
> *   Include images, css, and web.xml in the generated package, if provided
> *   Provide default index.html if omitted
> *   Provide default web.xml if omitted and WAR format specified
> *   Optionally minify the generated JavaScript
> 
> ### js-specific options
> 
> 1.  `--minify`: Perform a minification pass after generating JavaScript,
> renaming classes and methods to short, generated names to reduce download
> sizes and provide some obfuscation.
> 2.  `--debug`: Enable generation of source maps.
> 3.  `--debug-full`: Enable generation of source maps and bundled source
> files.
> 4.  `--optimization`: Choose simple, advanced, or full.
>    *   simple: Perform only basic optimizations
>    *   advanced: Perform more optimizations. Recommended for production.
>    *   full: Perform aggressive optimizations. Increases compilation time.
> 5.  `--timezone-support`: Enables timezone support, at the cost of
> increased application size
> 6.  `--locale-list`: Add extra locales via a list, at the cost of increased
> application size. Format: comma-separated list of locale IDs like "en\_US,
> ru\_RU"
> 
> ### Unsupported options for the JavaScript type
> 
> These options are unsupported for `--type js`
> 
> *   `--file-associations`: Not yet meaningful for a web-based app, though
> it may be in the future once PWAs support file types: [
> https://github.com/WICG/file-handling](https://github.com/WICG/file-handling)
> *   `--app-version, --copyright, --description, --license-file, --vendor`:
> jpackage will only support --name initially. Users can customize index.html
> (and the rest of the application) to show branding and metadata as desired.
> *   `--java-options`: Not yet supported, use `--arguments` instead.
> 
> Caveats
> -------
> 
> Certain Java classes are not feasible to implement in a browser setting.
> Socket, for example, is not useful in a browser since JavaScript cannot
> open arbitrary socket connections. Code using unavailable classes will fail
> during packaging time with warnings about the missing classes.
> 
> Testing
> -------
> 
> Since TeaVM is Java-based, tests will be able to run on any platform.
> 
> Testing will focus on the new jpackage code and added functionality. Tests
> will confirm that when valid parameters are provided, that output is
> generated with the right name and in the right folder. Contents of the
> generated ZIP and WAR files will be checked for the presence of expected
> files. Testing generated files in a browser will be done manually.
> 
> A thorough test of TeaVM itself is out of scope for the jpackage testing.
> This is in line with jpackage testing for other platforms, in which the
> external packaging tool (like Wix on Windows) isn't exhaustively tested.
> 
> Dependencies
> ------------
> 
> The jpackage `js` type will require TeaVM binaries to be present.
> 
> Implementation options:
> 
> *   Download TeaVM on-demand and cache it. (This is the likely option.)
>    *   Look for TeaVM in local repositories for popular build tools like
> Maven and Gradle
>    *   If not found locally, download TeaVM binaries from the read-only
> central repository and store in the cache folder
>    *   Invoke TeaVM from the local repository or cache
> *   Require that TeaVM binaries be installed locally
>    *   Provide the path to TeaVM binaries on the command line
> *   Bundle TeaVM
>    *   Challenging due to incompatible licenses (Apache v2 vs. GPL v2 with
> CPE)
>    *   Probably unnecessary given the options above. Other jpackage
> options require pre-installed tools, this will be no different.
> 
> High-Level Design
> -----------------
> 
> A new bundler will be added to the jpackage Java source code.
> 
> It will first ensure that TeaVM binaries (JAR files) are available locally,
> as described in the section above.
> 
> The new bundler will use TeaVM's TeaVMRunner ([
> https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java](https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java)),
> which conveniently accepts options similar to jpackage itself. TeaVMRunner
> will do the heavy lifting of converting the application JAR files and
> resources into `classes.js`.
> 
> The bundler will provide additional files required to make a web
> application, including an `index.html` to launch the `main()` method. The
> bundler will create the final archive (ZIP or WAR) using Java's
> ZipOutputStream. For the WAR format, the bundler will also add `web.xml`
> and `MANIFEST.MF` if not present to create a deployable, standard WAR file.


From github.com+18174180+yassinhajaj at openjdk.java.net  Sun Apr 25 09:26:36 2021
From: github.com+18174180+yassinhajaj at openjdk.java.net (YassinHajaj)
Date: Sun, 25 Apr 2021 09:26:36 GMT
Subject: RFR: 8037397: RegEx pattern matching loses character class after
 intersection (&&) operator [v2]
In-Reply-To: <vs7Ko0ruXgiYCEnllsz4f-4gWrTL-8Oj5SJv9gZjSFQ=.39fdb046-bd98-4527-9256-530fe303ebdb@github.com>
References: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>
 <AUVhBclJRTbqzA0jiR0f9swp73YrA5d_jYQxp0riKEs=.925329ed-56ab-4135-9e39-60c97ccea063@github.com>
 <vs7Ko0ruXgiYCEnllsz4f-4gWrTL-8Oj5SJv9gZjSFQ=.39fdb046-bd98-4527-9256-530fe303ebdb@github.com>
Message-ID: <5GSUXcghire2wJiGmyi_BD17o2z6iE53ye-DP9IoacE=.fb7923f8-789f-46c0-b679-7721a307083c@github.com>

On Fri, 2 Apr 2021 15:44:23 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing missing space
>
> Tagging with CSR because this will impact a long-standing (buggy) behavior.

Hi @igraves ,

If you want to test all characters from `A-Z` and `0-9`, consider using `rangeClosed` instead of `range`


Stream<Character> letterChars = IntStream.range('A', 'Z').mapToObj((i) -> (char) i);
Stream<Character> digitChars = IntStream.range('0', '9').mapToObj((i) -> (char) i);

Becomes

Stream<Character> letterChars = IntStream.rangeClosed('A', 'Z').mapToObj((i) -> (char) i);
Stream<Character> digitChars = IntStream.rangeClosed('0', '9').mapToObj((i) -> (char) i);

-------------

PR: https://git.openjdk.java.net/jdk/pull/3291

From github.com+18174180+yassinhajaj at openjdk.java.net  Sun Apr 25 09:48:38 2021
From: github.com+18174180+yassinhajaj at openjdk.java.net (YassinHajaj)
Date: Sun, 25 Apr 2021 09:48:38 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <DAqlNN1EEtZq1tY493jw2XeA27e7NOL350g-3FMrfi4=.ae5327d7-8eb5-4d67-ae66-faf86c0c06b0@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
 <DAqlNN1EEtZq1tY493jw2XeA27e7NOL350g-3FMrfi4=.ae5327d7-8eb5-4d67-ae66-faf86c0c06b0@github.com>
Message-ID: <ehuOyapt83O9BHUINFbZ4jkMDVJfZhyDyEpsqnuORAE=.7e1bcbbb-fee6-422e-9e6c-53bd69102797@github.com>

On Mon, 12 Apr 2021 16:12:17 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright headers
>>  - Tidied up lambdas
>
> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 400:
> 
>> 398:     private static final String getProperty(final String propName, final String defVal) {
>> 399:         PrivilegedAction<String> pa = () -> System.getProperty(propName, defVal);
>> 400:         return AccessController.doPrivileged(pa);
> 
> Hmmm... This is not strictly equivalent but will work because java.naming is loaded by the boot loader and has the permission to read all system properties. I guess the code on the left-hand side was written at a time where JNDI was still in a stand-alone library?

@dfuch I noticed the same about the swallowed exception that returns the default value. This wouldn't cause any regression?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3416

From lancea at openjdk.java.net  Sun Apr 25 10:18:45 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 25 Apr 2021 10:18:45 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties
In-Reply-To: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
References: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
Message-ID: <x8VgrBDSGgPEpJ9JPeKtqlZuAS8GBlxkgF56XgcohhU=.301e6cb8-57fb-4108-b049-41bb4c8771b0@github.com>

On Fri, 23 Apr 2021 00:41:17 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Update module summary, add a few existing properties and features into the tables.

Good morning Joe,

The changes look good based on the discussions we have had about the change and the property documentation is more convenient to find

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3644

From github.com+471021+marschall at openjdk.java.net  Sun Apr 25 10:38:03 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sun, 25 Apr 2021 10:38:03 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v10]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <0AiUvcaOonoGy21KYfhiLIVw08_KKOavevmV-o_098U=.0f7b97fe-ab8b-4a09-82d6-52da34a02657@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos in comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/c4c859e0..bbc4274f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=08-09

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+471021+marschall at openjdk.java.net  Sun Apr 25 13:49:48 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sun, 25 Apr 2021 13:49:48 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]
In-Reply-To: <DMkAz61UUwn0jmGXGO1U_rRoOACJCisPZ9c5XFdWYXs=.76e49872-21de-4f0d-a519-39e4f32addf9@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
 <DMkAz61UUwn0jmGXGO1U_rRoOACJCisPZ9c5XFdWYXs=.76e49872-21de-4f0d-a519-39e4f32addf9@github.com>
Message-ID: <u43lLo9s7PSe_z3REiwA3G7pqJbfVaF4mhvarp2x-4M=.6bf5c7c8-6228-42da-9579-4c454cc08fe7@github.com>

On Fri, 16 Apr 2021 17:00:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge master
>>  - Fix bug in CharArrayReader and add unit test
>>  - Clean up unit tests
>>  - Revert off-heap code path
>>  - Replace c-style array declarations
>>  - Share work buffer between #skip and #read
>>  - Update copyright year
>>  - Implement review comment
>>  - Revert StreamDecoder changes
>>  - Implement CharArrayReader#read(CharBuffer)
>>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0
>
> test/jdk/java/io/CharArrayReader/ReadCharBuffer.java line 50:
> 
>> 48:     @DataProvider(name = "buffers")
>> 49:     public Object[][] createBuffers() {
>> 50:         // test both on-heap and off-heap buffers has they may use different code paths
> 
> "as they may"

Done, and the other two as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+741251+turbanoff at openjdk.java.net  Sun Apr 25 14:28:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 25 Apr 2021 14:28:42 GMT
Subject: RFR: 8265474: Dubious 'null' assignment in CompactByteArray.expand
Message-ID: <VgD5N1gsnxjI0L6HjaDWiX3Sc2FU3jBwoqw-xeSI_EI=.8b997c59-a7e9-47d7-9cfe-94c95a2b5502@github.com>

I propose to remove 'null' assignment of field CompactByteArray.values in `expand` method. In the next statement this field is overridden with another value - `tempArray`.
This code was there from initial load of OpenJDK sources. I believe it was just leftovers from development phase of this class. There is no practical reason to assign `null` to non-volatile field and then overwrite it with another value.
Also I've removed unused method `getArray`. I hope it's ok to cleanup such unused stuff in the same PR.

-------------

Commit messages:
 - 8265474: Dubious 'null' assignment in CompactByteArray.expand
 - [PATCH] Remove dubious 'null' assignment to CompactByteArray.values

Changes: https://git.openjdk.java.net/jdk/pull/1880/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1880&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265474
  Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1880.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1880/head:pull/1880

PR: https://git.openjdk.java.net/jdk/pull/1880

From peter.levart at gmail.com  Sun Apr 25 18:09:04 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 25 Apr 2021 20:09:04 +0200
Subject: ReversibleCollection proposal
In-Reply-To: <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
 <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
 <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>
 <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>
Message-ID: <85906d24-f9c8-1b6f-77c0-b8cf5ca48457@gmail.com>


On 4/23/21 8:33 AM, Stuart Marks wrote:
>> This is what I intended anyway, ie that its OK for "first" to work on
>> an unordered collection, just that addFirst() has very weak semantics
>> wrt first-ness.
>>
>> "Ensures that this collection contains the specified element(optional
>> operation). This has the same basic behaviour as add(E), but
>> implementations may choose to add the element in first position if
>> they have some kind of guarantee of ordering. An exception should not
>> be thrown unless add(E) would also have thrown the exception."
>
> What seems to be going on here is that people want to add generality 
> by promoting this set of methods from ReversibleCollection up to 
> Collection. Unfortunately, the only way to do so is to make the 
> specification so loose that the semantics are destroyed.
>
> Having these methods on Collection could lead to a situation where 
> calling addFirst and then getFirst might result in getFirst returning 
> a different element from what was passed to addFirst. This doesn't 
> make any sense for methods that have "first" in the name. 


When making this proposition, I was only thinking of how to enable new 
yet-nonexistent operations on collections that have order / are 
reversible and that the code calling these methods would already knows 
that it is dealing with ordered / reversible collections. I wasn't 
thinking about how to prevent mistakes like passing unordered collection 
to code that expects ordered / reversible collection. This can only be 
solved in two ways. The way immutability of collections is solved (throw 
exception in runtime when requesting operation that makes no sense in 
unordered collection) or by introducing new type - ReversibleCollection 
that solves this in compile time. So I take back my vote for suggestion 
to introduce methods like getFirst(), removeFirst() that would return 
arbitrary element. There's still a possibility for those methods to 
throw at runtime though. But I don't know whether this would be so 
nicely accepted as immutability was. WDYT?

Peter



From 93q62q at gmail.com  Mon Apr 26 00:10:30 2021
From: 93q62q at gmail.com (Andrew Oliver)
Date: Sun, 25 Apr 2021 17:10:30 -0700
Subject: Proposal to add JavaScript platform to jpackage
In-Reply-To: <99221D16-7066-495F-8AA8-E828F31EB831@gmail.com>
References: <CADCvFPacpOzwVcbwZ9Xbsx=88p=16+FfzWOZQzVdCZab=4LC_g@mail.gmail.com>
 <99221D16-7066-495F-8AA8-E828F31EB831@gmail.com>
Message-ID: <CADCvFPZVQhNDoSbGYhrUFyv6v8i7hArSZLdQjQezGOvv4YLqxw@mail.gmail.com>

While I agree it is a somewhat different platform than Linux, Mac, or
Windows, I do think the web is a platform worth targeting.  And when seen
through just a slightly different lens, it is more like the others than it
might first seem:

On the platform:
* It is difficult for users to run Java bytecode or JARs directly
* Bytecode needs some form of transformation to operate efficiently
* Packaging into a platform-specific format is required for easy
distribution
* Without a packager tool, developers have to surmount significant
obstacles to distribute on the platform, reducing the appeal and adoption
of Java

Yes, there are maven and gradle plugins available to allow Java to target
the JavaScript platform.  ( For example,
https://teavm.org/docs/intro/getting-started.html )

However, for many users a browser-friendly solution with a small number of
dependencies is going to be the only option.  Take, for example, new users,
students, and educational settings.  In many cases, programming assignments
are required to be posted on the web.  If the JDK could target
self-contained web applications, as per this proposal, students could
easily post their assignments for the whole class to see.  This would be
much more reasonable than asking students to learn Java and maven and POM
files (and I'm saying that as a fan of maven).

Lest people misinterpret the above as suggesting this JEP is useful only in
an educational context, many business projects these days need to be web
applications.  Users are often unwilling or unable to download and install
applications for short, quick, or one-off transactions.  Thus there is a
large market for projects that absolutely require a web presence.  This JEP
would help illustrate how Java could be used even for front-end web
development.  Yes, large-scale projects would likely use maven or gradle.
But for quick proofs-of-concept, little could make it easier to demonstrate
the ability to do front-end development in Java then easily packaging a
Java code into a ZIP and deploying on any web server (or a WAR on an
application server, if desired).

  -Andrew

On Sat, Apr 24, 2021 at 10:39 PM Scott Palmer <swpalmer at gmail.com> wrote:

> This doesn?t seem like something that should be the job of jpackage.  The
> jpackage tool is currently used for producing platform-specific packages or
> installers targeted at end-users that include native launchers and a JRE.
> Web-based applications are an entirely different beast. This seems like
> more of a job for a Maven or Gradle plugin.
>
> Regards,
>
> Scott
>
>
> > On Apr 24, 2021, at 5:59 PM, Andrew Oliver <93q62q at gmail.com> wrote:
> >
> > Below is a Java Enhancement Proposal for your consideration to add
> > JavaScript to jpackage as a new target platform.  I would appreciate
> > feedback on the proposal contents.  I am also interested in learning
> about
> > the process, specifically what approvals are required prior to start of
> > implementation, should sufficient consensus be reached.
> >
> > ( To view this proposal as a web page, please visit:
> > https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html )
> >
> > Thank you!
> >
> >  -Andrew Oliver
> >
> > Title: Add JavaScript platform to jpackage
> > Author: Andrew Oliver
> > Created: 2021/04/24
> > Type: Feature
> > State: Draft
> > Exposure: Open
> > Component: tools/jpackage
> > Scope: JDK
> > Discussion: core-libs-dev at openjdk.java.net
> > Template: 1.0
> >
> > Summary
> > -------
> >
> > jpackage already allows packaging Java applications for several
> platforms.
> > This proposal adds a new platform: JavaScript.
> >
> > This effort will enable jpackage to convert bytecode from the provided
> > classes into JavaScript, and generate the required HTML to invoke the
> > specified main method when opened in a web browser. These files will be
> > bundled into a WAR file for easy deployment.
> >
> > Goals
> > -----
> >
> > *   Enabling JVM languages to build client-side web applications
> > *   Allow easy generation of JavaScript from JVM bytecode
> > *   Allow easy deployment and execution of generated JavaScript in web
> > browsers
> > *   Allow easy deployment of the generated JavaScript in all web server
> > environments
> >    *   Java web application container (like Tomcat)
> >    *   Static file web servers
> >    *   Static file web hosting services
> >
> > Non-Goals
> > ---------
> >
> > *   Allowing execution of JavaScript server-side. (Java already has
> > numerous options for executing bytecode server-side.)
> >
> > Motivation
> > ----------
> >
> > Java was once used to create client-side web applications via applets
> that
> > could be launched by visiting a web page. Applets could draw on an area
> of
> > the screen (like HTML5 Canvas) or manipulate the page DOM to create
> dynamic
> > front-end applications (like JS single-page apps).
> >
> > However, as evident in JEP 398 ([
> > https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)),
> > applets are no longer feasible due to the actions of browser vendors.
> While
> > browsers have lost the ability to execute Java bytecode or invoke methods
> > from the Java class libraries, they do have mature engines for executing
> a
> > different sort of code (JavaScript) and an extensive list of useful APIs.
> > By converting class files to JavaScript, and providing mechanisms to
> invoke
> > browser APIs, Java can again be used to create in-browser applications.
> > [TeaVM](https://teavm.org) has demonstrated that this is feasible and
> has
> > numerous benefits:
> >
> > *   Provides a strongly-typed language for client-side web development
> > *   Provides a wealth of IDEs, build tools, and testing tools for
> > client-side web development
> > *   Allows teams with Java experience to produce apps with familiar
> > technology
> > *   Allows sharing of POJO and business logic classes, simplifying
> > development
> > *   Allows options for porting applet- and JNLP-based systems to
> > present-day browsers
> >
> > Details
> > -------
> >
> > An additional jpackage option for type will be added: `js`
> >
> > jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
> > code to JavaScript, with the main class compiled to a JavaScript method
> > called 'main()'.
> >
> > jpackage bundles application code, runtime, and resources into a
> > platform-specific format. For this new JavaScript type, the layout will
> be
> > either a ZIP file or a standard WAR file. The ZIP format will contain the
> > files ready to be extracted to a static file webserver or HTML hosting
> > service. Generated WARs will have the required structure to be deployable
> > in a Java web application container.
> >
> > ### WAR layout
> >
> > *   HelloApp.war
> >    *   index.html (Main application page, loads classes.js and invokes
> > main())
> >    *   teavm
> >        *   classes.js (Class files, templates, and resources compiled to
> > JavaScript)
> >    *   css
> >        *   (CSS files from application)
> >    *   META-INF
> >        *   MANIFEST.MF
> >    *   WEB-INF
> >        *   web.xml
> >
> > ### ZIP Layout
> >
> > *   HelloApp.zip
> >    *   index.html (Main application page, loads classes.js and invokes
> > main())
> >    *   teavm
> >        *   classes.js (Class files, templates, and resources compiled to
> > JavaScript)
> >    *   css
> >        *   (CSS files from application)
> >
> > Basic usage: Non-modular applications
> > -------------------------------------
> >
> > Command-line usage is similar to jpackage today, except you use the
> `--type
> > js`. For example, if you have your application JARs in a folder called
> > `lib` and the JAR with the declared `main()` method is `main.jar`, you
> > could use this command:
> >
> > ```
> > $ jpackage --type js --name myapp --input lib --main-jar main.jar
> > ```
> >
> > This will produce `myapp.war` in the current directory. This is a
> standard
> > WAR file ready for deployment in any web application container (like
> > Tomcat). When myapp/index.html is opened in a browser, the code in main()
> > will be executed, in-browser. A typical Hello World main() method like
> >
> > ```
> >    public static void main(String args\[\]) {
> >        System.out.println("Hello, Browser!");
> >    }
> > ```
> >
> > will print the message on the browser developer console.
> >
> > Processing
> > ----------
> >
> > Conversion of the input JAR files to the classes.js file will be done by
> > TeaVM. It will
> >
> > *   Convert provided class files to JavaScript
> > *   Expose the specified main method as main()
> > *   Provide implementation of selected core Java classes that function
> in a
> > browser environment
> > *   Bundle resources into the generated JavaScript
> > *   Include images, css, and web.xml in the generated package, if
> provided
> > *   Provide default index.html if omitted
> > *   Provide default web.xml if omitted and WAR format specified
> > *   Optionally minify the generated JavaScript
> >
> > ### js-specific options
> >
> > 1.  `--minify`: Perform a minification pass after generating JavaScript,
> > renaming classes and methods to short, generated names to reduce download
> > sizes and provide some obfuscation.
> > 2.  `--debug`: Enable generation of source maps.
> > 3.  `--debug-full`: Enable generation of source maps and bundled source
> > files.
> > 4.  `--optimization`: Choose simple, advanced, or full.
> >    *   simple: Perform only basic optimizations
> >    *   advanced: Perform more optimizations. Recommended for production.
> >    *   full: Perform aggressive optimizations. Increases compilation
> time.
> > 5.  `--timezone-support`: Enables timezone support, at the cost of
> > increased application size
> > 6.  `--locale-list`: Add extra locales via a list, at the cost of
> increased
> > application size. Format: comma-separated list of locale IDs like
> "en\_US,
> > ru\_RU"
> >
> > ### Unsupported options for the JavaScript type
> >
> > These options are unsupported for `--type js`
> >
> > *   `--file-associations`: Not yet meaningful for a web-based app, though
> > it may be in the future once PWAs support file types: [
> >
> https://github.com/WICG/file-handling](https://github.com/WICG/file-handling)
> > *   `--app-version, --copyright, --description, --license-file,
> --vendor`:
> > jpackage will only support --name initially. Users can customize
> index.html
> > (and the rest of the application) to show branding and metadata as
> desired.
> > *   `--java-options`: Not yet supported, use `--arguments` instead.
> >
> > Caveats
> > -------
> >
> > Certain Java classes are not feasible to implement in a browser setting.
> > Socket, for example, is not useful in a browser since JavaScript cannot
> > open arbitrary socket connections. Code using unavailable classes will
> fail
> > during packaging time with warnings about the missing classes.
> >
> > Testing
> > -------
> >
> > Since TeaVM is Java-based, tests will be able to run on any platform.
> >
> > Testing will focus on the new jpackage code and added functionality.
> Tests
> > will confirm that when valid parameters are provided, that output is
> > generated with the right name and in the right folder. Contents of the
> > generated ZIP and WAR files will be checked for the presence of expected
> > files. Testing generated files in a browser will be done manually.
> >
> > A thorough test of TeaVM itself is out of scope for the jpackage testing.
> > This is in line with jpackage testing for other platforms, in which the
> > external packaging tool (like Wix on Windows) isn't exhaustively tested.
> >
> > Dependencies
> > ------------
> >
> > The jpackage `js` type will require TeaVM binaries to be present.
> >
> > Implementation options:
> >
> > *   Download TeaVM on-demand and cache it. (This is the likely option.)
> >    *   Look for TeaVM in local repositories for popular build tools like
> > Maven and Gradle
> >    *   If not found locally, download TeaVM binaries from the read-only
> > central repository and store in the cache folder
> >    *   Invoke TeaVM from the local repository or cache
> > *   Require that TeaVM binaries be installed locally
> >    *   Provide the path to TeaVM binaries on the command line
> > *   Bundle TeaVM
> >    *   Challenging due to incompatible licenses (Apache v2 vs. GPL v2
> with
> > CPE)
> >    *   Probably unnecessary given the options above. Other jpackage
> > options require pre-installed tools, this will be no different.
> >
> > High-Level Design
> > -----------------
> >
> > A new bundler will be added to the jpackage Java source code.
> >
> > It will first ensure that TeaVM binaries (JAR files) are available
> locally,
> > as described in the section above.
> >
> > The new bundler will use TeaVM's TeaVMRunner ([
> >
> https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java](https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java)
> ),
> > which conveniently accepts options similar to jpackage itself.
> TeaVMRunner
> > will do the heavy lifting of converting the application JAR files and
> > resources into `classes.js`.
> >
> > The bundler will provide additional files required to make a web
> > application, including an `index.html` to launch the `main()` method. The
> > bundler will create the final archive (ZIP or WAR) using Java's
> > ZipOutputStream. For the WAR format, the bundler will also add `web.xml`
> > and `MANIFEST.MF` if not present to create a deployable, standard WAR
> file.
>
>

From mli at openjdk.java.net  Mon Apr 26 01:23:46 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 26 Apr 2021 01:23:46 GMT
Subject: RFR: JDK-8265496: improve null check in
 DeflaterOutputStream/InflaterInputStream
Message-ID: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>

code like below will create Deflater before null check, although it's not a real mem leak, but it's better to do null check before new Deflater.

        try {
            DeflaterOutputStream dos = new DeflaterOutputStream(null);
        } catch (NullPointerException e) {
            passed = true;
        }
Similar issues exist in several other classes.

-------------

Commit messages:
 - JDK-8265496: improve null check in DeflaterOutputStream/InflaterInputStream

Changes: https://git.openjdk.java.net/jdk/pull/3681/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3681&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265496
  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3681.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3681/head:pull/3681

PR: https://git.openjdk.java.net/jdk/pull/3681

From mli at openjdk.java.net  Mon Apr 26 02:36:54 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 26 Apr 2021 02:36:54 GMT
Subject: RFR: JDK-8265496: improve null check in
 DeflaterOutputStream/InflaterInputStream [v2]
In-Reply-To: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>
References: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>
Message-ID: <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>

> code like below will create Deflater before null check, although it's not a real mem leak, but it's better to do null check before new Deflater.
> 
>         try {
>             DeflaterOutputStream dos = new DeflaterOutputStream(null);
>         } catch (NullPointerException e) {
>             passed = true;
>         }
> Similar issues exist in several other classes.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  update copyrights.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3681/files
  - new: https://git.openjdk.java.net/jdk/pull/3681/files/25a88c61..38c45b62

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3681&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3681&range=00-01

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3681.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3681/head:pull/3681

PR: https://git.openjdk.java.net/jdk/pull/3681

From vtewari at openjdk.java.net  Mon Apr 26 05:30:27 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Mon, 26 Apr 2021 05:30:27 GMT
Subject: RFR: JDK-8265496: improve null check in
 DeflaterOutputStream/InflaterInputStream [v2]
In-Reply-To: <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>
References: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>
 <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>
Message-ID: <PA4b8LT0TwMty9T-8lrV2KBH8D_PUvcd6Msv0gcHctA=.ec93e50f-b1fb-4a67-beec-ee59126debd2@github.com>

On Mon, 26 Apr 2021 02:36:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> code like below will create Deflater before null check, although it's not a real mem leak, but it's better to do null check before new Deflater.
>> 
>>         try {
>>             DeflaterOutputStream dos = new DeflaterOutputStream(null);
>>         } catch (NullPointerException e) {
>>             passed = true;
>>         }
>> Similar issues exist in several other classes.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights.

Changes looks OK to me, did you change  "DataOutputStreamTest.java" as well. I can see only copyright changes ?.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3681

From yyang at openjdk.java.net  Mon Apr 26 06:33:31 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Apr 2021 06:33:31 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
Message-ID: <rD3RCyB8LBa04-MgpqOqPi3HmVH2nDbDhoGJHVzdbug=.d86c723c-6fa2-4b2d-adf8-5bfe45a5e67c@github.com>

On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove java_nio_Buffer in javaClasses.hpp

Can I have a review of this PR? Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From github.com+782446+simon04 at openjdk.java.net  Mon Apr 26 07:27:37 2021
From: github.com+782446+simon04 at openjdk.java.net (Simon Legner)
Date: Mon, 26 Apr 2021 07:27:37 GMT
Subject: Integrated: 8264031: (zipfs) Typo in ZipFileSystem.deleteFile
 ZipException
In-Reply-To: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>
References: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>
Message-ID: <_a9xdZNG8ymj_gTaKocQDPfxfMb20cpbXJnkyOPVpqA=.0563fba7-c7fe-48f9-895b-e7f699c29f59@github.com>

On Tue, 16 Feb 2021 13:48:20 GMT, Simon Legner <github.com+782446+simon04 at openjdk.org> wrote:

> 8264031: (zipfs) Typo in ZipFileSystem.deleteFile ZipException

This pull request has now been integrated.

Changeset: 7b609a20
Author:    Simon Legner <Simon.Legner at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b609a20
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8264031: (zipfs) Typo in ZipFileSystem.deleteFile ZipException

Reviewed-by: shade, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/2588

From github.com+10835776+stsypanov at openjdk.java.net  Mon Apr 26 08:00:40 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 26 Apr 2021 08:00:40 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <CNby1eR4i4aQoSuqcr5tgnePbh1jXUXDF28PdrPZQM8=.0b9404aa-276c-435b-a8e7-3a6fda21b2d8@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
 <CNby1eR4i4aQoSuqcr5tgnePbh1jXUXDF28PdrPZQM8=.0b9404aa-276c-435b-a8e7-3a6fda21b2d8@github.com>
Message-ID: <0WxB-NH33GzJXA0TYpM-G-bVDdeLWqmFFKLi_R8-54o=.6968a96f-c349-4988-96a4-d982458ebe8e@github.com>

On Mon, 19 Apr 2021 14:45:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null.
>
> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 458:
> 
>> 456:         private static boolean isSamePackage(Class<?> class1, Class<?> class2) {
>> 457:             return class1.getClassLoader() == class2.getClassLoader()
>> 458:                    && class1.getPackageName().equals(class2.getPackageName());
> 
> If the j.u.c.atomic code is changed then it will need to be coordinated with Doug Lea's repo. The rest of the changes are good and thanks for following up from the comments in the other issue.

@AlanBateman if DL is not responding, will it be ok to just revert the changes related to `java.util.concurrent`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3571

From pconcannon at openjdk.java.net  Mon Apr 26 08:35:48 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 26 Apr 2021 08:35:48 GMT
Subject: RFR: 8265746: Update java.time to use instanceof pattern variable
 (part II) [v2]
In-Reply-To: <frmXbSglJBsqm0AYpbnD7U64zNbqwlTMHNT09HmGDUk=.7f1d7910-e335-45e4-af24-d58efdb7ea4d@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <frmXbSglJBsqm0AYpbnD7U64zNbqwlTMHNT09HmGDUk=.7f1d7910-e335-45e4-af24-d58efdb7ea4d@github.com>
Message-ID: <9Y31mmaYRt36MOa1iNUHDVRJBt3_g5i5t8EHipt1i08=.de3e1ffe-7f86-4864-97a8-04a68df51d1f@github.com>

On Fri, 23 Apr 2021 14:29:36 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Patrick Concannon 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:
>> 
>>  - Removed redundant braces
>>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>>  - 8265746: Update java.time to use instanceof pattern variable (part II)
>
> src/java.base/share/classes/java/time/Clock.java line 623:
> 
>> 621:             return (obj instanceof FixedClock other
>> 622:                     && instant.equals(other.instant)
>> 623:                     && zone.equals(other.zone));
> 
> The outer set of braces is redundant.

Braces removed in 7f32ddb

> src/java.base/share/classes/java/time/ZonedDateTime.java line 2191:
> 
>> 2189:             && dateTime.equals(other.dateTime)
>> 2190:             && offset.equals(other.offset)
>> 2191:             && zone.equals(other.zone));
> 
> same here.

See 7f32ddb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3650

From pconcannon at openjdk.java.net  Mon Apr 26 08:35:49 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 26 Apr 2021 08:35:49 GMT
Subject: Integrated: 8265746: Update java.time to use instanceof pattern
 variable (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <VV9tn4c66YNe6s2NhKlUrXP2pbc2YPhe7dUh5Zpv_Bw=.2802dddd-91c1-4adb-bfd3-8a7a68417b10@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

This pull request has now been integrated.

Changeset: 45c5da0f
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45c5da0f
Stats:     152 lines in 20 files changed: 0 ins; 48 del; 104 mod

8265746: Update java.time to use instanceof pattern variable (part II)

Reviewed-by: dfuchs, lancea, rriggs, chegar, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/3650

From alanb at openjdk.java.net  Mon Apr 26 08:48:35 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 26 Apr 2021 08:48:35 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <0WxB-NH33GzJXA0TYpM-G-bVDdeLWqmFFKLi_R8-54o=.6968a96f-c349-4988-96a4-d982458ebe8e@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
 <CNby1eR4i4aQoSuqcr5tgnePbh1jXUXDF28PdrPZQM8=.0b9404aa-276c-435b-a8e7-3a6fda21b2d8@github.com>
 <0WxB-NH33GzJXA0TYpM-G-bVDdeLWqmFFKLi_R8-54o=.6968a96f-c349-4988-96a4-d982458ebe8e@github.com>
Message-ID: <e2WZv9pyj7oHGKgGu0uSc7svXGzy-kujLvgrTn-Skf8=.1656129f-ac88-4c98-b6cf-629292253f7f@github.com>

On Mon, 26 Apr 2021 07:57:21 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 458:
>> 
>>> 456:         private static boolean isSamePackage(Class<?> class1, Class<?> class2) {
>>> 457:             return class1.getClassLoader() == class2.getClassLoader()
>>> 458:                    && class1.getPackageName().equals(class2.getPackageName());
>> 
>> If the j.u.c.atomic code is changed then it will need to be coordinated with Doug Lea's repo. The rest of the changes are good and thanks for following up from the comments in the other issue.
>
> @AlanBateman if DL is not responding, will it be ok to just revert the changes related to `java.util.concurrent`?

That should be fine, the null check in Objects.equals is benign with these usages.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3571

From fguallini at openjdk.java.net  Mon Apr 26 09:39:40 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Mon, 26 Apr 2021 09:39:40 GMT
Subject: RFR: 8183374: Refactor java/lang/Runtime shell tests to java
In-Reply-To: <8RGdfm-WomCVRb2rHh4JJylflepR5_FC0zsMvMznlDc=.7cf373c7-9ecc-48b7-9ae8-033fc39d2527@github.com>
References: <8RGdfm-WomCVRb2rHh4JJylflepR5_FC0zsMvMznlDc=.7cf373c7-9ecc-48b7-9ae8-033fc39d2527@github.com>
Message-ID: <ErnMQXetvbViEDzXJMVUxbem1bNpQ7nGVQkXI-qHAOg=.214dc973-76fb-42e0-9dc7-ef92b7c4a768@github.com>

On Mon, 19 Apr 2021 15:07:16 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Refactor the following shell tests to java:
> test/jdk/java/lang/RuntimeTests/shutdown/ShutdownHooks.sh
> test/jdk/java/lang/Runtime/exec/SetCwd.java
> 
> In addition, the test SetCwd was running itself in separate java subprocesses in order to exercise Runtime.exec. It was creating a folder structure with multiple test class copies to distinguish between main and child processes to prevent an infinite recursion. That logic is simplified now, tests follow the testng annotations flow whereas the subprocesses entry point is a nested class main

Please, have a look at this PR, it would also need sponsoring, thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/3572

From prappo at openjdk.java.net  Mon Apr 26 09:39:55 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 26 Apr 2021 09:39:55 GMT
Subject: RFR: 8265961: Fix comments in logging.properties
Message-ID: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>

I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/3688/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3688&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265961
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3688/head:pull/3688

PR: https://git.openjdk.java.net/jdk/pull/3688

From github.com+10835776+stsypanov at openjdk.java.net  Mon Apr 26 11:27:31 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 26 Apr 2021 11:27:31 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <e2WZv9pyj7oHGKgGu0uSc7svXGzy-kujLvgrTn-Skf8=.1656129f-ac88-4c98-b6cf-629292253f7f@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
 <CNby1eR4i4aQoSuqcr5tgnePbh1jXUXDF28PdrPZQM8=.0b9404aa-276c-435b-a8e7-3a6fda21b2d8@github.com>
 <0WxB-NH33GzJXA0TYpM-G-bVDdeLWqmFFKLi_R8-54o=.6968a96f-c349-4988-96a4-d982458ebe8e@github.com>
 <e2WZv9pyj7oHGKgGu0uSc7svXGzy-kujLvgrTn-Skf8=.1656129f-ac88-4c98-b6cf-629292253f7f@github.com>
Message-ID: <BgujLBzc3hYCcHM7HCG7GR7zq1tnZ1suRA3kvb3Uvvk=.f780f0d8-6da9-4c7b-a205-3dcac30f01d9@github.com>

On Mon, 26 Apr 2021 08:45:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman if DL is not responding, will it be ok to just revert the changes related to `java.util.concurrent`?
>
> That should be fine, the null check in Objects.equals is benign with these usages.

One more thing I'm thinking about (not to be done in this PR of course) is to move call to `String.intern()` from where it is now in `Class.getPackageName()`

public String getPackageName() {
    String pn = this.packageName;
    if (pn == null) {
        Class<?> c = this;
        while (c.isArray()) {
            c = c.getComponentType();
        }
        if (c.isPrimitive()) {
            pn = "java.lang";
        } else {
            String cn = c.getName();
            int dot = cn.lastIndexOf('.');
            pn = (dot != -1) ? cn.substring(0, dot).intern() : "";    // <---
        }
        this.packageName = pn;
    }
    return pn;
}

to `packageName` field assignement like

this.packageName = pn.intern();

this would add two more Strings (`""` and `"java.lang"`) into string table and allow to avoid `String.equals()` in favour of `==` call when comparing package names. What do you think?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3571

From lzang at openjdk.java.net  Mon Apr 26 11:40:29 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 26 Apr 2021 11:40:29 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v4]
In-Reply-To: <3NgvnAImIrOF6eaXJSim4TCHPruhp6yD2tVqBm-RMHM=.1bc66bec-53fb-4840-b0ef-c03a7cc111d1@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
 <z-VtWLNFeho201QW1vLymWa3vB-TSkwMElKw_seESeM=.c5d67dac-2543-4bd4-b5d3-dfc15e56d4fa@github.com>
 <BIAT8d0uhmiDK4YwqSHGZSgTh1Ach6qQvgEbark9kdE=.5f053c10-7e37-4a0f-9a37-8a92b7bd5585@github.com>
 <3NgvnAImIrOF6eaXJSim4TCHPruhp6yD2tVqBm-RMHM=.1bc66bec-53fb-4840-b0ef-c03a7cc111d1@github.com>
Message-ID: <FjhT3nQg6Vb9Hb8pxNAkwPgYw85k8IQcMmORwLOicEM=.241c2836-cdb2-4e22-9d11-6455c6c8947d@github.com>

On Thu, 8 Apr 2021 08:54:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Dear All,
>> May I ask your help to review this change? Thanks!
>> 
>> BRs,
>> Lin
>
>> Dear All,
>> May I ask your help to review this change? Thanks!
> 
> @LanceAndersen Do you have cycles to help Lin? This proposal will require discussion, they may be case for the header to be a record for example. My personal view is that the PR should be set aside until there is at least at least some agreement on the API.

Dear @AlanBateman @LanceAndersen,
    May I ask your help to review whether the usage of Record and Builder pattern is reasonable in the PR? Thanks

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From dfuchs at openjdk.java.net  Mon Apr 26 12:01:32 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 26 Apr 2021 12:01:32 GMT
Subject: RFR: 8048199: Replace anonymous inner classes with lambdas,
 where applicable, in JNDI [v2]
In-Reply-To: <ehuOyapt83O9BHUINFbZ4jkMDVJfZhyDyEpsqnuORAE=.7e1bcbbb-fee6-422e-9e6c-53bd69102797@github.com>
References: <t1iv3m8snnXhgANK6VR_cunmlQLKiTbAELpx9udtq54=.549db64d-17df-453d-b9fd-040277b8ac90@github.com>
 <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com>
 <DAqlNN1EEtZq1tY493jw2XeA27e7NOL350g-3FMrfi4=.ae5327d7-8eb5-4d67-ae66-faf86c0c06b0@github.com>
 <ehuOyapt83O9BHUINFbZ4jkMDVJfZhyDyEpsqnuORAE=.7e1bcbbb-fee6-422e-9e6c-53bd69102797@github.com>
Message-ID: <fPZgda3NqczUn9PBA7SOnWDORx_mhbx0dqpNJBLxXFQ=.e3599cf9-7858-422a-9dca-edeaea4209cb@github.com>

On Sun, 25 Apr 2021 09:45:15 GMT, YassinHajaj <github.com+18174180+YassinHajaj at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 400:
>> 
>>> 398:     private static final String getProperty(final String propName, final String defVal) {
>>> 399:         PrivilegedAction<String> pa = () -> System.getProperty(propName, defVal);
>>> 400:         return AccessController.doPrivileged(pa);
>> 
>> Hmmm... This is not strictly equivalent but will work because java.naming is loaded by the boot loader and has the permission to read all system properties. I guess the code on the left-hand side was written at a time where JNDI was still in a stand-alone library?
>
> @dfuch I noticed the same about the swallowed exception that returns the default value. This wouldn't cause any regression?

As I noted - the SecurityException should never occur so I don't expect this could cause a regression.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3416

From kevin.rushforth at oracle.com  Mon Apr 26 12:38:54 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 26 Apr 2021 05:38:54 -0700
Subject: Proposal to add JavaScript platform to jpackage
In-Reply-To: <CADCvFPZVQhNDoSbGYhrUFyv6v8i7hArSZLdQjQezGOvv4YLqxw@mail.gmail.com>
References: <CADCvFPacpOzwVcbwZ9Xbsx=88p=16+FfzWOZQzVdCZab=4LC_g@mail.gmail.com>
 <99221D16-7066-495F-8AA8-E828F31EB831@gmail.com>
 <CADCvFPZVQhNDoSbGYhrUFyv6v8i7hArSZLdQjQezGOvv4YLqxw@mail.gmail.com>
Message-ID: <03adccfa-0253-ff1a-0620-9d5e3e925b96@oracle.com>

Without commenting on the value proposition of what you propose to do, I 
am fairly certain that jpackage is not the way to do it. The job of 
jpackage is to take an application, bundle it with a Java Runtime, and 
create a native package / installer from it. What you are describing 
goes far beyond that. You are describing a new capability of the JDK 
that would take Java bytecode and compile it to run it on top of a 
JavaScript engine.

> jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
> code to JavaScript, with the main class compiled to a JavaScript method
> called 'main()'.

This is a good indicator that your proposal isn't simply targeting a new 
platform that already exists, and for which there is a Java runtime that 
supports running on this platform.

-- Kevin


On 4/25/2021 5:10 PM, Andrew Oliver wrote:
> While I agree it is a somewhat different platform than Linux, Mac, or
> Windows, I do think the web is a platform worth targeting.  And when seen
> through just a slightly different lens, it is more like the others than it
> might first seem:
>
> On the platform:
> * It is difficult for users to run Java bytecode or JARs directly
> * Bytecode needs some form of transformation to operate efficiently
> * Packaging into a platform-specific format is required for easy
> distribution
> * Without a packager tool, developers have to surmount significant
> obstacles to distribute on the platform, reducing the appeal and adoption
> of Java
>
> Yes, there are maven and gradle plugins available to allow Java to target
> the JavaScript platform.  ( For example,
> https://teavm.org/docs/intro/getting-started.html )
>
> However, for many users a browser-friendly solution with a small number of
> dependencies is going to be the only option.  Take, for example, new users,
> students, and educational settings.  In many cases, programming assignments
> are required to be posted on the web.  If the JDK could target
> self-contained web applications, as per this proposal, students could
> easily post their assignments for the whole class to see.  This would be
> much more reasonable than asking students to learn Java and maven and POM
> files (and I'm saying that as a fan of maven).
>
> Lest people misinterpret the above as suggesting this JEP is useful only in
> an educational context, many business projects these days need to be web
> applications.  Users are often unwilling or unable to download and install
> applications for short, quick, or one-off transactions.  Thus there is a
> large market for projects that absolutely require a web presence.  This JEP
> would help illustrate how Java could be used even for front-end web
> development.  Yes, large-scale projects would likely use maven or gradle.
> But for quick proofs-of-concept, little could make it easier to demonstrate
> the ability to do front-end development in Java then easily packaging a
> Java code into a ZIP and deploying on any web server (or a WAR on an
> application server, if desired).
>
>    -Andrew
>
> On Sat, Apr 24, 2021 at 10:39 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
>> This doesn?t seem like something that should be the job of jpackage.  The
>> jpackage tool is currently used for producing platform-specific packages or
>> installers targeted at end-users that include native launchers and a JRE.
>> Web-based applications are an entirely different beast. This seems like
>> more of a job for a Maven or Gradle plugin.
>>
>> Regards,
>>
>> Scott
>>
>>
>>> On Apr 24, 2021, at 5:59 PM, Andrew Oliver <93q62q at gmail.com> wrote:
>>>
>>> Below is a Java Enhancement Proposal for your consideration to add
>>> JavaScript to jpackage as a new target platform.  I would appreciate
>>> feedback on the proposal contents.  I am also interested in learning
>> about
>>> the process, specifically what approvals are required prior to start of
>>> implementation, should sufficient consensus be reached.
>>>
>>> ( To view this proposal as a web page, please visit:
>>> https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html )
>>>
>>> Thank you!
>>>
>>>   -Andrew Oliver
>>>
>>> Title: Add JavaScript platform to jpackage
>>> Author: Andrew Oliver
>>> Created: 2021/04/24
>>> Type: Feature
>>> State: Draft
>>> Exposure: Open
>>> Component: tools/jpackage
>>> Scope: JDK
>>> Discussion: core-libs-dev at openjdk.java.net
>>> Template: 1.0
>>>
>>> Summary
>>> -------
>>>
>>> jpackage already allows packaging Java applications for several
>> platforms.
>>> This proposal adds a new platform: JavaScript.
>>>
>>> This effort will enable jpackage to convert bytecode from the provided
>>> classes into JavaScript, and generate the required HTML to invoke the
>>> specified main method when opened in a web browser. These files will be
>>> bundled into a WAR file for easy deployment.
>>>
>>> Goals
>>> -----
>>>
>>> *   Enabling JVM languages to build client-side web applications
>>> *   Allow easy generation of JavaScript from JVM bytecode
>>> *   Allow easy deployment and execution of generated JavaScript in web
>>> browsers
>>> *   Allow easy deployment of the generated JavaScript in all web server
>>> environments
>>>     *   Java web application container (like Tomcat)
>>>     *   Static file web servers
>>>     *   Static file web hosting services
>>>
>>> Non-Goals
>>> ---------
>>>
>>> *   Allowing execution of JavaScript server-side. (Java already has
>>> numerous options for executing bytecode server-side.)
>>>
>>> Motivation
>>> ----------
>>>
>>> Java was once used to create client-side web applications via applets
>> that
>>> could be launched by visiting a web page. Applets could draw on an area
>> of
>>> the screen (like HTML5 Canvas) or manipulate the page DOM to create
>> dynamic
>>> front-end applications (like JS single-page apps).
>>>
>>> However, as evident in JEP 398 ([
>>> https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)),
>>> applets are no longer feasible due to the actions of browser vendors.
>> While
>>> browsers have lost the ability to execute Java bytecode or invoke methods
>>> from the Java class libraries, they do have mature engines for executing
>> a
>>> different sort of code (JavaScript) and an extensive list of useful APIs.
>>> By converting class files to JavaScript, and providing mechanisms to
>> invoke
>>> browser APIs, Java can again be used to create in-browser applications.
>>> [TeaVM](https://teavm.org) has demonstrated that this is feasible and
>> has
>>> numerous benefits:
>>>
>>> *   Provides a strongly-typed language for client-side web development
>>> *   Provides a wealth of IDEs, build tools, and testing tools for
>>> client-side web development
>>> *   Allows teams with Java experience to produce apps with familiar
>>> technology
>>> *   Allows sharing of POJO and business logic classes, simplifying
>>> development
>>> *   Allows options for porting applet- and JNLP-based systems to
>>> present-day browsers
>>>
>>> Details
>>> -------
>>>
>>> An additional jpackage option for type will be added: `js`
>>>
>>> jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
>>> code to JavaScript, with the main class compiled to a JavaScript method
>>> called 'main()'.
>>>
>>> jpackage bundles application code, runtime, and resources into a
>>> platform-specific format. For this new JavaScript type, the layout will
>> be
>>> either a ZIP file or a standard WAR file. The ZIP format will contain the
>>> files ready to be extracted to a static file webserver or HTML hosting
>>> service. Generated WARs will have the required structure to be deployable
>>> in a Java web application container.
>>>
>>> ### WAR layout
>>>
>>> *   HelloApp.war
>>>     *   index.html (Main application page, loads classes.js and invokes
>>> main())
>>>     *   teavm
>>>         *   classes.js (Class files, templates, and resources compiled to
>>> JavaScript)
>>>     *   css
>>>         *   (CSS files from application)
>>>     *   META-INF
>>>         *   MANIFEST.MF
>>>     *   WEB-INF
>>>         *   web.xml
>>>
>>> ### ZIP Layout
>>>
>>> *   HelloApp.zip
>>>     *   index.html (Main application page, loads classes.js and invokes
>>> main())
>>>     *   teavm
>>>         *   classes.js (Class files, templates, and resources compiled to
>>> JavaScript)
>>>     *   css
>>>         *   (CSS files from application)
>>>
>>> Basic usage: Non-modular applications
>>> -------------------------------------
>>>
>>> Command-line usage is similar to jpackage today, except you use the
>> `--type
>>> js`. For example, if you have your application JARs in a folder called
>>> `lib` and the JAR with the declared `main()` method is `main.jar`, you
>>> could use this command:
>>>
>>> ```
>>> $ jpackage --type js --name myapp --input lib --main-jar main.jar
>>> ```
>>>
>>> This will produce `myapp.war` in the current directory. This is a
>> standard
>>> WAR file ready for deployment in any web application container (like
>>> Tomcat). When myapp/index.html is opened in a browser, the code in main()
>>> will be executed, in-browser. A typical Hello World main() method like
>>>
>>> ```
>>>     public static void main(String args\[\]) {
>>>         System.out.println("Hello, Browser!");
>>>     }
>>> ```
>>>
>>> will print the message on the browser developer console.
>>>
>>> Processing
>>> ----------
>>>
>>> Conversion of the input JAR files to the classes.js file will be done by
>>> TeaVM. It will
>>>
>>> *   Convert provided class files to JavaScript
>>> *   Expose the specified main method as main()
>>> *   Provide implementation of selected core Java classes that function
>> in a
>>> browser environment
>>> *   Bundle resources into the generated JavaScript
>>> *   Include images, css, and web.xml in the generated package, if
>> provided
>>> *   Provide default index.html if omitted
>>> *   Provide default web.xml if omitted and WAR format specified
>>> *   Optionally minify the generated JavaScript
>>>
>>> ### js-specific options
>>>
>>> 1.  `--minify`: Perform a minification pass after generating JavaScript,
>>> renaming classes and methods to short, generated names to reduce download
>>> sizes and provide some obfuscation.
>>> 2.  `--debug`: Enable generation of source maps.
>>> 3.  `--debug-full`: Enable generation of source maps and bundled source
>>> files.
>>> 4.  `--optimization`: Choose simple, advanced, or full.
>>>     *   simple: Perform only basic optimizations
>>>     *   advanced: Perform more optimizations. Recommended for production.
>>>     *   full: Perform aggressive optimizations. Increases compilation
>> time.
>>> 5.  `--timezone-support`: Enables timezone support, at the cost of
>>> increased application size
>>> 6.  `--locale-list`: Add extra locales via a list, at the cost of
>> increased
>>> application size. Format: comma-separated list of locale IDs like
>> "en\_US,
>>> ru\_RU"
>>>
>>> ### Unsupported options for the JavaScript type
>>>
>>> These options are unsupported for `--type js`
>>>
>>> *   `--file-associations`: Not yet meaningful for a web-based app, though
>>> it may be in the future once PWAs support file types: [
>>>
>> https://github.com/WICG/file-handling](https://github.com/WICG/file-handling)
>>> *   `--app-version, --copyright, --description, --license-file,
>> --vendor`:
>>> jpackage will only support --name initially. Users can customize
>> index.html
>>> (and the rest of the application) to show branding and metadata as
>> desired.
>>> *   `--java-options`: Not yet supported, use `--arguments` instead.
>>>
>>> Caveats
>>> -------
>>>
>>> Certain Java classes are not feasible to implement in a browser setting.
>>> Socket, for example, is not useful in a browser since JavaScript cannot
>>> open arbitrary socket connections. Code using unavailable classes will
>> fail
>>> during packaging time with warnings about the missing classes.
>>>
>>> Testing
>>> -------
>>>
>>> Since TeaVM is Java-based, tests will be able to run on any platform.
>>>
>>> Testing will focus on the new jpackage code and added functionality.
>> Tests
>>> will confirm that when valid parameters are provided, that output is
>>> generated with the right name and in the right folder. Contents of the
>>> generated ZIP and WAR files will be checked for the presence of expected
>>> files. Testing generated files in a browser will be done manually.
>>>
>>> A thorough test of TeaVM itself is out of scope for the jpackage testing.
>>> This is in line with jpackage testing for other platforms, in which the
>>> external packaging tool (like Wix on Windows) isn't exhaustively tested.
>>>
>>> Dependencies
>>> ------------
>>>
>>> The jpackage `js` type will require TeaVM binaries to be present.
>>>
>>> Implementation options:
>>>
>>> *   Download TeaVM on-demand and cache it. (This is the likely option.)
>>>     *   Look for TeaVM in local repositories for popular build tools like
>>> Maven and Gradle
>>>     *   If not found locally, download TeaVM binaries from the read-only
>>> central repository and store in the cache folder
>>>     *   Invoke TeaVM from the local repository or cache
>>> *   Require that TeaVM binaries be installed locally
>>>     *   Provide the path to TeaVM binaries on the command line
>>> *   Bundle TeaVM
>>>     *   Challenging due to incompatible licenses (Apache v2 vs. GPL v2
>> with
>>> CPE)
>>>     *   Probably unnecessary given the options above. Other jpackage
>>> options require pre-installed tools, this will be no different.
>>>
>>> High-Level Design
>>> -----------------
>>>
>>> A new bundler will be added to the jpackage Java source code.
>>>
>>> It will first ensure that TeaVM binaries (JAR files) are available
>> locally,
>>> as described in the section above.
>>>
>>> The new bundler will use TeaVM's TeaVMRunner ([
>>>
>> https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java](https://github.com/konsoletyper/teavm/blob/master/tools/cli/src/main/java/org/teavm/cli/TeaVMRunner.java)
>> ),
>>> which conveniently accepts options similar to jpackage itself.
>> TeaVMRunner
>>> will do the heavy lifting of converting the application JAR files and
>>> resources into `classes.js`.
>>>
>>> The bundler will provide additional files required to make a web
>>> application, including an `index.html` to launch the `main()` method. The
>>> bundler will create the final archive (ZIP or WAR) using Java's
>>> ZipOutputStream. For the WAR format, the bundler will also add `web.xml`
>>> and `MANIFEST.MF` if not present to create a deployable, standard WAR
>> file.
>>
>>


From jvernee at openjdk.java.net  Mon Apr 26 12:55:30 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Apr 2021 12:55:30 GMT
Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args
 functions from invoke_native
In-Reply-To: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>
References: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>
Message-ID: <QlmXh_SY3AN4TlR1x8WxO71-41jsIKjDLGWp1GQz3hw=.8f6c236b-c7cc-41b6-bd4d-440d3b649ca4@github.com>

On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI.  The differences are outlined in [1].  In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either registers or on the stack following the normal calling
> convention.  To handle this, va_list is a struct containing separate
> pointers for arguments located in integer registers, floating point
> registers, and on the stack.  Apple's ABI simplifies this by passing all
> variadic arguments on the stack and the va_list type becomes a simple
> char* pointer.
> 
> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to
> represent the new ABI variant on macOS.  StackVaList is based on
> WinVaList lightly modified to handle the different TypeClasses on
> AArch64.  The original AArch64Linker is renamed to AapcsLinker and is
> currently used for all non-Mac platforms.  I think we also need to add a
> WinAArch64 CABI but I haven't yet been able to test on a Windows system
> so will do that later.
> 
> The macOS ABI also uses a different method of spilling arguments to the
> stack (the standard ABI pads each argument to a multiple of 8 byte stack
> slots, but the Mac ABI packs arguments according to their natural
> alignment).  None of the existing tests exercise this so I'll open a new
> JBS issue and work on that separately.
> 
> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64.
> 
> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms

Hi Nick. Sorry for the late reply, I've been out sick. I'll hopefully be taking a thorough look at this soon (still catching up on things).

I'm pretty impressed that such a large amount of code can just be shared between the two platforms :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3617

From alanb at openjdk.java.net  Mon Apr 26 13:23:27 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 26 Apr 2021 13:23:27 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
Message-ID: <9-2H-KUkJbuLQ4wO0bSrKG4OgihZzAU30TryjlFi3jc=.bdd81481-05e6-473b-b837-2ae17fd19067@github.com>

On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove java_nio_Buffer in javaClasses.hpp

src/java.base/share/classes/java/nio/Buffer.java line 740:

> 738:      */
> 739:     final int checkIndex(int i) {                       // package-private
> 740:         return Objects.checkIndex(i, limit);

Changing Buffer.checkIndex to use Objects.checkIndex is okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From peter.levart at gmail.com  Mon Apr 26 14:09:54 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 26 Apr 2021 16:09:54 +0200
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <BgujLBzc3hYCcHM7HCG7GR7zq1tnZ1suRA3kvb3Uvvk=.f780f0d8-6da9-4c7b-a205-3dcac30f01d9@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
 <CNby1eR4i4aQoSuqcr5tgnePbh1jXUXDF28PdrPZQM8=.0b9404aa-276c-435b-a8e7-3a6fda21b2d8@github.com>
 <0WxB-NH33GzJXA0TYpM-G-bVDdeLWqmFFKLi_R8-54o=.6968a96f-c349-4988-96a4-d982458ebe8e@github.com>
 <e2WZv9pyj7oHGKgGu0uSc7svXGzy-kujLvgrTn-Skf8=.1656129f-ac88-4c98-b6cf-629292253f7f@github.com>
 <BgujLBzc3hYCcHM7HCG7GR7zq1tnZ1suRA3kvb3Uvvk=.f780f0d8-6da9-4c7b-a205-3dcac30f01d9@github.com>
Message-ID: <75a6bf81-06d7-45fc-3c0d-42e436c9d058@gmail.com>


On 4/26/21 1:27 PM, ?????? ??????? wrote:
> On Mon, 26 Apr 2021 08:45:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>
>>> @AlanBateman if DL is not responding, will it be ok to just revert the changes related to `java.util.concurrent`?
>> That should be fine, the null check in Objects.equals is benign with these usages.
> One more thing I'm thinking about (not to be done in this PR of course) is to move call to `String.intern()` from where it is now in `Class.getPackageName()`
>
> public String getPackageName() {
>      String pn = this.packageName;
>      if (pn == null) {
>          Class<?> c = this;
>          while (c.isArray()) {
>              c = c.getComponentType();
>          }
>          if (c.isPrimitive()) {
>              pn = "java.lang";
>          } else {
>              String cn = c.getName();
>              int dot = cn.lastIndexOf('.');
>              pn = (dot != -1) ? cn.substring(0, dot).intern() : "";    // <---
>          }
>          this.packageName = pn;
>      }
>      return pn;
> }
>
> to `packageName` field assignement like
>
> this.packageName = pn.intern();
>
> this would add two more Strings (`""` and `"java.lang"`) into string table and allow to avoid `String.equals()` in favour of `==` call when comparing package names. What do you think?


I think this is not needed as string constants are all already interned 
strings (guaranteed by VM). Also be careful not to return a string which 
is not interned (which would happen if you did what you are proposing 
above).


Regards, Peter


>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/3571

From mli at openjdk.java.net  Mon Apr 26 14:31:28 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 26 Apr 2021 14:31:28 GMT
Subject: RFR: JDK-8265496: improve null check in
 DeflaterOutputStream/InflaterInputStream [v2]
In-Reply-To: <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>
References: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>
 <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>
Message-ID: <axgR1rex_PQW9SvamsA4VoXqCjEDOcEt4xQz9_6iI1k=.8809cdf4-36d1-4c70-8458-6b262e9166ba@github.com>

On Mon, 26 Apr 2021 02:36:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> code like below will create Deflater before null check, although it's not a real mem leak, but it's better to do null check before new Deflater.
>> 
>>         try {
>>             DeflaterOutputStream dos = new DeflaterOutputStream(null);
>>         } catch (NullPointerException e) {
>>             passed = true;
>>         }
>> Similar issues exist in several other classes.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights.

It's changed by another patch sometimes ago, but I missed to update the copyright.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3681

From mcimadamore at openjdk.java.net  Mon Apr 26 14:33:27 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 26 Apr 2021 14:33:27 GMT
Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args
 functions from invoke_native
In-Reply-To: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>
References: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>
Message-ID: <KPCzy4fJ-QNl_yDAPl9avV9x_-J3TEVI-Dh8E0Scagw=.2b28a5bd-5d8c-42c0-b1cb-56fa5ec4a9a0@github.com>

On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI.  The differences are outlined in [1].  In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either registers or on the stack following the normal calling
> convention.  To handle this, va_list is a struct containing separate
> pointers for arguments located in integer registers, floating point
> registers, and on the stack.  Apple's ABI simplifies this by passing all
> variadic arguments on the stack and the va_list type becomes a simple
> char* pointer.
> 
> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to
> represent the new ABI variant on macOS.  StackVaList is based on
> WinVaList lightly modified to handle the different TypeClasses on
> AArch64.  The original AArch64Linker is renamed to AapcsLinker and is
> currently used for all non-Mac platforms.  I think we also need to add a
> WinAArch64 CABI but I haven't yet been able to test on a Windows system
> so will do that later.
> 
> The macOS ABI also uses a different method of spilling arguments to the
> stack (the standard ABI pads each argument to a multiple of 8 byte stack
> slots, but the Mac ABI packs arguments according to their natural
> alignment).  None of the existing tests exercise this so I'll open a new
> JBS issue and work on that separately.
> 
> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64.
> 
> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms

I'll leave fine details to @JornVernee  - high level bits seem correct. I think we should be more transparent in e.g. enum constant on the fact that AArch64 really means linux - and perhaps use Arm64 instead of AArch64.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java line 35:

> 33:     SysV,
> 34:     Win64,
> 35:     AArch64,

This should be Linux AArch64. Btw, should we use Arm64 instead, which seems to be the more common name to refer to the platform?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/aapcs/AapcsLinker.java line 50:

> 48:  * the ARM 64-bit Architecture".
> 49:  */
> 50: public class AapcsLinker implements CLinker {

I see why it's called like that - but this is really either AArch64Linker or Arm64Linker. E.g. the platform standard one.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/aapcs/AapcsVaList.java line 54:

> 52:  * Linux. Variadic parameters may be passed in registers or on the stack.
> 53:  */
> 54: public class AapcsVaList implements VaList {

Same here - not sure I like Aapcs much

-------------

PR: https://git.openjdk.java.net/jdk/pull/3617

From lancea at openjdk.java.net  Mon Apr 26 14:58:25 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 26 Apr 2021 14:58:25 GMT
Subject: RFR: JDK-8265496: improve null check in
 DeflaterOutputStream/InflaterInputStream [v2]
In-Reply-To: <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>
References: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>
 <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>
Message-ID: <o0ppeqg4nwEDucZgnYXceLJkBKioA2drf6ngbFoNwJM=.2d016c1a-0248-47ac-9686-b751e2b4549e@github.com>

On Mon, 26 Apr 2021 02:36:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> code like below will create Deflater before null check, although it's not a real mem leak, but it's better to do null check before new Deflater.
>> 
>>         try {
>>             DeflaterOutputStream dos = new DeflaterOutputStream(null);
>>         } catch (NullPointerException e) {
>>             passed = true;
>>         }
>> Similar issues exist in several other classes.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights.

Hi Hamlin,

The change looks fine.  Please add the noreg-trivial change to the issue given there is not a test update for this so that you do not get pinged by a bot

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3681

From dfuchs at openjdk.java.net  Mon Apr 26 15:34:29 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 26 Apr 2021 15:34:29 GMT
Subject: RFR: 8265961: Fix comments in logging.properties
In-Reply-To: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
References: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
Message-ID: <oh-VnD_LYE-bx582iSuFVvI9lY6DdgSPaE1CHn6Hygc=.47fb872a-c147-41e0-a7de-5fffdb7cec43@github.com>

On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues.

LGTM, but English is not my primary language.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3688

From lance.andersen at oracle.com  Mon Apr 26 15:38:21 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 26 Apr 2021 15:38:21 +0000
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v4]
In-Reply-To: <FjhT3nQg6Vb9Hb8pxNAkwPgYw85k8IQcMmORwLOicEM=.241c2836-cdb2-4e22-9d11-6455c6c8947d@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
 <z-VtWLNFeho201QW1vLymWa3vB-TSkwMElKw_seESeM=.c5d67dac-2543-4bd4-b5d3-dfc15e56d4fa@github.com>
 <BIAT8d0uhmiDK4YwqSHGZSgTh1Ach6qQvgEbark9kdE=.5f053c10-7e37-4a0f-9a37-8a92b7bd5585@github.com>
 <3NgvnAImIrOF6eaXJSim4TCHPruhp6yD2tVqBm-RMHM=.1bc66bec-53fb-4840-b0ef-c03a7cc111d1@github.com>
 <FjhT3nQg6Vb9Hb8pxNAkwPgYw85k8IQcMmORwLOicEM=.241c2836-cdb2-4e22-9d11-6455c6c8947d@github.com>
Message-ID: <D119E1FB-682C-41CE-9B77-E22968E1C7ED@oracle.com>

Hi Lin,

Sorry for not replying earlier, I thought I had.

I believe we should still  flush out the API proposal on the CoreLibs alias before continuing to move forward with updates to the PR (as was suggested by both Alan and I)

For example,  the updates to the PR does not include any proposed changes to GZIPInputStream and this should be something we should come to an agreement on as it can possibly impact the direction.  I am not sure we need to add multiple constructors to GZIPOutputStream as part of the proposed change.

It would also be useful to know where is the actual pain point, that is, is there a tool or API not having these fields settable for that is causing an issue?  I ask so that we can make sure that we are taking that into consideration.

Please note, that I am not trying to discourage your contribution or work to date, I just want to make sure we get agreement on the way forward as it not only impact the PR, but the CSR which will be needed as well.

Best
Lance

On Apr 26, 2021, at 7:40 AM, Lin Zang <lzang at openjdk.java.net<mailto:lzang at openjdk.java.net>> wrote:

On Thu, 8 Apr 2021 08:54:06 GMT, Alan Bateman <alanb at openjdk.org<mailto:alanb at openjdk.org>> wrote:

Dear All,
May I ask your help to review this change? Thanks!

BRs,
Lin

Dear All,
May I ask your help to review this change? Thanks!

@LanceAndersen Do you have cycles to help Lin? This proposal will require discussion, they may be case for the header to be a record for example. My personal view is that the PR should be set aside until there is at least at least some agreement on the API.

Dear @AlanBateman @LanceAndersen,
   May I ask your help to review whether the usage of Record and Builder pattern is reasonable in the PR? Thanks

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From prappo at openjdk.java.net  Mon Apr 26 15:41:30 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 26 Apr 2021 15:41:30 GMT
Subject: RFR: 8265961: Fix comments in logging.properties
In-Reply-To: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
References: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
Message-ID: <hTQuS2rDCC-zIHy1s2Wh9nqGOzfPrL6ntXIUJufIVEU=.97068f48-848a-46bb-aeac-fe8efecde7db@github.com>

On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues.

Thanks, Daniel. Let's maybe wait for one more reviewer then. I am also a bit skeptical about this use of "the" here:


# Limit the messages that are printed on the console to INFO and above.
        ^


I don't think it's required.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3688

From mr at openjdk.java.net  Mon Apr 26 15:56:26 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Mon, 26 Apr 2021 15:56:26 GMT
Subject: RFR: 8265961: Fix comments in logging.properties
In-Reply-To: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
References: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
Message-ID: <6MHg1nq5hZuXOr5BFaq_tnLVlNlIPq70oKB-NJ-hnVI=.de382fdc-15bc-4ab6-977d-34dc670c8d87@github.com>

On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues.

Otherwise, these changes look fine.

src/java.logging/share/conf/logging.properties line 5:

> 3: #
> 4: # You can use a different file by specifying a filename
> 5: # in the java.util.logging.config.file system property.

Unless the `java.util.logging.config` property contains more than one item of information, the original "with" is more appropriate here.

src/java.logging/share/conf/logging.properties line 46:

> 44: java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
> 45: 
> 46: # Limit the messages that are printed on the console to INFO and above.

"Limit the messages ..." could be more direct. Consider "Only print messages to the console if they have level INFO or above."

-------------

Changes requested by mr (Lead).

PR: https://git.openjdk.java.net/jdk/pull/3688

From sverre.moe at gmail.com  Mon Apr 26 17:19:08 2021
From: sverre.moe at gmail.com (Sverre Moe)
Date: Mon, 26 Apr 2021 19:19:08 +0200
Subject: jpackage regression on Windows
Message-ID: <CALAJ+5BxfCZ3wHzhxyQ8J02yN9e+k_R7uPecdhna5mmRk1oPVQ@mail.gmail.com>

There was a regression introduced in JDK 15 of jpackage tool on Windows.
The file permission of the built EXE has changed. The file is now ReadOnly.
Both EXE and MSI was ReadWrite, now
EXE is Read-Only while MSI is still Read-Write

The EXE can no longer be signed because it cannot be modified.

I just filed a bug report on this
internal review ID : 9070046

/Sverre

From prappo at openjdk.java.net  Mon Apr 26 17:25:59 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 26 Apr 2021 17:25:59 GMT
Subject: RFR: 8265961: Fix comments in logging.properties [v2]
In-Reply-To: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
References: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
Message-ID: <A5NjAsNuPyZPwNlb3cuRcjq-toXwMapNu2UaKmlLkqw=.b0a9b95b-ddfd-418e-927b-a4df111adc40@github.com>

> I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Rollback "in" -> "with"; remove more trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3688/files
  - new: https://git.openjdk.java.net/jdk/pull/3688/files/69388538..df7a7961

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3688&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3688&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3688/head:pull/3688

PR: https://git.openjdk.java.net/jdk/pull/3688

From mr at openjdk.java.net  Mon Apr 26 17:26:02 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Mon, 26 Apr 2021 17:26:02 GMT
Subject: RFR: 8265961: Fix comments in logging.properties [v2]
In-Reply-To: <A5NjAsNuPyZPwNlb3cuRcjq-toXwMapNu2UaKmlLkqw=.b0a9b95b-ddfd-418e-927b-a4df111adc40@github.com>
References: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
 <A5NjAsNuPyZPwNlb3cuRcjq-toXwMapNu2UaKmlLkqw=.b0a9b95b-ddfd-418e-927b-a4df111adc40@github.com>
Message-ID: <UFvyRWXq_kbAuYoUykFBUh-CSp91t6gGOs0gLCkL-Vg=.e0f4901e-a47c-4fed-b898-71e9b1738381@github.com>

On Mon, 26 Apr 2021 17:14:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rollback "in" -> "with"; remove more trailing whitespace

Marked as reviewed by mr (Lead).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3688

From iris at openjdk.java.net  Mon Apr 26 17:26:05 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 26 Apr 2021 17:26:05 GMT
Subject: RFR: 8265961: Fix comments in logging.properties [v2]
In-Reply-To: <A5NjAsNuPyZPwNlb3cuRcjq-toXwMapNu2UaKmlLkqw=.b0a9b95b-ddfd-418e-927b-a4df111adc40@github.com>
References: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
 <A5NjAsNuPyZPwNlb3cuRcjq-toXwMapNu2UaKmlLkqw=.b0a9b95b-ddfd-418e-927b-a4df111adc40@github.com>
Message-ID: <AmTLTbB-e-Zmxa3fh0_qgw1nagW6L8gw5hKu19mLFns=.f18cd158-afef-4501-8f98-937580757a42@github.com>

On Mon, 26 Apr 2021 17:14:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rollback "in" -> "with"; remove more trailing whitespace

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3688

From jjg at openjdk.java.net  Mon Apr 26 17:26:06 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 26 Apr 2021 17:26:06 GMT
Subject: RFR: 8265961: Fix comments in logging.properties [v2]
In-Reply-To: <A5NjAsNuPyZPwNlb3cuRcjq-toXwMapNu2UaKmlLkqw=.b0a9b95b-ddfd-418e-927b-a4df111adc40@github.com>
References: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
 <A5NjAsNuPyZPwNlb3cuRcjq-toXwMapNu2UaKmlLkqw=.b0a9b95b-ddfd-418e-927b-a4df111adc40@github.com>
Message-ID: <BFcPBlRWJwqbl6Mcui-xeNLY1gFJEIrYuhtEU0Kx_hc=.10a43258-390a-4a82-815d-ad73f9e6f84e@github.com>

On Mon, 26 Apr 2021 17:14:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rollback "in" -> "with"; remove more trailing whitespace

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3688

From prappo at openjdk.java.net  Mon Apr 26 17:26:09 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 26 Apr 2021 17:26:09 GMT
Subject: RFR: 8265961: Fix comments in logging.properties [v2]
In-Reply-To: <6MHg1nq5hZuXOr5BFaq_tnLVlNlIPq70oKB-NJ-hnVI=.de382fdc-15bc-4ab6-977d-34dc670c8d87@github.com>
References: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
 <6MHg1nq5hZuXOr5BFaq_tnLVlNlIPq70oKB-NJ-hnVI=.de382fdc-15bc-4ab6-977d-34dc670c8d87@github.com>
Message-ID: <_hmR8EUSjUwFoSvENAr--0Zbes5cA8tJ3HHMcvGkT74=.3f8de421-42f2-414c-9537-adb7bb7fb3cc@github.com>

On Mon, 26 Apr 2021 15:48:18 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rollback "in" -> "with"; remove more trailing whitespace
>
> src/java.logging/share/conf/logging.properties line 5:
> 
>> 3: #
>> 4: # You can use a different file by specifying a filename
>> 5: # in the java.util.logging.config.file system property.
> 
> Unless the `java.util.logging.config` property contains more than one item of information, the original "with" is more appropriate here.

Is it because in this case "with" is similar to "by" and "using" in the sense that "with" conveys that the system property acts as a "tool" with which the effect, specifying a filename, is achieved?

> src/java.logging/share/conf/logging.properties line 46:
> 
>> 44: java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
>> 45: 
>> 46: # Limit the messages that are printed on the console to INFO and above.
> 
> "Limit the messages ..." could be more direct. Consider "Only print messages to the console if they have level INFO or above."

Understood and thanks. That said, I will not use what you suggested for the sake of consistency: the "limit the messages" phrasing is also used in the API:


    /**
     * Set the log level specifying which message levels will be
     * logged by this {@code Handler}.  Message levels lower than this
     * value will be discarded.
     * <p>
     * The intention is to allow developers to turn on voluminous
     * logging, but to limit the messages that are sent to certain
     * {@code Handlers}.
     *
     * @param newLevel   the new value for the log level
     * @throws  SecurityException  if a security manager exists and if
     *             the caller does not have {@code LoggingPermission("control")}.
     */
    public synchronized void setLevel(Level newLevel) throws SecurityException {

-------------

PR: https://git.openjdk.java.net/jdk/pull/3688

From bpb at openjdk.java.net  Mon Apr 26 17:28:38 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 26 Apr 2021 17:28:38 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v10]
In-Reply-To: <0AiUvcaOonoGy21KYfhiLIVw08_KKOavevmV-o_098U=.0f7b97fe-ab8b-4a09-82d6-52da34a02657@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <0AiUvcaOonoGy21KYfhiLIVw08_KKOavevmV-o_098U=.0f7b97fe-ab8b-4a09-82d6-52da34a02657@github.com>
Message-ID: <CkI3VI_Kr0AmhVWiEtwvi80VaVYRziwdg98RCIJIivg=.d910f2b5-917e-4506-a2bb-0a7a34010b21@github.com>

On Sun, 25 Apr 2021 10:38:03 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1915

From prappo at openjdk.java.net  Mon Apr 26 17:38:02 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 26 Apr 2021 17:38:02 GMT
Subject: Integrated: 8265961: Fix comments in logging.properties
In-Reply-To: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
References: <E5cJmNOGRzCr_suEWj4__Z_TZhflsHzYy-0R4BZDbAk=.ad1bdd34-80d3-41e1-8ea0-8d427ae4b516@github.com>
Message-ID: <a6_3x_qJOq30nD7x7bQgt87F98i78IQ3_HGFfV0ZwIY=.b7ad7e1d-22bb-477b-96b7-83480cc718b1@github.com>

On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues.

This pull request has now been integrated.

Changeset: efe6b933
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/efe6b933
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8265961: Fix comments in logging.properties

Reviewed-by: dfuchs, mr, iris, jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/3688

From github.com+471021+marschall at openjdk.java.net  Mon Apr 26 17:38:06 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Mon, 26 Apr 2021 17:38:06 GMT
Subject: Integrated: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <xiX03t4PjYZ2HzdSfaIHjaaoMhZf8PW6tOWcZkiy_Bg=.7a1e161f-a4f4-4a45-b05d-327909a66ba0@github.com>

On Thu, 31 Dec 2020 10:10:56 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

This pull request has now been integrated.

Changeset: 65c19c40
Author:    Philippe Marschall <philippe.marschall at gmail.com>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/65c19c40
Stats:     371 lines in 6 files changed: 361 ins; 0 del; 10 mod

4926314: Optimize Reader.read(CharBuffer)

Reviewed-by: alanb, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1915

From naoto at openjdk.java.net  Mon Apr 26 18:25:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 26 Apr 2021 18:25:35 GMT
Subject: RFR: JDK-8265496: improve null check in
 DeflaterOutputStream/InflaterInputStream [v2]
In-Reply-To: <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>
References: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>
 <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>
Message-ID: <GO2_7XmgwJQ2fA774HuPfozUqm0hv6WaG5fFEQRPSRU=.ea340339-ca60-4687-92a8-ae48712608df@github.com>

On Mon, 26 Apr 2021 02:36:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> code like below will create Deflater before null check, although it's not a real mem leak, but it's better to do null check before new Deflater.
>> 
>>         try {
>>             DeflaterOutputStream dos = new DeflaterOutputStream(null);
>>         } catch (NullPointerException e) {
>>             passed = true;
>>         }
>> Similar issues exist in several other classes.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3681

From kvn at openjdk.java.net  Mon Apr 26 18:57:43 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 18:57:43 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
Message-ID: <Lc7bg6OTgo-fgIlGu__9dvggsFiT1JlySJAPyUR-KC8=.3716044a-fcd4-4e94-bee1-5c0f3c59c666@github.com>

On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove java_nio_Buffer in javaClasses.hpp

@veresov please look on C1 changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From egahlin at openjdk.java.net  Mon Apr 26 21:24:48 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 26 Apr 2021 21:24:48 GMT
Subject: RFR: 8203359: Container level resources events [v10]
In-Reply-To: <r5gSFDRqdBOmjl3bmVNoHb1klfdKpd5tlYWEXOW8GuA=.026f4b58-9beb-4737-aba9-eed37f264501@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <r5gSFDRqdBOmjl3bmVNoHb1klfdKpd5tlYWEXOW8GuA=.026f4b58-9beb-4737-aba9-eed37f264501@github.com>
Message-ID: <UolOacbfsJ2sATwxiNsix_jalUPIhiCQEUwqPEoU8VI=.b96bc598-61c1-48ef-bc24-f952d6956cd1@github.com>

On Thu, 22 Apr 2021 16:00:32 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
>> 
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
>> * CPU related metrics
>> * Memory related metrics
>> * I/O related metrics
>> 
>> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
>> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).
>
> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Prevent event container bytecode generation if no container present
>  - Fix event metadata
>  - Roll back conditional registration of container events
>  - Remove container events flag
>  - Remove trailing spaces
>  - Doh
>  - Report container type and register events conditionally
>  - Remove unused test files
>  - Initial test support for JFR container events
>  - Update the JFR control files
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/904d9495...04c3f092

src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 729:

> 727: 
> 728:     public static boolean shouldSkipBytecode(String eventName, Class<?> superClass) {
> 729:         if (!superClass.getName().equals("jdk.jfr.events.AbstractJDKEvent")) {

Was there a problem checking against the class instance? If so, perhaps you could add a check that the class is in the boot class loader (null).

src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 737:

> 735:     private static Metrics getMetrics() {
> 736:         if (metrics == null) {
> 737:             metrics = Metrics.systemMetrics();

Will this not lead to a lookup every time in an non-container environment?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From kvn at openjdk.java.net  Mon Apr 26 22:45:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 22:45:25 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v6]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <nltrVq6SKEmgbuz4LuFlhxOqflGrSyf04EhJefvGxUA=.b01a8293-d4c2-4f8f-8e59-9d2ca2a7db4e@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into JDK-8264805
 - Address review comments
 - Remove exports from Graal module to jdk.aot
 - Merge branch 'master' into JDK-8264805
 - Merge branch 'master' into JDK-8264805
 - 8264805: Remove the experimental Ahead-of-Time Compiler

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=05
  Stats: 26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

PR: https://git.openjdk.java.net/jdk/pull/3398

From igraves at openjdk.java.net  Tue Apr 27 00:27:49 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 27 Apr 2021 00:27:49 GMT
Subject: RFR: 8260560: convert jdeps and jdeprscan tools to use Stream.toList()
Message-ID: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>

8260560: convert jdeps and jdeprscan tools to use Stream.toList()

-------------

Commit messages:
 - Updating jdeps and jdeprscan to use Stream.toList()

Changes: https://git.openjdk.java.net/jdk/pull/3705/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3705&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260560
  Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3705.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3705/head:pull/3705

PR: https://git.openjdk.java.net/jdk/pull/3705

From mli at openjdk.java.net  Tue Apr 27 01:09:37 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 27 Apr 2021 01:09:37 GMT
Subject: RFR: JDK-8265496: improve null check in
 DeflaterOutputStream/InflaterInputStream [v2]
In-Reply-To: <o0ppeqg4nwEDucZgnYXceLJkBKioA2drf6ngbFoNwJM=.2d016c1a-0248-47ac-9686-b751e2b4549e@github.com>
References: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>
 <_b4qtK0pP1-u924gsHu98UnE2RXhcJcp4Gs2Pa0CGIo=.a6360d7c-cfe5-4ab2-ba16-2bef8876905f@github.com>
 <o0ppeqg4nwEDucZgnYXceLJkBKioA2drf6ngbFoNwJM=.2d016c1a-0248-47ac-9686-b751e2b4549e@github.com>
Message-ID: <U-DZXj9xxccLrjqPNjdooegIdyS9af6dDbE3VLYEZpE=.80f7c7fa-4a5e-476a-9175-9de5547af800@github.com>

On Mon, 26 Apr 2021 14:55:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi Hamlin,
> 
> The change looks fine. Please add the noreg-trivial change to the issue given there is not a test update for this so that you do not get pinged by a bot

Hi Lance, Thanks for reminding.

Thanks @LanceAndersen @naotoj @vyommani for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3681

From mli at openjdk.java.net  Tue Apr 27 01:09:38 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 27 Apr 2021 01:09:38 GMT
Subject: Integrated: JDK-8265496: improve null check in
 DeflaterOutputStream/InflaterInputStream
In-Reply-To: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>
References: <MyTkv_RnXfmIRFhsbzqgVpADk8FMosG3QCTviWoGL2c=.fb821099-997c-49d8-947e-b1fb9fdf74d4@github.com>
Message-ID: <tQSo0xiqWB2xHMtY709hPahELufGCA7Qw2JfDGV-6gk=.7c4f208d-e3ae-4a2a-9a56-3d6bfcde73a3@github.com>

On Mon, 26 Apr 2021 01:17:43 GMT, Hamlin Li <mli at openjdk.org> wrote:

> code like below will create Deflater before null check, although it's not a real mem leak, but it's better to do null check before new Deflater.
> 
>         try {
>             DeflaterOutputStream dos = new DeflaterOutputStream(null);
>         } catch (NullPointerException e) {
>             passed = true;
>         }
> Similar issues exist in several other classes.

This pull request has now been integrated.

Changeset: 15d47877
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/15d47877
Stats:     15 lines in 8 files changed: 0 ins; 0 del; 15 mod

8265496: improve null check in DeflaterOutputStream/InflaterInputStream

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/3681

From kvn at openjdk.java.net  Tue Apr 27 01:15:37 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 01:15:37 GMT
Subject: Integrated: 8264805: Remove the experimental Ahead-of-Time Compiler
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <3MIAR4n0RJot9rerXkZf7hB7NlYhJbPI6ri5q9IP3SM=.c6fecb4a-0d84-4c78-bf41-b750ee03d6df@github.com>

On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

This pull request has now been integrated.

Changeset: 694acedf
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/694acedf
Stats:     26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod

8264805: Remove the experimental Ahead-of-Time Compiler

Reviewed-by: coleenp, erikj, stefank, iignatyev, dholmes, aph, shade, iklam, mchung, iveresov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3398

From bpb at openjdk.java.net  Tue Apr 27 01:32:47 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Apr 2021 01:32:47 GMT
Subject: RFR: 8266014: Regression brought by optimization done with JDK-4926314
Message-ID: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>

Please consider this request to correct a minor problem with the optimization added for JDK-4926314. The change is to attempt to read the number of elements remaining in the target buffer unless that number is non-positive in which case read zero. The test addition fails without and passes with the implementation change.

-------------

Commit messages:
 - 8266014: Regression brought by optimization done with JDK-4926314

Changes: https://git.openjdk.java.net/jdk/pull/3708/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3708&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266014
  Stats: 20 lines in 2 files changed: 16 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3708.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3708/head:pull/3708

PR: https://git.openjdk.java.net/jdk/pull/3708

From ngasson at openjdk.java.net  Tue Apr 27 02:10:35 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 27 Apr 2021 02:10:35 GMT
Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args
 functions from invoke_native
In-Reply-To: <KPCzy4fJ-QNl_yDAPl9avV9x_-J3TEVI-Dh8E0Scagw=.2b28a5bd-5d8c-42c0-b1cb-56fa5ec4a9a0@github.com>
References: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>
 <KPCzy4fJ-QNl_yDAPl9avV9x_-J3TEVI-Dh8E0Scagw=.2b28a5bd-5d8c-42c0-b1cb-56fa5ec4a9a0@github.com>
Message-ID: <GGb9sh_YCn2554_6CuCoIYJMFJ85pZPO8l0R3urH5ws=.55714c05-9e16-4c98-b2d4-69eabb13686b@github.com>

On Mon, 26 Apr 2021 14:29:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI.  The differences are outlined in [1].  In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either registers or on the stack following the normal calling
>> convention.  To handle this, va_list is a struct containing separate
>> pointers for arguments located in integer registers, floating point
>> registers, and on the stack.  Apple's ABI simplifies this by passing all
>> variadic arguments on the stack and the va_list type becomes a simple
>> char* pointer.
>> 
>> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to
>> represent the new ABI variant on macOS.  StackVaList is based on
>> WinVaList lightly modified to handle the different TypeClasses on
>> AArch64.  The original AArch64Linker is renamed to AapcsLinker and is
>> currently used for all non-Mac platforms.  I think we also need to add a
>> WinAArch64 CABI but I haven't yet been able to test on a Windows system
>> so will do that later.
>> 
>> The macOS ABI also uses a different method of spilling arguments to the
>> stack (the standard ABI pads each argument to a multiple of 8 byte stack
>> slots, but the Mac ABI packs arguments according to their natural
>> alignment).  None of the existing tests exercise this so I'll open a new
>> JBS issue and work on that separately.
>> 
>> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64.
>> 
>> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/aapcs/AapcsLinker.java line 50:
> 
>> 48:  * the ARM 64-bit Architecture".
>> 49:  */
>> 50: public class AapcsLinker implements CLinker {
> 
> I see why it's called like that - but this is really either AArch64Linker or Arm64Linker. E.g. the platform standard one.

How about StandardAArch64Linker? Otherwise MacOsAArch64Linker sounds like it should be a specialisation of AArch64Linker.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3617

From ngasson at openjdk.java.net  Tue Apr 27 02:16:37 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 27 Apr 2021 02:16:37 GMT
Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args
 functions from invoke_native
In-Reply-To: <KPCzy4fJ-QNl_yDAPl9avV9x_-J3TEVI-Dh8E0Scagw=.2b28a5bd-5d8c-42c0-b1cb-56fa5ec4a9a0@github.com>
References: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>
 <KPCzy4fJ-QNl_yDAPl9avV9x_-J3TEVI-Dh8E0Scagw=.2b28a5bd-5d8c-42c0-b1cb-56fa5ec4a9a0@github.com>
Message-ID: <Nzvid85CCSe5cgJgE2kvtHVtWEO8eBbgUoOb_l_UhlY=.853f1ea9-8fe4-432e-9946-9b1515ed58ea@github.com>

On Mon, 26 Apr 2021 14:27:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI.  The differences are outlined in [1].  In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either registers or on the stack following the normal calling
>> convention.  To handle this, va_list is a struct containing separate
>> pointers for arguments located in integer registers, floating point
>> registers, and on the stack.  Apple's ABI simplifies this by passing all
>> variadic arguments on the stack and the va_list type becomes a simple
>> char* pointer.
>> 
>> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to
>> represent the new ABI variant on macOS.  StackVaList is based on
>> WinVaList lightly modified to handle the different TypeClasses on
>> AArch64.  The original AArch64Linker is renamed to AapcsLinker and is
>> currently used for all non-Mac platforms.  I think we also need to add a
>> WinAArch64 CABI but I haven't yet been able to test on a Windows system
>> so will do that later.
>> 
>> The macOS ABI also uses a different method of spilling arguments to the
>> stack (the standard ABI pads each argument to a multiple of 8 byte stack
>> slots, but the Mac ABI packs arguments according to their natural
>> alignment).  None of the existing tests exercise this so I'll open a new
>> JBS issue and work on that separately.
>> 
>> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64.
>> 
>> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java line 35:
> 
>> 33:     SysV,
>> 34:     Win64,
>> 35:     AArch64,
> 
> This should be Linux AArch64. Btw, should we use Arm64 instead, which seems to be the more common name to refer to the platform?

I thought about using MacOsArm64 as that would be closer to the terminology Apple uses, but then we use AArch64 pretty consistently everywhere else in OpenJDK/Hotspot to refer to this architecture, so it seems strange to deviate here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3617

From ngasson at openjdk.java.net  Tue Apr 27 02:16:37 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 27 Apr 2021 02:16:37 GMT
Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args
 functions from invoke_native
In-Reply-To: <GGb9sh_YCn2554_6CuCoIYJMFJ85pZPO8l0R3urH5ws=.55714c05-9e16-4c98-b2d4-69eabb13686b@github.com>
References: <Fb3ZCFGhlrtHbqCP5ywk4Hyxm_b-tqp2HN6c1a_RtrA=.0de5994e-c849-47fb-8842-41b4b5078eda@github.com>
 <KPCzy4fJ-QNl_yDAPl9avV9x_-J3TEVI-Dh8E0Scagw=.2b28a5bd-5d8c-42c0-b1cb-56fa5ec4a9a0@github.com>
 <GGb9sh_YCn2554_6CuCoIYJMFJ85pZPO8l0R3urH5ws=.55714c05-9e16-4c98-b2d4-69eabb13686b@github.com>
Message-ID: <okA2YQ4a8RZanfG6ZIEYfStro2cxBp_JYB4svITNwps=.d1ecf800-81ee-4760-a6af-00234c74ad48@github.com>

On Tue, 27 Apr 2021 02:07:50 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/aapcs/AapcsLinker.java line 50:
>> 
>>> 48:  * the ARM 64-bit Architecture".
>>> 49:  */
>>> 50: public class AapcsLinker implements CLinker {
>> 
>> I see why it's called like that - but this is really either AArch64Linker or Arm64Linker. E.g. the platform standard one.
>
> How about StandardAArch64Linker? Otherwise MacOsAArch64Linker sounds like it should be a specialisation of AArch64Linker.

Or LinuxAArch64Linker if we're going to rename the CABI enum AArch64 -> LinuxAArch64? But this would also be used on other OSs that use the Arm ABI spec as-is (e.g. *BSD).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3617

From kvn at openjdk.java.net  Tue Apr 27 02:18:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 02:18:40 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v4]
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <0mJY3m49euRLBowk0WfgXqx6bGSqNJFykEXZdJ9cO6k=.87753850-16f7-4c15-b526-c29898caf5ac@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> 
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'JDK-8264805' into JDK-8264806
 - Merge branch 'master' into JDK-8264805
 - Restore Compiler::isGraalEnabled()
 - Restore Graal Builder image makefile
 - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
 - Address review comments
 - 8264806: Remove the experimental JIT compiler
 - Remove exports from Graal module to jdk.aot
 - Merge branch 'master' into JDK-8264805
 - Merge branch 'master' into JDK-8264805
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b524a81a...db7c9aaf

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3421/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=03
  Stats: 468493 lines in 3247 files changed: 2 ins; 468290 del; 201 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3421.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421

PR: https://git.openjdk.java.net/jdk/pull/3421

From stuart.marks at oracle.com  Tue Apr 27 03:50:36 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 26 Apr 2021 20:50:36 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <85906d24-f9c8-1b6f-77c0-b8cf5ca48457@gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
 <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
 <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>
 <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>
 <85906d24-f9c8-1b6f-77c0-b8cf5ca48457@gmail.com>
Message-ID: <6f0d7d03-ec96-b204-7252-efe413792073@oracle.com>



On 4/25/21 11:09 AM, Peter Levart wrote:
> When making this proposition, I was only thinking of how to enable new 
> yet-nonexistent operations on collections that have order / are reversible and that 
> the code calling these methods would already knows that it is dealing with ordered / 
> reversible collections. I wasn't thinking about how to prevent mistakes like passing 
> unordered collection to code that expects ordered / reversible collection. This can 
> only be solved in two ways. The way immutability of collections is solved (throw 
> exception in runtime when requesting operation that makes no sense in unordered 
> collection) or by introducing new type - ReversibleCollection that solves this in 
> compile time. So I take back my vote for suggestion to introduce methods like 
> getFirst(), removeFirst() that would return arbitrary element. There's still a 
> possibility for those methods to throw at runtime though. But I don't know whether 
> this would be so nicely accepted as immutability was. WDYT?

Consider some collection implementation X that has some semantics and a suite of 
operations that support those semantics. An implementation can throw 
UnsupportedOperationException if for some reason that operation doesn't make sense 
for the implementation, but fundamentally that implementation still has "X-ness".

Look at Arrays.asList for example. It's backed by an array, so add and remove 
operations aren't supported. But it's still fundamentally a List in that it has N 
elements, is ordered, the elements are numbered from 0 to N-1, sublists can be 
obtained between two arbitrary indexes, its ListIterator supports iteration in both 
directions, it has a clear and useful definition for equals() and hashCode(), etc.

Similarly, an unmodifiable List is still a List.

Now consider adding {add,get,remove}{First,Last} methods to the Collection 
interface. Collection doesn't have any semantics for these methods itself, so we're 
hoping that there is some sensible mapping from these methods to appropriate 
operations on Collections implementations or subinterfaces.

  * Presumably for unordered collections like HashSet, all of these methods would be 
left to throw UOE.

  * A queue has a head and a tail, so perhaps these are mapped to first and last, 
respectively, and Queue would support addLast and removeFirst but not addFirst and 
removeLast. But that wouldn't work for PriorityQueue.

  * A stack has a "top": the most recently pushed element. Does the stack top 
correspond to the first or the last? It could be either -- in fact, in the JDK, for 
Stack the top is the last element but for Deque the top is the first element.

  * For some other ordered collection, who knows what a reasonable mapping would be?

This approach feels backwards to me. Instead of starting from an abstraction that 
has strong semantics and then applying all (or at least most) of the applicable 
methods, we're starting with a suite of methods and looking around for relationships 
to a variety of abstractions that might or might not have much in common. That seems 
like a recipe for a bad API to me.

s'marks


From kvn at openjdk.java.net  Tue Apr 27 04:44:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 04:44:17 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v5]
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <9SR3Bnj0ywpPcSx4uU4G9oH7cXJv6dWPIkvyIb_rnKo=.30180267-aeb7-4ab3-947a-cdf80e62c81c@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> 
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

Vladimir Kozlov 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-8264806
 - Merge branch 'JDK-8264805' into JDK-8264806
 - Merge branch 'master' into JDK-8264805
 - Restore Compiler::isGraalEnabled()
 - Restore Graal Builder image makefile
 - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
 - Address review comments
 - 8264806: Remove the experimental JIT compiler
 - Remove exports from Graal module to jdk.aot
 - Merge branch 'master' into JDK-8264805
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/694acedf...b1e9ba63

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3421/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=04
  Stats: 441532 lines in 2884 files changed: 0 ins; 441518 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3421.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421

PR: https://git.openjdk.java.net/jdk/pull/3421

From donraab at gmail.com  Tue Apr 27 05:08:28 2021
From: donraab at gmail.com (Donald Raab)
Date: Tue, 27 Apr 2021 01:08:28 -0400
Subject: New convenience methods on Stream
Message-ID: <B78DB84E-2AF4-4EDB-ABCD-6C9843258BD6@gmail.com>

Hi all,

I?d like to propose adding one or two of the following methods on Stream to cover more surface area of the Collections ecosystem, without requiring a big increase in the size of the Stream interface. Apologies if this has come up for discussion before. 


1. Stream contents into a mutable collection created by a Supplier. 

default <R extends Collection<T>> R toCollection(Supplier<R> supplier)
{
    return this.collect(Collectors.toCollection(supplier));
}

Usage Examples:

HashSet<String> set = stream.toCollection(HashSet::new);
TreeSet<String> sortedSet = stream.toCollection(TreeSet::new);
ArrayDeque<String> deque = stream.toCollection(ArrayDeque::new);


2. Pass the result of toArray directly into a function that can then return a Collection. This should work with Set.of, List.of and any 3rd party collections which take arrays.

default <R extends Collection<T>> R to(Function<T[], R> function)
{
    return function.apply((T[]) this.toArray());
}

Usage Examples:

Set<String> set = stream.to(Set::of);
List<String> list = stream.to(List::of);
List<String> arrayList = stream.to(Arrays::asList);


3. Stream contents directly into any mutable collection. This would then work with all other mutable JDK Collection types.

default <R extends Collection<T>> R into(R result)
{
    Collections.addAll(result, (T[]) this.toArray());
    return result;
}

Usage Examples:

HashSet<String> set = stream.into(new HashSet<>());
TreeSet<String> sortedSet = stream.into(new TreeSet<>(Comparator.reverseOrder()));
CopyOnWriteArrayList<String> list = stream.into(new CopyOnWriteArrayList<>());


There may be better default implementations, but I just wanted something here for illustrative purposes.

Thoughts?

Don

From donraab at gmail.com  Tue Apr 27 05:35:59 2021
From: donraab at gmail.com (Donald Raab)
Date: Tue, 27 Apr 2021 01:35:59 -0400
Subject: New convenience methods on Stream
In-Reply-To: <B78DB84E-2AF4-4EDB-ABCD-6C9843258BD6@gmail.com>
References: <B78DB84E-2AF4-4EDB-ABCD-6C9843258BD6@gmail.com>
Message-ID: <C9C81B33-BB99-4903-B080-6A1A86DD27CD@gmail.com>

I realized after sending that option 2 can be made more abstract:

default <R extends Iterable<T>> R to(Function<T[], R> function)
{
    return function.apply((T[]) this.toArray());
}

> 
> 2. Pass the result of toArray directly into a function that can then return a Collection. This should work with Set.of, List.of and any 3rd party collections which take arrays.
> 
> default <R extends Collection<T>> R to(Function<T[], R> function)
> {
>    return function.apply((T[]) this.toArray());
> }
> 
> Usage Examples:
> 
> Set<String> set = stream.to(Set::of);
> List<String> list = stream.to(List::of);
> List<String> arrayList = stream.to(Arrays::asList);
> 


From kvn at openjdk.java.net  Tue Apr 27 06:26:53 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 06:26:53 GMT
Subject: Integrated: 8264806: Remove the experimental JIT compiler
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <Ag2soyoHyod50x0jbW9wCqjeeiPoY5exNLGilCeUBOw=.915beb49-19c7-4091-9476-c069bffc8123@github.com>

On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> 
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

This pull request has now been integrated.

Changeset: 4785e112
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4785e112
Stats:     441532 lines in 2884 files changed: 0 ins; 441518 del; 14 mod

8264806: Remove the experimental JIT compiler

Reviewed-by: iignatyev, erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/3421

From sverre.moe at gmail.com  Tue Apr 27 06:42:16 2021
From: sverre.moe at gmail.com (Sverre Moe)
Date: Tue, 27 Apr 2021 08:42:16 +0200
Subject: jpackage regression on Windows
In-Reply-To: <CALAJ+5BxfCZ3wHzhxyQ8J02yN9e+k_R7uPecdhna5mmRk1oPVQ@mail.gmail.com>
References: <CALAJ+5BxfCZ3wHzhxyQ8J02yN9e+k_R7uPecdhna5mmRk1oPVQ@mail.gmail.com>
Message-ID: <CALAJ+5BH+F0pnEw-XRbWg_mHRqq8VxKNKq3T6XgEF9g9mNdq5A@mail.gmail.com>

Seems it was filed, and has already been fixed in JDK17
https://bugs.openjdk.java.net/browse/JDK-8261845

Strange, I searched, but could not find any issues when I filed my bug
report.

/Sverre


man. 26. apr. 2021 kl. 19:19 skrev Sverre Moe <sverre.moe at gmail.com>:

> There was a regression introduced in JDK 15 of jpackage tool on Windows.
> The file permission of the built EXE has changed. The file is now ReadOnly.
> Both EXE and MSI was ReadWrite, now
> EXE is Read-Only while MSI is still Read-Write
>
> The EXE can no longer be signed because it cannot be modified.
>
> I just filed a bug report on this
> internal review ID : 9070046
>
> /Sverre
>

From sgehwolf at openjdk.java.net  Tue Apr 27 08:49:35 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 27 Apr 2021 08:49:35 GMT
Subject: RFR: 8203359: Container level resources events [v9]
In-Reply-To: <S0fGjdjgqlYMST-XYxOtBIzzEFmsnTuqWxqoVw6hWEc=.0614abbf-51ad-4080-87f1-a6d847ada645@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <jGPUMTr4BuKk_7hI067HqZ_x8DnTIqq_qUw9wVbEz0U=.e4f82b2e-8280-4162-80ff-5c15e0d50538@github.com>
 <X8hGPKIwYg0bcYkktxwO5yZ0KNlW4ZY2mNLrFdKVKCo=.4436ef8a-8c00-4dda-ac68-1416a8ea970f@github.com>
 <S0fGjdjgqlYMST-XYxOtBIzzEFmsnTuqWxqoVw6hWEc=.0614abbf-51ad-4080-87f1-a6d847ada645@github.com>
Message-ID: <YGOyucAMpUW2e1wCpXnwBnVyfY93rvLQvWQeNzFo1i0=.a4cd1d88-3344-45c0-a061-8c7a7b21e08e@github.com>

On Thu, 22 Apr 2021 15:08:59 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> I wonder if something similar to below could be added to jdk.jfr.internal.Utils:
>> 
>>     private static Metrics[] metrics;
>>     public static Metrics getMetrics() {
>>         if (metrics == null) {
>>             metrics = new Metrics[] { Metrics.systemMetrics() };
>>         }
>>         return metrics[0];
>>     }
>> 
>>     public static boolean shouldSkipBytecode(String eventName, Class<?> superClass) {
>>         if (superClass != AbstractJDKEvent.class) {
>>             return false;
>>         }
>>         if (!eventName.startsWith("jdk.Container")) {
>>             return false;
>>         }
>>         return getMetrics() == null;
>>     }
>> 
>> Then we could add checks to jdk.jfr.internal.JVMUpcalls::bytesForEagerInstrumentation(...)
>> 
>>     eventName = ei.getEventName();
>>     if (Utils.shouldSkipBytecode(eventName, superClass))) {
>>         return oldBytes;
>>     }
>> 
>> and jdk.jfr.internal.JVMUpcalls:onRetransform(...)
>> 
>>     if (jdk.internal.event.Event.class.isAssignableFrom(clazz) && !Modifier.isAbstract(clazz.getModifiers())) {
>>         if (Utils.shouldSkipBytecode(clazz.getName(), clazz.getSuperclass())) {
>>             return oldBytes;
>>         }
>> 
>> This way we would not pay for generating bytecode for events in a non-container environment. 
>> 
>> Not sure if it works, but could perhaps make startup faster? We would still pay for generating the event handlers during registration, but it's much trickier to avoid since we need to store the event type somewhere.
>
> @egahlin Sounds good.
> Any particular reason you are using `Metrics[]` array?

@jbachorik Has this been tested on cgroups v1 and cgroups v2 Linux systems?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From github.com+10835776+stsypanov at openjdk.java.net  Tue Apr 27 09:20:37 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 27 Apr 2021 09:20:37 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <75a6bf81-06d7-45fc-3c0d-42e436c9d058@gmail.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
 <75a6bf81-06d7-45fc-3c0d-42e436c9d058@gmail.com>
Message-ID: <U_HThSfhrEPWdNOnqDRy57brAp-HsEIADyKvOsV45Xo=.47f9e6f6-cb5e-4dfe-a109-421b0b5327b1@github.com>

On Mon, 26 Apr 2021 14:12:01 GMT, Peter Levart <peter.levart at gmail.com> wrote:

> Also be careful not to return a string which
is not interned (which would happen if you did what you are proposing
above).

Ok, I'm probably missing something, but when we move `String.intern()` call to `this.packageName = pn.intern();` there is no case when non-interned String is returned: there's only one assignment to the field `packageName` and the value assigned is always interned, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3571

From peter.levart at gmail.com  Tue Apr 27 09:25:30 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 27 Apr 2021 11:25:30 +0200
Subject: ReversibleCollection proposal
In-Reply-To: <6f0d7d03-ec96-b204-7252-efe413792073@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
 <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
 <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>
 <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>
 <85906d24-f9c8-1b6f-77c0-b8cf5ca48457@gmail.com>
 <6f0d7d03-ec96-b204-7252-efe413792073@oracle.com>
Message-ID: <b112dcad-3839-fdfd-437e-5d7287f0063c@gmail.com>

On 4/27/21 5:50 AM, Stuart Marks wrote:

>
>
> On 4/25/21 11:09 AM, Peter Levart wrote:
>> When making this proposition, I was only thinking of how to enable 
>> new yet-nonexistent operations on collections that have order / are 
>> reversible and that the code calling these methods would already 
>> knows that it is dealing with ordered / reversible collections. I 
>> wasn't thinking about how to prevent mistakes like passing unordered 
>> collection to code that expects ordered / reversible collection. This 
>> can only be solved in two ways. The way immutability of collections 
>> is solved (throw exception in runtime when requesting operation that 
>> makes no sense in unordered collection) or by introducing new type - 
>> ReversibleCollection that solves this in compile time. So I take back 
>> my vote for suggestion to introduce methods like getFirst(), 
>> removeFirst() that would return arbitrary element. There's still a 
>> possibility for those methods to throw at runtime though. But I don't 
>> know whether this would be so nicely accepted as immutability was. WDYT?
>
> Consider some collection implementation X that has some semantics and 
> a suite of operations that support those semantics. An implementation 
> can throw UnsupportedOperationException if for some reason that 
> operation doesn't make sense for the implementation, but fundamentally 
> that implementation still has "X-ness".
>
> Look at Arrays.asList for example. It's backed by an array, so add and 
> remove operations aren't supported. But it's still fundamentally a 
> List in that it has N elements, is ordered, the elements are numbered 
> from 0 to N-1, sublists can be obtained between two arbitrary indexes, 
> its ListIterator supports iteration in both directions, it has a clear 
> and useful definition for equals() and hashCode(), etc.
>
> Similarly, an unmodifiable List is still a List.
>
> Now consider adding {add,get,remove}{First,Last} methods to the 
> Collection interface. Collection doesn't have any semantics for these 
> methods itself, so we're hoping that there is some sensible mapping 
> from these methods to appropriate operations on Collections 
> implementations or subinterfaces.
>
> ?* Presumably for unordered collections like HashSet, all of these 
> methods would be left to throw UOE.
>
> ?* A queue has a head and a tail, so perhaps these are mapped to first 
> and last, respectively, and Queue would support addLast and 
> removeFirst but not addFirst and removeLast. But that wouldn't work 
> for PriorityQueue.
>
> ?* A stack has a "top": the most recently pushed element. Does the 
> stack top correspond to the first or the last? It could be either -- 
> in fact, in the JDK, for Stack the top is the last element but for 
> Deque the top is the first element.
>
> ?* For some other ordered collection, who knows what a reasonable 
> mapping would be?
>
> This approach feels backwards to me. Instead of starting from an 
> abstraction that has strong semantics and then applying all (or at 
> least most) of the applicable methods, we're starting with a suite of 
> methods and looking around for relationships to a variety of 
> abstractions that might or might not have much in common. That seems 
> like a recipe for a bad API to me.
>
> s'marks


Right, I'm persuaded. Now if only the problems of transition to the 
usage of new type that Remi is worried about were mild enough. Source 
(in)compatibility is not that important if workarounds exist that are 
also backwards source compatible so that the same codebase can be 
compiled with different JDKs. Binary compatibility is important. And I 
guess there is a variant of the proposal that includes 
ReversibleCollection and ReversibleSet and is binary compatible.

Now just some of my thoughts about the proposal:

- SortedSet.addFirst/.addLast - I think an operation that would be used 
in situations like: "I know this element should always be greater than 
any existing element in the set and I will push it to the end which 
should also verify my assumption" is a perfectly valid operation. So 
those methods throwing IllegalStateException in case the invariant can't 
be kept seem perfectly fine to me.

- ReversibleCollection.addFirst/.addLast are specified to have void 
return type. This works for List and Deque which always add element and 
so have no information to return. OTOH Collection.add is specified to 
return boolean to indicate whether collection was modified or not, but 
Set modifies the specification of that method a bit to be: return false 
or true when Set already contained an element equal to the parameter or 
not. So ReversibleCollection.addFirst/.addLast could play the same 
trick. for List(s) and Deque(s) it would always return true, but for 
ReversibleSet(s) it would return true only if the set didn't contain an 
element equal to the parameter, so re-positioning of equal element would 
return false although the collection was modified as a result.

- Perhaps unrelated to this proposal, but just for completeness, 
existing Collection interface could be extended with methods like: 
getAny() and removeAny().


Regards, Peter



From sgehwolf at openjdk.java.net  Tue Apr 27 09:45:46 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 27 Apr 2021 09:45:46 GMT
Subject: RFR: 8203359: Container level resources events [v10]
In-Reply-To: <r5gSFDRqdBOmjl3bmVNoHb1klfdKpd5tlYWEXOW8GuA=.026f4b58-9beb-4737-aba9-eed37f264501@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <r5gSFDRqdBOmjl3bmVNoHb1klfdKpd5tlYWEXOW8GuA=.026f4b58-9beb-4737-aba9-eed37f264501@github.com>
Message-ID: <XQdCvpWzyXyZvqbA8Z-B8L7SuSCEJFyVtZRAfTAw1Xs=.ac6f9c59-9a68-4a2c-a729-797ca4229b66@github.com>

On Thu, 22 Apr 2021 16:00:32 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
>> 
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
>> * CPU related metrics
>> * Memory related metrics
>> * I/O related metrics
>> 
>> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
>> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).
>
> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Prevent event container bytecode generation if no container present
>  - Fix event metadata
>  - Roll back conditional registration of container events
>  - Remove container events flag
>  - Remove trailing spaces
>  - Doh
>  - Report container type and register events conditionally
>  - Remove unused test files
>  - Initial test support for JFR container events
>  - Update the JFR control files
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/23dc6e83...04c3f092

@jbachorik The test needs fixing.

test/hotspot/jtreg/containers/docker/TestJFREvents.java line 147:

> 145:                                       .addClassOptions(eventName, "period=endChunk"))
> 146:             .shouldHaveExitValue(0)
> 147:             .shouldContain(memoryPressureFld)

This test fails for me on cgroupv1 with:


----------System.err:(42/1407)----------
 stdout: [===== EventType: jdk.ContainerMemoryUsage
startTime = 946400166
duration = 0
eventThread = {
  osName = "main"
  osThreadId = 6
  javaName = "main"
  javaThreadId = 1
  group = {
    parent = {
      parent = N/A
      name = "system"
    }
    name = "main"
  }
}

stackTrace = null
memoryFailCount = 0
memoryUsage = 57786368
swapMemoryUsage = 57782272
];
 stderr: []
 exitValue = 0

java.lang.RuntimeException: 'memoryPressure' missing from stdout/stderr

        at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:206)
        at TestJFREvents.testMemoryUsage(TestJFREvents.java:147)
        at TestJFREvents.main(TestJFREvents.java:77)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:831)

JavaTest Message: Test threw exception: java.lang.RuntimeException: 'memoryPressure' missing from stdout/stderr

JavaTest Message: shutting down test


I think `memoryPressure` got removed from the code and, thus, should get removed from the test.

-------------

Changes requested by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3126

From alanb at openjdk.java.net  Tue Apr 27 09:48:34 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 27 Apr 2021 09:48:34 GMT
Subject: RFR: 8266014: Regression brought by optimization done with
 JDK-4926314
In-Reply-To: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>
References: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>
Message-ID: <rEuDx97EcZ16QSx2z_IYeR5ZUjo8hbjMKtDFfewMogE=.7d5f6aa9-d5c2-4735-be9b-c73eda3e9726@github.com>

On Tue, 27 Apr 2021 01:26:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this request to correct a minor problem with the optimization added for JDK-4926314. The change is to attempt to read the number of elements remaining in the target buffer unless that number is non-positive in which case read zero. The test addition fails without and passes with the implementation change.

Marked as reviewed by alanb (Reviewer).

test/jdk/java/io/Reader/ReadCharBuffer.java line 107:

> 105:     public void readZeroLength() {
> 106:         BufferedReader r =
> 107:             new BufferedReader(new CharArrayReader(new char[]{1, 2, 3}));

Spurious line break here but otherwise is good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3708

From jlaskey at openjdk.java.net  Tue Apr 27 10:50:51 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 27 Apr 2021 10:50:51 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v7]
In-Reply-To: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
Message-ID: <f7Sxm4zDo9zwsuqIyQVU6HonLDB3vPNppAs6vNkWGJo=.194ecc5f-f8fa-435d-83e5-e0d82891211d@github.com>

> Move makeXXXSpilterator from public (@hidden) to protected. No API ch

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary constructor.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3469/files
  - new: https://git.openjdk.java.net/jdk/pull/3469/files/3381f008..482ea0ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469&range=05-06

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3469.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469

PR: https://git.openjdk.java.net/jdk/pull/3469

From jlaskey at openjdk.java.net  Tue Apr 27 10:50:59 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 27 Apr 2021 10:50:59 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v6]
In-Reply-To: <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <F2tqDWpUm9xI32JtEdbAAU6seXhR7qJnTRZOvrmfrbk=.f6f03b72-f0b0-4879-9d32-4dc001fad971@github.com>
Message-ID: <KHYjzMuT4eHMQWaIK1X9Aa7ofZAh61IfiTQsT42U2PM=.28961386-6905-499d-895d-c69276bfb956@github.com>

On Wed, 21 Apr 2021 13:13:16 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8265137
>  - Remove @hidden
>  - Correct the hierarchy of Random
>  - Remove extraneous references to makeXXXSpliterator
>  - Move makeXXXSpliterator methods to RandomSupport
>  - change static final from 'proxy' to 'PROXY'
>  - Make makeXXXSpliterator final
>  - Move makeXXXSpilterator from public (@hidden) to protected. No API change.

Please mark the CSR https://bugs.openjdk.java.net/browse/JDK-8265221 as reviewed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From jlaskey at openjdk.java.net  Tue Apr 27 10:50:59 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 27 Apr 2021 10:50:59 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v4]
In-Reply-To: <8WMeTb7egLgmwoimo7VTgEYJhUrOo4oJHawc8lH7nmA=.cd93c13b-140b-429e-8388-d352ee3510fb@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <RWHOu929wlgVn5zDszU0aWj551fI6s_NpjP7Svc-2VQ=.200daabd-046d-43a0-a402-a08f0a87683e@github.com>
 <IeR3O6gCBBZJzm5I6ISgSnQp_JqEC27Uf0IcAlPl4qQ=.d7169c52-c9ac-4f43-ab79-dcbe6c62de95@github.com>
 <8WMeTb7egLgmwoimo7VTgEYJhUrOo4oJHawc8lH7nmA=.cd93c13b-140b-429e-8388-d352ee3510fb@github.com>
Message-ID: <Pq9ohbk0NDO_5r9zPCIY4R7tJoyg6bPOImlHStFwC9c=.72b047ea-ff66-40f8-b175-780f4ebe6a27@github.com>

On Thu, 15 Apr 2021 12:17:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1656:
>> 
>>> 1654:         // Methods required by class AbstractSpliteratorGenerator
>>> 1655: 
>>> 1656:         protected Spliterator.OfInt makeIntsSpliterator(long index, long fence, int origin, int bound) {
>> 
>> Are those still needed? It looks like this was not detected because of the missing `@Override`. Those could also be private or removed at all? The code is also handled by the above private versions (`this` is not instanceof `ThreadLocalRandom`).
>
> True that. There are also some mentions in the comments.

Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From jlaskey at openjdk.java.net  Tue Apr 27 10:50:59 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 27 Apr 2021 10:50:59 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v4]
In-Reply-To: <Pq9ohbk0NDO_5r9zPCIY4R7tJoyg6bPOImlHStFwC9c=.72b047ea-ff66-40f8-b175-780f4ebe6a27@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <RWHOu929wlgVn5zDszU0aWj551fI6s_NpjP7Svc-2VQ=.200daabd-046d-43a0-a402-a08f0a87683e@github.com>
 <IeR3O6gCBBZJzm5I6ISgSnQp_JqEC27Uf0IcAlPl4qQ=.d7169c52-c9ac-4f43-ab79-dcbe6c62de95@github.com>
 <8WMeTb7egLgmwoimo7VTgEYJhUrOo4oJHawc8lH7nmA=.cd93c13b-140b-429e-8388-d352ee3510fb@github.com>
 <Pq9ohbk0NDO_5r9zPCIY4R7tJoyg6bPOImlHStFwC9c=.72b047ea-ff66-40f8-b175-780f4ebe6a27@github.com>
Message-ID: <ssE8hExU6VssZ7sVJVoI1y4nzXkaeyJ71riR5AwHkok=.a93b7a28-69a5-4be5-a0ef-199dfe7ff5ad@github.com>

On Tue, 27 Apr 2021 10:44:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> True that. There are also some mentions in the comments.
>
> Thank you.

Please mark the CSR as reviewed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From sgehwolf at openjdk.java.net  Tue Apr 27 12:59:58 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 27 Apr 2021 12:59:58 GMT
Subject: RFR: 8203359: Container level resources events [v9]
In-Reply-To: <S0fGjdjgqlYMST-XYxOtBIzzEFmsnTuqWxqoVw6hWEc=.0614abbf-51ad-4080-87f1-a6d847ada645@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <jGPUMTr4BuKk_7hI067HqZ_x8DnTIqq_qUw9wVbEz0U=.e4f82b2e-8280-4162-80ff-5c15e0d50538@github.com>
 <X8hGPKIwYg0bcYkktxwO5yZ0KNlW4ZY2mNLrFdKVKCo=.4436ef8a-8c00-4dda-ac68-1416a8ea970f@github.com>
 <S0fGjdjgqlYMST-XYxOtBIzzEFmsnTuqWxqoVw6hWEc=.0614abbf-51ad-4080-87f1-a6d847ada645@github.com>
Message-ID: <TYOwgG2JSw-Jh0JHNSEi8-uLTgO58a-lFfZ-_p-L6LA=.60d363c4-eac9-4fcd-8ea9-e68498368d04@github.com>

On Thu, 22 Apr 2021 15:08:59 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> I wonder if something similar to below could be added to jdk.jfr.internal.Utils:
>> 
>>     private static Metrics[] metrics;
>>     public static Metrics getMetrics() {
>>         if (metrics == null) {
>>             metrics = new Metrics[] { Metrics.systemMetrics() };
>>         }
>>         return metrics[0];
>>     }
>> 
>>     public static boolean shouldSkipBytecode(String eventName, Class<?> superClass) {
>>         if (superClass != AbstractJDKEvent.class) {
>>             return false;
>>         }
>>         if (!eventName.startsWith("jdk.Container")) {
>>             return false;
>>         }
>>         return getMetrics() == null;
>>     }
>> 
>> Then we could add checks to jdk.jfr.internal.JVMUpcalls::bytesForEagerInstrumentation(...)
>> 
>>     eventName = ei.getEventName();
>>     if (Utils.shouldSkipBytecode(eventName, superClass))) {
>>         return oldBytes;
>>     }
>> 
>> and jdk.jfr.internal.JVMUpcalls:onRetransform(...)
>> 
>>     if (jdk.internal.event.Event.class.isAssignableFrom(clazz) && !Modifier.isAbstract(clazz.getModifiers())) {
>>         if (Utils.shouldSkipBytecode(clazz.getName(), clazz.getSuperclass())) {
>>             return oldBytes;
>>         }
>> 
>> This way we would not pay for generating bytecode for events in a non-container environment. 
>> 
>> Not sure if it works, but could perhaps make startup faster? We would still pay for generating the event handlers during registration, but it's much trickier to avoid since we need to store the event type somewhere.
>
> @egahlin Sounds good.
> Any particular reason you are using `Metrics[]` array?

> @jbachorik Has this been tested on cgroups v1 and cgroups v2 Linux systems?

OK. I've tested the latest iteration on both (cgroup v2 and cgroup v1). Testing looks good other than the `memoryPressure` issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From plevart at openjdk.java.net  Tue Apr 27 13:53:40 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 27 Apr 2021 13:53:40 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <U_HThSfhrEPWdNOnqDRy57brAp-HsEIADyKvOsV45Xo=.47f9e6f6-cb5e-4dfe-a109-421b0b5327b1@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
 <75a6bf81-06d7-45fc-3c0d-42e436c9d058@gmail.com>
 <U_HThSfhrEPWdNOnqDRy57brAp-HsEIADyKvOsV45Xo=.47f9e6f6-cb5e-4dfe-a109-421b0b5327b1@github.com>
Message-ID: <_SF1gQB3rQSwslNQhfQZ1K81vsce0D2WpCi350e1gww=.6db0ed73-6a22-47ab-ba7a-4ca96ef927ca@github.com>

On Tue, 27 Apr 2021 09:17:43 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> > Also be careful not to return a string which
> > is not interned (which would happen if you did what you are proposing
> > above).
> 
> Ok, I'm probably missing something, but when we move `String.intern()` call to `this.packageName = pn.intern();` there is no case when non-interned String is returned: there's only one assignment to the field `packageName` and the value assigned is always interned, right?

I see:

    return pn;
    
...in code. The local var is returned. As said, string constants are already interned. Calling .intern() on them will mean unnecessary overhead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3571

From henri.tremblay at gmail.com  Tue Apr 27 15:08:39 2021
From: henri.tremblay at gmail.com (Henri Tremblay)
Date: Tue, 27 Apr 2021 11:08:39 -0400
Subject: ReversibleCollection proposal
Message-ID: <CADZL2=s1jAuP=DnQ_BdG_4jeZ5HL-Z8M_Wzp73rnwEYbLSTyoA@mail.gmail.com>

Hi,

Not sure if this will end up in the right mailing list thread but let's see.

I just read quickly the proposal and it made me think about another common
issue. I wonder if we could tackle it as well.

I will call it the "find the first element when there is only one" problem.

It happens on unordered collections like a HashSet. It forces to do

Set<String> s = new HashSet<>();

if (s.size() == 1) {
    return s.iterator().next();

    // or

    return s.stream().findFirst().get();
}

Which is a lot of ugliness and object instantiation just to get the first
element.

I would be nice to have a public T findFirst() directly on Iterable<T>.
With a default implementation returning iterator().next(). Things like
ArrayList will want to override will return elementData[0]. It would return
null when the list is empty. Or NoSuchElementException.

It needs to be polished of course but will that be acceptable?

Thanks,
Henri

From alanb at openjdk.java.net  Tue Apr 27 15:38:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 27 Apr 2021 15:38:39 GMT
Subject: RFR: 8260560: convert jdeps and jdeprscan tools to use
 Stream.toList()
In-Reply-To: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
References: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
Message-ID: <5XiU_ITIOIzVoHJhR1SGCZVjVqIy2w_imGO1-ZtSLLU=.207a54f9-95bd-4f50-941a-680e04dde582@github.com>

On Tue, 27 Apr 2021 00:20:49 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8260560: convert jdeps and jdeprscan tools to use Stream.toList()

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3705

From dev at anthonyv.be  Tue Apr 27 16:17:14 2021
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Tue, 27 Apr 2021 18:17:14 +0200
Subject: =?utf-8?q?Re=3A?= ReversibleCollection proposal
In-Reply-To: <b112dcad-3839-fdfd-437e-5d7287f0063c@gmail.com>
Message-ID: <38af-60883900-4c5-3a732100@161619996>

On Tuesday, April 27, 2021 11:25 CEST, Peter Levart <peter.levart at gmail.com> wrote:  
> Now just some of my thoughts about the proposal:
> 
> - SortedSet.addFirst/.addLast - I think an operation that would be used 
> in situations like: "I know this element should always be greater than 
> any existing element in the set and I will push it to the end which 
> should also verify my assumption" is a perfectly valid operation. So 
> those methods throwing IllegalStateException in case the invariant can't 
> be kept seem perfectly fine to me.

This was raised before and addressed by Stuart in [0]:
"An alternative as you suggest might be that SortedSet::addFirst/addLast could throw 
something like IllegalStateException if the element is wrongly positioned. 
(Deque::addFirst/addLast will throw ISE if the addition would exceed a capacity 
restriction.) This seems error-prone, though, and it's easier to understand and 
specify that these methods simply throw UOE unconditionally. If there's a good use 
case for the alternative I'd be interested in hearing it though."

> - ReversibleCollection.addFirst/.addLast are specified to have void 
> return type. This works for List and Deque which always add element and 
> so have no information to return. OTOH Collection.add is specified to 
> return boolean to indicate whether collection was modified or not, but 
> Set modifies the specification of that method a bit to be: return false 
> or true when Set already contained an element equal to the parameter or 
> not. So ReversibleCollection.addFirst/.addLast could play the same 
> trick. for List(s) and Deque(s) it would always return true, but for 
> ReversibleSet(s) it would return true only if the set didn't contain an 
> element equal to the parameter, so re-positioning of equal element would 
> return false although the collection was modified as a result.

If addFirst/addLast were to return boolean, Deque would no longer compile due to its existing methods being incompatible with the new ones.

> Regards, Peter

Kind regards, Anthony

[0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076518.html


From mchung at openjdk.java.net  Tue Apr 27 16:31:37 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 27 Apr 2021 16:31:37 GMT
Subject: RFR: 8260560: convert jdeps and jdeprscan tools to use
 Stream.toList()
In-Reply-To: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
References: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
Message-ID: <UUSrFhgtCZWs52aVLsfxyh9LG3NWLGUYNcONwlv3jNU=.7b51180a-3ec1-410d-a73e-954e54288f8b@github.com>

On Tue, 27 Apr 2021 00:20:49 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8260560: convert jdeps and jdeprscan tools to use Stream.toList()

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3705

From iris at openjdk.java.net  Tue Apr 27 17:12:35 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 27 Apr 2021 17:12:35 GMT
Subject: RFR: 8260560: convert jdeps and jdeprscan tools to use
 Stream.toList()
In-Reply-To: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
References: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
Message-ID: <xPmdTCH3i93vfRmqO2TkmJu-pMQiNY4pu9aS6SRmbKY=.7376f002-4e3e-4db1-9df5-15b5be23de96@github.com>

On Tue, 27 Apr 2021 00:20:49 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8260560: convert jdeps and jdeprscan tools to use Stream.toList()

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3705

From mcimadamore at openjdk.java.net  Tue Apr 27 18:01:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 27 Apr 2021 18:01:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator)
Message-ID: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>

This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.

[1] - https://openjdk.java.net/jeps/412

-------------

Commit messages:
 - Add linker test excludes for x86 and other platforms which do not support `CLinker`
 - Integrate latest API tweaks
 - Fix x86 build
 - Fix `TestLinkToNativeRBP`
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/3699/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264774
  Stats: 14083 lines in 213 files changed: 8502 ins; 3605 del; 1976 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Tue Apr 27 18:01:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 27 Apr 2021 18:01:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator)
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <Bgm0ejmxX0MriQSdG102BRTiOZDpMCTN2Ikzplhm3-M=.caca5dee-8f47-4863-ba0b-d077ef5b5025@github.com>

On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Here we list the main changes introduced in this PR. As usual, a big thank to all who helped along the way: @ChrisHegarty, @iwanowww, @JornVernee, @PaulSandoz and @sundararajana.

### Managing memory segments: `ResourceScope`

This PR introduces a new abstraction (first discussed [here](https://inside.java/2021/01/25/memory-access-pulling-all-the-threads/)), namely `ResourceScope` which is used to manage the lifecycle of resources associated with off-heap memory (such as `MemorySegment`, `VaList`, etc). This is probably the biggest change in the API, as `MemorySegment` is no longer `AutoCloseable`: it instead features a *scope accessor* which can be used to access the memory segment's `ResourceScope`; the `ResourceScope` is the new  `AutoCloseable`. In other words, code like this:


try (MemorySegment segment = MemorySegment.allocateNative(100)) {
   ...
}   


Now becomes like this:


try (ResourceScope scope = ResourceScope.ofConfinedScope()) {
   MemorySegment segment = MemorySegment.allocateNative(100, scope);
   ...
}   


While simple cases where only one segment is allocated become a little more verbose, this new API idiom obviously scales much better when multiple segments are created with the same lifecycle. Another important fact, which is captured by the name of the `ResourceScope` factory in the above snippet, is that segments no longer feature dynamic ownership changes. These were cool, but ultimately too expensive to support in the shared case. Instead, the API now requires clients to make a choice upfront (confined, shared or *implicit* - where the latter means GC-managed, like direct buffers).

Implementation-wise, `ResourceScope` is implemented by a bunch of internal classes: `ResourceScopeImpl`, `ConfinedScope` and `SharedScope`. A resource scope impl has a so called *resource list* which can be also shared or confined. This is where cleanup actions are added; the resource list can be attached to a `Cleaner` to get implicit deallocation. There is a new test `TestResourceScope` to stress test the behavior of resource scopes, as well as a couple of microbenchmarks to assess the cost of creating/closing scopes (`ResourceScopeClose`) and acquiring/releasing them (`BulkMismatchAcquire`).

### IO operation on shared buffer views

In the previous iteration of the Memory Access API we have introduced the concept of *shared* segments. Shared segments are as easy to use as confined ones, and they are as fast. One problem with shared segments was that it wasn't clear how to support IO operations on byte buffers derived from such segments: since the segment memory could be released at any time, there was simply no way to guarantee that a shared segment could not be closed in the middle of a (possibly async) IO operation.

In this iteration, shared segments are just segments backed by a *shared resource scope*. The new API introduces way to manage the new complexity, in the form of two methods `ResourceScope::acquire` and `ResourceScope::release`, respectively, which can be used to *acquire* a resource scope. When a resource scope is in the acquired state, it cannot be closed (you can think of it as some slightly better and asymmetric form of an atomic reference counter).

This means we are now finally in a position to add support for IO operations on all byte buffers, including those derived from shared segments. A big thank to @ChrisHegarty who lead the effort here. More info on this work are included in his [writeup](https://inside.java/2021/04/21/fma-and-nio-channels/).

Most of the implementation for this feature occurs in the internal NIO packages; a new method on `Buffer` has been added to facilitate acquiring from NIO code - most of the logic associated with acquiring is in the `IOUtil` class. @ChrisHegarty has added many good tests for scoped IO operations under the `foreign/channels` folder, to check for all possible buffer/scope flavors.

### Allocating at speed: `SegmentAllocator`

Another abstraction introduced in this JEP is that of `SegmentAllocator`. A segment allocator is a functional interface which can be used to tell other APIs (and, crucially, the `CLinker` API) how segments should be allocated, if the need arise. For instance, think about some code which turns a Java string into a C string. Such code will invariably:

1. allocate a memory segment off heap
2. bulk copy (where possible) the content of the Java string into the off-heap segment
3. add a NULL terminator

So, in (1) such string conversion routine need to allocate a new off-heap segment; how is that done? Is that a call to malloc? Or something else? In the previous iteration of the Foreign Linker API, the method `CLinker::toCString` had two overloads: a simple version, only taking a Java string parameter; and a more advanced version taking a `NativeScope`. A `NativeScope` was, at its core, a custom segment allocator - but the allocation scheme was fixed in `NativeScope` as that class always acted as an arena-style allocator.

`SegmentAllocator` is like `NativeScope` in spirit, in that it helps programs allocating segments - but it does so in a more general way than `NativeScope`, since a `SegmentAllocator` is not tied to any specific allocation strategy: in fact the strategy is left there to be defined by the user. As before, `SegmentAllocator` does provide some common factories, e.g. to create an arena allocator similar to `NativeScope` - but the `CLinker` API is now free to work with _any_ implementations of the `SegmentAllocator` interface. This generalization is crucial, given that, when operating with off-heap memory, allocation performance is often the bottleneck.

Not only is `SegmentAllocator` accepted by all methods in the `CLinker` API which need to allocate memory: even the behavior of downcall method handle can now be affected by segment allocators: when linking a native function which returns a struct by value, the `CLinker` API will in fact need to dynamically allocate a segment to hold the result. In such cases, the method handle generated by `CLinker` will now accept an additional *prefix* parameter of type `SegmentAllocator` which tells `CLinker` *how* should memory be allocated for the result value. For instance, now clients can tell `CLinker` to return structs by value in *heap* segments, by using a `SegmentAllocator` which allocates memory on the heap; this might be useful if the segment is quickly discarded after use.

There's not much implementation for `SegmentAllocator` as most of it is defined in terms of `default` methods in the interface itself. However we do have implementation classes for the arena allocation scheme (`ArenaAllocator.java`). We support confined allocation and shared allocation. The shared allocation achieves lock-free by using a `ThreadLocal` of confined arena allocators. `TestSegmentAllocators` is the test which checks most of the arena allocation flavors.

### `MemoryAddress` as scoped entities

A natural consequence of introducing the `ResourceScope` abstraction is that now not only `MemorySegment` are associated with a scope, but even instances of `MemoryAddress` can be. This means extra safety, because passing addresses which are associated with a closed scope to a native function will issue an exception. As before, it is possible to have memory addresses which the runtime knows nothing about (those returned by native calls, or those created via `MemoryAddress::ofLong`); these addresses are simply associated with the so called *global scope* - meaning that they are not actively managed by the user and are considered to be "always alive" by the runtime (as before).

Implementation-wise, you will now see that `MemoryAddressImpl` is no longer a pair of `Object`/`long`. It is now a pair of `MemorySegment`/`long`. The `MemorySegment`, if present, tells us which segment this address has been obtained from (and hence which scope is associated with the address). If null, if means that the address has no segment, and therefore is associated with the global scope. The `long` part acts as an offset into the segment (if segment is non-null), or as an absolute address. A new test `SafeFunctionAccessTest` attempts to call native functions with (closed) scoped addresses to see if exceptions are thrown.

### *Virtual* downcall method handles

There are cases where the address of a downcall handle cannot be specified when a downcall method handle is linked, but can only be known subsequently, by doing more native calls. To better support these use cases, `CLinker` now provides a factory for downcall method handles which does *not* require any function entry point. Instead, such entry point will be provided *dynamically*, via an additional prefix parameter (of type `MemoryAddress`). Many thanks to @JornVernee who implemented this improvement.

The implementation changes for this range from tweaking the Java ABI support (to make sure that the prefix argument is handled as expected), to low-level hotspot changes to parameterize the generated compiled stub to use the address (dynamic) parameter. Note that regular downcall method handles (the ones that are bound to an address) are now simply obtained by getting a "virtual" method handle, and inserting a `MemoryAddress` coordinate in the first argument position. `TestVirtualCalls` has been written explicitly to test dynamic passing of address parameters but, in reality, all existing downcall tests are stressing the new implementation logic (since, as said before, the old logic is expressed as an adaptation of the new virtual method handles). The benchmark we used to test downcall performances `CallOverhead` has now been split into two: `CallOverheadConstant` vs. `CallOverheadVirtual`.

### Optimized upcall support

The previous iteration of the Foreign Linker API supported intrinsification of downcall handles, which allows calls to downcall method handles to perform as fast as a regular JNI call. The dual case, calling Java code from native code (upcalls) was left unoptimized. In this iteration, @JornVernee has added intrinsics support for upcalls as well as downcalls, based on some prior work from @iwanowww. As for downcalls, a lot of the adaptation now happens in Java code, before we jump into the target method handle. As for the code which calls such target handle, changes have been made so that the native code can jump to the optimized entry point (if one exists) for such method handle more directly. The performance improvements with this new approach are rather nice, with `CLinker` upcalls being 3x-4x faster compared with regular upcalls via JNI.

Again, here we have changes in the guts of the Java ABI support, as we needed to adjust the method handle specialization logic to be able to work in two directions (both from Java to native and from native to Java). On the Hotspot front, the optimization changes are in `universalUpcallHandler_x86_64.cpp`.

### Accessing restricted methods

It is still the case that some of the methods in the API are "restricted" and access to these methods is disabled by default. In previous iterations, access to such methods was granted by setting a JDK read-only runtime property: `-Dforeign.restricted=permit`. In this iteration we have refined the story for accessing restricted methods (thanks @sundararajana ), by introducing a new experimental command line option in the Java launcher, namely `--enable-native-access=<module list>`. This options accepts a list of modules (separated by commas), where a module name can also be `ALL-UNNAMED` (for the unnamed module). Adding this command line flag to the launcher has the effect of allowing access to restricted methods to a given set of modules (the list of modules specified in the command line option). Access to restricted methods from any other module not in the list is disallowed and will result in an `IllegalAccessException`.

When implementing this flag we considered two options: adding some resolution-time checks in the JVM (e.g. in `linkResolver`); or use `@CallerSensitive` methods. In the end we opted for the latter given that `@CallerSensitive` are generally well understood and optimized, and the general feeling was that inventing another form of callsite-dependent check might have been unnecessarily risky, given that the same checks can be implemented in Java using `@CallerSensitive`. We plan (not in 17) to add `javadoc` support by means of an annotation (like we do for preview API methods) so that the text that is currently copied and pasted in all restricted methods can be inferred automagically by javadoc.

### GitHub testing status

Most platforms build and tests pass. There are a bunch of *additional* Linux platforms which do not yet work correctly:

* Zero
* arm
* ppc
* s390

The first two can be addresses easily by stubbing out few functions (I'll do that shortly). The last two are harder, as this patch moves some static functions (e.g. `long_move`, `float_move`) up to `SharedRuntime`; unfortunately, while most platforms use the same signatures for these function, on ppc and s390 that's not the case and function with same name, but incompatible signatures are defined there, leading to build issues. We will try to tweak the code around this, to make sure that these platforms remain buildable.

Javadoc: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v1/javadoc/jdk/incubator/foreign/package-summary.html
Specdiff: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v1/specdiff/overview-summary.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From jbhateja at openjdk.java.net  Tue Apr 27 18:17:54 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 27 Apr 2021 18:17:54 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization
Message-ID: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>

Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-

    vec1 = lanewise(VectorOperators.LSHL, n)
    vec2 = lanewise(VectorOperators.LSHR, n)
    res = lanewise(VectorOperations.OR, vec1 , vec2)

This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.

AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.

Please find below the performance data for included JMH benchmark.
Machine:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascaselake Server)

``
Benchmark | (TESTSIZE) | Baseline (ops/min) | Withopt (ops/min) | Gain %
-- | -- | -- | -- | --
RotateBenchmark.testRotateLeftI | 64 | 6813.033 | 6936.507 | 1.81
RotateBenchmark.testRotateLeftI | 64 | 11549.524 | 12109.845 | 4.85
RotateBenchmark.testRotateLeftI | 64 | 17780.166 | 18180.083 | 2.25
RotateBenchmark.testRotateLeftI | 128 | 3355.631 | 3426.436 | 2.11
RotateBenchmark.testRotateLeftI | 128 | 5925.534 | 6096.71 | 2.89
RotateBenchmark.testRotateLeftI | 128 | 8847.645 | 8964.224 | 1.32
RotateBenchmark.testRotateLeftI | 256 | 1704.192 | 1779.964 | 4.45
RotateBenchmark.testRotateLeftI | 256 | 2919.158 | 3000.392 | 2.78
RotateBenchmark.testRotateLeftI | 256 | 4386.134 | 4514.211 | 2.92
RotateBenchmark.testRotateLeftL | 64 | 3419.193 | 3500.522 | 2.38
RotateBenchmark.testRotateLeftL | 64 | 5982.87 | 6056.589 | 1.23
RotateBenchmark.testRotateLeftL | 64 | 8829.172 | 8949.157 | 1.36
RotateBenchmark.testRotateLeftL | 128 | 1684.745 | 1784.49 | 5.92
RotateBenchmark.testRotateLeftL | 128 | 2942.226 | 2947.684 | 0.19
RotateBenchmark.testRotateLeftL | 128 | 4385.488 | 4554.113 | 3.85
RotateBenchmark.testRotateLeftL | 256 | 834.195 | 856.939 | 2.73
RotateBenchmark.testRotateLeftL | 256 | 1463.802 | 1551.051 | 5.96
RotateBenchmark.testRotateLeftL | 256 | 2187.005 | 2268.596 | 3.73
RotateBenchmark.testRotateRightI | 64 | 6676.132 | 7077.587 | 6.01
RotateBenchmark.testRotateRightI | 64 | 11452.825 | 11855.45 | 3.52
RotateBenchmark.testRotateRightI | 64 | 17507.286 | 18164.757 | 3.76
RotateBenchmark.testRotateRightI | 128 | 3412.394 | 3519.829 | 3.15
RotateBenchmark.testRotateRightI | 128 | 5905.677 | 5875.698 | -0.51
RotateBenchmark.testRotateRightI | 128 | 8745.95 | 8890.757 | 1.66
RotateBenchmark.testRotateRightI | 256 | 1681.176 | 1708.54 | 1.63
RotateBenchmark.testRotateRightI | 256 | 3004.008 | 3005.606 | 0.05
RotateBenchmark.testRotateRightI | 256 | 4466.633 | 4548.232 | 1.83
RotateBenchmark.testRotateRightL | 64 | 3361.499 | 3461.121 | 2.96
RotateBenchmark.testRotateRightL | 64 | 5873.37 | 6072.209 | 3.39
RotateBenchmark.testRotateRightL | 64 | 8820.284 | 9016.172 | 2.22
RotateBenchmark.testRotateRightL | 128 | 1715.556 | 1720.67 | 0.30
RotateBenchmark.testRotateRightL | 128 | 2957.337 | 3149.193 | 6.49
RotateBenchmark.testRotateRightL | 128 | 4440.468 | 4473.221 | 0.74
RotateBenchmark.testRotateRightL | 256 | 851.391 | 875.371 | 2.82
RotateBenchmark.testRotateRightL | 256 | 1452.422 | 1522.942 | 4.86
RotateBenchmark.testRotateRightL | 256 | 2208.454 | 2263.349 | 2.49

 ``

-------------

Commit messages:
 - 8266054: Changing gen-src.sh file permissions
 - 8266054: VectorAPI rotate operation optimization

Changes: https://git.openjdk.java.net/jdk/pull/3720/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266054
  Stats: 1282 lines in 45 files changed: 1201 ins; 58 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720

PR: https://git.openjdk.java.net/jdk/pull/3720

From naoto at openjdk.java.net  Tue Apr 27 18:43:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 27 Apr 2021 18:43:35 GMT
Subject: RFR: 8266014: Regression brought by optimization done with
 JDK-4926314
In-Reply-To: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>
References: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>
Message-ID: <4K-HlxeyckBC0iGyAPMA7fGsDsLWfVV_rwdoPgP87Ac=.e5828e52-ecbd-420b-81bf-26d118c0a2cb@github.com>

On Tue, 27 Apr 2021 01:26:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this request to correct a minor problem with the optimization added for JDK-4926314. The change is to attempt to read the number of elements remaining in the target buffer unless that number is non-positive in which case read zero. The test addition fails without and passes with the implementation change.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3708

From psandoz at openjdk.java.net  Tue Apr 27 18:45:34 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 27 Apr 2021 18:45:34 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization
In-Reply-To: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
Message-ID: <t6x-07deVE-31m3nJaiOWKhM_4oPZ-1tmfsMc1fx2AM=.f24f1776-bf4b-43c7-8316-e77cd2db7ca9@github.com>

On Tue, 27 Apr 2021 17:56:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server)
> 
> ``
> Benchmark | (TESTSIZE) | Baseline (ops/min) | Withopt (ops/min) | Gain %
> -- | -- | -- | -- | --
> RotateBenchmark.testRotateLeftI | 64 | 6813.033 | 6936.507 | 1.81
> RotateBenchmark.testRotateLeftI | 64 | 11549.524 | 12109.845 | 4.85
> RotateBenchmark.testRotateLeftI | 64 | 17780.166 | 18180.083 | 2.25
> RotateBenchmark.testRotateLeftI | 128 | 3355.631 | 3426.436 | 2.11
> RotateBenchmark.testRotateLeftI | 128 | 5925.534 | 6096.71 | 2.89
> RotateBenchmark.testRotateLeftI | 128 | 8847.645 | 8964.224 | 1.32
> RotateBenchmark.testRotateLeftI | 256 | 1704.192 | 1779.964 | 4.45
> RotateBenchmark.testRotateLeftI | 256 | 2919.158 | 3000.392 | 2.78
> RotateBenchmark.testRotateLeftI | 256 | 4386.134 | 4514.211 | 2.92
> RotateBenchmark.testRotateLeftL | 64 | 3419.193 | 3500.522 | 2.38
> RotateBenchmark.testRotateLeftL | 64 | 5982.87 | 6056.589 | 1.23
> RotateBenchmark.testRotateLeftL | 64 | 8829.172 | 8949.157 | 1.36
> RotateBenchmark.testRotateLeftL | 128 | 1684.745 | 1784.49 | 5.92
> RotateBenchmark.testRotateLeftL | 128 | 2942.226 | 2947.684 | 0.19
> RotateBenchmark.testRotateLeftL | 128 | 4385.488 | 4554.113 | 3.85
> RotateBenchmark.testRotateLeftL | 256 | 834.195 | 856.939 | 2.73
> RotateBenchmark.testRotateLeftL | 256 | 1463.802 | 1551.051 | 5.96
> RotateBenchmark.testRotateLeftL | 256 | 2187.005 | 2268.596 | 3.73
> RotateBenchmark.testRotateRightI | 64 | 6676.132 | 7077.587 | 6.01
> RotateBenchmark.testRotateRightI | 64 | 11452.825 | 11855.45 | 3.52
> RotateBenchmark.testRotateRightI | 64 | 17507.286 | 18164.757 | 3.76
> RotateBenchmark.testRotateRightI | 128 | 3412.394 | 3519.829 | 3.15
> RotateBenchmark.testRotateRightI | 128 | 5905.677 | 5875.698 | -0.51
> RotateBenchmark.testRotateRightI | 128 | 8745.95 | 8890.757 | 1.66
> RotateBenchmark.testRotateRightI | 256 | 1681.176 | 1708.54 | 1.63
> RotateBenchmark.testRotateRightI | 256 | 3004.008 | 3005.606 | 0.05
> RotateBenchmark.testRotateRightI | 256 | 4466.633 | 4548.232 | 1.83
> RotateBenchmark.testRotateRightL | 64 | 3361.499 | 3461.121 | 2.96
> RotateBenchmark.testRotateRightL | 64 | 5873.37 | 6072.209 | 3.39
> RotateBenchmark.testRotateRightL | 64 | 8820.284 | 9016.172 | 2.22
> RotateBenchmark.testRotateRightL | 128 | 1715.556 | 1720.67 | 0.30
> RotateBenchmark.testRotateRightL | 128 | 2957.337 | 3149.193 | 6.49
> RotateBenchmark.testRotateRightL | 128 | 4440.468 | 4473.221 | 0.74
> RotateBenchmark.testRotateRightL | 256 | 851.391 | 875.371 | 2.82
> RotateBenchmark.testRotateRightL | 256 | 1452.422 | 1522.942 | 4.86
> RotateBenchmark.testRotateRightL | 256 | 2208.454 | 2263.349 | 2.49
> 
>  ``

I noticed the tests are only updated for int and long, is that intentional? The HotSpot changes in some cases seem to imply all integral types are supported via the use of `is_integral_type`, contradicted by the use of `is_subword_type`.

I would recommend trying to leverage Integer/Long.rotateLeft/Right implementations. They are not available for byte/short, so lets add specific methods in those cases, that should make the Java op implementation clearer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From alanb at openjdk.java.net  Tue Apr 27 18:51:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 27 Apr 2021 18:51:38 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator)
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com>

On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

src/java.base/share/classes/java/lang/Module.java line 253:

> 251:     }
> 252: 
> 253:     boolean isEnableNativeAccess() {

Would it be possible change isEnableNativeAccess and addNEnableNativeAccess to keep them consistent with the existing methods in this file.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 384:

> 382:     Module addEnableNativeAccess(Module m);
> 383: 
> 384:     boolean isEnableNativeAccess(Module m);

Probably better to co-locate these with the other module methods, and add a comment so that it's consistent with the existing methods.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 272:

> 270:         BootLoader.loadModule(base);
> 271:         SharedSecrets.getJavaLangAccess()
> 272:                 .addEnableNativeAccess(Modules.defineModule(null, base.descriptor(), baseUri));

This would be cleaner if you replace it with:

Module baseModule = Modules.defineModule(null, base.descriptor(), baseUri);
JLA.addEnableNativeAccess(baseModule);

You can use JLA in addEnableNativeAccess too, no need for "jla".

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 876:

> 874:     }
> 875: 
> 876:     private static void addEnableNativeAccess(ModuleLayer layer) {

It would be useful to add a method description in the same style as the existing methods, just to keep these methods consistent.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 57:

> 55: 
> 56:     static int write(FileDescriptor fd, ByteBuffer src, long position,
> 57:                      boolean async, NativeDispatcher nd)

UnixAsynchronousSocketChannel is an outlier user of IOUtil and I think we need to see if we can avoid extending this class to async if possible.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466:

> 464:     }
> 465: 
> 466:     private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess();

It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From bpb at openjdk.java.net  Tue Apr 27 18:55:53 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Apr 2021 18:55:53 GMT
Subject: RFR: 8266014: Regression brought by optimization done with
 JDK-4926314 [v2]
In-Reply-To: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>
References: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>
Message-ID: <TZ_irsAr7sP_IC40X7Bkp5YQ1X8vkMG47hbMC1qWHYU=.b3589087-3293-4d54-8262-0a02bcfdd66e@github.com>

> Please consider this request to correct a minor problem with the optimization added for JDK-4926314. The change is to attempt to read the number of elements remaining in the target buffer unless that number is non-positive in which case read zero. The test addition fails without and passes with the implementation change.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8266014: Clean up spurious line break in the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3708/files
  - new: https://git.openjdk.java.net/jdk/pull/3708/files/198e09ce..50cb65c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3708&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3708&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3708.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3708/head:pull/3708

PR: https://git.openjdk.java.net/jdk/pull/3708

From bpb at openjdk.java.net  Tue Apr 27 18:55:59 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Apr 2021 18:55:59 GMT
Subject: RFR: 8266078: Reader.read(CharBuffer) advances Reader position for
 read-only Charbuffers
Message-ID: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>

Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position.

-------------

Commit messages:
 - 8266078: Reader.read(CharBuffer) advances Reader position for read-only Charbuffers

Changes: https://git.openjdk.java.net/jdk/pull/3725/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3725&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266078
  Stats: 70 lines in 2 files changed: 70 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3725.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3725/head:pull/3725

PR: https://git.openjdk.java.net/jdk/pull/3725

From iignatyev at openjdk.java.net  Tue Apr 27 19:10:50 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 19:10:50 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
 <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
Message-ID: <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com>

On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later).

@dougxc, I don't think that we should (or even can) rename it to `vm.jvmcicompiler.enabled`. although the value of the property is indeed `true` whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change `requires/VMProps.java` to set `vm.graal.enabled` only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here.

-- Igor

-------------

PR: https://git.openjdk.java.net/jdk/pull/3421

From rriggs at openjdk.java.net  Tue Apr 27 19:37:29 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 27 Apr 2021 19:37:29 GMT
Subject: RFR: 8266078: Reader.read(CharBuffer) advances Reader position
 for read-only Charbuffers
In-Reply-To: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
References: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
Message-ID: <E_XB8sc08DYDEIbj4elYl03i2qL-kS6PgMEHcsJESTs=.7a113d99-7151-4c07-930a-65cb92dd6a30@github.com>

On Tue, 27 Apr 2021 18:47:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position.

src/java.base/share/classes/java/io/Reader.java line 202:

> 200:             if (target.isReadOnly())
> 201:                 throw new ReadOnlyBufferException();
> 202:             int len = target.remaining();

It seems like the other branch of the if should also check for read-only and throw.
Or can the target not have an array if it is readonly.
It might return -1 for a readonly target if the source was used up. The always throw.

Moving the `if (target.isReadOnly())`  to the line 188: would be unambiguous.

test/jdk/java/io/Reader/ReadIntoReadOnlyBuffer.java line 52:

> 50:         try {
> 51:             r.read(b);
> 52:             throw new RuntimeException();

A helpful message would make it clearer what failed, when/if it fails.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3725

From bpb at openjdk.java.net  Tue Apr 27 19:45:09 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Apr 2021 19:45:09 GMT
Subject: RFR: 8266078: Reader.read(CharBuffer) advances Reader position
 for read-only Charbuffers
In-Reply-To: <E_XB8sc08DYDEIbj4elYl03i2qL-kS6PgMEHcsJESTs=.7a113d99-7151-4c07-930a-65cb92dd6a30@github.com>
References: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
 <E_XB8sc08DYDEIbj4elYl03i2qL-kS6PgMEHcsJESTs=.7a113d99-7151-4c07-930a-65cb92dd6a30@github.com>
Message-ID: <acKoMAC6K5VHbTlwLxoogBePSl4a83wxt8U-w3-mrf0=.200b0387-506f-40c0-ba77-6bb2011bfd08@github.com>

On Tue, 27 Apr 2021 19:31:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position.
>
> src/java.base/share/classes/java/io/Reader.java line 202:
> 
>> 200:             if (target.isReadOnly())
>> 201:                 throw new ReadOnlyBufferException();
>> 202:             int len = target.remaining();
> 
> It seems like the other branch of the if should also check for read-only and throw.
> Or can the target not have an array if it is readonly.
> It might return -1 for a readonly target if the source was used up. The always throw.
> 
> Moving the `if (target.isReadOnly())`  to the line 188: would be unambiguous.

It can't have an array if it is read-only.

Returns:
    true if, and only if, this buffer is backed by an array and is not read-only

https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/nio/CharBuffer.html#hasArray()

> test/jdk/java/io/Reader/ReadIntoReadOnlyBuffer.java line 52:
> 
>> 50:         try {
>> 51:             r.read(b);
>> 52:             throw new RuntimeException();
> 
> A helpful message would make it clearer what failed, when/if it fails.

Agreed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3725

From dnsimon at openjdk.java.net  Tue Apr 27 19:52:22 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 27 Apr 2021 19:52:22 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
 <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
 <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com>
Message-ID: <o7MoSCHYzz8LY-cQhlF8gksBqUecUrsZv_rnC9Z_oSc=.5d3e308f-3539-442c-a0f9-50c03ebc2e27@github.com>

On Tue, 27 Apr 2021 19:07:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> > I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later).
> 
> @dougxc, I don't think that we should (or even can) rename it to `vm.jvmcicompiler.enabled`. although the value of the property is indeed `true` whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change `requires/VMProps.java` to set `vm.graal.enabled` only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here.
> 
> -- Igor

Yes, we should just it as is until a second JVMCI compiler shows up.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3421

From mcimadamore at openjdk.java.net  Tue Apr 27 20:23:10 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 27 Apr 2021 20:23:10 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator)
In-Reply-To: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com>
Message-ID: <HR941JzKecV6wZfmlK-xg3KxM0yEOEIAIExPG62SJzk=.16b0bbb8-9dfb-49a1-8a35-df716eae3e61@github.com>

On Tue, 27 Apr 2021 18:46:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> src/java.base/share/classes/java/lang/Module.java line 253:
> 
>> 251:     }
>> 252: 
>> 253:     boolean isEnableNativeAccess() {
> 
> Would it be possible change isEnableNativeAccess and addNEnableNativeAccess to keep them consistent with the existing methods in this file.

Change as in "adding javadoc" ? Or is the naming of the method something that's bothering?

> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 384:
> 
>> 382:     Module addEnableNativeAccess(Module m);
>> 383: 
>> 384:     boolean isEnableNativeAccess(Module m);
> 
> Probably better to co-locate these with the other module methods, and add a comment so that it's consistent with the existing methods.

sure I'll fix this

> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 272:
> 
>> 270:         BootLoader.loadModule(base);
>> 271:         SharedSecrets.getJavaLangAccess()
>> 272:                 .addEnableNativeAccess(Modules.defineModule(null, base.descriptor(), baseUri));
> 
> This would be cleaner if you replace it with:
> 
> Module baseModule = Modules.defineModule(null, base.descriptor(), baseUri);
> JLA.addEnableNativeAccess(baseModule);
> 
> You can use JLA in addEnableNativeAccess too, no need for "jla".

ok

> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 876:
> 
>> 874:     }
>> 875: 
>> 876:     private static void addEnableNativeAccess(ModuleLayer layer) {
> 
> It would be useful to add a method description in the same style as the existing methods, just to keep these methods consistent.

I'll fix

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From bpb at openjdk.java.net  Tue Apr 27 20:25:32 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Apr 2021 20:25:32 GMT
Subject: RFR: 8266078: Reader.read(CharBuffer) advances Reader position
 for read-only Charbuffers [v2]
In-Reply-To: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
References: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
Message-ID: <yrzp7TE2c_ucO-DD2JxabxtguPJO-_OK9j1Zjtg7KNY=.72eec596-2306-4ee9-bb1f-c484da599a6c@github.com>

> Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8266078: Make read-only check global; add message in test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3725/files
  - new: https://git.openjdk.java.net/jdk/pull/3725/files/2fbaff7d..4a899b26

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3725&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3725&range=00-01

  Stats: 8 lines in 2 files changed: 5 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3725.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3725/head:pull/3725

PR: https://git.openjdk.java.net/jdk/pull/3725

From rriggs at openjdk.java.net  Tue Apr 27 21:19:13 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 27 Apr 2021 21:19:13 GMT
Subject: RFR: 8266078: Reader.read(CharBuffer) advances Reader position
 for read-only Charbuffers [v2]
In-Reply-To: <yrzp7TE2c_ucO-DD2JxabxtguPJO-_OK9j1Zjtg7KNY=.72eec596-2306-4ee9-bb1f-c484da599a6c@github.com>
References: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
 <yrzp7TE2c_ucO-DD2JxabxtguPJO-_OK9j1Zjtg7KNY=.72eec596-2306-4ee9-bb1f-c484da599a6c@github.com>
Message-ID: <1XsSy6WrCg2cedf5f7tN2rEluO2TOpScz3hVgBPl1QM=.42245b0f-acc1-4766-b065-5ede48865d1a@github.com>

On Tue, 27 Apr 2021 20:25:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266078: Make read-only check global; add message in test

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3725

From igraves at openjdk.java.net  Tue Apr 27 21:41:23 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 27 Apr 2021 21:41:23 GMT
Subject: RFR: 8266155: Convert java.base to use Stream.toList()
Message-ID: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>

8266155: Convert java.base to use Stream.toList()

-------------

Commit messages:
 - Migrating java.base to use Stream.toList()

Changes: https://git.openjdk.java.net/jdk/pull/3734/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3734&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266155
  Stats: 18 lines in 8 files changed: 0 ins; 4 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3734.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3734/head:pull/3734

PR: https://git.openjdk.java.net/jdk/pull/3734

From bpb at openjdk.java.net  Tue Apr 27 21:55:07 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Apr 2021 21:55:07 GMT
Subject: RFR: 8266155: Convert java.base to use Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <KY3YZ9lHY0GKOEIHRvhlW2tJOj0lBScCxdTo3RG0AIo=.b713f544-110b-47b5-bf6f-7837a8ce70e2@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

Looks all right.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3734

From naoto at openjdk.java.net  Tue Apr 27 22:00:11 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 27 Apr 2021 22:00:11 GMT
Subject: RFR: 8266155: Convert java.base to use Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <D6mefFUWVpv5pnPAKmJnVPHF1Qd1zgHWCGuXZRxWxQM=.e51d43b4-f26e-422f-8b8f-ec9955bd859e@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3734

From coleenp at openjdk.java.net  Tue Apr 27 22:51:10 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 27 Apr 2021 22:51:10 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com>

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

I looked at the runtime code, which looks fine. I didn't read the GC code.

src/hotspot/share/classfile/javaClasses.inline.hpp line 77:

> 75: 
> 76: uint8_t* java_lang_String::flags_addr(oop java_string) {
> 77:   assert(_initialized, "Mut be initialized");

typo: must

src/hotspot/share/classfile/stringTable.cpp line 784:

> 782:   SharedStringIterator iter(f);
> 783:   _shared_table.iterate(&iter);
> 784: }

So with this change (somewhere below) do you no longer deduplicate strings from the shared string table? ie

// The CDS archive does not include the string deduplication table. Only the string
// table is saved in the archive. The shared strings from CDS archive need to be
// added to the string deduplication table before deduplication occurs. That is
// done in the beginning of the StringDedupThread (see StringDedupThread::do_deduplication()).
void StringDedupThread::deduplicate_shared_strings(StringDedupStat* stat) {
  StringDedupSharedClosure sharedStringDedup(stat);
  StringTable::shared_oops_do(&sharedStringDedup);
}
Asking @iklam to have a look then.

src/hotspot/share/runtime/globals.hpp line 1994:

> 1992:                                                                             \
> 1993:   product(uint64_t, StringDeduplicationHashSeed, 0, DIAGNOSTIC,             \
> 1994:           "Seed for the table hashing function; 0 requests computed seed")  \

Should these two really be develop() options?

src/hotspot/share/runtime/mutexLocker.cpp line 239:

> 237:     def(StringDedupQueue_lock      , PaddedMonitor, leaf,        true,  _safepoint_check_never);
> 238:     def(StringDedupTable_lock      , PaddedMutex  , leaf + 1,    true,  _safepoint_check_never);
> 239:   }

Why weren't these duplicate definitions?  This is disturbing.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3662

From joehw at openjdk.java.net  Tue Apr 27 23:07:33 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 27 Apr 2021 23:07:33 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v2]
In-Reply-To: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
References: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
Message-ID: <XazS6DYYckl9rAhHK1E58XQOlQiHFRZonhziDi2PdJg=.f2ccfef6-ed7a-4706-b3b1-2c33cbe377a3@github.com>

> Update module summary, add a few existing properties and features into the tables.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Update the CSR. See Update 03 in the CSR

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3644/files
  - new: https://git.openjdk.java.net/jdk/pull/3644/files/dde2e361..e88be266

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=00-01

  Stats: 42 lines in 2 files changed: 2 ins; 1 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3644/head:pull/3644

PR: https://git.openjdk.java.net/jdk/pull/3644

From stuart.marks at oracle.com  Wed Apr 28 00:04:22 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 27 Apr 2021 17:04:22 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <b112dcad-3839-fdfd-437e-5d7287f0063c@gmail.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
 <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
 <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>
 <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>
 <85906d24-f9c8-1b6f-77c0-b8cf5ca48457@gmail.com>
 <6f0d7d03-ec96-b204-7252-efe413792073@oracle.com>
 <b112dcad-3839-fdfd-437e-5d7287f0063c@gmail.com>
Message-ID: <6393cd77-df67-15e4-6419-7ceb725d2a50@oracle.com>



On 4/27/21 2:25 AM, Peter Levart wrote:
> Right, I'm persuaded. Now if only the problems of transition to the usage of new 
> type that Remi is worried about were mild enough. Source (in)compatibility is not 
> that important if workarounds exist that are also backwards source compatible so 
> that the same codebase can be compiled with different JDKs. Binary compatibility is 
> important. And I guess there is a variant of the proposal that includes 
> ReversibleCollection and ReversibleSet and is binary compatible.

Yes, the source incompatibilities with the types seem to involve type inference 
(e.g., use of var choosing differently based on new types in the library) so it 
should be possible to make minor source code changes to adjust or override the type 
that's inferred.

On binary compatibility, that comes mostly from the newly introduced methods 
(reversed, addFirst etc.) and from adding covariant overrides to LinkedHashSet. I 
guess the "variant" you mention is adding new methods with the new return types 
(e.g., reversibleEntrySet) instead of covariant overrides. Or was it something else?

> Now just some of my thoughts about the proposal:
> 
> - SortedSet.addFirst/.addLast - I think an operation that would be used in 
> situations like: "I know this element should always be greater than any existing 
> element in the set and I will push it to the end which should also verify my 
> assumption" is a perfectly valid operation. So those methods throwing 
> IllegalStateException in case the invariant can't be kept seem perfectly fine to me.
> 
> - ReversibleCollection.addFirst/.addLast are specified to have void return type. 
> This works for List and Deque which always add element and so have no information to 
> return. OTOH Collection.add is specified to return boolean to indicate whether 
> collection was modified or not, but Set modifies the specification of that method a 
> bit to be: return false or true when Set already contained an element equal to the 
> parameter or not. So ReversibleCollection.addFirst/.addLast could play the same 
> trick. for List(s) and Deque(s) it would always return true, but for 
> ReversibleSet(s) it would return true only if the set didn't contain an element 
> equal to the parameter, so re-positioning of equal element would return false 
> although the collection was modified as a result.

Anthony Vanelverdinghe replied to both of these points so I'll follow up in a reply 
to his message.

> - Perhaps unrelated to this proposal, but just for completeness, existing Collection 
> interface could be extended with methods like: getAny() and removeAny().

Yes, I think there's something going on here, but the issues lead off in a different 
direction, which I think would be a distraction from ReversibleCollection. So I'd 
like to keep this as a separate topic. (But it's not a prohibition against talking 
about them.) Indeed, I see that Henri Tremblay has coincidentally (?) raised a 
similar topic, so I'll reply further to his message.

s'marks


From psandoz at openjdk.java.net  Wed Apr 28 00:17:54 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 28 Apr 2021 00:17:54 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator)
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <NAvpIjak6Lo_zuVjnWlc7orhQSLqjs3IUgklbR9k8nA=.15860f1d-8b59-40aa-a3ae-fdbb5b92909c@github.com>

On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

The Java changes are mostly familiar to me, having reviewed many PRs in the Panama repository, hence the lack of specific comments here. I did a pass through the changes and nothing major stood out to me.

The new API changes make it much easy to build APIs around memory segments, exposing and reusing resource scope, acquiring/releasing on resource scope, where necessary.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3699

From iklam at openjdk.java.net  Wed Apr 28 00:31:57 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 28 Apr 2021 00:31:57 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com>
Message-ID: <FJbJvc9ISiPyR9soIaPwTTK2Fd4D_jJfA17u0GGujH0=.1d310efe-73fb-495a-bfe4-726d25922599@github.com>

On Tue, 27 Apr 2021 22:47:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> src/hotspot/share/classfile/stringTable.cpp line 784:
> 
>> 782:   SharedStringIterator iter(f);
>> 783:   _shared_table.iterate(&iter);
>> 784: }
> 
> So with this change (somewhere below) do you no longer deduplicate strings from the shared string table? ie
> 
> // The CDS archive does not include the string deduplication table. Only the string
> // table is saved in the archive. The shared strings from CDS archive need to be
> // added to the string deduplication table before deduplication occurs. That is
> // done in the beginning of the StringDedupThread (see StringDedupThread::do_deduplication()).
> void StringDedupThread::deduplicate_shared_strings(StringDedupStat* stat) {
>   StringDedupSharedClosure sharedStringDedup(stat);
>   StringTable::shared_oops_do(&sharedStringDedup);
> }
> Asking @iklam to have a look then.

If I understand correctly, we no longer need to add the entire set of shared strings into the dedup table.


+// As a space optimization, when shared StringTable entries exist the shared
+// part of the StringTable is also used as a source for byte arrays.  This
+// permits deduplication of strings against those shared entries without
+// recording them in this table too.
+class StringDedup::Table : AllStatic {

...

+void StringDedup::Table::deduplicate(oop java_string) {
+  assert(java_lang_String::is_instance(java_string), "precondition");
+  _cur_stat.inc_inspected();
+  if ((StringTable::shared_entry_count() > 0) &&
+      try_deduplicate_shared(java_string)) {
+    return;                     // Done if deduplicated against shared StringTable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From iris at openjdk.java.net  Wed Apr 28 00:36:52 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Apr 2021 00:36:52 GMT
Subject: RFR: 8266155: Convert java.base to use Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <ccce-pWiORe39fUtIMDRvrPZd2OuuX6ZMRcVO9eSlwc=.a90a66f5-ba60-4b8c-8cc8-76c3f1b69985@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3734

From iklam at openjdk.java.net  Wed Apr 28 00:53:53 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 28 Apr 2021 00:53:53 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <8yDFk4JdgCTBjvxuLDC1Bkqel_WPwGXibQyU9yyxM0k=.f317ce73-527d-4012-ae50-4142ea0ead76@github.com>

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

Changes requested by iklam (Reviewer).

src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 557:

> 555:     // non-latin1, and deduplicating if we find a match.  For deduplication we
> 556:     // only care if the arrays consist of the same sequence of bytes.
> 557:     const jchar* chars = static_cast<jchar*>(value->base(T_CHAR));

The encoding of the shared strings always match CompactStrings. Otherwise the CDS archive will fail to map. E.g.,


$ java -XX:-CompactStrings -Xshare:dump 
$ java -XX:+CompactStrings -Xlog:cds -version
...
[0.032s][info][cds] UseSharedSpaces: The shared archive file's CompactStrings 
                    setting (disabled) does not equal the current CompactStrings setting (enabled).
[0.032s][info][cds] UseSharedSpaces: Unable to map shared spaces
...


So you can avoid this `if` block when `CompactStrings == true`. The `!java_lang_String::is_latin1(found)` check below can be changed to an assert.

Also, I think we need an explicit test case where you'd return `true` at line 564. I can write a new test case and email to you. I think it will involve dumping an archive with `-XX:-CompactStrings`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From mchung at openjdk.java.net  Wed Apr 28 01:18:03 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Apr 2021 01:18:03 GMT
Subject: RFR: JDK-8265773: incorrect jdeps message "jdk8internals" to describe
 a removed JDK internal API
Message-ID: <blCgr1AQAqA6r0xpRGnd2HsBIUxK2mnCloDy-lCgnN4=.c00216ab-4a0a-49f8-8d24-738a102cc186@github.com>

jdeps should print "JDK removed internal APIs" to give an informative description when a JDK internal API that is being referenced has been removed.  JDK-8213909 incorrectly changed it to print `jdk8internals`.

An example output is:


classes -> jdk8internals
   p.Main                                             -> sun.misc.Service                                      JDK removed internal API
   p.Main                                             -> sun.misc.SoftCache                                 JDK removed internal API

-------------

Commit messages:
 - JDK-8265773: jdeps message jdk8internals indicating a non-existent JDK API is incorrect

Changes: https://git.openjdk.java.net/jdk/pull/3741/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3741&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265773
  Stats: 75 lines in 3 files changed: 74 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3741.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3741/head:pull/3741

PR: https://git.openjdk.java.net/jdk/pull/3741

From stuart.marks at oracle.com  Wed Apr 28 05:19:29 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 27 Apr 2021 22:19:29 -0700
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <38af-60883900-4c5-3a732100@161619996>
References: <38af-60883900-4c5-3a732100@161619996>
Message-ID: <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>



On 4/27/21 9:17 AM, Anthony Vanelverdinghe wrote:
> On Tuesday, April 27, 2021 11:25 CEST, Peter Levart <peter.levart at gmail.com> wrote:
>> Now just some of my thoughts about the proposal:
>>
>> - SortedSet.addFirst/.addLast - I think an operation that would be used
>> in situations like: "I know this element should always be greater than
>> any existing element in the set and I will push it to the end which
>> should also verify my assumption" is a perfectly valid operation. So
>> those methods throwing IllegalStateException in case the invariant can't
>> be kept seem perfectly fine to me.
> 
> This was raised before and addressed by Stuart in [0]:
> "An alternative as you suggest might be that SortedSet::addFirst/addLast could throw
> something like IllegalStateException if the element is wrongly positioned.
> (Deque::addFirst/addLast will throw ISE if the addition would exceed a capacity
> restriction.) This seems error-prone, though, and it's easier to understand and
> specify that these methods simply throw UOE unconditionally. If there's a good use
> case for the alternative I'd be interested in hearing it though."

Yes, to be clear, it was Stephen Coleborne who raised this previously [1] and it's 
my response that's quoted above.

Some further thoughts on this.

This is an example where, depending on the current state of the collection, the 
method might throw or it might succeed. This is useful in concurrent collections 
(such as the capacity-restricted Deque above), where the caller cannot check 
preconditions beforehand, because they might be out of date by the time the 
operation is attempted. In such cases the caller might not want to block, but 
instead it might catch the exception and report an error to its caller (or drop the 
request). Thus, calling the exception-throwing method is appropriate.

Something like SortedSet::addLast seems different, though. The state is the *values* 
of the elements already in the collection. This is something that can easily be 
checked, and probably should be checked beforehand:

     if (sortedSet.isEmpty() || sortedSet.last().compareTo(e) <= 0)
         sortedSet.add(e);
     else
         // e wouldn't be the last element, do something different

Now this is a fair bit of code, and it would be shorter just to call 
sortedSet.addLast(e). But does that actually help? What if e is already in the set 
and is the last element? Is catching an exception really what we want to do if e 
wouldn't be the last element? Maybe we'd want to do nothing instead. If so, catching 
an exception in order to do nothing is extra work.

Again, I'd like to hear about use cases for a conditionally-throwing version of 
addLast et. al. I don't want to be limited by failure of imagination, but it does 
seem like this kind of behavior would be useful only in a narrow set of cases where 
it happens to do exactly the right thing. Otherwise, it just gets in the way, and 
its behavior is pretty obscure. So, color me skeptical.

> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076518.html

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076505.html

>> - ReversibleCollection.addFirst/.addLast are specified to have void
>> return type. This works for List and Deque which always add element and
>> so have no information to return. OTOH Collection.add is specified to
>> return boolean to indicate whether collection was modified or not, but
>> Set modifies the specification of that method a bit to be: return false
>> or true when Set already contained an element equal to the parameter or
>> not. So ReversibleCollection.addFirst/.addLast could play the same
>> trick. for List(s) and Deque(s) it would always return true, but for
>> ReversibleSet(s) it would return true only if the set didn't contain an
>> element equal to the parameter, so re-positioning of equal element would
>> return false although the collection was modified as a result.
> 
> If addFirst/addLast were to return boolean, Deque would no longer compile due to its existing methods being incompatible with the new ones.

Right, the current proposal copies the addX method signatures from Deque into 
ReversibleCollection.

I think it was Mike Duigou who said that a method that returns void is a missed 
opportunity. The idea is, the library probably has some useful bit of information it 
can return. If the caller doesn't need it, the caller can just ignore it.

On Collection::add returning a boolean, most calls to this ignore the return value, 
and the boolean "did this collection change as a result of this call?" is only 
occasionally useful. Sometimes it can be used for little tricks, such as an easy way 
to determine if a stream contains all unique elements:

     stream.allMatch(new HashSet<>()::add)

But really, the boolean return value doesn't seem all that useful.

Still, it could be added. The methods couldn't be called addFirst/addLast as Anthony 
pointed out, as this would clash with those methods already on Deque. However, Deque 
already contains boolean-returning offerFirst/offerLast methods! We could use those 
instead of addFirst/addLast, right?

Maybe. There are several different concerns here.

* Collection::add says:

"Returns true if this collection changed as a result of the call. (Returns false if 
this collection does not permit duplicates and already contains the specified element.)"

* Deque::add says:

"Inserts ... if it is possible to do so immediately without violating capacity 
restrictions, returning true upon success and throwing an IllegalStateException if 
no space is currently available."

* Deque::offerFirst/Last say:

"Inserts ... unless it would violate capacity restrictions. ... Returns: true if the 
element was added to this deque, else false"

* LinkedHashSet::offerX return value

If it's like add(), then it returns true if the element was added to the set, false 
if it wasn't added (even if repositioned). But Collection::add says true if this 
collection changed. Is repositioning a change? It isn't from the standpoint of 
equals(), but it is from the standpoint of ConcurrentModificationException. (At 
least that's true of access-ordered LinkedHashMap.)

* SortedSet::offerX return value

If it's like add(), then it returns true if the element was added to the set, false 
otherwise. But what about the case where the element isn't in the set, but adding it 
would not put it in the requested position?

  - if it's added but not in the requested position, that weakens the concepts of 
first/last

  - if it's not added and returns false, this clashes with other sets, where a false 
return means "not added because already in the set" but an equal element is present 
in the set after the call

Also, what if the element is already in the set but is in the wrong position?

***

The Deque class specification [2] has a nice table of the different operations, a 
subset of which is as follows:

              Exception       Special Value
     Insert   addFirst(e)     offerFirst(e)
     Remove   removeFirst()   pollFirst()
     Examine  getFirst()      peekFirst()

The original proposal takes the operations straight down the first column. It would 
be strangely inconsistent to take offerX from the second column and removeX and getX 
from the first column.

[2] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Deque.html

Using offerX certainly has the right "shape" of returning a boolean. The central 
question is what the boolean means. The problem is that Deque::offerX has a specific 
meaning that isn't operative in most collections, and we really want something more 
like Collection::add, but these clash. Trying to wedge in weird semantics of 
LinkedHashSet element reordering and SortedSet's special casing just makes things worse.

Finally, it's seems error-prone to have a conventional (i.e., non-concurrent) 
collection that tells you it has refused to insert an element by returning a 
boolean. It's too easy to ignore. Perfectly working code might silently break if the 
collection type is changed. (I'm reminded of various boolean-returning operations -- 
not queries -- on java.io.File, like delete and mkdir, which are a continual source 
of errors.)

I'll think about this more, but it doesn't seem promising.

s'marks

From ysuenaga at openjdk.java.net  Wed Apr 28 05:59:06 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 28 Apr 2021 05:59:06 GMT
Subject: RFR: 8266173: -Wmaybe-uninitialized happens in jni_util.c
Message-ID: <YKE53C7bOXZe3cs1fXHRyEMjwFY0bOMTOnk2CsEO9gI=.0df40377-15e0-4eb2-a263-01a8617b01f2@github.com>

We can see compiler warnings in jni_util.c as following on GCC 11. `buf` should be initialized.

-------------

Commit messages:
 - 8266173: -Wmaybe-uninitialized happens in jni_util.c

Changes: https://git.openjdk.java.net/jdk/pull/3742/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3742&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266173
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3742.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3742/head:pull/3742

PR: https://git.openjdk.java.net/jdk/pull/3742

From alanb at openjdk.java.net  Wed Apr 28 06:36:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 28 Apr 2021 06:36:57 GMT
Subject: RFR: 8266078: Reader.read(CharBuffer) advances Reader position
 for read-only Charbuffers [v2]
In-Reply-To: <yrzp7TE2c_ucO-DD2JxabxtguPJO-_OK9j1Zjtg7KNY=.72eec596-2306-4ee9-bb1f-c484da599a6c@github.com>
References: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
 <yrzp7TE2c_ucO-DD2JxabxtguPJO-_OK9j1Zjtg7KNY=.72eec596-2306-4ee9-bb1f-c484da599a6c@github.com>
Message-ID: <mCBzpFTG7eJpbLUruVKAD8p8I_NTL4FrICTk-TsbkCE=.559896bc-33a4-4928-88b1-0ae78036740d@github.com>

On Tue, 27 Apr 2021 20:25:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266078: Make read-only check global; add message in test

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/io/Reader.java line 206:

> 204:             char[] cbuf = new char[len];
> 205:             // If a read-only check had not been done above, then
> 206:             // the stream would be incorrectly advanced here.

The RO check is good but I'm not sure that this comment is useful (it might confuse future maintainers), I would be tempted to leave that part out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3725

From iklam at openjdk.java.net  Wed Apr 28 06:48:09 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 28 Apr 2021 06:48:09 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <8yDFk4JdgCTBjvxuLDC1Bkqel_WPwGXibQyU9yyxM0k=.f317ce73-527d-4012-ae50-4142ea0ead76@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
 <8yDFk4JdgCTBjvxuLDC1Bkqel_WPwGXibQyU9yyxM0k=.f317ce73-527d-4012-ae50-4142ea0ead76@github.com>
Message-ID: <FGI2qX4tf43QMa_gHls2WugfANSq1VxMg131ENNGxgE=.26c213e2-dd1c-4155-9622-75035f43981c@github.com>

On Wed, 28 Apr 2021 00:44:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this change to the String Deduplication facility.  It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporting GCs.
>> 
>> (The Shenandoah update was contributed by Zhengyu Gu.)
>> 
>> This change significantly simplifies the interface between a given GC and
>> the String Deduplication facility, which should make it much easier for
>> other GCs to opt in.  However, this change does not alter the set of GCs
>> providing support; currently only G1 and Shenandoah support string
>> deduplication.  Adding support by other GCs will be in followup RFEs.
>> 
>> Reviewing via the diffs might not be all that useful for some parts, as
>> several files have been essentially completely replaced, and a number of
>> files have been added or eliminated.  The full webrev might be a better
>> place to look.
>> 
>> The major changes are in gc/shared/stringdedup/* and in the supporting
>> collectors, but there are also some smaller changes in other places, most
>> notably classfile/{stringTable,javaClasses}.
>> 
>> This change is additionally labeled for review by core-libs, although there
>> are no source changes there.  This change injects a byte field of bits into
>> java.lang.String, using one of the previously unused padding bytes in that
>> class.  (There were two unused bytes, now only one.)
>> 
>> Testing:
>> mach5 tier1-2 with and without -XX:+UseStringDeduplication
>> 
>> Locally (linux-x64) ran all of the existing tests that use string
>> deduplication with both G1 and Shenandoah.  Note that
>> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
>> currently fails, for reasons I haven't figured out but suspect are test
>> related.
>> 
>> - gc/stringdedup/   -- these used to be in gc/g1
>> - runtime/cds/SharedStringsDedup.java
>> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
>> - runtime/cds/appcds/sharedStrings/*
>> 
>> shenandoah-only:
>> - gc/shenandoah/jvmti/TestHeapDump.java
>> - gc/shenandoah/TestStringDedup.java
>> - gc/shenandoah/TestStringDedupStress.java
>> 
>> Performance tested baseline, baseline + stringdedup, new with stringdedup,
>> finding no significant differences.
>
> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 557:
> 
>> 555:     // non-latin1, and deduplicating if we find a match.  For deduplication we
>> 556:     // only care if the arrays consist of the same sequence of bytes.
>> 557:     const jchar* chars = static_cast<jchar*>(value->base(T_CHAR));
> 
> The encoding of the shared strings always match CompactStrings. Otherwise the CDS archive will fail to map. E.g.,
> 
> 
> $ java -XX:-CompactStrings -Xshare:dump 
> $ java -XX:+CompactStrings -Xlog:cds -version
> ...
> [0.032s][info][cds] UseSharedSpaces: The shared archive file's CompactStrings 
>                     setting (disabled) does not equal the current CompactStrings setting (enabled).
> [0.032s][info][cds] UseSharedSpaces: Unable to map shared spaces
> ...
> 
> 
> So you can avoid this `if` block when `CompactStrings == true`. The `!java_lang_String::is_latin1(found)` check below can be changed to an assert.
> 
> Also, I think we need an explicit test case where you'd return `true` at line 564. I can write a new test case and email to you. I think it will involve dumping an archive with `-XX:-CompactStrings`.

Oh, I realized that my suggestion above is wrong. When `CompactStrings==true`, you can still have a string whose coder is UTF16:

https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.base/share/classes/java/lang/String.java#L343-L351

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From github.com+10835776+stsypanov at openjdk.java.net  Wed Apr 28 07:30:53 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 28 Apr 2021 07:30:53 GMT
Subject: RFR: 8265418: Clean-up redundant null-checks of
 Class.getPackageName()
In-Reply-To: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
References: <CGvkiJ4hiCj0mUDWtjoVFar0cCznIIuw6nElX6gaAew=.3f1bf704-4d84-4b40-a4f2-48c133d9d943@github.com>
Message-ID: <SQprqS_SbUulKxSyBRy-Z5OwaYnCpr26VF7_UUSEQGc=.0295da7c-1951-425b-97c6-a1b6dca23b4d@github.com>

On Mon, 19 Apr 2021 14:05:31 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null.

Oh, now I see my mistake, I believed that after `pn.intern()` is called variable `pn` can be used along with returned value. Thanks for explanation!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3571

From alanb at openjdk.java.net  Wed Apr 28 07:44:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 28 Apr 2021 07:44:50 GMT
Subject: RFR: JDK-8265773: incorrect jdeps message "jdk8internals" to
 describe a removed JDK internal API
In-Reply-To: <blCgr1AQAqA6r0xpRGnd2HsBIUxK2mnCloDy-lCgnN4=.c00216ab-4a0a-49f8-8d24-738a102cc186@github.com>
References: <blCgr1AQAqA6r0xpRGnd2HsBIUxK2mnCloDy-lCgnN4=.c00216ab-4a0a-49f8-8d24-738a102cc186@github.com>
Message-ID: <cDGh5RwBm1ixDyX-f0qDED5jlLem7Osl20g74lkCq7Q=.61ef3145-0e34-45ec-a083-93e656f91066@github.com>

On Wed, 28 Apr 2021 01:11:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> jdeps should print "JDK removed internal APIs" to give an informative description when a JDK internal API that is being referenced has been removed.  JDK-8213909 incorrectly changed it to print `jdk8internals`.
> 
> An example output is:
> 
> 
> classes -> jdk8internals
>    p.Main                                             -> sun.misc.Service                                      JDK removed internal API
>    p.Main                                             -> sun.misc.SoftCache                                 JDK removed internal API

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3741

From chegar at openjdk.java.net  Wed Apr 28 08:22:52 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Apr 2021 08:22:52 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator)
In-Reply-To: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com>
Message-ID: <L7XeCk-YX6SmwyXJDDOYrowlXUCgq6DABx4BNz4I8yI=.2787454d-b6ae-4426-831b-75f64b9ed7af@github.com>

On Tue, 27 Apr 2021 18:40:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466:
> 
>> 464:     }
>> 465: 
>> 466:     private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess();
> 
> It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil.

I went back and forth on this a number of times already. I think where we landed is a reasonable place, given the current shape of the code.

Scope is a private property of Buffer, and as such should be consulted anywhere where a buffer's address is being accessed. In fact, a prior prototype would not allow access to the underlying address value without the caller passing a valid handle for the buffer view's scope. It's hard to find the sweet-spot here between code reuse and safety, but the high-order bit is that the code accessing the address is auditable and testable to avoid accessing memory unsafely. Maybe there is a better alternative implementation code structure (at the cost of some duplication), but it is not obvious to me what that is (and I have given it some thought). Suggestions welcome.

Note, there is a little more follow-on work to be done in this area, if we are to expand support to other non-TCP channel implementations. Maybe investigation into possible code refactorings could be done as part of that?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From peter.levart at gmail.com  Wed Apr 28 09:10:17 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 28 Apr 2021 11:10:17 +0200
Subject: ReversibleCollection proposal
In-Reply-To: <6393cd77-df67-15e4-6419-7ceb725d2a50@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <CACzrW9B0Ns-4+Ff+PFBWV8b0Anj9PWC9eV_v_Q3qwb0Fxn2GSA@mail.gmail.com>
 <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
 <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>
 <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>
 <85906d24-f9c8-1b6f-77c0-b8cf5ca48457@gmail.com>
 <6f0d7d03-ec96-b204-7252-efe413792073@oracle.com>
 <b112dcad-3839-fdfd-437e-5d7287f0063c@gmail.com>
 <6393cd77-df67-15e4-6419-7ceb725d2a50@oracle.com>
Message-ID: <b9111a11-69c4-053f-7711-16763dcec944@gmail.com>


On 4/28/21 2:04 AM, Stuart Marks wrote:
>> Binary compatibility is important. And I guess there is a variant of 
>> the proposal that includes ReversibleCollection and ReversibleSet and 
>> is binary compatible.
>
> Yes, the source incompatibilities with the types seem to involve type 
> inference (e.g., use of var choosing differently based on new types in 
> the library) so it should be possible to make minor source code 
> changes to adjust or override the type that's inferred.
>
> On binary compatibility, that comes mostly from the newly introduced 
> methods (reversed, addFirst etc.) and from adding covariant overrides 
> to LinkedHashSet. I guess the "variant" you mention is adding new 
> methods with the new return types (e.g., reversibleEntrySet) instead 
> of covariant overrides. Or was it something else? 


Right, either adding new method with different name or not doing 
anything (left to user to insert a cast). As you already pointed out, 
introduction of NavigableSet/NavigableMap opted for new method name: 
(navigableKeySet) and new method parameters (subMap, headMap, tailMap) 
which were actually useful. So this trick might also bi applicable here:


public interface SortedMap/LinkedHashMap<K, V> {

 ??? ReversibleSet<Entry<K, V>> entrySet(boolean reversed);

 ??? ReversibleSet<K> keySet(boolean reversed);

 ??? ReversibleCollection<V> values(boolean reversed);



So you would say:

 ??? map.keySet(false) or map.keySet(true)

instead of:

 ??? map.reversibleKeySet() or map.reversibleKeySet().reversed()


The later is more readable, but nowadays almost everybody uses IDE(s), 
so they see the following for the former:

 ??? map.keySet(reversed: false) or map.keySet(reversed: true)


Peter



Peter



From chegar at openjdk.java.net  Wed Apr 28 09:14:53 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Apr 2021 09:14:53 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator)
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <tWptFGBzCBWOANAM1Xef8rJ44CRwfTlGtdcAj7ClMx4=.d84f1251-7f2c-4a30-a8d5-4b6ff746c7d1@github.com>

On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 135:

> 133: } finally {
> 134:    segment.scope().release(segmentHandle);
> 135: }

I do like the symmetry in this example, but just to add an alternative idiom:
    `segmentHandle.scope().release(segmentHandle)`
, which guarantees to avoid release throwing and IAE

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 186:

> 184:      *     <li>this resource scope is confined, and this method is called from a thread other than the thread owning this resource scope</li>
> 185:      *     <li>this resource scope is shared and a resource associated with this scope is accessed while this method is called</li>
> 186:      *     <li>one or more handles (see {@link #acquire()}) associated with this resource scope have not been closed</li>

Minor spec suggestion: "... associated with this resource scope have not been *released*"

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 205:

> 203:      * until all the resource scope handles acquired from it have been {@link #release(Handle)} released}.
> 204:      * @return a resource scope handle.
> 205:      */

Given recent changes, it might be good to generalise the opening sentence here. Maybe :
 " Acquires a resource scope handle associated with this resource scope. If the resource scope is explicit ... "   Or some such.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 10:20:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 10:20:53 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator)
In-Reply-To: <tWptFGBzCBWOANAM1Xef8rJ44CRwfTlGtdcAj7ClMx4=.d84f1251-7f2c-4a30-a8d5-4b6ff746c7d1@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <tWptFGBzCBWOANAM1Xef8rJ44CRwfTlGtdcAj7ClMx4=.d84f1251-7f2c-4a30-a8d5-4b6ff746c7d1@github.com>
Message-ID: <b2RSJYnb4NLSOG9p0NSG8_UMGZgTgav9dTjJZ_y7LSg=.855577d8-80fd-41bb-bb86-a80622c47e24@github.com>

On Wed, 28 Apr 2021 09:06:29 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 205:
> 
>> 203:      * until all the resource scope handles acquired from it have been {@link #release(Handle)} released}.
>> 204:      * @return a resource scope handle.
>> 205:      */
> 
> Given recent changes, it might be good to generalise the opening sentence here. Maybe :
>  " Acquires a resource scope handle associated with this resource scope. If the resource scope is explicit ... "   Or some such.

I'm afraid I don't get this comment ;-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From github.com+73799211+gregcawthorne at openjdk.java.net  Wed Apr 28 10:34:51 2021
From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne)
Date: Wed, 28 Apr 2021 10:34:51 GMT
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10,
 dexp iff 2.29 or greater on AArch64.
In-Reply-To: <3L8L5wzGgohp-2AXzFWxNCCKI4KsBLUUfOqHJ8lUc74=.77b833de-e3f0-41b5-a060-c731031bd9a5@github.com>
References: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
 <3L8L5wzGgohp-2AXzFWxNCCKI4KsBLUUfOqHJ8lUc74=.77b833de-e3f0-41b5-a060-c731031bd9a5@github.com>
Message-ID: <HXdjWgVWeFwv26LB0rcDSJuluRvGmNPrJvl9n2e1JG0=.c3084967-e475-460b-a1e3-0858be04b125@github.com>

On Wed, 28 Apr 2021 09:25:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Re monotonicity: all is not necessarily lost. There's a theorem due to Ferguson and Brightman which says that
> 
> ```
> if
>          abs(f(m+) - f(m))
> eps < -----------------------
>       abs(f(m+)) + abs(f(m))'
> 
> for all m, the approximation is monotone.
> 
> m is the machine number, m+ its successor
> eps the maximum relative error of the approximation f(m)
> ```
> 
> See
> http://www-leland.stanford.edu/class/ee486/doc/ferguson1991.pdf, particularly the Appendix, which contains a table of expressions for the five basic transcendental functions.

We can definitely be checked for single precision! I am uncertain how much water that would hold.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3510

From mcimadamore at openjdk.java.net  Wed Apr 28 10:42:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 10:42:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <tWptFGBzCBWOANAM1Xef8rJ44CRwfTlGtdcAj7ClMx4=.d84f1251-7f2c-4a30-a8d5-4b6ff746c7d1@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <tWptFGBzCBWOANAM1Xef8rJ44CRwfTlGtdcAj7ClMx4=.d84f1251-7f2c-4a30-a8d5-4b6ff746c7d1@github.com>
Message-ID: <d1pcParsPDlmy98fukYT0cdxpUr-8eAJpXUqFRE6LQM=.ff91bb78-0938-4ac6-88bc-7dbc73924f98@github.com>

On Wed, 28 Apr 2021 09:10:37 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address first batch of review comments
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 135:
> 
>> 133: } finally {
>> 134:    segment.scope().release(segmentHandle);
>> 135: }
> 
> I do like the symmetry in this example, but just to add an alternative idiom:
>     `segmentHandle.scope().release(segmentHandle)`
> , which guarantees to avoid release throwing and IAE

I see what you mean - I don't think I want to encourage that style too much by giving it prominence in the javadoc. It's true you can go back to the scope from the handle, so that you are guaranteed to release the right thing, but I think that should be unnecessary in most idiomatic uses.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 10:42:54 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 10:42:54 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address first batch of review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/7545f71f..a80d8180

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=00-01

  Stats: 42 lines in 4 files changed: 25 ins; 11 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From chegar at openjdk.java.net  Wed Apr 28 10:42:56 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Apr 2021 10:42:56 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <tWptFGBzCBWOANAM1Xef8rJ44CRwfTlGtdcAj7ClMx4=.d84f1251-7f2c-4a30-a8d5-4b6ff746c7d1@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <tWptFGBzCBWOANAM1Xef8rJ44CRwfTlGtdcAj7ClMx4=.d84f1251-7f2c-4a30-a8d5-4b6ff746c7d1@github.com>
Message-ID: <jSy399Se-f4k46eyRwLkzmrQZmj0q5DVByg7hvZxxtM=.6affc49d-7867-4e24-829b-a3c5b102596e@github.com>

On Wed, 28 Apr 2021 09:06:29 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address first batch of review comments
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 205:
> 
>> 203:      * until all the resource scope handles acquired from it have been {@link #release(Handle)} released}.
>> 204:      * @return a resource scope handle.
>> 205:      */
> 
> Given recent changes, it might be good to generalise the opening sentence here. Maybe :
>  " Acquires a resource scope handle associated with this resource scope. If the resource scope is explicit ... "   Or some such.

The spec for the acquire method talks only of explicit resource scopes. The comment is suggesting that the spec could be generalised a little, since it is possible to acquire a resource scope handle associated with implicit scopes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From forax at univ-mlv.fr  Wed Apr 28 12:08:42 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 28 Apr 2021 14:08:42 +0200 (CEST)
Subject: ReversibleCollection proposal
In-Reply-To: <6393cd77-df67-15e4-6419-7ceb725d2a50@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <649523484.391268.1619096317174.JavaMail.zimbra@u-pem.fr>
 <CACzrW9Bp2xCRymYX_BA0j0zTmp8bRp-9-fZFK24TMYMrjr3=Bg@mail.gmail.com>
 <8ab6e7e5-08cc-1757-8afb-4abf87a1ec9f@oracle.com>
 <85906d24-f9c8-1b6f-77c0-b8cf5ca48457@gmail.com>
 <6f0d7d03-ec96-b204-7252-efe413792073@oracle.com>
 <b112dcad-3839-fdfd-437e-5d7287f0063c@gmail.com>
 <6393cd77-df67-15e4-6419-7ceb725d2a50@oracle.com>
Message-ID: <1756963369.2051247.1619611722942.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> ?: "Peter Levart" <peter.levart at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Stephen Colebourne" <scolebourne at joda.org>
> Envoy?: Mercredi 28 Avril 2021 02:04:22
> Objet: Re: ReversibleCollection proposal

> On 4/27/21 2:25 AM, Peter Levart wrote:
>> Right, I'm persuaded. Now if only the problems of transition to the usage of new
>> type that Remi is worried about were mild enough. Source (in)compatibility is
>> not
>> that important if workarounds exist that are also backwards source compatible so
>> that the same codebase can be compiled with different JDKs. Binary compatibility
>> is
>> important. And I guess there is a variant of the proposal that includes
>> ReversibleCollection and ReversibleSet and is binary compatible.
> 
> Yes, the source incompatibilities with the types seem to involve type inference
> (e.g., use of var choosing differently based on new types in the library) so it
> should be possible to make minor source code changes to adjust or override the
> type
> that's inferred.
> 
> On binary compatibility, that comes mostly from the newly introduced methods
> (reversed, addFirst etc.) and from adding covariant overrides to LinkedHashSet.
> I
> guess the "variant" you mention is adding new methods with the new return types
> (e.g., reversibleEntrySet) instead of covariant overrides. Or was it something
> else?

Yes, you need type inference (compute lub), var is not necessary,
after all
  var a = f();
  g(a)
is equivalent to
  g(f())

So you have an issue with varargs like T..., any method that takes two T like m(T, T), or with the ternary operator ?:

At best you have a source compatibility issue, at worst, you have a runtime error or a runtime slowdown.
This is something that have not been study well but the worst scenario is when a VarHandle or a MethodHandle is involved IMO,
because a call like methodHandle.invokeExact() or VarHandle.compareAndSet will still compile if the inferred type changed but at runtime at best you will have a WrongMethodTypeException, at worst it will still work but performance will fall of the cliff.

But maybe nobody has ever written a code like
  methodHandle.invoke(flag? list: linkedHashMap)

Also the source compatibility issues are not only restricted to Java
- source compatiblity can also be a bigger issue than it was before for people that are using jshell/java as a shell script. 
- and what about the other JVM languages that are using the collection API, mostly Groovy and Kotlin because they are leveraging inference far more than in Java.
  Scala tends to use Scala collection, and Clojure or JRuby are dynamically typed so it should not be less an issue.

> 
> s'marks

R?mi

From forax at univ-mlv.fr  Wed Apr 28 12:20:37 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 28 Apr 2021 14:20:37 +0200 (CEST)
Subject: ReversibleCollection proposal
In-Reply-To: <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr>
 <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>
Message-ID: <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 23 Avril 2021 08:56:53
> Objet: Re: ReversibleCollection proposal

>> An API can not use ReversibleCollection as parameter before all the
>> implementations of Collection that have an ordering are updated to implement
>> ReversibleCollection instead of Collection.
>> 
>> By example, if I add a method
>>    public void foo(ReversibleCollection c)
>> in my library, people that want to be able to use foo with an existing
>> collection with an ordering have to wait that collection implementation to be
>> updated.
>> 
>> So i will not add a method like foo in my API until enough (whatever enough
>> means) implementation of Collection with an ordering have migrated.
>> 
>> This is a similar issue as the migration from Python 2 to Python 3, it takes at
>> least 10 years, so in 10 years, I will be able to had a public method that
>> takes a ReversibleCollection in my API,
>> without people not be able to using it.
> 
> This is a gigantic overstatement of the issue.
> 
> It is true that an API *in the JDK* as a practical matter cannot change a
> Collection
> parameter to ReversibleCollection, because it will break any callers that are
> currently passing Collection. The same is true of any library APIs where
> compatibility is a concern.
> 
> However, it can be quite useful in many contexts to use ReversibleCollection as
> a
> parameter. Newly introduced APIs can use ReversibleCollection. Certain APIs that
> consume List could reasonably be adjusted to consume a ReversibleCollection
> instead.
> (More likely an overload would probably be added in order to preserve binary
> compatibility.) 

You did not really answer to the real question, why should i use ReversibleCollection instead of a Collection as parameter.
You said that it's a better type because you can not send a HashSet, but as i said, sending a HashSet of 0 or 1 element is perfectly valid.
For me, we are not far from, it's typechecking for the sake of typechecking.
This can be an interesting exercise for my students but it is not really a goal in Java, we have Haskell and Scala for that.

I see the point of having getFirst()/getLast() or descendingSet() on LinkedHashMap (your right that getFirst() on Collection should be getAny()),
I don't see the point of using ReversibleCollection as a type of a parameter, there is no algorithm that uses a ReversibleCollection as parameter in the litterature.

> 
> s'marks

R?mi

From dholmes at openjdk.java.net  Wed Apr 28 12:45:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 28 Apr 2021 12:45:49 GMT
Subject: RFR: 8266173: -Wmaybe-uninitialized happens in jni_util.c
In-Reply-To: <YKE53C7bOXZe3cs1fXHRyEMjwFY0bOMTOnk2CsEO9gI=.0df40377-15e0-4eb2-a263-01a8617b01f2@github.com>
References: <YKE53C7bOXZe3cs1fXHRyEMjwFY0bOMTOnk2CsEO9gI=.0df40377-15e0-4eb2-a263-01a8617b01f2@github.com>
Message-ID: <phn0fMeR18PxB0HuClZsLsK_PnWt4q7xkYHVaVZFOvU=.4b7fca0e-b705-4f35-ab28-8a43b987b100@github.com>

On Wed, 28 Apr 2021 01:20:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can see compiler warnings in jni_util.c as following on GCC 11. `buf` should be initialized.

Seems ok.

src/java.base/share/native/libjava/jni_util.c line 465:

> 463: {
> 464:     int len = (int)strlen(str);
> 465:     jchar buf[512] = {0};

Seems harmless, but a spurious warning - which is to be expected I guess since the flag says "maybe".

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3742

From chegar at openjdk.java.net  Wed Apr 28 13:12:55 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Apr 2021 13:12:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
Message-ID: <WEoMxZ1dLnj7l5yctTJE6B5oVkVhq590e2b29ZtKw7Q=.0a5d5258-83e9-44ff-8b99-9e8d0557311a@github.com>

On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address first batch of review comments

Like Paul, I tracked the changes to this API in the Panama repo. Most of my remaining comments are small and come from re-reading the API docs.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 270:

> 268: 
> 269:     /**
> 270:      * Converts a Java string into a null-terminated C string, using the platform's default charset,

Sorry if this has come up before, but, is the platform's default charset the right choice here? For other areas, we choose UTF-8 as the default. In fact, there is a draft JEP to move the default charset to UTF-8. So if there is an implicit need to match the underlying platform's charset then this may need to be revisited.  For now, I just want to check that this is not an accidental reliance on the platform's default charset, but a deliberate one.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 101:

> 99:  * <h2>Lifecycle and confinement</h2>
> 100:  *
> 101:  * Memory segments are associated to a resource scope (see {@link ResourceScope}), which can be accessed using

Typo?? "Memory segments are associated *with* a resource scope"

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 112:

> 110: MemoryAccess.getLong(segment); // already closed!
> 111:  * }</pre></blockquote>
> 112:  * Additionally, access to a memory segment in subject to the thread-confinement checks enforced by the owning scope; that is,

Typo?? "Additionally, access to a memory segment *is* subject to ..."

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 114:

> 112:  * Additionally, access to a memory segment in subject to the thread-confinement checks enforced by the owning scope; that is,
> 113:  * if the segment is associated with a shared scope, it can be accessed by multiple threads; if it is associated with a confined
> 114:  * scope, it can only be accessed by the thread which own the scope.

Typo?? "it can only be accessed by the thread which ownS the scope."

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 693:

> 691:      */
> 692:     static MemorySegment allocateNative(MemoryLayout layout, ResourceScope scope) {
> 693:         Objects.requireNonNull(scope);

Should the allocateNative methods declare that they throw ISE, if the given ResourceScope is not alive?   ( I found myself asking this q, then considering the behaviour of a SegmentAllocator that is asked to allocate after a RS has been closed )

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3699

From henri.tremblay at gmail.com  Wed Apr 28 13:23:43 2021
From: henri.tremblay at gmail.com (Henri Tremblay)
Date: Wed, 28 Apr 2021 09:23:43 -0400
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>
References: <38af-60883900-4c5-3a732100@161619996>
 <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>
Message-ID: <CADZL2=ty7C7A_L0jVsZGmNou+SqeYoyiBquBAe9jm22ZUoCYCw@mail.gmail.com>

Hi,

(I think the first version of this message never went through, so here it
goes just in case)

I just read quickly the proposal and it made me think about another common
issue. I wonder if we could tackle it as well.
I will call it the "find the first element when there is only one" problem.
It happens on unordered collections like a HashSet. It forces to do

Set<String> s = new HashSet<>();
if (s.size() == 1) {
   return s.iterator().next();
   // or
   return s.stream().findFirst().get();
}

Which is a lot of ugliness and object instantiations just to get the first
element.
I would be nice to have a public T findFirst() directly on Iterable<T>.
With a default implementation returning iterator().next(). Things like
ArrayList will want to override will return elementData[0]. It would return
null when the list is empty. Or NoSuchElementException.
It needs to be polished of course but will that be acceptable?

Thanks,
Henri

From coffeys at openjdk.java.net  Wed Apr 28 13:35:52 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 28 Apr 2021 13:35:52 GMT
Subject: RFR: 8183374: Refactor java/lang/Runtime shell tests to java
In-Reply-To: <8RGdfm-WomCVRb2rHh4JJylflepR5_FC0zsMvMznlDc=.7cf373c7-9ecc-48b7-9ae8-033fc39d2527@github.com>
References: <8RGdfm-WomCVRb2rHh4JJylflepR5_FC0zsMvMznlDc=.7cf373c7-9ecc-48b7-9ae8-033fc39d2527@github.com>
Message-ID: <YyZH_jrnlg--QpBhxLGjFsEY5Xig54dAwE0PGv8YSCQ=.0ef91c7c-85a5-42cf-89a1-b8cbe9c232cb@github.com>

On Mon, 19 Apr 2021 15:07:16 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Refactor the following shell tests to java:
> test/jdk/java/lang/RuntimeTests/shutdown/ShutdownHooks.sh
> test/jdk/java/lang/Runtime/exec/SetCwd.java
> 
> In addition, the test SetCwd was running itself in separate java subprocesses in order to exercise Runtime.exec. It was creating a folder structure with multiple test class copies to distinguish between main and child processes to prevent an infinite recursion. That logic is simplified now, tests follow the testng annotations flow whereas the subprocesses entry point is a nested class main

Marked as reviewed by coffeys (Reviewer).

Looks fine to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3572

From mcimadamore at openjdk.java.net  Wed Apr 28 13:45:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 13:45:53 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <WEoMxZ1dLnj7l5yctTJE6B5oVkVhq590e2b29ZtKw7Q=.0a5d5258-83e9-44ff-8b99-9e8d0557311a@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <WEoMxZ1dLnj7l5yctTJE6B5oVkVhq590e2b29ZtKw7Q=.0a5d5258-83e9-44ff-8b99-9e8d0557311a@github.com>
Message-ID: <P3jVZzojl_jgrmyTRLuJ90KteoMWW0NQfB6F13Tin-8=.4ec989ef-d6aa-46f2-a5a2-a996c89ad8cf@github.com>

On Wed, 28 Apr 2021 13:08:26 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address first batch of review comments
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 693:
> 
>> 691:      */
>> 692:     static MemorySegment allocateNative(MemoryLayout layout, ResourceScope scope) {
>> 693:         Objects.requireNonNull(scope);
> 
> Should the allocateNative methods declare that they throw ISE, if the given ResourceScope is not alive?   ( I found myself asking this q, then considering the behaviour of a SegmentAllocator that is asked to allocate after a RS has been closed )

Good point, yes it should

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 13:50:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 13:50:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <WEoMxZ1dLnj7l5yctTJE6B5oVkVhq590e2b29ZtKw7Q=.0a5d5258-83e9-44ff-8b99-9e8d0557311a@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <WEoMxZ1dLnj7l5yctTJE6B5oVkVhq590e2b29ZtKw7Q=.0a5d5258-83e9-44ff-8b99-9e8d0557311a@github.com>
Message-ID: <vk_LJqGjFiLxp4EljigstAVCfrgsJFdCOVh-7JqjjoA=.dc0c5c3d-f469-4565-b867-bb079db234b9@github.com>

On Wed, 28 Apr 2021 12:47:36 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address first batch of review comments
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 270:
> 
>> 268: 
>> 269:     /**
>> 270:      * Converts a Java string into a null-terminated C string, using the platform's default charset,
> 
> Sorry if this has come up before, but, is the platform's default charset the right choice here? For other areas, we choose UTF-8 as the default. In fact, there is a draft JEP to move the default charset to UTF-8. So if there is an implicit need to match the underlying platform's charset then this may need to be revisited.  For now, I just want to check that this is not an accidental reliance on the platform's default charset, but a deliberate one.

I believe here the goal is to be consistent with `String::getBytes`:


/**
     * Encodes this {@code String} into a sequence of bytes using the
     * platform's default charset, storing the result into a new byte array.
     *
     * <p> The behavior of this method when this string cannot be encoded in
     * the default charset is unspecified.  The {@link
     * java.nio.charset.CharsetEncoder} class should be used when more control
     * over the encoding process is required.
     *
     * @return  The resultant byte array
     *
     * @since      1.1
     */
    public byte[] getBytes() {
        return encode(Charset.defaultCharset(), coder(), value);
    }


So, you are right in that there's an element of platform-dependency here - but I think it's a dependency that users learned to "ignore" mostly. If developers want to be precise, and platform independent, they can always use the Charset-accepting method. Of course this could be revisited, but I think there is some consistency in what the API is trying to do. If, in the future, defaultCharset will just be Utf8 - well, that's ok too - as long as the method is specified to be "defaultCharset" dependent, what's behind "defaultCharset" is an implementation detail that the user will have to be aware of one way or another.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From peter.levart at gmail.com  Wed Apr 28 13:54:50 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 28 Apr 2021 15:54:50 +0200
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>
References: <38af-60883900-4c5-3a732100@161619996>
 <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>
Message-ID: <056b8d18-3ccf-3dac-d64f-07bd2c586752@gmail.com>


On 4/28/21 7:19 AM, Stuart Marks wrote:
>
>
> On 4/27/21 9:17 AM, Anthony Vanelverdinghe wrote:
>> On Tuesday, April 27, 2021 11:25 CEST, Peter Levart 
>> <peter.levart at gmail.com> wrote:
>>> Now just some of my thoughts about the proposal:
>>>
>>> - SortedSet.addFirst/.addLast - I think an operation that would be used
>>> in situations like: "I know this element should always be greater than
>>> any existing element in the set and I will push it to the end which
>>> should also verify my assumption" is a perfectly valid operation. So
>>> those methods throwing IllegalStateException in case the invariant 
>>> can't
>>> be kept seem perfectly fine to me.
>>
>> This was raised before and addressed by Stuart in [0]:
>> "An alternative as you suggest might be that 
>> SortedSet::addFirst/addLast could throw
>> something like IllegalStateException if the element is wrongly 
>> positioned.
>> (Deque::addFirst/addLast will throw ISE if the addition would exceed 
>> a capacity
>> restriction.) This seems error-prone, though, and it's easier to 
>> understand and
>> specify that these methods simply throw UOE unconditionally. If 
>> there's a good use
>> case for the alternative I'd be interested in hearing it though."
>
> Yes, to be clear, it was Stephen Coleborne who raised this previously 
> [1] and it's my response that's quoted above.
>
> Some further thoughts on this.
>
> This is an example where, depending on the current state of the 
> collection, the method might throw or it might succeed. This is useful 
> in concurrent collections (such as the capacity-restricted Deque 
> above), where the caller cannot check preconditions beforehand, 
> because they might be out of date by the time the operation is 
> attempted. In such cases the caller might not want to block, but 
> instead it might catch the exception and report an error to its caller 
> (or drop the request). Thus, calling the exception-throwing method is 
> appropriate.
>
> Something like SortedSet::addLast seems different, though. The state 
> is the *values* of the elements already in the collection. This is 
> something that can easily be checked, and probably should be checked 
> beforehand:
>
> ??? if (sortedSet.isEmpty() || sortedSet.last().compareTo(e) <= 0)
> ??????? sortedSet.add(e);
> ??? else
> ??????? // e wouldn't be the last element, do something different


I was thinking more of a case where the else branch would actually throw 
IllegalStateException and do nothing else - a kind of add with 
precondition check. A precondition in the sense of 
Objects.requireNonNull(). I can't currently think of a real usecase now, 
so this kind of operation is probably very rare. Probably not useful 
since if you're adding to SortedSet, the order of elements added should 
not matter because SortedSet will sort them. If you just want to check 
the order of elements added and you are not willing to pay the price of 
SortedSet, you will be adding them to a List or LinkedHashSet, but then 
the method would not do the check...


>
> Now this is a fair bit of code, and it would be shorter just to call 
> sortedSet.addLast(e). But does that actually help? What if e is 
> already in the set and is the last element?


In that case the operation would be a no-op (or it would replace the 
element with the parameter - a slight difference as the element can be 
.equals() but not the same instance).


> Is catching an exception really what we want to do if e wouldn't be 
> the last element? Maybe we'd want to do nothing instead. If so, 
> catching an exception in order to do nothing is extra work.


I was only thinking of situations where propagating the exception would 
be the desired thing.


>
> Again, I'd like to hear about use cases for a conditionally-throwing 
> version of addLast et. al. I don't want to be limited by failure of 
> imagination, but it does seem like this kind of behavior would be 
> useful only in a narrow set of cases where it happens to do exactly 
> the right thing. Otherwise, it just gets in the way, and its behavior 
> is pretty obscure. So, color me skeptical.


Right, I don't know how common such operation would be. Probably not very.


Peter

which are a continual source of errors.)

>
> I'll think about this more, but it doesn't seem promising.
>
> s'marks

From fguallini at openjdk.java.net  Wed Apr 28 14:03:59 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Wed, 28 Apr 2021 14:03:59 GMT
Subject: Integrated: 8183374: Refactor java/lang/Runtime shell tests to java
In-Reply-To: <8RGdfm-WomCVRb2rHh4JJylflepR5_FC0zsMvMznlDc=.7cf373c7-9ecc-48b7-9ae8-033fc39d2527@github.com>
References: <8RGdfm-WomCVRb2rHh4JJylflepR5_FC0zsMvMznlDc=.7cf373c7-9ecc-48b7-9ae8-033fc39d2527@github.com>
Message-ID: <yLD7ZKcmLHwEvAPMS1FELHhU4wzLEf9ctSaYWLl_OyE=.9bb98f6c-40eb-4a93-8baf-f545f565e441@github.com>

On Mon, 19 Apr 2021 15:07:16 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Refactor the following shell tests to java:
> test/jdk/java/lang/RuntimeTests/shutdown/ShutdownHooks.sh
> test/jdk/java/lang/Runtime/exec/SetCwd.java
> 
> In addition, the test SetCwd was running itself in separate java subprocesses in order to exercise Runtime.exec. It was creating a folder structure with multiple test class copies to distinguish between main and child processes to prevent an infinite recursion. That logic is simplified now, tests follow the testng annotations flow whereas the subprocesses entry point is a nested class main

This pull request has now been integrated.

Changeset: ec383abc
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec383abc1d2e609cc6af94a526e11c407d7e91ff
Stats:     232 lines in 4 files changed: 67 ins; 121 del; 44 mod

8183374: Refactor java/lang/Runtime shell tests to java

Reviewed-by: coffeys

-------------

PR: https://git.openjdk.java.net/jdk/pull/3572

From zgu at openjdk.java.net  Wed Apr 28 14:48:05 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 28 Apr 2021 14:48:05 GMT
Subject: RFR: 8254598: StringDedupTable should use OopStorage
In-Reply-To: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
References: <KHHigOfbKnW853BMooJq-YCH7UJEJVw_AVxxp9LYHpM=.55192adc-111f-48bb-ac59-9a5046e8020d@github.com>
Message-ID: <xGjqiPgJSwWEzXIZFFjqHBVvo8q24f18Jqtlsag0jNg=.c2d94f1d-1399-443d-ab62-80080499db6d@github.com>

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the String Deduplication facility.  It is being
> changed to use OopStorage to hold weak references to relevant objects,
> rather than bespoke data structures requiring dedicated processing phases by
> supporting GCs.
> 
> (The Shenandoah update was contributed by Zhengyu Gu.)
> 
> This change significantly simplifies the interface between a given GC and
> the String Deduplication facility, which should make it much easier for
> other GCs to opt in.  However, this change does not alter the set of GCs
> providing support; currently only G1 and Shenandoah support string
> deduplication.  Adding support by other GCs will be in followup RFEs.
> 
> Reviewing via the diffs might not be all that useful for some parts, as
> several files have been essentially completely replaced, and a number of
> files have been added or eliminated.  The full webrev might be a better
> place to look.
> 
> The major changes are in gc/shared/stringdedup/* and in the supporting
> collectors, but there are also some smaller changes in other places, most
> notably classfile/{stringTable,javaClasses}.
> 
> This change is additionally labeled for review by core-libs, although there
> are no source changes there.  This change injects a byte field of bits into
> java.lang.String, using one of the previously unused padding bytes in that
> class.  (There were two unused bytes, now only one.)
> 
> Testing:
> mach5 tier1-2 with and without -XX:+UseStringDeduplication
> 
> Locally (linux-x64) ran all of the existing tests that use string
> deduplication with both G1 and Shenandoah.  Note that
> TestStringDeduplicationInterned.java is disabled for shenandoah, as it
> currently fails, for reasons I haven't figured out but suspect are test
> related.
> 
> - gc/stringdedup/   -- these used to be in gc/g1
> - runtime/cds/SharedStringsDedup.java
> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java
> - runtime/cds/appcds/sharedStrings/*
> 
> shenandoah-only:
> - gc/shenandoah/jvmti/TestHeapDump.java
> - gc/shenandoah/TestStringDedup.java
> - gc/shenandoah/TestStringDedupStress.java
> 
> Performance tested baseline, baseline + stringdedup, new with stringdedup,
> finding no significant differences.

Just FYI:
Concurrent GC, such as Sheanndoah and ZGC (if it decides to implement string deduplication in the future), can not enqueue candidates during concurrent thread root scanning, because of potential lock rank inversion between OopStorage lock and stack watermark lock.

src/hotspot/share/classfile/stringTable.cpp line 355:

> 353:   // Notify deduplication support that the string is being interned.  A string
> 354:   // must never be deduplicated after it has been interned.  Doing so interferes
> 355:   // with compiler optimizations don on e.g. interned string literals.

typo: don -> done

-------------

PR: https://git.openjdk.java.net/jdk/pull/3662

From bpb at openjdk.java.net  Wed Apr 28 15:29:20 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 28 Apr 2021 15:29:20 GMT
Subject: RFR: 8266078: Reader.read(CharBuffer) advances Reader position
 for read-only Charbuffers [v3]
In-Reply-To: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
References: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
Message-ID: <XXR3YgxI4G5E-FBrZc2ewRF8UCp3cwKBAzZdlK3rRG4=.8d9bd0bb-c230-4f4c-897c-f882aa580a75@github.com>

> Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8266078: Remove confusing comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3725/files
  - new: https://git.openjdk.java.net/jdk/pull/3725/files/4a899b26..8935981a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3725&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3725&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3725.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3725/head:pull/3725

PR: https://git.openjdk.java.net/jdk/pull/3725

From chegar at openjdk.java.net  Wed Apr 28 15:40:54 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Apr 2021 15:40:54 GMT
Subject: RFR: 8266078: Reader.read(CharBuffer) advances Reader position
 for read-only Charbuffers [v3]
In-Reply-To: <XXR3YgxI4G5E-FBrZc2ewRF8UCp3cwKBAzZdlK3rRG4=.8d9bd0bb-c230-4f4c-897c-f882aa580a75@github.com>
References: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
 <XXR3YgxI4G5E-FBrZc2ewRF8UCp3cwKBAzZdlK3rRG4=.8d9bd0bb-c230-4f4c-897c-f882aa580a75@github.com>
Message-ID: <tpfb2LY8SxQEjW4cxflNMoanVTb6-fVa0T1g5J15W-I=.b97fc9bc-bd08-4a86-8ed6-98b1050f69c3@github.com>

On Wed, 28 Apr 2021 15:29:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266078: Remove confusing comment

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3725

From chegar at openjdk.java.net  Wed Apr 28 15:45:51 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Apr 2021 15:45:51 GMT
Subject: RFR: 8266155: Convert java.base to use Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <cEXtMAY-kmVvoUJ_CTyWpa-_X9PWs4Xy2taHH-Iuf70=.18a98221-9f65-4998-a19b-c0359c7111a0@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

Marked as reviewed by chegar (Reviewer).

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6788:

> 6786:     }
> 6787: 
> 6788:     /**

I think the import of Collectors can be dropped in this file? And maybe a few other files too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3734

From alanb at openjdk.java.net  Wed Apr 28 16:11:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 28 Apr 2021 16:11:52 GMT
Subject: RFR: 8266155: Convert java.base to use Stream.toList()
In-Reply-To: <cEXtMAY-kmVvoUJ_CTyWpa-_X9PWs4Xy2taHH-Iuf70=.18a98221-9f65-4998-a19b-c0359c7111a0@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
 <cEXtMAY-kmVvoUJ_CTyWpa-_X9PWs4Xy2taHH-Iuf70=.18a98221-9f65-4998-a19b-c0359c7111a0@github.com>
Message-ID: <uME66ILdnMw-zG9r48mdkXiWDvO4ORG8IFYYL_2aXLE=.3f41faec-818c-471c-ad70-68ca9cb2d395@github.com>

On Wed, 28 Apr 2021 15:41:31 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> 8266155: Convert java.base to use Stream.toList()
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6788:
> 
>> 6786:     }
>> 6787: 
>> 6788:     /**
> 
> I think the import of Collectors can be dropped in this file? And maybe a few other files too?

The import can be dropped from the jdk.internal.module.* classes too.

jdk.internal.module.IllegalAccessLogger will likely be removed as part of JEP 403.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3734

From alanb at openjdk.java.net  Wed Apr 28 16:17:53 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 28 Apr 2021 16:17:53 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <vk_LJqGjFiLxp4EljigstAVCfrgsJFdCOVh-7JqjjoA=.dc0c5c3d-f469-4565-b867-bb079db234b9@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <WEoMxZ1dLnj7l5yctTJE6B5oVkVhq590e2b29ZtKw7Q=.0a5d5258-83e9-44ff-8b99-9e8d0557311a@github.com>
 <vk_LJqGjFiLxp4EljigstAVCfrgsJFdCOVh-7JqjjoA=.dc0c5c3d-f469-4565-b867-bb079db234b9@github.com>
Message-ID: <0P9z_Fj6-ogctJUqlsZRC3JfOXGCbx0YLNh8me9grio=.0d53fd2d-d6b0-4c69-9da1-4781a1194405@github.com>

On Wed, 28 Apr 2021 13:47:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 270:
>> 
>>> 268: 
>>> 269:     /**
>>> 270:      * Converts a Java string into a null-terminated C string, using the platform's default charset,
>> 
>> Sorry if this has come up before, but, is the platform's default charset the right choice here? For other areas, we choose UTF-8 as the default. In fact, there is a draft JEP to move the default charset to UTF-8. So if there is an implicit need to match the underlying platform's charset then this may need to be revisited.  For now, I just want to check that this is not an accidental reliance on the platform's default charset, but a deliberate one.
>
> I believe here the goal is to be consistent with `String::getBytes`:
> 
> 
> /**
>      * Encodes this {@code String} into a sequence of bytes using the
>      * platform's default charset, storing the result into a new byte array.
>      *
>      * <p> The behavior of this method when this string cannot be encoded in
>      * the default charset is unspecified.  The {@link
>      * java.nio.charset.CharsetEncoder} class should be used when more control
>      * over the encoding process is required.
>      *
>      * @return  The resultant byte array
>      *
>      * @since      1.1
>      */
>     public byte[] getBytes() {
>         return encode(Charset.defaultCharset(), coder(), value);
>     }
> 
> 
> So, you are right in that there's an element of platform-dependency here - but I think it's a dependency that users learned to "ignore" mostly. If developers want to be precise, and platform independent, they can always use the Charset-accepting method. Of course this could be revisited, but I think there is some consistency in what the API is trying to do. If, in the future, defaultCharset will just be Utf8 - well, that's ok too - as long as the method is specified to be "defaultCharset" dependent, what's behind "defaultCharset" is an implementation detail that the user will have to be aware of one way or another.

Naoto is working on a couple of changes in advance of JEP 400. One of these is to expose a system property with the host charset and I suspect that the CLinker method will want to use that instead of Charset.defaultCharset.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From rriggs at openjdk.java.net  Wed Apr 28 16:40:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 28 Apr 2021 16:40:53 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v2]
In-Reply-To: <XazS6DYYckl9rAhHK1E58XQOlQiHFRZonhziDi2PdJg=.f2ccfef6-ed7a-4706-b3b1-2c33cbe377a3@github.com>
References: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
 <XazS6DYYckl9rAhHK1E58XQOlQiHFRZonhziDi2PdJg=.f2ccfef6-ed7a-4706-b3b1-2c33cbe377a3@github.com>
Message-ID: <naxJY_YXwanXVkwPDVCg9AD13og3WGK-FZie_oofUvY=.6d08ad33-93c7-45e9-b050-56dce6cab50f@github.com>

On Tue, 27 Apr 2021 23:07:33 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Update module summary, add a few existing properties and features into the tables.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the CSR. See Update 03 in the CSR

src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java line 264:

> 262:             int temp;
> 263:             if (Integer.class.isAssignableFrom(value.getClass())) {
> 264:                 temp = (Integer)value;

Why not use pattern matching?
`if (value instanceof Integer intValue) {
  temp = intValue;
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/3644

From igraves at openjdk.java.net  Wed Apr 28 16:57:25 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 28 Apr 2021 16:57:25 GMT
Subject: RFR: 8266155: Convert java.base to use Stream.toList() [v2]
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>

> 8266155: Convert java.base to use Stream.toList()

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Removing redundant imports

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3734/files
  - new: https://git.openjdk.java.net/jdk/pull/3734/files/3fb335e8..a0242a13

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3734&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3734&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3734.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3734/head:pull/3734

PR: https://git.openjdk.java.net/jdk/pull/3734

From iris at openjdk.java.net  Wed Apr 28 17:05:07 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Apr 2021 17:05:07 GMT
Subject: RFR: 8266155: Convert java.base to use Stream.toList() [v2]
In-Reply-To: <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
 <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>
Message-ID: <WdZDr0c5_WI91GjcAZVbdtVXZY_iStJh3ELvPofyhlE=.bc366756-3583-43b4-b1db-be2d92aed50e@github.com>

On Wed, 28 Apr 2021 16:57:25 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> 8266155: Convert java.base to use Stream.toList()
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing redundant imports

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3734

From naoto at openjdk.java.net  Wed Apr 28 17:06:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 28 Apr 2021 17:06:06 GMT
Subject: RFR: 8265918: java/io/Console/CharsetTest.java failed with "expect:
 spawn id exp6 not open"
Message-ID: <2EW1U4s4-CI2ENmVrAKGgK6paoWJcJ6FQwx8VQapBBk=.ce948652-8cc7-4d35-bce5-b0837a8830ea@github.com>

This new regression test was introduced with the Console::charset(), but it fails on ubuntu platforms assuming its locales/encoding incorrectly. To not make false-alarm/noise on test runs, this fix minimizes the tests not depending on the underlying OS's environment variables.

-------------

Commit messages:
 - 8265918: java/io/Console/CharsetTest.java failed with "expect: spawn id exp6 not open"

Changes: https://git.openjdk.java.net/jdk/pull/3768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3768&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265918
  Stats: 13 lines in 2 files changed: 0 ins; 11 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3768/head:pull/3768

PR: https://git.openjdk.java.net/jdk/pull/3768

From alanb at openjdk.java.net  Wed Apr 28 17:19:51 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 28 Apr 2021 17:19:51 GMT
Subject: RFR: 8265918: java/io/Console/CharsetTest.java failed with
 "expect: spawn id exp6 not open"
In-Reply-To: <2EW1U4s4-CI2ENmVrAKGgK6paoWJcJ6FQwx8VQapBBk=.ce948652-8cc7-4d35-bce5-b0837a8830ea@github.com>
References: <2EW1U4s4-CI2ENmVrAKGgK6paoWJcJ6FQwx8VQapBBk=.ce948652-8cc7-4d35-bce5-b0837a8830ea@github.com>
Message-ID: <G9A22GyHMi034Gpa67p9_NlCTgBDqJLCEApmwaNnwvk=.c2104009-04ce-4f4b-be5d-9d6ab1442a5a@github.com>

On Wed, 28 Apr 2021 16:58:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This new regression test was introduced with the Console::charset(), but it fails on ubuntu platforms assuming its locales/encoding incorrectly. To not make false-alarm/noise on test runs, this fix minimizes the tests not depending on the underlying OS's environment variables.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3768

From iris at openjdk.java.net  Wed Apr 28 17:23:53 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Apr 2021 17:23:53 GMT
Subject: RFR: 8265918: java/io/Console/CharsetTest.java failed with
 "expect: spawn id exp6 not open"
In-Reply-To: <2EW1U4s4-CI2ENmVrAKGgK6paoWJcJ6FQwx8VQapBBk=.ce948652-8cc7-4d35-bce5-b0837a8830ea@github.com>
References: <2EW1U4s4-CI2ENmVrAKGgK6paoWJcJ6FQwx8VQapBBk=.ce948652-8cc7-4d35-bce5-b0837a8830ea@github.com>
Message-ID: <o7PeWM3HigqQ2hsCtJjMR2C2Y8Cw24ZtxyJqmlrF7HM=.ecadbfce-1f47-463a-a2bc-543746b129a7@github.com>

On Wed, 28 Apr 2021 16:58:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This new regression test was introduced with the Console::charset(), but it fails on ubuntu platforms assuming its locales/encoding incorrectly. To not make false-alarm/noise on test runs, this fix minimizes the tests not depending on the underlying OS's environment variables.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3768

From chegar at openjdk.java.net  Wed Apr 28 17:27:53 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Apr 2021 17:27:53 GMT
Subject: RFR: 8266155: Convert java.base to use Stream.toList() [v2]
In-Reply-To: <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
 <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>
Message-ID: <IKAxKZIh8vvmFtzCTvFNY_I6rMJykBvctlUFX6v_kvQ=.3c0446bc-34f1-478f-9309-b4cfcaea79d1@github.com>

On Wed, 28 Apr 2021 16:57:25 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> 8266155: Convert java.base to use Stream.toList()
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing redundant imports

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3734

From joehw at openjdk.java.net  Wed Apr 28 17:28:55 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 28 Apr 2021 17:28:55 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v2]
In-Reply-To: <naxJY_YXwanXVkwPDVCg9AD13og3WGK-FZie_oofUvY=.6d08ad33-93c7-45e9-b050-56dce6cab50f@github.com>
References: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
 <XazS6DYYckl9rAhHK1E58XQOlQiHFRZonhziDi2PdJg=.f2ccfef6-ed7a-4706-b3b1-2c33cbe377a3@github.com>
 <naxJY_YXwanXVkwPDVCg9AD13og3WGK-FZie_oofUvY=.6d08ad33-93c7-45e9-b050-56dce6cab50f@github.com>
Message-ID: <YhLHZi5aRypRmKFyH5R_3FBeB4gUpalPHcjop-q7fZM=.6296552b-3665-41be-adfd-79650bc718a8@github.com>

On Wed, 28 Apr 2021 16:21:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the CSR. See Update 03 in the CSR
>
> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java line 264:
> 
>> 262:             int temp;
>> 263:             if (Integer.class.isAssignableFrom(value.getClass())) {
>> 264:                 temp = (Integer)value;
> 
> Why not use pattern matching?
> `if (value instanceof Integer intValue) {
>   temp = intValue;
> }

Good question. Given that the earlier changes in the whole set (impl-specific properties) were backported, I assumed this would too, to be complete. Code consistency and clean backport may exceed the benefit of a more advanced code feature (e.g. pattern matching). 

I also am still doing works based on JDK 8, that provides a much quicker turnaround.

Saw Patrick's pattern matching changesets for some lib code. It's possible we could do it as well for the xml code. But in general, xml code, esp. those from Apache support a lower source level.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3644

From dfuchs at openjdk.java.net  Wed Apr 28 17:28:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Apr 2021 17:28:53 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
Message-ID: <689o3jJsku_BVrUSQATPla7V0BfqOYZuzlJXtmy347E=.6871722d-66a7-4364-8e19-3eecb6df2e3a@github.com>

On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address first batch of review comments

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java line 224:

> 222:  * Some methods in this package are considered <em>restricted</em>. Restricted methods are typically used to bind native
> 223:  * foreign data and/or functions to first-class Java API elements which can then be used directly by client. For instance
> 224:  * the restricted method {@link jdk.incubator.foreign.MemoryAddress#asSegment(long, ResourceScope)} can be used to create

typo: `used directly by client.` => `used directly by clients.` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From rriggs at openjdk.java.net  Wed Apr 28 17:34:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 28 Apr 2021 17:34:53 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v2]
In-Reply-To: <YhLHZi5aRypRmKFyH5R_3FBeB4gUpalPHcjop-q7fZM=.6296552b-3665-41be-adfd-79650bc718a8@github.com>
References: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
 <XazS6DYYckl9rAhHK1E58XQOlQiHFRZonhziDi2PdJg=.f2ccfef6-ed7a-4706-b3b1-2c33cbe377a3@github.com>
 <naxJY_YXwanXVkwPDVCg9AD13og3WGK-FZie_oofUvY=.6d08ad33-93c7-45e9-b050-56dce6cab50f@github.com>
 <YhLHZi5aRypRmKFyH5R_3FBeB4gUpalPHcjop-q7fZM=.6296552b-3665-41be-adfd-79650bc718a8@github.com>
Message-ID: <WwI3QyerlHlbbwRu8denwwOxidu5yqyX3HlBRqpcIXc=.fd54baeb-0551-44e2-9be2-50cb45789b35@github.com>

On Wed, 28 Apr 2021 17:25:46 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java line 264:
>> 
>>> 262:             int temp;
>>> 263:             if (Integer.class.isAssignableFrom(value.getClass())) {
>>> 264:                 temp = (Integer)value;
>> 
>> Why not use pattern matching?
>> `if (value instanceof Integer intValue) {
>>   temp = intValue;
>> }
>
> Good question. Given that the earlier changes in the whole set (impl-specific properties) were backported, I assumed this would too, to be complete. Code consistency and clean backport may exceed the benefit of a more advanced code feature (e.g. pattern matching). 
> 
> I also am still doing works based on JDK 8, that provides a much quicker turnaround.
> 
> Saw Patrick's pattern matching changesets for some lib code. It's possible we could do it as well for the xml code. But in general, xml code, esp. those from Apache support a lower source level.

ok, JDK 8 could use instanceof instead of isAssignable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3644

From iveresov at openjdk.java.net  Wed Apr 28 17:35:55 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 28 Apr 2021 17:35:55 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
Message-ID: <Q0BkGMwL3g4JdhCsLQ11X7xlGAfdsyTzY7SqXLw-uJk=.992c8a34-e6f5-4941-be46-53ba5a557df2@github.com>

On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove java_nio_Buffer in javaClasses.hpp

src/hotspot/share/c1/c1_GraphBuilder.cpp line 2052:

> 2050:         return;
> 2051:       }
> 2052: 

Do we need to keep this flag?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From mchung at openjdk.java.net  Wed Apr 28 17:38:09 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Apr 2021 17:38:09 GMT
Subject: Integrated: JDK-8265773: incorrect jdeps message "jdk8internals" to
 describe a removed JDK internal API
In-Reply-To: <blCgr1AQAqA6r0xpRGnd2HsBIUxK2mnCloDy-lCgnN4=.c00216ab-4a0a-49f8-8d24-738a102cc186@github.com>
References: <blCgr1AQAqA6r0xpRGnd2HsBIUxK2mnCloDy-lCgnN4=.c00216ab-4a0a-49f8-8d24-738a102cc186@github.com>
Message-ID: <-IR_mchw7lwN3PPNAHiUQk2XMY6roOeVKxA6Y835LFo=.3919ae29-4706-4755-9356-a52c73e5556b@github.com>

On Wed, 28 Apr 2021 01:11:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> jdeps should print "JDK removed internal APIs" to give an informative description when a JDK internal API that is being referenced has been removed.  JDK-8213909 incorrectly changed it to print `jdk8internals`.
> 
> An example output is:
> 
> 
> classes -> jdk8internals
>    p.Main                                             -> sun.misc.Service                                      JDK removed internal API
>    p.Main                                             -> sun.misc.SoftCache                                 JDK removed internal API

This pull request has now been integrated.

Changeset: b3b2bb28
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b3b2bb2875fc30d550d80e09c3e2b3f257a29869
Stats:     75 lines in 3 files changed: 74 ins; 0 del; 1 mod

8265773: incorrect jdeps message "jdk8internals" to describe a removed JDK internal API

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3741

From mchung at openjdk.java.net  Wed Apr 28 18:04:53 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Apr 2021 18:04:53 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
Message-ID: <h4_NeYqyksjn_t4QqL8CfDauoNEg3bnbM-5AxFnUhcM=.cc671ee9-8c39-46c1-af50-8cb1170ef85d@github.com>

On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address first batch of review comments

I reviewed the `--enable-native-access` related change that looks fine.

> Access to restricted methods from any other module not in the list is disallowed and will result in an IllegalAccessException.

I think you meant to say `IllegalCallerException` instead of `IllegalAccessException`.  Also do you intend to have javadoc to generate `@throw IllegalCallerException` for  the restricted methods automatically besides the javadoc description?

Making the restricted methods as `@CallerSensitive` in order to get the caller class for native access check is the proper approach.   However, some interface methods are restricted methods such as `CLinker::downcallHandle` whose the implementation method is `@CallerSensitive`.    I concern with the security issue with method handle and type aliasing.   On the other hand, `CLinker` is a sealed interface and only implemented by the platform and so it's less of a concern.   I think the interface method should also be `@CallerSensitive` so that for example a method handle for `CLinker::downcallHandle` will be produced with the proper caller-sensitive context.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From dfuchs at openjdk.java.net  Wed Apr 28 18:10:54 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Apr 2021 18:10:54 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
Message-ID: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com>

On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address first batch of review comments

src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 40:

> 38: 
> 39:     private IllegalNativeAccessChecker(Set<String> allowedModuleNames, boolean allowAllUnnamedModules) {
> 40:         this.allowedModuleNames = Collections.unmodifiableSet(allowedModuleNames);

Should that be Set.copyOf() to take advantage of the immutability of `SetN` (but at the expense of additional copying)...

src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 78:

> 76:         int index = 0;
> 77:         // the system property is removed after decoding
> 78:         String value = getAndRemoveProperty(prefix + index);

I am not sure what is going on with the removal of the properties, but if I'm not mistaken this is racy: from the implementation of the checker() method above, it looks as if two different threads could trigger a call to the decode() function concurrently, which can result in a random partitioning of the properties against the two checkers being instantiated, with one of them being eventually set as the system-wide checker.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 18:17:59 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 18:17:59 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <h4_NeYqyksjn_t4QqL8CfDauoNEg3bnbM-5AxFnUhcM=.cc671ee9-8c39-46c1-af50-8cb1170ef85d@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <h4_NeYqyksjn_t4QqL8CfDauoNEg3bnbM-5AxFnUhcM=.cc671ee9-8c39-46c1-af50-8cb1170ef85d@github.com>
Message-ID: <cnSqyJ3-e8EjmIlK2M2bajmRxGLbarvB9J-Ar4zGfiY=.768a1b8e-2921-4250-ad2b-a7180b62a42d@github.com>

On Wed, 28 Apr 2021 18:02:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I reviewed the `--enable-native-access` related change that looks fine.
> 
> > Access to restricted methods from any other module not in the list is disallowed and will result in an IllegalAccessException.
> 
> I think you meant to say `IllegalCallerException` instead of `IllegalAccessException`. Also do you intend to have javadoc to generate `@throw IllegalCallerException` for the restricted methods automatically besides the javadoc description?
> 

IllegalCalller is probably better yes - we started off with an access-like check, so things have evolved a bit. I'll also add the @throws.

> Making the restricted methods as `@CallerSensitive` in order to get the caller class for native access check is the proper approach. However, some interface methods are restricted methods such as `CLinker::downcallHandle` whose the implementation method is `@CallerSensitive`. I concern with the security issue with method handle and type aliasing. On the other hand, `CLinker` is a sealed interface and only implemented by the platform and so it's less of a concern. I think the interface method should also be `@CallerSensitive` so that for example a method handle for `CLinker::downcallHandle` will be produced with the proper caller-sensitive context.

I believe that we had to move @CallerSensitive out of interfaces because there was a test that was checking that @CS was not put on "virtual" methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 18:21:54 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 18:21:54 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com>
Message-ID: <b4BqSGYIotr9AptJsMkkzOWk2Pn94hFHwq-o_Gmbf_8=.3be9b02c-d254-4b6a-b91f-2d7849adab26@github.com>

On Wed, 28 Apr 2021 18:07:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address first batch of review comments
>
> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 78:
> 
>> 76:         int index = 0;
>> 77:         // the system property is removed after decoding
>> 78:         String value = getAndRemoveProperty(prefix + index);
> 
> I am not sure what is going on with the removal of the properties, but if I'm not mistaken this is racy: from the implementation of the checker() method above, it looks as if two different threads could trigger a call to the decode() function concurrently, which can result in a random partitioning of the properties against the two checkers being instantiated, with one of them being eventually set as the system-wide checker.

I think the method is called during module bootstrap - I don't think there is a race in practice. This method is also called in other parts of ModuleBootstrap. The code you allude to is called during initialization of the IllegalNativeAccessChecker singleton, which should happen only once, and only from one thread.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From joehw at openjdk.java.net  Wed Apr 28 18:22:27 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 28 Apr 2021 18:22:27 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v3]
In-Reply-To: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
References: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
Message-ID: <JUoHStEaIXXhIJs6ToANQlNs7ipS3svvsHAhu0KTHqM=.29fcd6ae-28ed-4957-ae96-5b11b6979b26@github.com>

> Update module summary, add a few existing properties and features into the tables.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  replace isAssignableFrom with instanceof

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3644/files
  - new: https://git.openjdk.java.net/jdk/pull/3644/files/e88be266..78047dcc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3644/head:pull/3644

PR: https://git.openjdk.java.net/jdk/pull/3644

From joehw at openjdk.java.net  Wed Apr 28 18:22:28 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 28 Apr 2021 18:22:28 GMT
Subject: RFR: 8265248: Implementation Specific Properties: change prefix,
 plus add existing properties [v2]
In-Reply-To: <WwI3QyerlHlbbwRu8denwwOxidu5yqyX3HlBRqpcIXc=.fd54baeb-0551-44e2-9be2-50cb45789b35@github.com>
References: <NBLkUwz73de-twMokthIdyxGht35c4hhIwPvXliY9_o=.3bfcc2a8-868d-4eee-8e80-84b783cd4045@github.com>
 <XazS6DYYckl9rAhHK1E58XQOlQiHFRZonhziDi2PdJg=.f2ccfef6-ed7a-4706-b3b1-2c33cbe377a3@github.com>
 <naxJY_YXwanXVkwPDVCg9AD13og3WGK-FZie_oofUvY=.6d08ad33-93c7-45e9-b050-56dce6cab50f@github.com>
 <YhLHZi5aRypRmKFyH5R_3FBeB4gUpalPHcjop-q7fZM=.6296552b-3665-41be-adfd-79650bc718a8@github.com>
 <WwI3QyerlHlbbwRu8denwwOxidu5yqyX3HlBRqpcIXc=.fd54baeb-0551-44e2-9be2-50cb45789b35@github.com>
Message-ID: <5tLRtx-ON4__Ol7xd-lHCnXNBPNoUwLfAm5bwV12T8U=.b91d698b-b17d-4c1d-801e-f29bb9354d3f@github.com>

On Wed, 28 Apr 2021 17:32:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Good question. Given that the earlier changes in the whole set (impl-specific properties) were backported, I assumed this would too, to be complete. Code consistency and clean backport may exceed the benefit of a more advanced code feature (e.g. pattern matching). 
>> 
>> I also am still doing works based on JDK 8, that provides a much quicker turnaround.
>> 
>> Saw Patrick's pattern matching changesets for some lib code. It's possible we could do it as well for the xml code. But in general, xml code, esp. those from Apache support a lower source level.
>
> ok, JDK 8 could use instanceof instead of isAssignable.

Thanks. Updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3644

From mchung at openjdk.java.net  Wed Apr 28 18:34:23 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Apr 2021 18:34:23 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
Message-ID: <qAp--Mv2cxw5tr-19iy0NNwmXjBT_1VIzG7CPoT-Ang=.4c9b189f-9b15-4f37-a769-ca2811f0de9b@github.com>

On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address first batch of review comments

> I believe that we had to move @CallerSensitive out of interfaces because there was a test that was checking that @cs was not put on "virtual" methods.

Good if we do have such test.    We need to re-examine this with the security team.   I suggest to create a JBS issue and follow up separately.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 18:33:36 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 18:33:36 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments:
  * fix typos in javadoc
  * document ISE being thrown in all methods accepting a scope; add more tests for that

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/a80d8180..24e554c5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=01-02

  Stats: 112 lines in 6 files changed: 50 ins; 0 del; 62 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 18:35:54 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 18:35:54 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com>
Message-ID: <9u5yskXth55699_itCsdggIyKauvUauftz9zy0svpLI=.744431e1-4a6d-4fe2-a664-09b35e53eaf7@github.com>

On Wed, 28 Apr 2021 17:53:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address first batch of review comments
>
> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 40:
> 
>> 38: 
>> 39:     private IllegalNativeAccessChecker(Set<String> allowedModuleNames, boolean allowAllUnnamedModules) {
>> 40:         this.allowedModuleNames = Collections.unmodifiableSet(allowedModuleNames);
> 
> Should that be Set.copyOf() to take advantage of the immutability of `SetN` (but at the expense of additional copying)...

Honestly, I'm not even sure why we should be concerned about mutation of the set here - since we create this with a bunch of values read from a system property... e.g. should we just store `allowedModuleNames` period?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 18:34:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 18:34:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <qAp--Mv2cxw5tr-19iy0NNwmXjBT_1VIzG7CPoT-Ang=.4c9b189f-9b15-4f37-a769-ca2811f0de9b@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <qAp--Mv2cxw5tr-19iy0NNwmXjBT_1VIzG7CPoT-Ang=.4c9b189f-9b15-4f37-a769-ca2811f0de9b@github.com>
Message-ID: <itldejDo7UHEdGDA6lZF7s5bavjssuE7e5qVPrlnDy0=.03683514-2207-41e8-b156-916de9dcfaae@github.com>

On Wed, 28 Apr 2021 18:23:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > I believe that we had to move @CallerSensitive out of interfaces because there was a test that was checking that @cs was not put on "virtual" methods.
> 
> Good if we do have such test. We need to re-examine this with the security team. I suggest to create a JBS issue and follow up separately.

The test in question is:

test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mchung at openjdk.java.net  Wed Apr 28 18:38:28 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Apr 2021 18:38:28 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <itldejDo7UHEdGDA6lZF7s5bavjssuE7e5qVPrlnDy0=.03683514-2207-41e8-b156-916de9dcfaae@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <qAp--Mv2cxw5tr-19iy0NNwmXjBT_1VIzG7CPoT-Ang=.4c9b189f-9b15-4f37-a769-ca2811f0de9b@github.com>
 <itldejDo7UHEdGDA6lZF7s5bavjssuE7e5qVPrlnDy0=.03683514-2207-41e8-b156-916de9dcfaae@github.com>
Message-ID: <K2P9p-3Zubd4dLN6-PwBhudrnREVndmyLzg8xNu1Gao=.9587435b-09ae-4572-ac8b-d0f6a4928433@github.com>

On Wed, 28 Apr 2021 18:26:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java

Yes that's the test.  That test misses to catch your case where aliasing may be possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From dfuchs at openjdk.java.net  Wed Apr 28 18:47:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Apr 2021 18:47:08 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <b4BqSGYIotr9AptJsMkkzOWk2Pn94hFHwq-o_Gmbf_8=.3be9b02c-d254-4b6a-b91f-2d7849adab26@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com>
 <b4BqSGYIotr9AptJsMkkzOWk2Pn94hFHwq-o_Gmbf_8=.3be9b02c-d254-4b6a-b91f-2d7849adab26@github.com>
Message-ID: <OxHn6AdnKcrQ5JuWqN8jWRhcMyDdd1BdTvww6APEOBw=.e48dd1a2-c318-4ffd-8f7d-aa7a5d595236@github.com>

On Wed, 28 Apr 2021 18:19:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 78:
>> 
>>> 76:         int index = 0;
>>> 77:         // the system property is removed after decoding
>>> 78:         String value = getAndRemoveProperty(prefix + index);
>> 
>> I am not sure what is going on with the removal of the properties, but if I'm not mistaken this is racy: from the implementation of the checker() method above, it looks as if two different threads could trigger a call to the decode() function concurrently, which can result in a random partitioning of the properties against the two checkers being instantiated, with one of them being eventually set as the system-wide checker.
>
> I think the method is called during module bootstrap - I don't think there is a race in practice. This method is also called in other parts of ModuleBootstrap. The code you allude to is called during initialization of the IllegalNativeAccessChecker singleton, which should happen only once, and only from one thread.

I'll take your word for it - the use of a volatile variable to store the singleton instance made this suspicious.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From dfuchs at openjdk.java.net  Wed Apr 28 19:09:54 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Apr 2021 19:09:54 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
Message-ID: <G9cJlgXJXrPLLhpcGRPxhnlo8TrZ_wAIHERdaCx5Y40=.8671e254-f45d-40f9-9a3a-10a2c70e21e6@github.com>

On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address first batch of review comments

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java line 52:

> 50:  * <p>
> 51:  * For {@link #lookup(String) memory addresses} obtained from a library lookup object,
> 52:  * since {@link CLinker#downcallHandle(Addressable, MethodType, FunctionDescriptor) native method handles}

These should be `{@linkplain }` since the text of the link is plain text (and not code)

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java line 88:

> 86:      * @return the memory segment associated with the library symbol (if any).
> 87:      * @throws IllegalArgumentException if the address associated with the lookup symbol do not match the
> 88:      * {@link MemoryLayout#byteAlignment() alignment constraints} in {@code layout}.

Same remark here (`{@linkplain }`)

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 43:

> 41:  * when performing memory dereference operations using a memory access var handle (see {@link MemoryHandles}).
> 42:  * <p>
> 43:  * A memory address is associated with a {@link ResourceScope resource scope}; the resource scope determines the

`{@linkplain }`

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 46:

> 44:  * lifecycle of the memory address, and whether the address can be used from multiple threads. Memory addresses
> 45:  * obtained from {@link #ofLong(long) numeric values}, or from native code, are associated with the
> 46:  * {@link ResourceScope#globalScope() global resource scope}. Memory addresses obtained from segments

... and here to (`{@linkplain }`)

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 102:

> 100:      * @param segment the segment relative to which this address offset should be computed
> 101:      * @throws IllegalArgumentException if {@code segment} is not compatible with this address; this can happen, for instance,
> 102:      * when {@code segment} models an heap memory region, while this address is a {@link #isNative() native} address.

`{@linkplain }`

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 209:

> 207:     /**
> 208:      * The native memory address instance modelling the {@code NULL} address, associated
> 209:      * with the {@link ResourceScope#globalScope() global} resource scope.

`{@linkplain }` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 28 19:55:58 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 28 Apr 2021 19:55:58 GMT
Subject: RFR: 8266014: Regression brought by optimization done with
 JDK-4926314 [v2]
In-Reply-To: <TZ_irsAr7sP_IC40X7Bkp5YQ1X8vkMG47hbMC1qWHYU=.b3589087-3293-4d54-8262-0a02bcfdd66e@github.com>
References: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>
 <TZ_irsAr7sP_IC40X7Bkp5YQ1X8vkMG47hbMC1qWHYU=.b3589087-3293-4d54-8262-0a02bcfdd66e@github.com>
Message-ID: <HCVodeyiOESbuTjuAyfuW6fjd1oCiaZHGJKE2HiONME=.40745f26-0bb7-4880-8c4a-c4497742d46f@github.com>

On Tue, 27 Apr 2021 18:55:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this request to correct a minor problem with the optimization added for JDK-4926314. The change is to attempt to read the number of elements remaining in the target buffer unless that number is non-positive in which case read zero. The test addition fails without and passes with the implementation change.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266014: Clean up spurious line break in the test

Marked as reviewed by mgkwill at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3708

From mcimadamore at openjdk.java.net  Wed Apr 28 20:38:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 20:38:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <G9cJlgXJXrPLLhpcGRPxhnlo8TrZ_wAIHERdaCx5Y40=.8671e254-f45d-40f9-9a3a-10a2c70e21e6@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <G9cJlgXJXrPLLhpcGRPxhnlo8TrZ_wAIHERdaCx5Y40=.8671e254-f45d-40f9-9a3a-10a2c70e21e6@github.com>
Message-ID: <rs4BagrdWMM9wjGGr-kuyKLKuo4NzwqyMQt7xfIzwcA=.a3e7be5d-f025-4ff1-996d-dc741814af7b@github.com>

On Wed, 28 Apr 2021 19:02:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address first batch of review comments
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 209:
> 
>> 207:     /**
>> 208:      * The native memory address instance modelling the {@code NULL} address, associated
>> 209:      * with the {@link ResourceScope#globalScope() global} resource scope.
> 
> `{@linkplain }` ?

thanks - I'll do a pass - I think I probably got all of them wrong

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 20:43:54 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 20:43:54 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
Message-ID: <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>

On Wed, 28 Apr 2021 18:33:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments:
>   * fix typos in javadoc
>   * document ISE being thrown in all methods accepting a scope; add more tests for that

> > test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java
> 
> Yes that's the test. That test misses to catch your case where aliasing may be possible.



> Yes that's the test. That test misses to catch your case where aliasing may be possible.

To be clear - by aliasing you mean when the @CallerSensitive implementation is called with invokeinterface - so, e.g. doing `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mchung at openjdk.java.net  Wed Apr 28 20:43:54 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Apr 2021 20:43:54 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
 <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>
Message-ID: <DqCFjiDHnq8UNre4Ux54AxHKFNcD4hfXW8_Yzcegyu8=.ec8272ca-15eb-4c7f-a0a9-d5f92c362dac@github.com>

On Wed, 28 Apr 2021 20:38:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> To be clear - by aliasing you mean when the @CallerSensitive implementation is called with invokeinterface - so, e.g. doing `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right?

Yes.   The caller would be java.base if it's invoked via method handle.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From sviswanathan at openjdk.java.net  Wed Apr 28 21:11:26 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 28 Apr 2021 21:11:26 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v2]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>

> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> This work is part of second round of incubation of the Vector API.
> JEP: https://bugs.openjdk.java.net/browse/JDK-8261663
> 
> Please review.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge master
 - remove whitespace
 - Merge master
 - Small fix
 - cleanup
 - x86 short vector math optimization for Vector API

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=01
  Stats: 417102 lines in 120 files changed: 416935 ins; 123 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From mcimadamore at openjdk.java.net  Wed Apr 28 21:13:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 21:13:53 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <DqCFjiDHnq8UNre4Ux54AxHKFNcD4hfXW8_Yzcegyu8=.ec8272ca-15eb-4c7f-a0a9-d5f92c362dac@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
 <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>
 <DqCFjiDHnq8UNre4Ux54AxHKFNcD4hfXW8_Yzcegyu8=.ec8272ca-15eb-4c7f-a0a9-d5f92c362dac@github.com>
Message-ID: <cdoCk0mIpSe5RAoNy0cW_KdmcGlSc0VvaQhekiohWrQ=.16c012f3-0b78-4a39-9686-e322451e3ba2@github.com>

On Wed, 28 Apr 2021 20:40:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > To be clear - by aliasing you mean when the @CallerSensitive implementation is called with invokeinterface - so, e.g. doing `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right?
> 
> Yes. The caller would be java.base if it's invoked via method handle.

I just did a test:


public class TestLookup {
    public static void main(String[] args) throws Throwable {
        MethodHandle handle = MethodHandles.lookup().findVirtual(CLinker.class, "downcallHandle", MethodType.methodType(MethodHandle.class, Addressable.class, MethodType.class, FunctionDescriptor.class));
        CLinker linker = CLinker.getInstance();
        handle.invoke(linker, MemoryAddress.NULL, MethodType.methodType(void.class), FunctionDescriptor.ofVoid());
    }
}


this fails as expected when the handle is invoked. To test I had to disable the check on CLinker.getInstance - otherwise that would have always throw anyway.

Also, on IllegalCaller vs. IllegalAccess - looking more, I think our impl throws IllegalCaller - now that was done because IllegalAccess is a checked exception and we don't want a checked exception here - but the option is called "enableNativeAccess" - is that still ok?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Wed Apr 28 21:49:50 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 28 Apr 2021 21:49:50 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v2]
In-Reply-To: <OxHn6AdnKcrQ5JuWqN8jWRhcMyDdd1BdTvww6APEOBw=.e48dd1a2-c318-4ffd-8f7d-aa7a5d595236@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <m7Ek_GPXwzq1oEbnqnECJ9iGpJFFHX--psGFQhq0eLQ=.55c11e83-a9eb-4f2a-a5b6-9bb28881610d@github.com>
 <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com>
 <b4BqSGYIotr9AptJsMkkzOWk2Pn94hFHwq-o_Gmbf_8=.3be9b02c-d254-4b6a-b91f-2d7849adab26@github.com>
 <OxHn6AdnKcrQ5JuWqN8jWRhcMyDdd1BdTvww6APEOBw=.e48dd1a2-c318-4ffd-8f7d-aa7a5d595236@github.com>
Message-ID: <kib7hImRKqsOPxENjGs6OY1Pfj0rmI7ovejTY8G0tQo=.e66b9f89-5d20-46e1-a0fc-d5d15e7598c2@github.com>

On Wed, 28 Apr 2021 18:44:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I think the method is called during module bootstrap - I don't think there is a race in practice. This method is also called in other parts of ModuleBootstrap. The code you allude to is called during initialization of the IllegalNativeAccessChecker singleton, which should happen only once, and only from one thread.
>
> I'll take your word for it - the use of a volatile variable to store the singleton instance made this suspicious.

good point - I think that came in when I adapted the code from IllegalAccessLogger - which can indeed be accessed from multiple threads. In this case the initialization is effectively part of bootstrap, and volatile is not required.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From naoto at openjdk.java.net  Wed Apr 28 22:32:58 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 28 Apr 2021 22:32:58 GMT
Subject: RFR: 8265989: System property for the native character encoding name
Message-ID: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>

After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

-------------

Commit messages:
 - 8265989: System property for the native character encoding name

Changes: https://git.openjdk.java.net/jdk/pull/3777/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3777&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265989
  Stats: 15 lines in 3 files changed: 8 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3777.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3777/head:pull/3777

PR: https://git.openjdk.java.net/jdk/pull/3777

From donraab at gmail.com  Wed Apr 28 22:58:05 2021
From: donraab at gmail.com (Donald Raab)
Date: Wed, 28 Apr 2021 18:58:05 -0400
Subject: New convenience methods on Stream
In-Reply-To: <C9C81B33-BB99-4903-B080-6A1A86DD27CD@gmail.com>
References: <B78DB84E-2AF4-4EDB-ABCD-6C9843258BD6@gmail.com>
 <C9C81B33-BB99-4903-B080-6A1A86DD27CD@gmail.com>
Message-ID: <F6FF5462-AFB7-405E-A1F1-760EAB962859@gmail.com>

I looked through a few libraries and found some methods where the option #2 proposal for Steam might be useful. If the JDK had constructors for ArrayList, HashSet and other collection types that take arrays this method would work there as well. 

> default <R extends Iterable<T>> R to(Function<T[], R> function)
> {
>    return function.apply((T[]) this.toArray());
> }


// JDK 
Set<String> set = stream.to(Set::of);
List<String> list = stream.to(List::of);
List<String> arraysAsList = stream.to(Arrays::asList);

// Guava
ArrayList<String> arrayList = stream.to(Lists::newArrayList);
HashSet<String> hashSet = stream.to(Sets::newHashSet);
Multiset<String> multiset = stream.to(ImmutableMultiset::copyOf);
List<String> guavaList = stream.to(ImmutableList::copyOf);
Set<String> guavaSet = stream.to(ImmutableSet::copyOf);

// Apache Commons Collections
FluentIterable<String> fluentIterable = stream.to(FluentIterable::of);

// Eclipse Collections
MutableList<String> adapter = stream.to(ArrayAdapter::adapt);

MutableList<String> mutableList = stream.to(Lists.mutable::with);
MutableSet<String> mutableSet = stream.to(Sets.mutable::with);
MutableBag<String> mutableBag = stream.to(Bags.mutable::with);

// Eclipse Collections - ListIterable, SetIterable and Bag all extend Iterable, not Collection
ListIterable<String> listIterable = stream.to(Lists.mutable::with);
SetIterable<String> setIterable = stream.to(Sets.mutable::with);
Bag<String> bag = stream.to(Bags.mutable::with);

// Eclipse Collections - Immutable Collections do not extend Collection
ImmutableList<String> immutableList = stream.to(Lists.immutable::with);
ImmutableSet<String> immutableSet = stream.to(Sets.immutable::with);
ImmutableBag<String> immutableBag = stream.to(Bags.immutable::with);

// Eclipse Collections - Stack does not extend Collection
StackIterable<String> stackIterable = stream.to(Stacks.mutable::with);
MutableStack<String> mutableStack = stream.to(Stacks.mutable::with);
ImmutableStack<String> immutableStack = stream.to(Stacks.immutable::with);

// Eclipse Collections - Mutable Map and MutableBiMap are both Iterable<V> so they are valid returns
MutableMap<String, String> map =
        stream.to(array -> ArrayAdapter.adapt(array)
                .toMap(String::toLowerCase, String::toUpperCase));

MutableBiMap<String, String> biMap =
        stream.to(array -> ArrayAdapter.adapt(array)
                .toBiMap(String::toLowerCase, String::toUpperCase));

Thanks,
Don

> On Apr 27, 2021, at 1:35 AM, Donald Raab <donraab at gmail.com> wrote:
> 
> I realized after sending that option 2 can be made more abstract:
> 
> default <R extends Iterable<T>> R to(Function<T[], R> function)
> {
>    return function.apply((T[]) this.toArray());
> }
> 
>> 
>> 2. Pass the result of toArray directly into a function that can then return a Collection. This should work with Set.of, List.of and any 3rd party collections which take arrays.
>> 
>> default <R extends Collection<T>> R to(Function<T[], R> function)
>> {
>>   return function.apply((T[]) this.toArray());
>> }
>> 
>> Usage Examples:
>> 
>> Set<String> set = stream.to(Set::of);
>> List<String> list = stream.to(List::of);
>> List<String> arrayList = stream.to(Arrays::asList);
>> 
> 


From mchung at openjdk.java.net  Wed Apr 28 23:26:01 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Apr 2021 23:26:01 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <cdoCk0mIpSe5RAoNy0cW_KdmcGlSc0VvaQhekiohWrQ=.16c012f3-0b78-4a39-9686-e322451e3ba2@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
 <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>
 <DqCFjiDHnq8UNre4Ux54AxHKFNcD4hfXW8_Yzcegyu8=.ec8272ca-15eb-4c7f-a0a9-d5f92c362dac@github.com>
 <cdoCk0mIpSe5RAoNy0cW_KdmcGlSc0VvaQhekiohWrQ=.16c012f3-0b78-4a39-9686-e322451e3ba2@github.com>
Message-ID: <L6SrFTB58RAe-IgK0yqhJB_FXTM-dBLe5a1xfrtTqwQ=.8455897b-3dfd-4f6a-929c-8b80f834e892@github.com>

On Wed, 28 Apr 2021 21:10:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I just did a test:
> 
> ```
> public class TestLookup {
>     public static void main(String[] args) throws Throwable {
>         MethodHandle handle = MethodHandles.lookup().findVirtual(CLinker.class, "downcallHandle", MethodType.methodType(MethodHandle.class, Addressable.class, MethodType.class, FunctionDescriptor.class));
>         CLinker linker = CLinker.getInstance();
>         handle.invoke(linker, MemoryAddress.NULL, MethodType.methodType(void.class), FunctionDescriptor.ofVoid());
>     }
> }
> ```
> 
> this fails as expected when the handle is invoked. To test I had to disable the check on CLinker.getInstance - otherwise that would have always throw anyway.

My statement was overly simplified.   If `handle` is invoked in another module B and invoked by a class in module B,  which module (the `lookup`'s module or ) do you expect be the caller to check against for native access check?    `CLinker::downcallHandle` is not caller-sensitive but its implementation is.

The method handle of a caller-sensitive method behaves as if it were called from an instruction contained in the lookup class [1].   

[1] https://download.java.net/java/early_access/jdk17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#callsens

> Also, on IllegalCaller vs. IllegalAccess - looking more, I think our impl throws IllegalCaller - now that was done because IllegalAccess is a checked exception and we don't want a checked exception here - but the option is called "enableNativeAccess" - is that still ok?

Yes the implementation throws `IllegalCallerException` which is why I point out this.   Hmm... this seems more of `IllegalAccess` as the caller does not have access to this restricted method.  OTOH, `Module::addOpens` grants deep reflection access to the named module if the caller has access.  Otherwise, `IllegalCallerException` is thrown.  So I think it's okay to throw ICE.  Others may have a different opinion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From joehw at openjdk.java.net  Thu Apr 29 00:44:51 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 29 Apr 2021 00:44:51 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
Message-ID: <L4cp8q0gJKCoJzPTAC6O44uUxLHQEYTSpH3SKvRVw1c=.b8f7c8e4-d030-4f7f-a701-79ef8aaafba6@github.com>

On Wed, 28 Apr 2021 22:24:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

src/java.base/share/classes/java/lang/System.java line 704:

> 702:      * <tr><th scope="row">{@systemProperty native.encoding}</th>
> 703:      *     <td>Character encoding name derived from the host environment and/or
> 704:      *     the user's settings. Setting this system property has no effect.</td></tr>

May be "This property is read-only" instead of "Setting this system property has no effect" to not confuse with "user's settings"?

test/jdk/java/lang/System/PropertyTest.java line 83:

> 81:                 {"java.runtime.version"},
> 82:                 {"java.runtime.name"},
> 83:                 {"native.encoding"},

Does this test differentiate between read-only and modifiable properties? "native.encoding" looks like it's explicitly overridable. Or do we need a test to verify it's not overridable?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From ysuenaga at openjdk.java.net  Thu Apr 29 01:07:51 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 29 Apr 2021 01:07:51 GMT
Subject: Integrated: 8266173: -Wmaybe-uninitialized happens in jni_util.c
In-Reply-To: <YKE53C7bOXZe3cs1fXHRyEMjwFY0bOMTOnk2CsEO9gI=.0df40377-15e0-4eb2-a263-01a8617b01f2@github.com>
References: <YKE53C7bOXZe3cs1fXHRyEMjwFY0bOMTOnk2CsEO9gI=.0df40377-15e0-4eb2-a263-01a8617b01f2@github.com>
Message-ID: <itGJkDeNIvjm50w2VKmHSnOtmWGl0Wdn7EA-3sZgzxA=.07989667-304a-4281-9053-bc05396e4c53@github.com>

On Wed, 28 Apr 2021 01:20:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can see compiler warnings in jni_util.c as following on GCC 11. `buf` should be initialized.

This pull request has now been integrated.

Changeset: 4a9f2319
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4a9f2319c9cec5c2cc69aafe6abdf93aff120084
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8266173: -Wmaybe-uninitialized happens in jni_util.c

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/3742

From yyang at openjdk.java.net  Thu Apr 29 02:33:52 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 02:33:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <Q0BkGMwL3g4JdhCsLQ11X7xlGAfdsyTzY7SqXLw-uJk=.992c8a34-e6f5-4941-be46-53ba5a557df2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
 <Q0BkGMwL3g4JdhCsLQ11X7xlGAfdsyTzY7SqXLw-uJk=.992c8a34-e6f5-4941-be46-53ba5a557df2@github.com>
Message-ID: <y2RFgnTfMyO9FW5rCXH2HDuOlBhTVTBXVNHUTWeEepQ=.71027855-d8a3-4485-a681-51d85f975cb9@github.com>

On Wed, 28 Apr 2021 17:32:18 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Do we need to keep this flag?

Exactly, the flag should be removed.

Thanks,
Yang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Thu Apr 29 02:47:19 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 02:47:19 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v3]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <oO4tk_2Yiw_kYXN-HKcgyD9P4T4pIU9x2LL-L7UJjb0=.9563d0aa-8437-4ac6-b23b-0331b030e081@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  remove InlineNIOCheckIndex flag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/7f30dc48..db8b6ef4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=01-02

  Stats: 23 lines in 3 files changed: 11 ins; 11 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Thu Apr 29 02:53:18 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 02:53:18 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v4]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <ECpWrl-zwxikeEMmm9o3N20vuTp-4DymPKnEnYgMmWE=.2cb02211-dbe7-496a-bc3f-386a2fe3173b@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  remove extra newline

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/db8b6ef4..bbdf4b9e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From iris at openjdk.java.net  Thu Apr 29 05:41:51 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 29 Apr 2021 05:41:51 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
Message-ID: <TE9VZ9G7z7jcqWWHDylRjDjC2r4setrSxGIaG4t34pI=.d5d9d9b1-c737-48e4-a84e-2b9153899db7@github.com>

On Wed, 28 Apr 2021 22:24:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From iris at openjdk.java.net  Thu Apr 29 05:41:51 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 29 Apr 2021 05:41:51 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <L4cp8q0gJKCoJzPTAC6O44uUxLHQEYTSpH3SKvRVw1c=.b8f7c8e4-d030-4f7f-a701-79ef8aaafba6@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <L4cp8q0gJKCoJzPTAC6O44uUxLHQEYTSpH3SKvRVw1c=.b8f7c8e4-d030-4f7f-a701-79ef8aaafba6@github.com>
Message-ID: <3JmCVIcKqI8MlE_0R1FPVuK1sxrNFcuZC4D9F8EgbJw=.d51d6c4a-2f8c-46b3-9cbc-9e7913e5be13@github.com>

On Thu, 29 Apr 2021 00:37:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.
>
> src/java.base/share/classes/java/lang/System.java line 704:
> 
>> 702:      * <tr><th scope="row">{@systemProperty native.encoding}</th>
>> 703:      *     <td>Character encoding name derived from the host environment and/or
>> 704:      *     the user's settings. Setting this system property has no effect.</td></tr>
> 
> May be "This property is read-only" instead of "Setting this system property has no effect" to not confuse with "user's settings"?

I suspect that if setProperty("native.encoding", "foo") succeeds, then it will return "foo".   I also believe that a later invocation of getProperty("native.encoding") will also return "foo".  If that's the case, then I don't think that the "read-only" alternative phrasing is correct.  To me, the alternative suggests that an error will be return if there is an attempt to set it or that the potential new value will be ignored.  The "no effect" phrasing avoids this problem.   I also suspect that the "no effect" phrasing was selected to align with the apiNote in lines 719-721.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From alanb at openjdk.java.net  Thu Apr 29 07:19:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 29 Apr 2021 07:19:57 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
Message-ID: <RbkBaU8H-etOk0bv3oIlOz1UHCFh9k-rHCmOUFZUZRw=.4826e3b8-fa31-43da-a98a-e1bb9d5e212c@github.com>

On Wed, 28 Apr 2021 22:24:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

src/java.base/share/classes/jdk/internal/util/SystemProps.java line 69:

> 67:                 ? raw.propDefault(Raw._sun_jnu_encoding_NDX)
> 68:                 : raw.propDefault(Raw._file_encoding_NDX));
> 69:         put(props, "native.encoding", nativeEncoding);

Shouldn't native.encoding be biased toward sun.jnu.encoding rather than file.encoding? Or maybe you'll change it when preparing the changes for JEP 400?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From dfuchs at openjdk.java.net  Thu Apr 29 09:33:58 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 29 Apr 2021 09:33:58 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v4]
In-Reply-To: <ECpWrl-zwxikeEMmm9o3N20vuTp-4DymPKnEnYgMmWE=.2cb02211-dbe7-496a-bc3f-386a2fe3173b@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <ECpWrl-zwxikeEMmm9o3N20vuTp-4DymPKnEnYgMmWE=.2cb02211-dbe7-496a-bc3f-386a2fe3173b@github.com>
Message-ID: <gYK8_Hj986HHZwEI1OhRFqEj3OpaQAIr_vCuoIFbIUU=.280ab91b-8ea7-473e-9271-7c8aeff3253e@github.com>

On Thu, 29 Apr 2021 02:53:18 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove extra newline

test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 60:

> 58:         } catch (IndexOutOfBoundsException e) {
> 59:             // got it!
> 60:         }

In all places where `Precondition.checkIndex` is expected to throw, an AssertionError should  be generated if it doesn't throw:


        try {
            Preconditions.checkIndex(1, 1, null);
            throw new AssertionError("Expected IndexOutOfBoundsException not thrown");
        } catch (IndexOutOfBoundsException e) {
            // got it!
        }

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Thu Apr 29 10:01:52 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 10:01:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v4]
In-Reply-To: <gYK8_Hj986HHZwEI1OhRFqEj3OpaQAIr_vCuoIFbIUU=.280ab91b-8ea7-473e-9271-7c8aeff3253e@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <ECpWrl-zwxikeEMmm9o3N20vuTp-4DymPKnEnYgMmWE=.2cb02211-dbe7-496a-bc3f-386a2fe3173b@github.com>
 <gYK8_Hj986HHZwEI1OhRFqEj3OpaQAIr_vCuoIFbIUU=.280ab91b-8ea7-473e-9271-7c8aeff3253e@github.com>
Message-ID: <ewDu_uDXvo4AcNMVI9sTYEzXHbl-dCjR2bQzg400uAc=.f55cf572-be46-42ef-8254-47f8a113d1ba@github.com>

On Thu, 29 Apr 2021 09:30:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove extra newline
>
> test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 60:
> 
>> 58:         } catch (IndexOutOfBoundsException e) {
>> 59:             // got it!
>> 60:         }
> 
> In all places where `Precondition.checkIndex` is expected to throw, an AssertionError should  be generated if it doesn't throw:
> 
> 
>         try {
>             Preconditions.checkIndex(1, 1, null);
>             throw new AssertionError("Expected IndexOutOfBoundsException not thrown");
>         } catch (IndexOutOfBoundsException e) {
>             // got it!
>         }

Yes, it does make sense

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From dfuchs at openjdk.java.net  Thu Apr 29 10:16:20 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 29 Apr 2021 10:16:20 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v5]
In-Reply-To: <mq9_O5lfLDVrZDWVzcd6jBk4jvufm6LZSh7a9pJzKfo=.20ed970f-53be-489d-8ea5-7628737cf6fb@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <mq9_O5lfLDVrZDWVzcd6jBk4jvufm6LZSh7a9pJzKfo=.20ed970f-53be-489d-8ea5-7628737cf6fb@github.com>
Message-ID: <TfUCHYj3Tzsl2zIEj1SUbvFoO7hr8ioncgvKGr5c1sg=.d259e35e-25e6-42d1-a4d8-86d008a11952@github.com>

On Thu, 29 Apr 2021 10:13:16 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AssertionError when expected exception was not thrown

test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 86:

> 84:             // read fields
> 85:             Preconditions.checkIndex(limit + 1, limit, (s, integers) -> new MyException("Reason:" + s + "::" + integers));
> 86:             throw new AssertionError("Expected IndexOutOfBoundsException not thrown");

nit: well maybe here it should be:

throw new AssertionError("Expected MyException not thrown");

test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 94:

> 92:     static void check1(int i) {
> 93:         try {
> 94:             Preconditions.checkIndex(i, 9999, (s, integers) -> new RuntimeException("ex"));

I believe 

throw new AssertionError("Expected IndexOutOfBoundsException not thrown");


should be added in `check1`...`check4` as well...

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Thu Apr 29 10:16:19 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 10:16:19 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v5]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <mq9_O5lfLDVrZDWVzcd6jBk4jvufm6LZSh7a9pJzKfo=.20ed970f-53be-489d-8ea5-7628737cf6fb@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  AssertionError when expected exception was not thrown

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/bbdf4b9e..1a96be7e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=03-04

  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From mcimadamore at openjdk.java.net  Thu Apr 29 10:34:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 29 Apr 2021 10:34:53 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <L6SrFTB58RAe-IgK0yqhJB_FXTM-dBLe5a1xfrtTqwQ=.8455897b-3dfd-4f6a-929c-8b80f834e892@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
 <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>
 <DqCFjiDHnq8UNre4Ux54AxHKFNcD4hfXW8_Yzcegyu8=.ec8272ca-15eb-4c7f-a0a9-d5f92c362dac@github.com>
 <cdoCk0mIpSe5RAoNy0cW_KdmcGlSc0VvaQhekiohWrQ=.16c012f3-0b78-4a39-9686-e322451e3ba2@github.com>
 <L6SrFTB58RAe-IgK0yqhJB_FXTM-dBLe5a1xfrtTqwQ=.8455897b-3dfd-4f6a-929c-8b80f834e892@github.com>
Message-ID: <U05VgHVCM-mzgyvhcErkcFxVtzS24vAqCj-Y73tbgsU=.947cfa12-4f39-460c-9140-8bb82b4272cc@github.com>

On Wed, 28 Apr 2021 23:22:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> My statement was overly simplified, sorry. If `handle` is invoked in another module B and invoked by a class in module B, which module (the `lookup`'s module or ) do you expect be the caller to check against for native access check? `CLinker::downcallHandle` is not caller-sensitive but its implementation is.
> 
> The method handle of a caller-sensitive method behaves as if it were called from an instruction contained in the lookup class [1].

I think I expect that, with caller sensitive, it is possible from a client in an "enabled" module to obtain a MethodHandle, and then pass it to an unprivileged module, which then calls it, and works ok. This matches my expectation (this trick could be used also to give a client access to an otherwise inaccessible - in the classic sense - method).

So, when working with method handles, I'm completely fine working with the lookup class as context (and not with the real caller class). 

Given all this, do you agree that current checks are not affected by interface-ness of some of the methods involved?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From yyang at openjdk.java.net  Thu Apr 29 10:40:52 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 10:40:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v5]
In-Reply-To: <TfUCHYj3Tzsl2zIEj1SUbvFoO7hr8ioncgvKGr5c1sg=.d259e35e-25e6-42d1-a4d8-86d008a11952@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <mq9_O5lfLDVrZDWVzcd6jBk4jvufm6LZSh7a9pJzKfo=.20ed970f-53be-489d-8ea5-7628737cf6fb@github.com>
 <TfUCHYj3Tzsl2zIEj1SUbvFoO7hr8ioncgvKGr5c1sg=.d259e35e-25e6-42d1-a4d8-86d008a11952@github.com>
Message-ID: <8qnpaKEeGr3iGKtcGK8l5YjtxP_Y3cdmwbbDVvr-Y7Y=.d0a0cc48-3027-4b15-982b-88b18c4d0830@github.com>

On Thu, 29 Apr 2021 10:13:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AssertionError when expected exception was not thrown
>
> test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 94:
> 
>> 92:     static void check1(int i) {
>> 93:         try {
>> 94:             Preconditions.checkIndex(i, 9999, (s, integers) -> new RuntimeException("ex"));
> 
> I believe 
> 
> throw new AssertionError("Expected IndexOutOfBoundsException not thrown");
> 
> 
> should be added in `check1`...`check4` as well...

Hmm.. They would throw desired exceptions only if i==9999.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From mcimadamore at openjdk.java.net  Thu Apr 29 11:15:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 29 Apr 2021 11:15:00 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v4]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <nzCCquh7cqwkajQmyjV-dOenouy-jBNGAI0FKmnhZ0o=.db4b9853-6e95-4d0c-a163-b11cd028efdd@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments:
  * Fix all link vs. linkplain
  * Remove `volatile` and other defensive copying in `IllegalNativeAccessChecker`
  * Added @throws clauses in restricted methods for `IllegalCallerException`

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/24e554c5..20671853

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=02-03

  Stats: 102 lines in 8 files changed: 57 ins; 0 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Thu Apr 29 11:15:32 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 29 Apr 2021 11:15:32 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
Message-ID: <AbJigAQ39Cs0ToaBjQXuo9NuTCql1oW0AES3d6ZCeso=.c057d5c3-978b-48e7-8eb1-d473f3ccead6@github.com>

On Wed, 28 Apr 2021 18:33:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments:
>   * fix typos in javadoc
>   * document ISE being thrown in all methods accepting a scope; add more tests for that

Here's a new round of javadoc/specdiff with latest changes
Javadoc: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v2/javadoc/jdk/incubator/foreign/package-summary.html
Specdiff: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v2/specdiff/overview-summary.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Thu Apr 29 12:22:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 29 Apr 2021 12:22:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v5]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <02OtcjUL7EtDhrlea772aQceCYVBpl3uMAWuwkgK6p0=.46f81497-dcc1-4ab2-b60a-84ee417f1301@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

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 ten additional commits since the last revision:

 - Merge branch 'master' into JEP-412
 - Address review comments:
   * Fix all link vs. linkplain
   * Remove `volatile` and other defensive copying in `IllegalNativeAccessChecker`
   * Added @throws clauses in restricted methods for `IllegalCallerException`
 - Address review comments:
   * fix typos in javadoc
   * document ISE being thrown in all methods accepting a scope; add more tests for that
 - Address first batch of review comments
 - Add linker test excludes for x86 and other platforms which do not support `CLinker`
 - Integrate latest API tweaks
 - Fix x86 build
 - Fix `TestLinkToNativeRBP`
 - Initial push

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/20671853..f27db3f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=03-04

  Stats: 477828 lines in 3664 files changed: 4983 ins; 470775 del; 2070 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From naoto at openjdk.java.net  Thu Apr 29 13:04:52 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 29 Apr 2021 13:04:52 GMT
Subject: Integrated: 8265918: java/io/Console/CharsetTest.java failed with
 "expect: spawn id exp6 not open"
In-Reply-To: <2EW1U4s4-CI2ENmVrAKGgK6paoWJcJ6FQwx8VQapBBk=.ce948652-8cc7-4d35-bce5-b0837a8830ea@github.com>
References: <2EW1U4s4-CI2ENmVrAKGgK6paoWJcJ6FQwx8VQapBBk=.ce948652-8cc7-4d35-bce5-b0837a8830ea@github.com>
Message-ID: <OLWrV6v07QjjYUJYMIcaDbGYVxGJTEjw-aHnJMho0-k=.3906903b-087d-451a-9197-eb76ee423600@github.com>

On Wed, 28 Apr 2021 16:58:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This new regression test was introduced with the Console::charset(), but it fails on ubuntu platforms assuming its locales/encoding incorrectly. To not make false-alarm/noise on test runs, this fix minimizes the tests not depending on the underlying OS's environment variables.

This pull request has now been integrated.

Changeset: 294347b5
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/294347b59be684ee398b442a1c64824eb03311dc
Stats:     13 lines in 2 files changed: 0 ins; 11 del; 2 mod

8265918: java/io/Console/CharsetTest.java failed with "expect: spawn id exp6 not open"

Reviewed-by: alanb, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/3768

From naoto at openjdk.java.net  Thu Apr 29 13:09:54 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 29 Apr 2021 13:09:54 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <3JmCVIcKqI8MlE_0R1FPVuK1sxrNFcuZC4D9F8EgbJw=.d51d6c4a-2f8c-46b3-9cbc-9e7913e5be13@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <L4cp8q0gJKCoJzPTAC6O44uUxLHQEYTSpH3SKvRVw1c=.b8f7c8e4-d030-4f7f-a701-79ef8aaafba6@github.com>
 <3JmCVIcKqI8MlE_0R1FPVuK1sxrNFcuZC4D9F8EgbJw=.d51d6c4a-2f8c-46b3-9cbc-9e7913e5be13@github.com>
Message-ID: <-1DDZYmc7t6ku4qKnSQ09mXOeILUe3yR_Hu2q1rYekw=.de2dd7fe-1c99-4648-8050-d4a5735ea76e@github.com>

On Thu, 29 Apr 2021 05:38:21 GMT, Iris Clark <iris at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 704:
>> 
>>> 702:      * <tr><th scope="row">{@systemProperty native.encoding}</th>
>>> 703:      *     <td>Character encoding name derived from the host environment and/or
>>> 704:      *     the user's settings. Setting this system property has no effect.</td></tr>
>> 
>> May be "This property is read-only" instead of "Setting this system property has no effect" to not confuse with "user's settings"?
>
> I suspect that if setProperty("native.encoding", "foo") succeeds, then it will return "foo".   I also believe that a later invocation of getProperty("native.encoding") will also return "foo".  If that's the case, then I don't think that the "read-only" alternative phrasing is correct.  To me, the alternative suggests that an error will be return if there is an attempt to set it or that the potential new value will be ignored.  The "no effect" phrasing avoids this problem.   I also suspect that the "no effect" phrasing was selected to align with the apiNote in lines 719-721.

Thanks, Joe and Iris. I agree with Iris and that's the reason I chose the description. System properties are inherently mutable. There are some "protected" ones, by that I mean a private copy is made just after initialization for VM use, which is not affected by later setProperty() calls. But I don't think this new property should be treated as such.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From ysuenaga at openjdk.java.net  Thu Apr 29 13:11:15 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 29 Apr 2021 13:11:15 GMT
Subject: RFR: 8266168: -Wmaybe-uninitialized happens in check_code.c
Message-ID: <rqjw9Rq9S7MC6w3w0-TYBOccocrucX6E1fJsMm1yABU=.8ca2166d-5348-4386-b862-0a5f47267161@github.com>

We can see following compiler warning in check_code.c on GCC 11.

-------------

Commit messages:
 - 8266168: -Wmaybe-uninitialized happens in check_code.c

Changes: https://git.openjdk.java.net/jdk/pull/3787/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3787&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266168
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3787/head:pull/3787

PR: https://git.openjdk.java.net/jdk/pull/3787

From naoto at openjdk.java.net  Thu Apr 29 13:14:52 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 29 Apr 2021 13:14:52 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <RbkBaU8H-etOk0bv3oIlOz1UHCFh9k-rHCmOUFZUZRw=.4826e3b8-fa31-43da-a98a-e1bb9d5e212c@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <RbkBaU8H-etOk0bv3oIlOz1UHCFh9k-rHCmOUFZUZRw=.4826e3b8-fa31-43da-a98a-e1bb9d5e212c@github.com>
Message-ID: <H61pziXTy_TmaaJiTZWZnSHh01PaX8n1QBvQYdFoiiI=.cfd4bf6c-a2a7-4dca-b57b-98e6ba428c1d@github.com>

On Thu, 29 Apr 2021 07:17:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.
>
> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 69:
> 
>> 67:                 ? raw.propDefault(Raw._sun_jnu_encoding_NDX)
>> 68:                 : raw.propDefault(Raw._file_encoding_NDX));
>> 69:         put(props, "native.encoding", nativeEncoding);
> 
> Shouldn't native.encoding be biased toward sun.jnu.encoding rather than file.encoding? Or maybe you'll change it when preparing the changes for JEP 400?

`native.encoding` preserves the encoding that current `Charset.defaultCharset()` is returning, which is based on `file.encoding`. So I believe the current implementation is correct. If it is biased toward `sun.jnu.encoding`, it would be problematic especially on Windows where that represents `system locale`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From alanb at openjdk.java.net  Thu Apr 29 13:26:49 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 29 Apr 2021 13:26:49 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <H61pziXTy_TmaaJiTZWZnSHh01PaX8n1QBvQYdFoiiI=.cfd4bf6c-a2a7-4dca-b57b-98e6ba428c1d@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <RbkBaU8H-etOk0bv3oIlOz1UHCFh9k-rHCmOUFZUZRw=.4826e3b8-fa31-43da-a98a-e1bb9d5e212c@github.com>
 <H61pziXTy_TmaaJiTZWZnSHh01PaX8n1QBvQYdFoiiI=.cfd4bf6c-a2a7-4dca-b57b-98e6ba428c1d@github.com>
Message-ID: <Cu5-h0O6XHeXhU9QWkT_C_dvNfuUuyAjv9tBuCoD6kY=.0eeb4f6e-bbb9-455b-9f25-5f450c8293c4@github.com>

On Thu, 29 Apr 2021 13:11:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 69:
>> 
>>> 67:                 ? raw.propDefault(Raw._sun_jnu_encoding_NDX)
>>> 68:                 : raw.propDefault(Raw._file_encoding_NDX));
>>> 69:         put(props, "native.encoding", nativeEncoding);
>> 
>> Shouldn't native.encoding be biased toward sun.jnu.encoding rather than file.encoding? Or maybe you'll change it when preparing the changes for JEP 400?
>
> `native.encoding` preserves the encoding that current `Charset.defaultCharset()` is returning, which is based on `file.encoding`. So I believe the current implementation is correct. If it is biased toward `sun.jnu.encoding`, it would be problematic especially on Windows where that represents `system locale`.

Okay for now but the value of file.encoding will change to "UTF-8" so will be different to native.encoding.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From rriggs at openjdk.java.net  Thu Apr 29 13:42:51 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Apr 2021 13:42:51 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <-1DDZYmc7t6ku4qKnSQ09mXOeILUe3yR_Hu2q1rYekw=.de2dd7fe-1c99-4648-8050-d4a5735ea76e@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <L4cp8q0gJKCoJzPTAC6O44uUxLHQEYTSpH3SKvRVw1c=.b8f7c8e4-d030-4f7f-a701-79ef8aaafba6@github.com>
 <3JmCVIcKqI8MlE_0R1FPVuK1sxrNFcuZC4D9F8EgbJw=.d51d6c4a-2f8c-46b3-9cbc-9e7913e5be13@github.com>
 <-1DDZYmc7t6ku4qKnSQ09mXOeILUe3yR_Hu2q1rYekw=.de2dd7fe-1c99-4648-8050-d4a5735ea76e@github.com>
Message-ID: <3NyOPh2FffnIS4-mFYOA3WyKlBwTMYiqrveAx5gd7BA=.88de355c-9e15-4381-aeb3-523cc315898e@github.com>

On Thu, 29 Apr 2021 13:06:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I suspect that if setProperty("native.encoding", "foo") succeeds, then it will return "foo".   I also believe that a later invocation of getProperty("native.encoding") will also return "foo".  If that's the case, then I don't think that the "read-only" alternative phrasing is correct.  To me, the alternative suggests that an error will be return if there is an attempt to set it or that the potential new value will be ignored.  The "no effect" phrasing avoids this problem.   I also suspect that the "no effect" phrasing was selected to align with the apiNote in lines 719-721.
>
> Thanks, Joe and Iris. I agree with Iris and that's the reason I chose the description. System properties are inherently mutable. There are some "protected" ones, by that I mean a private copy is made just after initialization for VM use, which is not affected by later setProperty() calls. But I don't think this new property should be treated as such.

The value of native.encoding should be a static property; that is, read once at startup and later modification
does not change the behavior of the Java runtime.

Whereas the value of native.encoding is derived from the value of native variables and those native
values do not change while Java is running, I think the behavior of the Java runtime should stay the same.
Unless it is static, the Java runtime will need to read the property every time it is needed and behavior can
change from call to call and actions in one thread can affect other threads.
Is there a use case where the application needs to change the encoding for every use in the Java runtime
independently of the native values.
Such an application should be explicit about its charset requirements and use APIs to select them explicitly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From naoto at openjdk.java.net  Thu Apr 29 13:42:51 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 29 Apr 2021 13:42:51 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <Cu5-h0O6XHeXhU9QWkT_C_dvNfuUuyAjv9tBuCoD6kY=.0eeb4f6e-bbb9-455b-9f25-5f450c8293c4@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <RbkBaU8H-etOk0bv3oIlOz1UHCFh9k-rHCmOUFZUZRw=.4826e3b8-fa31-43da-a98a-e1bb9d5e212c@github.com>
 <H61pziXTy_TmaaJiTZWZnSHh01PaX8n1QBvQYdFoiiI=.cfd4bf6c-a2a7-4dca-b57b-98e6ba428c1d@github.com>
 <Cu5-h0O6XHeXhU9QWkT_C_dvNfuUuyAjv9tBuCoD6kY=.0eeb4f6e-bbb9-455b-9f25-5f450c8293c4@github.com>
Message-ID: <WL8F5zscttHlR9n6PFIMWtwPTTXZwEWU3E1nDOpQmwA=.db8599ee-b4e1-4f9e-90e9-27cca3a3f7be@github.com>

On Thu, 29 Apr 2021 13:23:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `native.encoding` preserves the encoding that current `Charset.defaultCharset()` is returning, which is based on `file.encoding`. So I believe the current implementation is correct. If it is biased toward `sun.jnu.encoding`, it would be problematic especially on Windows where that represents `system locale`.
>
> Okay for now but the value of file.encoding will change to "UTF-8" so will be different to native.encoding.

Yes. That will be covered by JEP400.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From mcimadamore at openjdk.java.net  Thu Apr 29 14:11:58 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 29 Apr 2021 14:11:58 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
Message-ID: <e_SeiARdE6hQsA-5zFShkorGg1lr8KkF0YYcNsS3cgo=.52c6a0ce-bd03-4b13-98eb-05d202ce0c1b@github.com>

On Wed, 28 Apr 2021 22:24:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

Naive question: any reason as to why we're not providing a new static API method in Charset to return the platform encoder? This initially will return same thing as Charset.defaultEncoder - but as JEP 400 is delivered the two will diverge. Any reason as to why we don't want to expose the platform encoder in the API?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From mcimadamore at openjdk.java.net  Thu Apr 29 14:15:54 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 29 Apr 2021 14:15:54 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <e_SeiARdE6hQsA-5zFShkorGg1lr8KkF0YYcNsS3cgo=.52c6a0ce-bd03-4b13-98eb-05d202ce0c1b@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <e_SeiARdE6hQsA-5zFShkorGg1lr8KkF0YYcNsS3cgo=.52c6a0ce-bd03-4b13-98eb-05d202ce0c1b@github.com>
Message-ID: <UV8kx6NKad3vfo5TchF0ixjb2LijzeEcIroxgrJ0ZAY=.66038785-c62c-48e6-86fd-f36881b3c56b@github.com>

On Thu, 29 Apr 2021 14:08:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Naive question: any reason as to why we're not providing a new static API method in Charset to return the platform encoder? This initially will return same thing as Charset.defaultEncoder - but as JEP 400 is delivered the two will diverge. Any reason as to why we don't want to expose the platform encoder in the API?

Ok, I see this is addressed in the CSR:


We converged on a system property out of concern that an API method for the native encoding would be confusing for many developers.


The problem with this approach is that I think clients that need the platform encoder will have to stash it somewhere in a static field (to prevent reading property and parsing value over and over). It might also be harder for javadoc (I'm thinking of some of the Panama API) to express a dependency on it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From alanb at openjdk.java.net  Thu Apr 29 14:43:55 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 29 Apr 2021 14:43:55 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <UV8kx6NKad3vfo5TchF0ixjb2LijzeEcIroxgrJ0ZAY=.66038785-c62c-48e6-86fd-f36881b3c56b@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <e_SeiARdE6hQsA-5zFShkorGg1lr8KkF0YYcNsS3cgo=.52c6a0ce-bd03-4b13-98eb-05d202ce0c1b@github.com>
 <UV8kx6NKad3vfo5TchF0ixjb2LijzeEcIroxgrJ0ZAY=.66038785-c62c-48e6-86fd-f36881b3c56b@github.com>
Message-ID: <qU87QQ4ALwXR_MDrf4QMjL1Ykh2YsRVFTzz5IVzD5DI=.b4bf51b3-3e1b-48bc-bfaa-fb9e64b076f8@github.com>

On Thu, 29 Apr 2021 14:12:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Naive question: any reason as to why we're not providing a new static API method in Charset to return the platform encoder? This initially will return same thing as Charset.defaultEncoder - but as JEP 400 is delivered the two will diverge. Any reason as to why we don't want to expose the platform encoder in the API?

Agree an API would be better.  We've looked at it a few times but have concerns that it would be confusing to most developers, esp. if it were another static method on Charset.  System and Runtime have been examined too. The proposal here doesn't preclude adding an API in the future, it's mostly a question on whether it is needed and where would it be defined.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From bpb at openjdk.java.net  Thu Apr 29 15:38:53 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 29 Apr 2021 15:38:53 GMT
Subject: Integrated: 8266014: Regression brought by optimization done with
 JDK-4926314
In-Reply-To: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>
References: <2Ct2FE0voY2rKn6je546JuscZnwrnIO4LH-7jJbJ7UQ=.a23f8b16-411d-47e0-8409-f045f6c80b58@github.com>
Message-ID: <OvVhnZOfY9FjkBML7G_CtWCtkmkAXJkzH_hWlih26vI=.cea9c72b-4f0e-44d6-8312-d9fb97c8f8ed@github.com>

On Tue, 27 Apr 2021 01:26:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this request to correct a minor problem with the optimization added for JDK-4926314. The change is to attempt to read the number of elements remaining in the target buffer unless that number is non-positive in which case read zero. The test addition fails without and passes with the implementation change.

This pull request has now been integrated.

Changeset: 2a037395
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2a037395306edc96338073dead70045fcf3167c6
Stats:     20 lines in 2 files changed: 16 ins; 2 del; 2 mod

8266014: Regression brought by optimization done with JDK-4926314

Reviewed-by: alanb, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/3708

From jpai at openjdk.java.net  Thu Apr 29 15:41:55 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 29 Apr 2021 15:41:55 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v4]
In-Reply-To: <xIE8AvPWcFR_f-z7z4Om_zSn1J8_xUXY6egI9MHIrNU=.8ae9c4f6-cd29-4f46-ab82-47ea43052205@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <xIE8AvPWcFR_f-z7z4Om_zSn1J8_xUXY6egI9MHIrNU=.8ae9c4f6-cd29-4f46-ab82-47ea43052205@github.com>
Message-ID: <0XokWYXVb6wKP82I5fJCll_pYayCpu46bb34r4_K7sU=.ae8dfde4-ae99-425e-9074-2abbf81d774f@github.com>

On Thu, 1 Apr 2021 15:02:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Lance's review - include tests for --extract long form option
>  - cleanup after each test
>  - Adjust test for new error messages
>  - Lance's review - add a code comment for xdestDir
>  - Lance's review - updates to the help messages in jar.properties
>  - Lance's review - add comment to the magic number 6 in the tests
>  - Lance's review - add comments to test methods

Still active. Been busy with a few other things and I just need to get back and implement some inputs from Lance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2752

From bpb at openjdk.java.net  Thu Apr 29 15:58:03 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 29 Apr 2021 15:58:03 GMT
Subject: Integrated: 8266078: Reader.read(CharBuffer) advances Reader position
 for read-only Charbuffers
In-Reply-To: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
References: <eXJ-lXb-DrWId0Lc1tQUysCSn0Nx4YUkDGKhZ6cQOIs=.c95f0a6d-71ba-42dc-b4de-a1cd19ed4386@github.com>
Message-ID: <X5KuWwRnJNhF8tl6l6O1n1d8zUF1RRMpd7x01zgjr24=.7bb358fa-d41e-4a6b-8822-4d54c78775f7@github.com>

On Tue, 27 Apr 2021 18:47:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position.

This pull request has now been integrated.

Changeset: 5f156660
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5f15666092d9928c07cbe66cdd96538459ffe393
Stats:     71 lines in 2 files changed: 71 ins; 0 del; 0 mod

8266078: Reader.read(CharBuffer) advances Reader position for read-only Charbuffers

Reviewed-by: rriggs, alanb, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/3725

From naoto at openjdk.java.net  Thu Apr 29 16:34:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 29 Apr 2021 16:34:50 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
Message-ID: <--yRaKYVMaJd2zywMaz2Si1dMXvuvSTmR4mnyTdF6Qk=.52691876-bd56-4ff8-a8e8-db8173742835@github.com>

On Wed, 28 Apr 2021 22:24:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

Unless there is some use case other than for migration, I would not introduce a static method as Alan mentioned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From joehw at openjdk.java.net  Thu Apr 29 18:02:53 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 29 Apr 2021 18:02:53 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <3NyOPh2FffnIS4-mFYOA3WyKlBwTMYiqrveAx5gd7BA=.88de355c-9e15-4381-aeb3-523cc315898e@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <L4cp8q0gJKCoJzPTAC6O44uUxLHQEYTSpH3SKvRVw1c=.b8f7c8e4-d030-4f7f-a701-79ef8aaafba6@github.com>
 <3JmCVIcKqI8MlE_0R1FPVuK1sxrNFcuZC4D9F8EgbJw=.d51d6c4a-2f8c-46b3-9cbc-9e7913e5be13@github.com>
 <-1DDZYmc7t6ku4qKnSQ09mXOeILUe3yR_Hu2q1rYekw=.de2dd7fe-1c99-4648-8050-d4a5735ea76e@github.com>
 <3NyOPh2FffnIS4-mFYOA3WyKlBwTMYiqrveAx5gd7BA=.88de355c-9e15-4381-aeb3-523cc315898e@github.com>
Message-ID: <lrp2WuCyYSV-7amFFg0-egDH4rC2v9p_9Rpt0AesrSM=.f39ee390-0555-4dbc-8372-241f9ad88840@github.com>

On Thu, 29 Apr 2021 13:39:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thanks, Joe and Iris. I agree with Iris and that's the reason I chose the description. System properties are inherently mutable. There are some "protected" ones, by that I mean a private copy is made just after initialization for VM use, which is not affected by later setProperty() calls. But I don't think this new property should be treated as such.
>
> The value of native.encoding should be a static property; that is, read once at startup and later modification
> does not change the behavior of the Java runtime.
> 
> Whereas the value of native.encoding is derived from the value of native variables and those native
> values do not change while Java is running, I think the behavior of the Java runtime should stay the same.
> Unless it is static, the Java runtime will need to read the property every time it is needed and behavior can
> change from call to call and actions in one thread can affect other threads.
> Is there a use case where the application needs to change the encoding for every use in the Java runtime
> independently of the native values.
> Such an application should be explicit about its charset requirements and use APIs to select them explicitly.

Ok, understandable, and having a statement to clearly say 'no effect' would be indeed helpful. While working on methods with a charset parameter some time ago, I remember reading some user discussions about unable to programmatically change the default encoding, a confusion mostly as the user attempted to set encoding, e.g. System.setProperty("file.encoding", encoding), it seems that "the property is set (meaning no error), but it did not have the desired effect". Then there was also a mention in some tutorial where file.encoding and sun.jnu.encoding were recognized as read-only. The problem or confusion was that it appeared there?s such an API and the operation was successful, but it really didn?t have the effect.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From mchung at openjdk.java.net  Thu Apr 29 18:20:53 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 29 Apr 2021 18:20:53 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <U05VgHVCM-mzgyvhcErkcFxVtzS24vAqCj-Y73tbgsU=.947cfa12-4f39-460c-9140-8bb82b4272cc@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
 <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>
 <DqCFjiDHnq8UNre4Ux54AxHKFNcD4hfXW8_Yzcegyu8=.ec8272ca-15eb-4c7f-a0a9-d5f92c362dac@github.com>
 <cdoCk0mIpSe5RAoNy0cW_KdmcGlSc0VvaQhekiohWrQ=.16c012f3-0b78-4a39-9686-e322451e3ba2@github.com>
 <L6SrFTB58RAe-IgK0yqhJB_FXTM-dBLe5a1xfrtTqwQ=.8455897b-3dfd-4f6a-929c-8b80f834e892@github.com>
 <U05VgHVCM-mzgyvhcErkcFxVtzS24vAqCj-Y73tbgsU=.947cfa12-4f39-460c-9140-8bb82b4272cc@github.com>
Message-ID: <UvyGpWdRxJDT1_J_okYNIP1JUQeGiar76pGQtxP4gNI=.bd657c24-2226-49c2-a3a7-1562bcffe93d@github.com>

On Thu, 29 Apr 2021 10:31:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I think I expect that, with caller sensitive, it is possible from a client in an "enabled" module to obtain a MethodHandle, and then pass it to an unprivileged module, which then calls it, and works ok. This matches my expectation (this trick could be used also to give a client access to an otherwise inaccessible - in the classic sense - method).
> 
> So, when working with method handles, I'm completely fine working with the lookup class as context (and not with the real caller class).

Good, this matches the behavior of method handles for CSMs.   However, I think the implementation does the opposite since we don't support interface method being CSM.  Can you test that out?

> Given all this, do you agree that current checks are not affected by interface-ness of some of the methods involved?

I think the implementation does not support that.   I will also need to look into how this impacts JDK-8266010.  As I suggest earlier, I'm fine to do this as a follow up after integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From sviswanathan at openjdk.java.net  Thu Apr 29 21:39:11 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 29 Apr 2021 21:39:11 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice operations
Message-ID: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>

All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).

Changes include:
 * Rewrite Vector API slice/unslice using already intrinsic methods
 * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
 * Vector API conversion tests thresholds adjustment
 
Base Performance:
Benchmark (size) Mode Cnt Score Error Units
TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms

Performance with patch:
Benchmark (size) Mode Cnt Score Error Units
TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

-------------

Commit messages:
 - 8265128: [REDO] Optimize Vector API slice and unslice operations

Changes: https://git.openjdk.java.net/jdk/pull/3804/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265128
  Stats: 886 lines in 44 files changed: 175 ins; 518 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3804.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3804/head:pull/3804

PR: https://git.openjdk.java.net/jdk/pull/3804

From uschindler at openjdk.java.net  Thu Apr 29 21:57:55 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Thu, 29 Apr 2021 21:57:55 GMT
Subject: RFR: 8265137: java.util.Random suddenly has new public methods
 nowhere documented [v7]
In-Reply-To: <f7Sxm4zDo9zwsuqIyQVU6HonLDB3vPNppAs6vNkWGJo=.194ecc5f-f8fa-435d-83e5-e0d82891211d@github.com>
References: <kTPaDGvoEQOVm6qnMNef6lENqCrrPhjhvjR4YeinWio=.6e804893-d9e1-4e57-9fcf-1dc256aaf3c8@github.com>
 <f7Sxm4zDo9zwsuqIyQVU6HonLDB3vPNppAs6vNkWGJo=.194ecc5f-f8fa-435d-83e5-e0d82891211d@github.com>
Message-ID: <b1YOncSbyswd1wKH0nw0-hP5vP8PnltygAk5EF3obVE=.50a701d3-a54f-4fd4-be99-26c80f93ca0b@github.com>

On Tue, 27 Apr 2021 10:50:51 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary constructor.

Marked as reviewed by uschindler (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3469

From psandoz at openjdk.java.net  Thu Apr 29 23:12:51 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 29 Apr 2021 23:12:51 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations
In-Reply-To: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
Message-ID: <EV_vCwC-iVsJ_MUPJfX-tUglh7lrGO3S9DPjC9PNdrU=.7dba7cfc-4e93-446d-a7d9-72e8bcddda1d@github.com>

On Thu, 29 Apr 2021 21:29:03 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2283:

> 2281:     @ForceInline
> 2282:     $abstractvectortype$ sliceTemplate(int origin) {
> 2283:         Objects.checkIndex(origin, length());

For `Objects.checkIndex` the upper bound is exclusive, where as i think in this case it needs to be inclusive.

The original bound check was:

       if ((origin < 0) || (origin >= VLENGTH)) {
         throw new ArrayIndexOutOfBoundsException("Index " + origin + " out of bounds for vector length " + VLENGTH);
       }
...

in accordance with the spec in the JavaDoc.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2284:

> 2282:     $abstractvectortype$ sliceTemplate(int origin) {
> 2283:         Objects.checkIndex(origin, length());
> 2284:         VectorShuffle<$Boxtype$> Iota = iotaShuffle();

Suggestion:

        VectorShuffle<$Boxtype$> iota = iotaShuffle();

use lower case first letter for variable names.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2287:

> 2285:         VectorMask<$Boxtype$> BlendMask = Iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));
> 2286:         Iota = iotaShuffle(origin, 1, true);
> 2287:         return vspecies().zero().blend(this.rearrange(Iota), BlendMask);

Observation: this is like `this.rearrange(iota, blendMask)` but we avoid the checking for exceptional shuffle indexes, since we know there are no such exceptional indexes.

And, of course,this method is like `slice(origin vspecies().zero())`. I wonder if this template should defer to the vector accepting tempting? Or the method on vector itself?

test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java line 51:

> 49:     }
> 50: 
> 51:     static final int INVOC_COUNT = Integer.getInteger("jdk.incubator.vector.test.loop-iterations", 100);

Why did you change this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Thu Apr 29 23:39:00 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 29 Apr 2021 23:39:00 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations
In-Reply-To: <EV_vCwC-iVsJ_MUPJfX-tUglh7lrGO3S9DPjC9PNdrU=.7dba7cfc-4e93-446d-a7d9-72e8bcddda1d@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <EV_vCwC-iVsJ_MUPJfX-tUglh7lrGO3S9DPjC9PNdrU=.7dba7cfc-4e93-446d-a7d9-72e8bcddda1d@github.com>
Message-ID: <gwPwtC3waBKmpr9y-Yh5GlMMKohxeU1Kb_8B98c9qnA=.60fedc2f-b968-4834-a4b5-6a2251a401a7@github.com>

On Thu, 29 Apr 2021 22:59:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2283:
> 
>> 2281:     @ForceInline
>> 2282:     $abstractvectortype$ sliceTemplate(int origin) {
>> 2283:         Objects.checkIndex(origin, length());
> 
> For `Objects.checkIndex` the upper bound is exclusive, where as i think in this case it needs to be inclusive.
> 
> The original bound check was:
> 
>        if ((origin < 0) || (origin >= VLENGTH)) {
>          throw new ArrayIndexOutOfBoundsException("Index " + origin + " out of bounds for vector length " + VLENGTH);
>        }
> ...
> 
> in accordance with the spec in the JavaDoc.

Thanks for pointing this out. I will update this to Objects.checkIndex(origin, length()+1);

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2284:
> 
>> 2282:     $abstractvectortype$ sliceTemplate(int origin) {
>> 2283:         Objects.checkIndex(origin, length());
>> 2284:         VectorShuffle<$Boxtype$> Iota = iotaShuffle();
> 
> Suggestion:
> 
>         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 
> use lower case first letter for variable names.

I will make this change.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2287:
> 
>> 2285:         VectorMask<$Boxtype$> BlendMask = Iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));
>> 2286:         Iota = iotaShuffle(origin, 1, true);
>> 2287:         return vspecies().zero().blend(this.rearrange(Iota), BlendMask);
> 
> Observation: this is like `this.rearrange(iota, blendMask)` but we avoid the checking for exceptional shuffle indexes, since we know there are no such exceptional indexes.
> 
> And, of course,this method is like `slice(origin vspecies().zero())`. I wonder if this template should defer to the vector accepting tempting? Or the method on vector itself?

Trying to optimize as much as possible:
  There is overhead in checking for exception shuffle indices. 
  The slice(origin, vector) version has one extra rearrange call.

> test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java line 51:
> 
>> 49:     }
>> 50: 
>> 51:     static final int INVOC_COUNT = Integer.getInteger("jdk.incubator.vector.test.loop-iterations", 100);
> 
> Why did you change this?

Following reasons:
The INVOC_COUNT is set as 100 for all other tests.
The conversion tests take longer time to complete than other tests.
For the conversion tests it looks like the intrinsics don't trigger sometimes and tests take longer to execute and timeout. This was one of the reasons for backout last time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Fri Apr 30 00:17:24 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 00:17:24 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v2]
In-Reply-To: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
Message-ID: <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments implementation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3804/files
  - new: https://git.openjdk.java.net/jdk/pull/3804/files/54dd9206..59275ff6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=00-01

  Stats: 140 lines in 7 files changed: 0 ins; 0 del; 140 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3804.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3804/head:pull/3804

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Fri Apr 30 00:17:24 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 00:17:24 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations
In-Reply-To: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
Message-ID: <2opc6tTQSrlcWwUz_hpbX80AVyujsk_SPBDtXaCcMDo=.5f9cd5c2-ebe3-4a99-b384-e174b979ae7b@github.com>

On Thu, 29 Apr 2021 21:29:03 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

@PaulSandoz I have implemented your review comments. Please take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From psandoz at openjdk.java.net  Fri Apr 30 00:26:57 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 00:26:57 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v2]
In-Reply-To: <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>
Message-ID: <ujfoAas6-HvMY_RChzMRRJn5BVgvkt--LDLD5j4M5qs=.e019f2cb-4cf8-4fe3-9b0b-e5fd07bf582a@github.com>

On Fri, 30 Apr 2021 00:17:24 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments implementation

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2255:

> 2253:         Objects.checkIndex(origin, length() + 1);
> 2254:         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 2255:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));

Suggestion:

        VectorMask<$Boxtype$> blendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2257:

> 2255:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));
> 2256:         iota = iotaShuffle(origin, 1, true);
> 2257:         return (($abstractvectortype$)v1).rearrange(iota).blend(this.rearrange(iota), BlendMask);

Suggestion:

        return that.rearrange(iota).blend(this.rearrange(iota), blendMask);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2285:

> 2283:         Objects.checkIndex(origin, length() + 1);
> 2284:         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 2285:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));

Suggestion:

        VectorMask<$Boxtype$> blendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2287:

> 2285:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));
> 2286:         iota = iotaShuffle(origin, 1, true);
> 2287:         return vspecies().zero().blend(this.rearrange(iota), BlendMask);

Suggestion:

        return vspecies().zero().blend(this.rearrange(iota), blendMask);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2306:

> 2304:         Objects.checkIndex(origin, length() + 1);
> 2305:         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 2306:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare((part == 0) ? VectorOperators.GE : VectorOperators.LT,

Suggestion:

        VectorMask<$Boxtype$> blendMask = iota.toVector().compare((part == 0) ? VectorOperators.GE : VectorOperators.LT,

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2309:

> 2307:                                                                   (broadcast(($type$)(origin))));
> 2308:         iota = iotaShuffle(-origin, 1, true);
> 2309:         return (($abstractvectortype$)w).blend(this.rearrange(iota), BlendMask);

Suggestion:

        return that.blend(this.rearrange(iota), blendMask);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2346:

> 2344:         Objects.checkIndex(origin, length() + 1);
> 2345:         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 2346:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.GE,

Suggestion:

        VectorMask<$Boxtype$> blendMask = iota.toVector().compare(VectorOperators.GE,

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2349:

> 2347:                                                                   (broadcast(($type$)(origin))));
> 2348:         iota = iotaShuffle(-origin, 1, true);
> 2349:         return vspecies().zero().blend(this.rearrange(iota), BlendMask);

Suggestion:

        return vspecies().zero().blend(this.rearrange(iota), blendMask);

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From psandoz at openjdk.java.net  Fri Apr 30 00:26:58 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 00:26:58 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v2]
In-Reply-To: <gwPwtC3waBKmpr9y-Yh5GlMMKohxeU1Kb_8B98c9qnA=.60fedc2f-b968-4834-a4b5-6a2251a401a7@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <EV_vCwC-iVsJ_MUPJfX-tUglh7lrGO3S9DPjC9PNdrU=.7dba7cfc-4e93-446d-a7d9-72e8bcddda1d@github.com>
 <gwPwtC3waBKmpr9y-Yh5GlMMKohxeU1Kb_8B98c9qnA=.60fedc2f-b968-4834-a4b5-6a2251a401a7@github.com>
Message-ID: <WwxdocDVhbI52IuBGm3UW6qcQFeabkHANYbf8O5GKMM=.a63c0a29-361d-4490-9b2c-65c1ad93d2d4@github.com>

On Thu, 29 Apr 2021 23:36:22 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java line 51:
>> 
>>> 49:     }
>>> 50: 
>>> 51:     static final int INVOC_COUNT = Integer.getInteger("jdk.incubator.vector.test.loop-iterations", 100);
>> 
>> Why did you change this?
>
> Following reasons:
> The INVOC_COUNT is set as 100 for all other tests.
> The conversion tests take longer time to complete than other tests.
> For the conversion tests it looks like the intrinsics don't trigger sometimes and tests take longer to execute and timeout. This was one of the reasons for backout last time.

ok

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Fri Apr 30 01:58:27 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 01:58:27 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
Message-ID: <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments: blendmask etc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3804/files
  - new: https://git.openjdk.java.net/jdk/pull/3804/files/59275ff6..94f184ef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=01-02

  Stats: 56 lines in 7 files changed: 0 ins; 0 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3804.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3804/head:pull/3804

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Fri Apr 30 01:58:30 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 01:58:30 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v2]
In-Reply-To: <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>
Message-ID: <9y-PxR99CcZJTpYG8NvzZtAz4PO7m-N7APoIe7kWruk=.75d590cc-5cb8-4588-9a62-c3f013f85291@github.com>

On Fri, 30 Apr 2021 00:17:24 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments implementation

@PaulSandoz Thanks a lot for these suggestions. I have included all of them in this updated commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From yyang at openjdk.java.net  Fri Apr 30 02:19:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 30 Apr 2021 02:19:30 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  better check1-4

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/1a96be7e..954abc6e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=04-05

  Stats: 32 lines in 1 file changed: 31 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From psandoz at openjdk.java.net  Fri Apr 30 02:33:52 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 02:33:52 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
Message-ID: <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>

On Fri, 30 Apr 2021 01:58:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments: blendmask etc

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From almatvee at openjdk.java.net  Fri Apr 30 04:29:01 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 30 Apr 2021 04:29:01 GMT
Subject: RFR: 8266179: [macos] jpackage should specify architecture for
 produced pkg files
Message-ID: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com>

jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2.

-------------

Commit messages:
 - 8266179: [macos] jpackage should specify architecture for produced pkg files

Changes: https://git.openjdk.java.net/jdk/pull/3807/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3807&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266179
  Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3807.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3807/head:pull/3807

PR: https://git.openjdk.java.net/jdk/pull/3807

From joehw at openjdk.java.net  Fri Apr 30 04:41:54 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 30 Apr 2021 04:41:54 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
Message-ID: <v8kBkhr-KYObCODzK23mgUYVPp2RiluRQ6GD2_wgsxg=.001b091b-e904-4110-9781-09adab82be73@github.com>

On Wed, 28 Apr 2021 22:24:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From dfuchs at openjdk.java.net  Fri Apr 30 08:59:51 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 30 Apr 2021 08:59:51 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
Message-ID: <7a4Q1KdYnrj-8iKArQaCHP_s6QHuN58Gz1PpvlSOKzo=.03f760ef-75a4-4882-ac3a-b5a21bc3d73d@github.com>

On Fri, 30 Apr 2021 02:19:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better check1-4

Thanks for taking this feedback into account and updating the test!
Note: I only reviewed the test.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3615

From lzang at openjdk.java.net  Fri Apr 30 11:55:12 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 30 Apr 2021 11:55:12 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v6]
In-Reply-To: <EIq06Sr2HC72GyP_n1zQtPjGQ-FMSwTQteonPK39IsQ=.ede214cb-15c6-4cfa-ab09-174894c88e5c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <EIq06Sr2HC72GyP_n1zQtPjGQ-FMSwTQteonPK39IsQ=.ede214cb-15c6-4cfa-ab09-174894c88e5c@github.com>
Message-ID: <h0IFMItn3Z3dzmrizozX89LbPiKA5ZkE96weOjonK-o=.db45ef67-8444-4e6e-9d7f-6888952d2bbc@github.com>

On Thu, 15 Apr 2021 12:41:17 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 4890732: GZIPOutputStream doesn't support optional GZIP fields
>
> Lin Zang 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 ten additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into gzip-field
>  - remove trailing spaces
>  - Use record and Builder pattern
>  - add class GZIPHeaderData, refine testcases
>  - update copyright
>  - reuse arguments constructor for non-argument one.
>  - add test case
>  - remove trailing spaces
>  - 4890732: support optional GZIP fields in GZIPOutputStream

Dear Lance, 
    Sorry for late response.
    
>  the updates to the PR does not include any proposed changes to GZIPInputStream and this should be something we should come to an agreement on as it can possibly impact the direction. I am not sure we need to add multiple constructors to GZIPOutputStream as part of the proposed change.

With the latest change, the gzip header data could be composed by GZIPHeaderBuilder, But it seems ithere still need a way to write the header data when GZipOutputStream is created.Therefore IMHO at least one more constructor is required which could accept the header data and then write them.

For GZIPInputStream, as there is GZIPHeaderBuilder now, I think there is no need to add any constructor for it. We can use the builder to generate gzip header data when parsing the Gzip header.  For example, re-write the readHeader() to generate gzip header data, and provide api that user could access the header data.

> It would also be useful to know where is the actual pain point, that is, is there a tool or API not having these fields settable for that is causing an issue? I ask so that we can make sure that we are taking that into consideration.

Frankly, I only experienced the use of extra gzip header field when work on the gziped heap dump file generated by  `jmap -dump` with `gz` option. It uses the extra field to provide some meta info that maybe used for decompressing.  I didn't see the usage of these header info in other place.  So I believe that not having these fields settable is OK  at present (at least).

The intention that I try to provide this PR is that I think, since the gzip file spec has described the header field, maybe in some scenario user may need a way to access/set it in Java.  

Thanks.
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From mcimadamore at openjdk.java.net  Fri Apr 30 12:23:45 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 30 Apr 2021 12:23:45 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v6]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <tmPtJ-HL02xAhTrHZgWJXHu0KlzndGt9Dca0r9JCebc=.e31c4e9f-880f-496e-bc9b-24a79f34e261@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  * Add @CS to interface methods in the Foreign API
  * Beef up test for methd handles and restricted methods

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/f27db3f3..75474a1f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=04-05

  Stats: 306 lines in 8 files changed: 306 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From mcimadamore at openjdk.java.net  Fri Apr 30 12:27:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 30 Apr 2021 12:27:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <UvyGpWdRxJDT1_J_okYNIP1JUQeGiar76pGQtxP4gNI=.bd657c24-2226-49c2-a3a7-1562bcffe93d@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
 <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>
 <DqCFjiDHnq8UNre4Ux54AxHKFNcD4hfXW8_Yzcegyu8=.ec8272ca-15eb-4c7f-a0a9-d5f92c362dac@github.com>
 <cdoCk0mIpSe5RAoNy0cW_KdmcGlSc0VvaQhekiohWrQ=.16c012f3-0b78-4a39-9686-e322451e3ba2@github.com>
 <L6SrFTB58RAe-IgK0yqhJB_FXTM-dBLe5a1xfrtTqwQ=.8455897b-3dfd-4f6a-929c-8b80f834e892@github.com>
 <U05VgHVCM-mzgyvhcErkcFxVtzS24vAqCj-Y73tbgsU=.947cfa12-4f39-460c-9140-8bb82b4272cc@github.com>
 <UvyGpWdRxJDT1_J_okYNIP1JUQeGiar76pGQtxP4gNI=.bd657c24-2226-49c2-a3a7-1562bcffe93d@github.com>
Message-ID: <z1iEfHGxloZm2O2AhKPq9y_zYwEGymaWSUDOzefVNE4=.a1e23412-73fa-4691-be18-4ae0c02e4a60@github.com>

On Thu, 29 Apr 2021 18:18:00 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I think the implementation does not support that. I will also need to look into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do this as a follow up after integration.

I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).

Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From herrick at openjdk.java.net  Fri Apr 30 12:51:50 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 30 Apr 2021 12:51:50 GMT
Subject: RFR: 8266179: [macos] jpackage should specify architecture for
 produced pkg files
In-Reply-To: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com>
References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com>
Message-ID: <zm2elRtrPkziOMbFU8zv8snlTPsbuSHd-nrf95KTUJ8=.c37ad928-9452-49f2-a2b2-47b0338785e6@github.com>

On Fri, 30 Apr 2021 04:22:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3807

From kcr at openjdk.java.net  Fri Apr 30 12:51:50 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 30 Apr 2021 12:51:50 GMT
Subject: RFR: 8266179: [macos] jpackage should specify architecture for
 produced pkg files
In-Reply-To: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com>
References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com>
Message-ID: <KW37n31A8ygNQwYVsVHu0fwWn_-jVrz7LOLe5UaHrW8=.ffdbed32-57a8-446d-aa31-29c2b477335a@github.com>

On Fri, 30 Apr 2021 04:22:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2.

The fix looks good. Would it be feasible to include an automated test for this?

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/3807

From jbhateja at openjdk.java.net  Fri Apr 30 12:59:34 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 30 Apr 2021 12:59:34 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v2]
In-Reply-To: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
Message-ID: <YcxnCbTjMJi0n5ftQm1iYxc2JDTezQvoHkaWd0olAU8=.f3ffc87a-06ea-40b3-9956-14ff566159d8@github.com>

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server)
> 
> ``
> Benchmark | (TESTSIZE) | Baseline (ops/min) | Withopt (ops/min) | Gain %
> -- | -- | -- | -- | --
> RotateBenchmark.testRotateLeftI | 64 | 6813.033 | 6936.507 | 1.81
> RotateBenchmark.testRotateLeftI | 64 | 11549.524 | 12109.845 | 4.85
> RotateBenchmark.testRotateLeftI | 64 | 17780.166 | 18180.083 | 2.25
> RotateBenchmark.testRotateLeftI | 128 | 3355.631 | 3426.436 | 2.11
> RotateBenchmark.testRotateLeftI | 128 | 5925.534 | 6096.71 | 2.89
> RotateBenchmark.testRotateLeftI | 128 | 8847.645 | 8964.224 | 1.32
> RotateBenchmark.testRotateLeftI | 256 | 1704.192 | 1779.964 | 4.45
> RotateBenchmark.testRotateLeftI | 256 | 2919.158 | 3000.392 | 2.78
> RotateBenchmark.testRotateLeftI | 256 | 4386.134 | 4514.211 | 2.92
> RotateBenchmark.testRotateLeftL | 64 | 3419.193 | 3500.522 | 2.38
> RotateBenchmark.testRotateLeftL | 64 | 5982.87 | 6056.589 | 1.23
> RotateBenchmark.testRotateLeftL | 64 | 8829.172 | 8949.157 | 1.36
> RotateBenchmark.testRotateLeftL | 128 | 1684.745 | 1784.49 | 5.92
> RotateBenchmark.testRotateLeftL | 128 | 2942.226 | 2947.684 | 0.19
> RotateBenchmark.testRotateLeftL | 128 | 4385.488 | 4554.113 | 3.85
> RotateBenchmark.testRotateLeftL | 256 | 834.195 | 856.939 | 2.73
> RotateBenchmark.testRotateLeftL | 256 | 1463.802 | 1551.051 | 5.96
> RotateBenchmark.testRotateLeftL | 256 | 2187.005 | 2268.596 | 3.73
> RotateBenchmark.testRotateRightI | 64 | 6676.132 | 7077.587 | 6.01
> RotateBenchmark.testRotateRightI | 64 | 11452.825 | 11855.45 | 3.52
> RotateBenchmark.testRotateRightI | 64 | 17507.286 | 18164.757 | 3.76
> RotateBenchmark.testRotateRightI | 128 | 3412.394 | 3519.829 | 3.15
> RotateBenchmark.testRotateRightI | 128 | 5905.677 | 5875.698 | -0.51
> RotateBenchmark.testRotateRightI | 128 | 8745.95 | 8890.757 | 1.66
> RotateBenchmark.testRotateRightI | 256 | 1681.176 | 1708.54 | 1.63
> RotateBenchmark.testRotateRightI | 256 | 3004.008 | 3005.606 | 0.05
> RotateBenchmark.testRotateRightI | 256 | 4466.633 | 4548.232 | 1.83
> RotateBenchmark.testRotateRightL | 64 | 3361.499 | 3461.121 | 2.96
> RotateBenchmark.testRotateRightL | 64 | 5873.37 | 6072.209 | 3.39
> RotateBenchmark.testRotateRightL | 64 | 8820.284 | 9016.172 | 2.22
> RotateBenchmark.testRotateRightL | 128 | 1715.556 | 1720.67 | 0.30
> RotateBenchmark.testRotateRightL | 128 | 2957.337 | 3149.193 | 6.49
> RotateBenchmark.testRotateRightL | 128 | 4440.468 | 4473.221 | 0.74
> RotateBenchmark.testRotateRightL | 256 | 851.391 | 875.371 | 2.82
> RotateBenchmark.testRotateRightL | 256 | 1452.422 | 1522.942 | 4.86
> RotateBenchmark.testRotateRightL | 256 | 2208.454 | 2263.349 | 2.49
> 
>  ``

Jatin Bhateja 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:

 - 8266054: Review comments resolution.
 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - 8266054: Changing gen-src.sh file permissions
 - 8266054: VectorAPI rotate operation optimization

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3720/files
  - new: https://git.openjdk.java.net/jdk/pull/3720/files/1e3e350e..eee407b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=00-01

  Stats: 6574 lines in 245 files changed: 4515 ins; 1280 del; 779 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720

PR: https://git.openjdk.java.net/jdk/pull/3720

From mcimadamore at openjdk.java.net  Fri Apr 30 15:20:42 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 30 Apr 2021 15:20:42 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v7]
In-Reply-To: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
Message-ID: <xHNHdhBRHVEHfehNhvq_oli_DrFP2sG-A4f6vM9UV7U=.db4711de-f37c-485a-a775-e57bdb4b7493@github.com>

> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Revert bad change in benchmark copyright
 - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/75474a1f..793ea5c5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=05-06

  Stats: 23 lines in 3 files changed: 17 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

From herrick at openjdk.java.net  Fri Apr 30 15:31:59 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 30 Apr 2021 15:31:59 GMT
Subject: RFR: JDK-8266227: Fix help text for --mac-signing-keychain
Message-ID: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com>

JDK-8266227: Fix help text for --mac-signing-keychain

-------------

Commit messages:
 - JDK-8266227: Fix help text for --mac-signing-keychain

Changes: https://git.openjdk.java.net/jdk/pull/3819/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3819&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266227
  Stats: 89 lines in 3 files changed: 27 ins; 5 del; 57 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3819.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3819/head:pull/3819

PR: https://git.openjdk.java.net/jdk/pull/3819

From psandoz at openjdk.java.net  Fri Apr 30 15:48:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 15:48:03 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v2]
In-Reply-To: <YcxnCbTjMJi0n5ftQm1iYxc2JDTezQvoHkaWd0olAU8=.f3ffc87a-06ea-40b3-9956-14ff566159d8@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <YcxnCbTjMJi0n5ftQm1iYxc2JDTezQvoHkaWd0olAU8=.f3ffc87a-06ea-40b3-9956-14ff566159d8@github.com>
Message-ID: <HBXgFsgLdv7Sxkr2rVZxvrINOPs1W3evCYYTIeANxE4=.e30ef1cb-443b-4da6-a04b-95b48ebf213b@github.com>

On Fri, 30 Apr 2021 12:59:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server)
>> 
>> ``
>> Benchmark | (TESTSIZE) | Baseline (ops/min) | Withopt (ops/min) | Gain %
>> -- | -- | -- | -- | --
>> RotateBenchmark.testRotateLeftI | 64 | 6813.033 | 6936.507 | 1.81
>> RotateBenchmark.testRotateLeftI | 64 | 11549.524 | 12109.845 | 4.85
>> RotateBenchmark.testRotateLeftI | 64 | 17780.166 | 18180.083 | 2.25
>> RotateBenchmark.testRotateLeftI | 128 | 3355.631 | 3426.436 | 2.11
>> RotateBenchmark.testRotateLeftI | 128 | 5925.534 | 6096.71 | 2.89
>> RotateBenchmark.testRotateLeftI | 128 | 8847.645 | 8964.224 | 1.32
>> RotateBenchmark.testRotateLeftI | 256 | 1704.192 | 1779.964 | 4.45
>> RotateBenchmark.testRotateLeftI | 256 | 2919.158 | 3000.392 | 2.78
>> RotateBenchmark.testRotateLeftI | 256 | 4386.134 | 4514.211 | 2.92
>> RotateBenchmark.testRotateLeftL | 64 | 3419.193 | 3500.522 | 2.38
>> RotateBenchmark.testRotateLeftL | 64 | 5982.87 | 6056.589 | 1.23
>> RotateBenchmark.testRotateLeftL | 64 | 8829.172 | 8949.157 | 1.36
>> RotateBenchmark.testRotateLeftL | 128 | 1684.745 | 1784.49 | 5.92
>> RotateBenchmark.testRotateLeftL | 128 | 2942.226 | 2947.684 | 0.19
>> RotateBenchmark.testRotateLeftL | 128 | 4385.488 | 4554.113 | 3.85
>> RotateBenchmark.testRotateLeftL | 256 | 834.195 | 856.939 | 2.73
>> RotateBenchmark.testRotateLeftL | 256 | 1463.802 | 1551.051 | 5.96
>> RotateBenchmark.testRotateLeftL | 256 | 2187.005 | 2268.596 | 3.73
>> RotateBenchmark.testRotateRightI | 64 | 6676.132 | 7077.587 | 6.01
>> RotateBenchmark.testRotateRightI | 64 | 11452.825 | 11855.45 | 3.52
>> RotateBenchmark.testRotateRightI | 64 | 17507.286 | 18164.757 | 3.76
>> RotateBenchmark.testRotateRightI | 128 | 3412.394 | 3519.829 | 3.15
>> RotateBenchmark.testRotateRightI | 128 | 5905.677 | 5875.698 | -0.51
>> RotateBenchmark.testRotateRightI | 128 | 8745.95 | 8890.757 | 1.66
>> RotateBenchmark.testRotateRightI | 256 | 1681.176 | 1708.54 | 1.63
>> RotateBenchmark.testRotateRightI | 256 | 3004.008 | 3005.606 | 0.05
>> RotateBenchmark.testRotateRightI | 256 | 4466.633 | 4548.232 | 1.83
>> RotateBenchmark.testRotateRightL | 64 | 3361.499 | 3461.121 | 2.96
>> RotateBenchmark.testRotateRightL | 64 | 5873.37 | 6072.209 | 3.39
>> RotateBenchmark.testRotateRightL | 64 | 8820.284 | 9016.172 | 2.22
>> RotateBenchmark.testRotateRightL | 128 | 1715.556 | 1720.67 | 0.30
>> RotateBenchmark.testRotateRightL | 128 | 2957.337 | 3149.193 | 6.49
>> RotateBenchmark.testRotateRightL | 128 | 4440.468 | 4473.221 | 0.74
>> RotateBenchmark.testRotateRightL | 256 | 851.391 | 875.371 | 2.82
>> RotateBenchmark.testRotateRightL | 256 | 1452.422 | 1522.942 | 4.86
>> RotateBenchmark.testRotateRightL | 256 | 2208.454 | 2263.349 | 2.49
>> 
>>  ``
>
> Jatin Bhateja 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:
> 
>  - 8266054: Review comments resolution.
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - 8266054: Changing gen-src.sh file permissions
>  - 8266054: VectorAPI rotate operation optimization

src/hotspot/cpu/x86/x86.ad line 1652:

> 1650:     case Op_RotateRightV:
> 1651:     case Op_RotateLeftV:
> 1652:       if (is_subword_type(bt)) {

Does that have the effect of not intrinsifying for `byte` or `short`?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 728:

> 726:                 case VECTOR_OP_URSHIFT: return (v0, v1) ->
> 727:                         v0.bOp(v1, (i, a, n) -> ($type$)((a & LSHR_SETUP_MASK) >>> n));
> 728: #if[long]

I recommend you create new methods in `IntVector` etc called `rotateLeft` and `rotateRight` that do what is in the lambda expressions. Then you can collapse this to non-conditional cases calling those methods.

Do the same for the tests (like i did with the unsigned support), see

https://github.com/openjdk/jdk/blob/a31777959abc7cac1bf6d2a453d6fc15b628d866/test/jdk/jdk/incubator/vector/templates/Unit-header.template#L1429

and

https://github.com/openjdk/jdk/blob/a31777959abc7cac1bf6d2a453d6fc15b628d866/test/jdk/jdk/incubator/vector/gen-template.sh#L491

That will avoid the embedding of complex expressions.

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 37:

> 35: 
> 36:   @Param({"64","128","256"})
> 37:   public int TESTSIZE;

Suggestion:

  int size;

Lower case for instance field names (same applies to the species).
No need for `public`.

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 55:

> 53: 
> 54:   public final long[] specialValsL = {0L, -0L, Long.MIN_VALUE, Long.MAX_VALUE};
> 55:   public final int[] specialValsI = {0, -0, Integer.MIN_VALUE, Integer.MAX_VALUE};

Suggestion:

  static final long[] specialValsL = {0L, -0L, Long.MIN_VALUE, Long.MAX_VALUE};
  static final int[] specialValsI = {0, -0, Integer.MIN_VALUE, Integer.MAX_VALUE};

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 83:

> 81:   @Benchmark
> 82:   public void testRotateLeftI(Blackhole bh) {
> 83:     for(int i = 0 ; i < 10000; i++) {

No need for the outer loop. JMH will do that for you.

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 85:

> 83:     for(int i = 0 ; i < 10000; i++) {
> 84:       for (int j = 0 ; j < TESTSIZE; j+= ISPECIES.length()) {
> 85:         vecI = IntVector.fromArray(ISPECIES, inpI, j);

Suggestion:

        var vecI = IntVector.fromArray(ISPECIES, inpI, j);

Use a local variable instead of storing to a field

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 91:

> 89:         vecI = vecI.lanewise(VectorOperators.ROL, i);
> 90:         vecI.lanewise(VectorOperators.ROL, i).intoArray(resI, j);
> 91:       }

Suggestion:

      }
      return resI;

return the result to better ensure HotSpot does not detect the result is unused.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From itakiguchi at openjdk.java.net  Fri Apr 30 16:11:30 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 30 Apr 2021 16:11:30 GMT
Subject: RFR: 8266013: Unexpected replacement character handling on
 stateful CharsetEncoder [v2]
In-Reply-To: <SoeZ13f8UIKlpsttywQzetNsNB6YjXdKNWOzPsnxDNA=.36e520b1-97a6-40aa-9f93-69265f54d553@github.com>
References: <SoeZ13f8UIKlpsttywQzetNsNB6YjXdKNWOzPsnxDNA=.36e520b1-97a6-40aa-9f93-69265f54d553@github.com>
Message-ID: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>

> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data.
> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset.
> EBCDIC Mix charset encoder is stateful encoder.
> Shift code should be added by switching character set.
> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F"
> SI is not in right place.
> 
> Also ISO2022 related charsets use escape sequence to switch character set.
> But same kind of issue is there.

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8266013: Unexpected replacement character handling on stateful CharsetEncoder

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3719/files
  - new: https://git.openjdk.java.net/jdk/pull/3719/files/d6a0a41b..33107e67

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3719&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3719&range=00-01

  Stats: 59 lines in 2 files changed: 40 ins; 5 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3719.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3719/head:pull/3719

PR: https://git.openjdk.java.net/jdk/pull/3719

From sviswanathan at openjdk.java.net  Fri Apr 30 17:12:54 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 17:12:54 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
 <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
Message-ID: <OKiLq6ekHxo2uDtmrQSMo2lZshGkqZW3KpjH7xcoC8U=.0b1d9a95-44cb-44e5-99a7-3c306e936ac2@github.com>

On Fri, 30 Apr 2021 02:31:07 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments: blendmask etc
>
> Marked as reviewed by psandoz (Reviewer).

@PaulSandoz would it be possible for you to run this through your testing?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From mchung at openjdk.java.net  Fri Apr 30 17:23:01 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 30 Apr 2021 17:23:01 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: <z1iEfHGxloZm2O2AhKPq9y_zYwEGymaWSUDOzefVNE4=.a1e23412-73fa-4691-be18-4ae0c02e4a60@github.com>
References: <X3kNLGKzk_kkj5IK6aQiVAMCA0yAew-bI_XLozUHHhE=.5336822b-3090-4a59-b5b4-335fdaa89fb8@github.com>
 <IC_9iI4vEDD79C1a_QEbFbZEa-Mbsq9WUCuCv7TLpOA=.b3e4389d-99ab-45a1-897a-b8df244b192a@github.com>
 <DYfsJCgqoOnKk29iHG5ltNoD64S5ZEvgYKYH5TzFGL0=.5ac80b3f-6080-4275-bf48-db7751f649b7@github.com>
 <DqCFjiDHnq8UNre4Ux54AxHKFNcD4hfXW8_Yzcegyu8=.ec8272ca-15eb-4c7f-a0a9-d5f92c362dac@github.com>
 <cdoCk0mIpSe5RAoNy0cW_KdmcGlSc0VvaQhekiohWrQ=.16c012f3-0b78-4a39-9686-e322451e3ba2@github.com>
 <L6SrFTB58RAe-IgK0yqhJB_FXTM-dBLe5a1xfrtTqwQ=.8455897b-3dfd-4f6a-929c-8b80f834e892@github.com>
 <U05VgHVCM-mzgyvhcErkcFxVtzS24vAqCj-Y73tbgsU=.947cfa12-4f39-460c-9140-8bb82b4272cc@github.com>
 <UvyGpWdRxJDT1_J_okYNIP1JUQeGiar76pGQtxP4gNI=.bd657c24-2226-49c2-a3a7-1562bcffe93d@github.com>
 <z1iEfHGxloZm2O2AhKPq9y_zYwEGymaWSUDOzefVNE4=.a1e23412-73fa-4691-be18-4ae0c02e4a60@github.com>
Message-ID: <IajdP0aQ86wEmS6mETtAFsASUUyu_RfNwxoHcqf84SQ=.b34fb36b-2388-4e79-a114-d89b9587db88@github.com>

On Fri, 30 Apr 2021 12:24:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).

Thanks.
 
> Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?

I create JDK-8266383 and I will look into that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699

From psandoz at openjdk.java.net  Fri Apr 30 17:33:52 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 17:33:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
Message-ID: <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>

On Fri, 30 Apr 2021 02:19:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better check1-4

It was my hope this would eventually happen when we added `Objects.checkIndex` and the underlying intrinsic. Very good!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From vromero at openjdk.java.net  Fri Apr 30 17:40:47 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 30 Apr 2021 17:40:47 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v5]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <jaaZysmhTCB_6_r-W7njinAlomxlcFIuOD5akEaxPZo=.bc25be8a-6c4a-420f-84b9-6d5efc0e3097@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

Vicente Romero 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 ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - updating comment after review feedback
 - removing javax.lang.model changes
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - fixing failing regression tests
 - JVM related changes
 - 8260517: Compiler implementation for Sealed Classes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/43e9cb5f..2744f615

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=03-04

  Stats: 506473 lines in 3844 files changed: 20558 ins; 483521 del; 2394 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526

PR: https://git.openjdk.java.net/jdk/pull/3526

From psandoz at openjdk.java.net  Fri Apr 30 17:47:57 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 17:47:57 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
 <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
Message-ID: <-VJVRq98DoOIRYPdSB8b2k1oOAI2vHeyKgo00bvGbSE=.00ef20ca-d072-4426-9e8e-c0e5433d3440@github.com>

On Fri, 30 Apr 2021 02:31:07 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments: blendmask etc
>
> Marked as reviewed by psandoz (Reviewer).

> @PaulSandoz would it be possible for you to run this through your testing?

Started, will report back when done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From asemenyuk at openjdk.java.net  Fri Apr 30 18:01:51 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 30 Apr 2021 18:01:51 GMT
Subject: RFR: 8266179: [macos] jpackage should specify architecture for
 produced pkg files
In-Reply-To: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com>
References: <_gh_MxhomqtrPwIlUnVhPyIzhvwAtucLkkAhnrM_ItE=.96f31a3e-43d4-4ce3-8ed1-8e2d1c1949d0@github.com>
Message-ID: <_5QdDmqflydgJqGWl0_Wq9lKqS_Jo3cLb69f0oX32Ps=.6f3868de-6151-4336-b11b-1e29746dc8b5@github.com>

On Fri, 30 Apr 2021 04:22:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> jpackage should specify architecture for produced PKG files via hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable on x64 without specifying hostArchitectures which is not correct and if install on arm Mac it will request Rosetta 2. With proposed fix by setting hostArchitectures="x86_x64" if installer contains x64 binaries, it will be installable on x64 Mac and will require Rosetta 2 on arm Mac. hostArchitectures will be set to arm64 if installer contain aarch64 binaries and will gave error when run on x64 Mac and will be installable on arm Mac without triggering installation of Rosetta 2.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3807

From stuart.marks at oracle.com  Fri Apr 30 18:15:47 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 30 Apr 2021 11:15:47 -0700
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
In-Reply-To: <d14e2c71-0236-d8bc-9917-6198584f7956@gmail.com>
References: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
 <e71bbf02-9080-1afa-42af-2094e751688f@oracle.com>
 <371602c3-69b4-1a1f-1e12-1d04914f3463@gmail.com>
 <fab1c198-6f6c-0149-b027-ae5ce9e1cbf6@oracle.com>
 <4aa48a1d-0e80-5531-4938-0cf04ce6396f@gmail.com>
 <CAKjRUT5nC=rQhmdG619uCaowKUN0k1T0RRRosqgYDuK-Nomx9w@mail.gmail.com>
 <d14e2c71-0236-d8bc-9917-6198584f7956@gmail.com>
Message-ID: <c55460f8-3b0d-d9a3-a2f8-93ab20d84ca8@oracle.com>

(Catching up on old email threads.)

I don't have much to add to the technical discussion here. Yes, caching the Integer 
instances seems obsolescent, and it seems unlikely that caching String conversions 
will be helpful. I've gone ahead and closed out the bug. [1]

On triaging bugs... we do triage bugs pretty effectively, I think. However, 
enhancement requests (like this one) tend to languish. People tend to notice ones 
that are obviously bad ideas or obviously good ideas and act on them quickly. 
However, there are a lot of items that are neither obviously good nor bad, so they 
just sit there. Sometimes they just sit there even after there has been some email 
discussion on them. :-)

Sometimes I think we take these requests a bit too seriously. It looks to me like 
the submitter put about five minutes of thought into the request, and we've 
collectively probably spent 10x that dealing with it. I probably put too much effort 
into this bug myself; instead of researching the history, I could have simply closed 
it with a comment saying, "Closed, per discussion in <core-libs-dev link>" which 
would have been reasonable.

Anyway, it's closed.

s'marks


[1] https://bugs.openjdk.java.net/browse/JDK-8252827


On 4/17/21 5:19 AM, Raffaello Giulietti wrote:
> Hi,
> 
> in view of Integer becoming a primitive class [1], the IntegerCache is probably 
> going to disappear.
> 
> For a small, fixed range like the one you are proposing [-1, 16], there's no real 
> need for a separate cache class. You could have a switch in the implementation of 
> toString(), with the string literals then being part of the constant pool of the 
> class. Not free beer, but supported by the VM since day 0.
> 
> It's only when the range is open that you'd need a cache similar to IntegerCache.
> 
> 
> My 2 cents as well :-)
> Raffaello
> 
> ----
> 
> [1] https://openjdk.java.net/jeps/402
> 
> On 2021-04-17 11:18, Laurent Bourg?s wrote:
>> Hi,
>>
>> I read the JBS bug and I interpret it as:
>> - IntegerCache provides Integer instances for [-128, 127] by default
>> - Having Integer.toString(int) could behave the same or at least cache most 
>> probable values like [-1 to 16] or using the IntegerCache range.
>>
>> It looks trivial and potentially could benefits to jdk itself to reduce memory 
>> garbage : is Integer.toString(int) widely used in the jdk codebase ?
>>
>> Finally it can be alternatively implemented in application's code.
>>
>> My 2 cents,
>> Laurent
>>
>> Le sam. 17 avr. 2021 ? 11:06, Raffaello Giulietti <raffaello.giulietti at gmail.com 
>> <mailto:raffaello.giulietti at gmail.com>> a ?crit?:
>>
>>
>>
>> ??? On 2021-04-17 07:07, David Holmes wrote:
>> ???? > On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
>> ???? >> I guess the reporter meant to limit the cache range similarly to
>> ??? the
>> ???? >> one used for valueOf().
>> ???? >>
>> ???? >> I have no clue about the benefit/cost ratio for the proposed String
>> ???? >> cache. It really depends on usage, workload, etc. One can easily
>> ???? >> imagine both extreme scenarios but it's hard to tell how the
>> ??? average
>> ???? >> one would look.
>> ???? >>
>> ???? >> My post is only about either solving the issue by implementing the
>> ???? >> cache, which I can contribute to; or closing it because of lack of
>> ???? >> real-world need or interest.
>> ???? >
>> ???? > Caching for the sake of caching is not an objective in itself.
>> ??? Unless
>> ???? > the caching can be shown to solve a real problem, and the
>> ??? strategy for
>> ???? > managing the cache is well-defined, then I would just close the
>> ???? > enhancement request. (Historically whether an issue we don't have
>> ??? any
>> ???? > firm plans to address is just left open "forever" or closed, depends
>> ???? > very much on who does the bug triaging in that area. :) )
>> ???? >
>> ???? > Cheers,
>> ???? > David
>> ???? >
>>
>>
>> ??? Indeed, the impression is that many of the issues are probably open
>> ??? because it's unclear whether they should be addressed with some
>> ??? implementation or spec effort or whether they should be closed.
>> ??? Triaging
>> ??? is certainly a harder job than it appears at first sight ;-)
>>
>> ??? It would be useful to have a kind of "suspended" or "limbo" resolution
>> ??? state on the JBS for issues like this one, so people searching for more
>> ??? compelling open ones would not encounter them.
>>
>> ??? Personally, I would close this issue without a "fix"; or "suspend" it.
>>
>>
>> ??? Greetings
>> ??? Raffaello
>>
>>
>>
>> ???? >>
>> ???? >> Greetings
>> ???? >> Raffaello
>> ???? >>
>> ???? >>
>> ???? >> On 2021-04-16 20:36, Roger Riggs wrote:
>> ???? >>> Hi,
>> ???? >>>
>> ???? >>> Is there any way to quantify the savings?
>> ???? >>> And what technique can be applied to limit the size of the cache.
>> ???? >>> The size of the small integer cache is somewhat arbitrary.
>> ???? >>>
>> ???? >>> Regards, Roger
>> ???? >>>
>> ???? >>> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
>> ???? >>>> Hello,
>> ???? >>>>
>> ???? >>>> does the enhancement proposed in [1] make sense, both today
>> ??? and when
>> ???? >>>> wrappers will be migrated to primitive classes?
>> ???? >>>> If so, it should be rather simple to add it and I could
>> ??? prepare a PR.
>> ???? >>>> If not, the issue might perhaps be closed.
>> ???? >>>>
>> ???? >>>>
>> ???? >>>> Greetings
>> ???? >>>> Raffaello
>> ???? >>>>
>> ???? >>>> ----
>> ???? >>>>
>> ???? >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252827
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8252827>
>> ???? >>>
>>

From stuart.marks at oracle.com  Fri Apr 30 18:49:48 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 30 Apr 2021 11:49:48 -0700
Subject: Collection::getAny discussion
In-Reply-To: <CADZL2=ty7C7A_L0jVsZGmNou+SqeYoyiBquBAe9jm22ZUoCYCw@mail.gmail.com>
References: <38af-60883900-4c5-3a732100@161619996>
 <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>
 <CADZL2=ty7C7A_L0jVsZGmNou+SqeYoyiBquBAe9jm22ZUoCYCw@mail.gmail.com>
Message-ID: <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com>

Hi Henri,

I've changed the subject of this thread because I think it's out of scope of the 
ReversibleCollection proposal. I don't mean to say that we can't talk about it, but 
I would like it to be decoupled from ReversibleCollection. I'm somewhat arbitrarily 
calling it "Collection::getAny" because something similar to that was mentioned by 
both Remi and Peter elsewhere in this thread. There is also a bunch of history in 
the bug database that contains related ideas.

Before we dive in, I want to explain why this is separate from ReversibleCollection. 
Most of the ideas, including yours, involve an implementation that does something 
like `iterator().next()`, in other words, getting the "first" element from an 
Iterator. Hey, there's getFirst() in ReversibleCollection, let's use that! No. The 
"first" element of an iterator is in general an arbitrary element, which is 
different from the "first" element in the structural ordering of elements provided 
by a ReversibleCollection. The "arbitrary" notion is captured by "getAny" so that's 
what I'll use as a working term. (Of course any actual API we might add would have a 
better name if we can find one.)

For a historical perspective, let's dig into the bug database and take a look at 
this bug:

https://bugs.openjdk.java.net/browse/JDK-4939317

This requests a method Collection.get(Object). This searches the collection for an 
element that equals() the argument and returns the element, or it returns null if 
the element isn't found. (Recall in those days it was impossible to add a method to 
an interface without breaking compatibility, so it also proposes various workarounds 
that are no longer necessary.)

There's a comment from Josh Bloch saying that Collection should have had a get() 
method as well as a no-arg remove() method. Well ok then! And he points to the 
then-new Queue interface that was delivered in Java SE 5. Queue adds the following 
methods that seem relevant to this discussion:

  * E element() -- gets the head element, throws NSEE if empty
  * E remove() -- removes and returns the head element, throws NSEE if empty

(It also adds peek() and poll(), which are similar to the above except they return 
null if empty.)

This is kind of odd, in that none of these methods satisfy what the bug's submitter 
was requesting, which is a one-arg get() method. Also, these methods are on Queue, 
which doesn't really help with collections in general.

You're asking for something that's somewhat different, which you called the "find 
the first element when there is only one" problem. Here, there's a precondition that 
the collection have a single element. (It's not clear to me what should happen if 
the collection has zero or more than one element.)

To throw a couple more variations into the mix, Guava has a couple Collectors (for 
streams) that do interesting things. The class is MoreCollectors:

https://guava.dev/releases/30.1.1-jre/api/docs/com/google/common/collect/MoreCollectors.html

and the collectors are:

  * onlyElement -- if source has 1 element, returns it; throws NSEE if empty, IAE if > 1
  * toOptional -- if source has 0 or 1 elements, returns an Optional; otherwise throws

These apply to streams, but I think you can see the applicability to Collection as 
well. In particular, your proposal is similar to what onlyElement would look like if 
it were on Collection.

Let's summarize the variations so far:

  * preconditions: exactly one element, at-most-one, at-least-one
  * behavior if preconditions not met: return null, return empty Optional, throw
    exception
  * remove element or just peek
  * match a particular element, or return an arbitrary element

That's a lot of variations!

Before we talk about specific APIs, though, I wanted to talk about use cases. Which 
of these variations are more useful or less useful? Which are likely to appear in 
code? Henri gave a fairly specific example with a reasonable "success" case 
(preconditions met) but it's not clear what should happen if the preconditions 
aren't met. Clearly an API would have to choose. What would the use site look like? 
In particular, does the use site always have to check for null, or catch an 
exception, or something?

Answers to these questions will help determine what APIs, if any, we might want to add.

***

There's another thing looming in the distance, which is pattern matching. You might 
have seen one of Brian Goetz's talks on pattern matching futures. You can get a 
glimpse of some upcoming pattern matching features in JEP 405.

 ??? http://openjdk.java.net/jeps/405

In particular, this JEP extends pattern matching with an /extraction/ step, where, 
if there is a match, record or array components can be extracted and bound to local 
variables. This is a step closer to /deconstruction patterns/, where arbitrary 
classes and interfaces (not just records or arrays) can participate in pattern 
matching. (See discussion of this at the end of the JEP.)

Deconstruction patterns apply directly to this discussion. For example, Henri's 
example could be rewritten like this, using pattern matching:

 ??? Set<String> s = ... ;
 ??? if (s instanceof Set.containing(String string)) {
 ??????? // use string, which is the only element
 ??? } else {
 ??????? // handle failure
 ??? }

This "containing" thing would be a deconstruction pattern declared on Set or 
Collection (or possibly elsewhere), and as I've written here, it implicitly matches 
sets that contain exactly one element. Taking a nod from JEP 405's varargs-style 
pattern, extracting an arbitrary element from a set that contains one or more 
elements might look like this:

 ??? Set<String> s = ... ;
 ??? if (s instanceof Set.containing(String string, ...)) { // varargs style
 ??????? // use string, which is an arbitrary element
 ??? } else {
 ??????? // handle failure
 ??? }

This deconstruction pattern addresses a bunch of the design decisions all at once. 
It handles one or at-least-one element. The preconditions-not-met case is handled by 
matching failure. Matching failure also sidesteps the issue of whether we return 
null, return an Optional, or throw an exception. Since pattern matching is 
inherently conditional, you can't forget to check for null or catch an exception 
(and you won't have to deal with that darned Optional API). The only thing this 
doesn't handle is removing an element. I don't think we want pattern matching to 
have side effects, and element removal is probably pretty rare. But we can still 
discuss whether it's a valuable case to support.

In summary, I think it's important and useful to have a conversation about use 
cases, what problems we are trying to achieve, and what we think the code at the 
call site should look like. That can be used to drive API discussions, such as 
adding new methods. It can /also/ be used to drive discussion about deconstruction 
patterns that would be useful to add to collections. Furthermore, since the pattern 
matching language feature is being designed right now, this discussion can help by 
providing information of the form "libraries need to be able to do this kind of 
pattern matching".

Thanks.

s'marks



On 4/28/21 6:23 AM, Henri Tremblay wrote:
> Hi,
>
> (I think the?first version of?this message never went through, so here it goes 
> just in case)
>
> I just read quickly the proposal and it made me think about another common issue. 
> I wonder if we could tackle it as well.
> I will call it the "find the first element when there is only one" problem.
> It happens on unordered collections like a HashSet. It forces to do
>
> Set<String> s = new HashSet<>();
> if (s.size() == 1) {
> ? ?return s.iterator().next();
> ? ?// or
> ? ?return s.stream().findFirst().get();
> }
>
> Which is a lot of ugliness and object instantiations just to get the first element.
> I would be nice to have a public T findFirst() directly on Iterable<T>. With a 
> default implementation returning iterator().next(). Things like ArrayList will 
> want to override will return elementData[0]. It would return null when the list is 
> empty. Or NoSuchElementException.
> It needs to be polished of course but will that be acceptable?
>
> Thanks,
> Henri

From iveresov at openjdk.java.net  Fri Apr 30 19:23:52 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 30 Apr 2021 19:23:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
Message-ID: <Uf0aONZoxL2AE5JwWz23tigdbIG4wWcicoT4TGMCabc=.9b789615-35ed-4434-8e03-5b2bbb90291c@github.com>

On Fri, 30 Apr 2021 02:19:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better check1-4

Looks like now the test fails in the pre-submit tests?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From stuart.marks at oracle.com  Fri Apr 30 19:25:39 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 30 Apr 2021 12:25:39 -0700
Subject: [External] : Re: ReversibleCollection proposal
In-Reply-To: <056b8d18-3ccf-3dac-d64f-07bd2c586752@gmail.com>
References: <38af-60883900-4c5-3a732100@161619996>
 <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>
 <056b8d18-3ccf-3dac-d64f-07bd2c586752@gmail.com>
Message-ID: <0f89b6f8-31e4-bb25-56f2-0a8bbcb6f2ac@oracle.com>

OK, I think we can wrap up this portion of the thread.

As the proposal stands, it has add{First,Last} returning void instead of some useful 
value. For SortedSet and for LinkedHashMap's views, these throw UOE. Can we do better?

Collection has add(), Deque has add{First,Last} and offer{First,Last}, and 
BlockingDeque has put{First,Last}. I'm loathe to add new insertion methods that 
differ from these, either in signatures or semantics.

The BlockingDeque putX methods have blocking behavior, which only makes sense for a 
concurrent collection. Still, because these exist, we mustn't add putX methods 
elsewhere that have different semantics.

After having thought about this for a couple days, I think it's a really bad idea to 
reuse offerX methods. These would allow a collection to refuse the addition of an 
element and merely return a boolean indicating that. I can easily see people writing 
offerX code that doesn't check the return value, and if things shift around in their 
program, elements can be silently dropped. This would set a new precedent, as the 
present behavior is that collections can reject adding an element only by throwing 
an exception. Allowing refusal by returning 'false' would be a bad precedent.

So I think we're stuck with void-returning add{First,Last} methods.

Regarding throwing UOE, I think it's useful to distinguish between the LinkedHashMap 
views and SortedSet. Today, it's already the case that Map's view collections don't 
support addition, so the ReversibleX views of LinkedHashMap are similar in this regard.

SortedSet is different, as it's a top-level collection interface instead of a view 
collection. It's unusual for it not to support the addX operations. We explored some 
alternatives, such as throwing exceptions if preconditions aren't met. These seem 
fairly rare, and the alternative behaviors don't seem all that useful. In any case 
nothing emerged that was clearly better than simple UOE-throwing behavior.

OK, I think it's been useful to analyze various alternatives -- in particular I 
hadn't seriously considered the offerX methods -- but I'll leave the proposal as it 
stands regarding add{First,Last} methods.

s'marks



On 4/28/21 6:54 AM, Peter Levart wrote:
> 
> On 4/28/21 7:19 AM, Stuart Marks wrote:
>>
>>
>> On 4/27/21 9:17 AM, Anthony Vanelverdinghe wrote:
>>> On Tuesday, April 27, 2021 11:25 CEST, Peter Levart <peter.levart at gmail.com> wrote:
>>>> Now just some of my thoughts about the proposal:
>>>>
>>>> - SortedSet.addFirst/.addLast - I think an operation that would be used
>>>> in situations like: "I know this element should always be greater than
>>>> any existing element in the set and I will push it to the end which
>>>> should also verify my assumption" is a perfectly valid operation. So
>>>> those methods throwing IllegalStateException in case the invariant can't
>>>> be kept seem perfectly fine to me.
>>>
>>> This was raised before and addressed by Stuart in [0]:
>>> "An alternative as you suggest might be that SortedSet::addFirst/addLast could throw
>>> something like IllegalStateException if the element is wrongly positioned.
>>> (Deque::addFirst/addLast will throw ISE if the addition would exceed a capacity
>>> restriction.) This seems error-prone, though, and it's easier to understand and
>>> specify that these methods simply throw UOE unconditionally. If there's a good use
>>> case for the alternative I'd be interested in hearing it though."
>>
>> Yes, to be clear, it was Stephen Coleborne who raised this previously [1] and it's 
>> my response that's quoted above.
>>
>> Some further thoughts on this.
>>
>> This is an example where, depending on the current state of the collection, the 
>> method might throw or it might succeed. This is useful in concurrent collections 
>> (such as the capacity-restricted Deque above), where the caller cannot check 
>> preconditions beforehand, because they might be out of date by the time the 
>> operation is attempted. In such cases the caller might not want to block, but 
>> instead it might catch the exception and report an error to its caller (or drop 
>> the request). Thus, calling the exception-throwing method is appropriate.
>>
>> Something like SortedSet::addLast seems different, though. The state is the 
>> *values* of the elements already in the collection. This is something that can 
>> easily be checked, and probably should be checked beforehand:
>>
>> ??? if (sortedSet.isEmpty() || sortedSet.last().compareTo(e) <= 0)
>> ??????? sortedSet.add(e);
>> ??? else
>> ??????? // e wouldn't be the last element, do something different
> 
> 
> I was thinking more of a case where the else branch would actually throw 
> IllegalStateException and do nothing else - a kind of add with precondition check. A 
> precondition in the sense of Objects.requireNonNull(). I can't currently think of a 
> real usecase now, so this kind of operation is probably very rare. Probably not 
> useful since if you're adding to SortedSet, the order of elements added should not 
> matter because SortedSet will sort them. If you just want to check the order of 
> elements added and you are not willing to pay the price of SortedSet, you will be 
> adding them to a List or LinkedHashSet, but then the method would not do the check...
> 
> 
>>
>> Now this is a fair bit of code, and it would be shorter just to call 
>> sortedSet.addLast(e). But does that actually help? What if e is already in the set 
>> and is the last element?
> 
> 
> In that case the operation would be a no-op (or it would replace the element with 
> the parameter - a slight difference as the element can be .equals() but not the same 
> instance).
> 
> 
>> Is catching an exception really what we want to do if e wouldn't be the last 
>> element? Maybe we'd want to do nothing instead. If so, catching an exception in 
>> order to do nothing is extra work.
> 
> 
> I was only thinking of situations where propagating the exception would be the 
> desired thing.
> 
> 
>>
>> Again, I'd like to hear about use cases for a conditionally-throwing version of 
>> addLast et. al. I don't want to be limited by failure of imagination, but it does 
>> seem like this kind of behavior would be useful only in a narrow set of cases 
>> where it happens to do exactly the right thing. Otherwise, it just gets in the 
>> way, and its behavior is pretty obscure. So, color me skeptical.
> 
> 
> Right, I don't know how common such operation would be. Probably not very.
> 
> 
> Peter
> 
> which are a continual source of errors.)
> 
>>
>> I'll think about this more, but it doesn't seem promising.
>>
>> s'marks

From igraves at openjdk.java.net  Fri Apr 30 19:55:51 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 30 Apr 2021 19:55:51 GMT
Subject: Integrated: 8260560: convert jdeps and jdeprscan tools to use
 Stream.toList()
In-Reply-To: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
References: <z_XGdMKf9c-N-WOR6ioj7vGVB0PNJ2OOguAbCQWHddw=.273bf899-921d-4e4e-9487-bc401f5f8a2b@github.com>
Message-ID: <QDr5ps3NXUb4Oa6Q3nQWfA3YPhHHs9U7sD-ugDn7_sU=.a1473d32-6b3e-4c5b-8992-4b5689ee6c97@github.com>

On Tue, 27 Apr 2021 00:20:49 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8260560: convert jdeps and jdeprscan tools to use Stream.toList()

This pull request has now been integrated.

Changeset: c36c63a0
Author:    Ian Graves <igraves at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c36c63a008fa5e8b00dfc36c887cd9497fb91ab5
Stats:     9 lines in 4 files changed: 0 ins; 0 del; 9 mod

8260560: convert jdeps and jdeprscan tools to use Stream.toList()

Reviewed-by: alanb, mchung, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/3705

From igraves at openjdk.java.net  Fri Apr 30 19:55:53 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 30 Apr 2021 19:55:53 GMT
Subject: Integrated: 8266155: Convert java.base to use Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <mHvLtfWQoKQB8d_mdnzBEVfdDC9E2_aUn4RxaMm_6Fk=.8a104d57-5f16-41be-bf84-e8b0a2628b1c@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

This pull request has now been integrated.

Changeset: dd05158b
Author:    Ian Graves <igraves at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dd05158b24e8b399052a170ea9fe9ee6f65c0432
Stats:     25 lines in 8 files changed: 0 ins; 11 del; 14 mod

8266155: Convert java.base to use Stream.toList()

Reviewed-by: bpb, naoto, iris, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/3734

From donraab at gmail.com  Fri Apr 30 20:02:54 2021
From: donraab at gmail.com (Donald Raab)
Date: Fri, 30 Apr 2021 16:02:54 -0400
Subject: Collection::getAny discussion
In-Reply-To: <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com>
References: <38af-60883900-4c5-3a732100@161619996>
 <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>
 <CADZL2=ty7C7A_L0jVsZGmNou+SqeYoyiBquBAe9jm22ZUoCYCw@mail.gmail.com>
 <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com>
Message-ID: <F5030016-8FCB-4672-8742-4C03232D586A@gmail.com>

There is a default method getAny defined on the RichIterable interface in Eclipse Collections. Adding a getAny with the same signature to Collection is bound to cause a break similar to CharSequence.isEmpty did with JDK 15 but possibly more extensive since RichIterable is the parent interface for all collection types in Eclipse Collections. Adding it with a different signature (returns Optional) could cause extensive damage.

https://www.eclipse.org/collections/javadoc/10.4.0/org/eclipse/collections/api/RichIterable.html#getAny() 

I highly recommend we stop looking to add new zero-argument default methods to 20+ year Collection interfaces and hope that we don?t break anything. There seems to be desire to breathe life into the old Collection interfaces. IMO, we should just start planning and focusing on a Collections 2.0 design.


> On Apr 30, 2021, at 2:49 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi Henri,
> 
> I've changed the subject of this thread because I think it's out of scope of the ReversibleCollection proposal. I don't mean to say that we can't talk about it, but I would like it to be decoupled from ReversibleCollection. I'm somewhat arbitrarily calling it "Collection::getAny" because something similar to that was mentioned by both Remi and Peter elsewhere in this thread. There is also a bunch of history in the bug database that contains related ideas.
> 
> Before we dive in, I want to explain why this is separate from ReversibleCollection. Most of the ideas, including yours, involve an implementation that does something like `iterator().next()`, in other words, getting the "first" element from an Iterator. Hey, there's getFirst() in ReversibleCollection, let's use that! No. The "first" element of an iterator is in general an arbitrary element, which is different from the "first" element in the structural ordering of elements provided by a ReversibleCollection. The "arbitrary" notion is captured by "getAny" so that's what I'll use as a working term. (Of course any actual API we might add would have a better name if we can find one.)
> 
> For a historical perspective, let's dig into the bug database and take a look at this bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-4939317
> 
> This requests a method Collection.get(Object). This searches the collection for an element that equals() the argument and returns the element, or it returns null if the element isn't found. (Recall in those days it was impossible to add a method to an interface without breaking compatibility, so it also proposes various workarounds that are no longer necessary.)
> 
> There's a comment from Josh Bloch saying that Collection should have had a get() method as well as a no-arg remove() method. Well ok then! And he points to the then-new Queue interface that was delivered in Java SE 5. Queue adds the following methods that seem relevant to this discussion:
> 
> * E element() -- gets the head element, throws NSEE if empty
> * E remove() -- removes and returns the head element, throws NSEE if empty
> 
> (It also adds peek() and poll(), which are similar to the above except they return null if empty.)
> 
> This is kind of odd, in that none of these methods satisfy what the bug's submitter was requesting, which is a one-arg get() method. Also, these methods are on Queue, which doesn't really help with collections in general.
> 
> You're asking for something that's somewhat different, which you called the "find the first element when there is only one" problem. Here, there's a precondition that the collection have a single element. (It's not clear to me what should happen if the collection has zero or more than one element.)
> 
> To throw a couple more variations into the mix, Guava has a couple Collectors (for streams) that do interesting things. The class is MoreCollectors:
> 
> https://guava.dev/releases/30.1.1-jre/api/docs/com/google/common/collect/MoreCollectors.html
> 
> and the collectors are:
> 
> * onlyElement -- if source has 1 element, returns it; throws NSEE if empty, IAE if > 1
> * toOptional -- if source has 0 or 1 elements, returns an Optional; otherwise throws
> 
> These apply to streams, but I think you can see the applicability to Collection as well. In particular, your proposal is similar to what onlyElement would look like if it were on Collection.
> 
> Let's summarize the variations so far:
> 
> * preconditions: exactly one element, at-most-one, at-least-one
> * behavior if preconditions not met: return null, return empty Optional, throw
>   exception
> * remove element or just peek
> * match a particular element, or return an arbitrary element
> 
> That's a lot of variations!
> 
> Before we talk about specific APIs, though, I wanted to talk about use cases. Which of these variations are more useful or less useful? Which are likely to appear in code? Henri gave a fairly specific example with a reasonable "success" case (preconditions met) but it's not clear what should happen if the preconditions aren't met. Clearly an API would have to choose. What would the use site look like? In particular, does the use site always have to check for null, or catch an exception, or something?
> 
> Answers to these questions will help determine what APIs, if any, we might want to add.
> 
> ***
> 
> There's another thing looming in the distance, which is pattern matching. You might have seen one of Brian Goetz's talks on pattern matching futures. You can get a glimpse of some upcoming pattern matching features in JEP 405.
> 
>     http://openjdk.java.net/jeps/405
> 
> In particular, this JEP extends pattern matching with an /extraction/ step, where, if there is a match, record or array components can be extracted and bound to local variables. This is a step closer to /deconstruction patterns/, where arbitrary classes and interfaces (not just records or arrays) can participate in pattern matching. (See discussion of this at the end of the JEP.)
> 
> Deconstruction patterns apply directly to this discussion. For example, Henri's example could be rewritten like this, using pattern matching:
> 
>     Set<String> s = ... ;
>     if (s instanceof Set.containing(String string)) {
>         // use string, which is the only element
>     } else {
>         // handle failure
>     }
> 
> This "containing" thing would be a deconstruction pattern declared on Set or Collection (or possibly elsewhere), and as I've written here, it implicitly matches sets that contain exactly one element. Taking a nod from JEP 405's varargs-style pattern, extracting an arbitrary element from a set that contains one or more elements might look like this:
> 
>     Set<String> s = ... ;
>     if (s instanceof Set.containing(String string, ...)) { // varargs style
>         // use string, which is an arbitrary element
>     } else {
>         // handle failure
>     }
> 
> This deconstruction pattern addresses a bunch of the design decisions all at once. It handles one or at-least-one element. The preconditions-not-met case is handled by matching failure. Matching failure also sidesteps the issue of whether we return null, return an Optional, or throw an exception. Since pattern matching is inherently conditional, you can't forget to check for null or catch an exception (and you won't have to deal with that darned Optional API). The only thing this doesn't handle is removing an element. I don't think we want pattern matching to have side effects, and element removal is probably pretty rare. But we can still discuss whether it's a valuable case to support.
> 
> In summary, I think it's important and useful to have a conversation about use cases, what problems we are trying to achieve, and what we think the code at the call site should look like. That can be used to drive API discussions, such as adding new methods. It can /also/ be used to drive discussion about deconstruction patterns that would be useful to add to collections. Furthermore, since the pattern matching language feature is being designed right now, this discussion can help by providing information of the form "libraries need to be able to do this kind of pattern matching".
> 
> Thanks.
> 
> s'marks
> 
> 
> 
> On 4/28/21 6:23 AM, Henri Tremblay wrote:
>> Hi,
>> 
>> (I think the first version of this message never went through, so here it goes just in case)
>> 
>> I just read quickly the proposal and it made me think about another common issue. I wonder if we could tackle it as well.
>> I will call it the "find the first element when there is only one" problem.
>> It happens on unordered collections like a HashSet. It forces to do
>> 
>> Set<String> s = new HashSet<>();
>> if (s.size() == 1) {
>>    return s.iterator().next();
>>    // or
>>    return s.stream().findFirst().get();
>> }
>> 
>> Which is a lot of ugliness and object instantiations just to get the first element.
>> I would be nice to have a public T findFirst() directly on Iterable<T>. With a default implementation returning iterator().next(). Things like ArrayList will want to override will return elementData[0]. It would return null when the list is empty. Or NoSuchElementException.
>> It needs to be polished of course but will that be acceptable?
>> 
>> Thanks,
>> Henri


From brian.goetz at oracle.com  Fri Apr 30 20:14:55 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 30 Apr 2021 16:14:55 -0400
Subject: Collection::getAny discussion
In-Reply-To: <F5030016-8FCB-4672-8742-4C03232D586A@gmail.com>
References: <38af-60883900-4c5-3a732100@161619996>
 <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>
 <CADZL2=ty7C7A_L0jVsZGmNou+SqeYoyiBquBAe9jm22ZUoCYCw@mail.gmail.com>
 <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com>
 <F5030016-8FCB-4672-8742-4C03232D586A@gmail.com>
Message-ID: <534c8276-8afe-f707-160e-58c170cdc4e0@oracle.com>

While I agree that we should be careful, let's not paint ourselves into 
an either/or strawman.? The choice is not "never add anything to 
Collection" vs "let's dump every silly idea that comes to anyone's mind 
into Collection"; it is, as always, going to involve tradeoffs between 
stability and evolution.

We cannot constrain ourselves so hard that we cannot evolve the core 
libraries because it might collide with someone else's subclass.? That's 
not reasonable, nor is that good for Java.

On the other hand, we must continue to exercise care in many dimensions 
when adding to libraries that are widely used and implemented -- which 
we already do (so much so, in fact, that people are often frustrated by 
our seeming conservatism.)







On 4/30/2021 4:02 PM, Donald Raab wrote:
> There is a default method getAny defined on the RichIterable interface in Eclipse Collections. Adding a getAny with the same signature to Collection is bound to cause a break similar to CharSequence.isEmpty did with JDK 15 but possibly more extensive since RichIterable is the parent interface for all collection types in Eclipse Collections. Adding it with a different signature (returns Optional) could cause extensive damage.
>
> https://www.eclipse.org/collections/javadoc/10.4.0/org/eclipse/collections/api/RichIterable.html#getAny()
>
> I highly recommend we stop looking to add new zero-argument default methods to 20+ year Collection interfaces and hope that we don?t break anything. There seems to be desire to breathe life into the old Collection interfaces. IMO, we should just start planning and focusing on a Collections 2.0 design.
>
>
>> On Apr 30, 2021, at 2:49 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>
>> Hi Henri,
>>
>> I've changed the subject of this thread because I think it's out of scope of the ReversibleCollection proposal. I don't mean to say that we can't talk about it, but I would like it to be decoupled from ReversibleCollection. I'm somewhat arbitrarily calling it "Collection::getAny" because something similar to that was mentioned by both Remi and Peter elsewhere in this thread. There is also a bunch of history in the bug database that contains related ideas.
>>
>> Before we dive in, I want to explain why this is separate from ReversibleCollection. Most of the ideas, including yours, involve an implementation that does something like `iterator().next()`, in other words, getting the "first" element from an Iterator. Hey, there's getFirst() in ReversibleCollection, let's use that! No. The "first" element of an iterator is in general an arbitrary element, which is different from the "first" element in the structural ordering of elements provided by a ReversibleCollection. The "arbitrary" notion is captured by "getAny" so that's what I'll use as a working term. (Of course any actual API we might add would have a better name if we can find one.)
>>
>> For a historical perspective, let's dig into the bug database and take a look at this bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-4939317
>>
>> This requests a method Collection.get(Object). This searches the collection for an element that equals() the argument and returns the element, or it returns null if the element isn't found. (Recall in those days it was impossible to add a method to an interface without breaking compatibility, so it also proposes various workarounds that are no longer necessary.)
>>
>> There's a comment from Josh Bloch saying that Collection should have had a get() method as well as a no-arg remove() method. Well ok then! And he points to the then-new Queue interface that was delivered in Java SE 5. Queue adds the following methods that seem relevant to this discussion:
>>
>> * E element() -- gets the head element, throws NSEE if empty
>> * E remove() -- removes and returns the head element, throws NSEE if empty
>>
>> (It also adds peek() and poll(), which are similar to the above except they return null if empty.)
>>
>> This is kind of odd, in that none of these methods satisfy what the bug's submitter was requesting, which is a one-arg get() method. Also, these methods are on Queue, which doesn't really help with collections in general.
>>
>> You're asking for something that's somewhat different, which you called the "find the first element when there is only one" problem. Here, there's a precondition that the collection have a single element. (It's not clear to me what should happen if the collection has zero or more than one element.)
>>
>> To throw a couple more variations into the mix, Guava has a couple Collectors (for streams) that do interesting things. The class is MoreCollectors:
>>
>> https://guava.dev/releases/30.1.1-jre/api/docs/com/google/common/collect/MoreCollectors.html
>>
>> and the collectors are:
>>
>> * onlyElement -- if source has 1 element, returns it; throws NSEE if empty, IAE if > 1
>> * toOptional -- if source has 0 or 1 elements, returns an Optional; otherwise throws
>>
>> These apply to streams, but I think you can see the applicability to Collection as well. In particular, your proposal is similar to what onlyElement would look like if it were on Collection.
>>
>> Let's summarize the variations so far:
>>
>> * preconditions: exactly one element, at-most-one, at-least-one
>> * behavior if preconditions not met: return null, return empty Optional, throw
>>    exception
>> * remove element or just peek
>> * match a particular element, or return an arbitrary element
>>
>> That's a lot of variations!
>>
>> Before we talk about specific APIs, though, I wanted to talk about use cases. Which of these variations are more useful or less useful? Which are likely to appear in code? Henri gave a fairly specific example with a reasonable "success" case (preconditions met) but it's not clear what should happen if the preconditions aren't met. Clearly an API would have to choose. What would the use site look like? In particular, does the use site always have to check for null, or catch an exception, or something?
>>
>> Answers to these questions will help determine what APIs, if any, we might want to add.
>>
>> ***
>>
>> There's another thing looming in the distance, which is pattern matching. You might have seen one of Brian Goetz's talks on pattern matching futures. You can get a glimpse of some upcoming pattern matching features in JEP 405.
>>
>>      http://openjdk.java.net/jeps/405
>>
>> In particular, this JEP extends pattern matching with an /extraction/ step, where, if there is a match, record or array components can be extracted and bound to local variables. This is a step closer to /deconstruction patterns/, where arbitrary classes and interfaces (not just records or arrays) can participate in pattern matching. (See discussion of this at the end of the JEP.)
>>
>> Deconstruction patterns apply directly to this discussion. For example, Henri's example could be rewritten like this, using pattern matching:
>>
>>      Set<String> s = ... ;
>>      if (s instanceof Set.containing(String string)) {
>>          // use string, which is the only element
>>      } else {
>>          // handle failure
>>      }
>>
>> This "containing" thing would be a deconstruction pattern declared on Set or Collection (or possibly elsewhere), and as I've written here, it implicitly matches sets that contain exactly one element. Taking a nod from JEP 405's varargs-style pattern, extracting an arbitrary element from a set that contains one or more elements might look like this:
>>
>>      Set<String> s = ... ;
>>      if (s instanceof Set.containing(String string, ...)) { // varargs style
>>          // use string, which is an arbitrary element
>>      } else {
>>          // handle failure
>>      }
>>
>> This deconstruction pattern addresses a bunch of the design decisions all at once. It handles one or at-least-one element. The preconditions-not-met case is handled by matching failure. Matching failure also sidesteps the issue of whether we return null, return an Optional, or throw an exception. Since pattern matching is inherently conditional, you can't forget to check for null or catch an exception (and you won't have to deal with that darned Optional API). The only thing this doesn't handle is removing an element. I don't think we want pattern matching to have side effects, and element removal is probably pretty rare. But we can still discuss whether it's a valuable case to support.
>>
>> In summary, I think it's important and useful to have a conversation about use cases, what problems we are trying to achieve, and what we think the code at the call site should look like. That can be used to drive API discussions, such as adding new methods. It can /also/ be used to drive discussion about deconstruction patterns that would be useful to add to collections. Furthermore, since the pattern matching language feature is being designed right now, this discussion can help by providing information of the form "libraries need to be able to do this kind of pattern matching".
>>
>> Thanks.
>>
>> s'marks
>>
>>
>>
>> On 4/28/21 6:23 AM, Henri Tremblay wrote:
>>> Hi,
>>>
>>> (I think the first version of this message never went through, so here it goes just in case)
>>>
>>> I just read quickly the proposal and it made me think about another common issue. I wonder if we could tackle it as well.
>>> I will call it the "find the first element when there is only one" problem.
>>> It happens on unordered collections like a HashSet. It forces to do
>>>
>>> Set<String> s = new HashSet<>();
>>> if (s.size() == 1) {
>>>     return s.iterator().next();
>>>     // or
>>>     return s.stream().findFirst().get();
>>> }
>>>
>>> Which is a lot of ugliness and object instantiations just to get the first element.
>>> I would be nice to have a public T findFirst() directly on Iterable<T>. With a default implementation returning iterator().next(). Things like ArrayList will want to override will return elementData[0]. It would return null when the list is empty. Or NoSuchElementException.
>>> It needs to be polished of course but will that be acceptable?
>>>
>>> Thanks,
>>> Henri


From herrick at openjdk.java.net  Fri Apr 30 20:26:26 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 30 Apr 2021 20:26:26 GMT
Subject: RFR: JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java
 hangs with fastdebug
Message-ID: <TbV6qqUBcAZdOZN3fued0En-nAmMhWfuj4SHAOznxDU=.0c90a5ca-38ad-491d-a880-21212bac5ba5@github.com>

JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug

just disabling this test when vm.debug

-------------

Commit messages:
 - JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug

Changes: https://git.openjdk.java.net/jdk/pull/3827/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3827&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266129
  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3827.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3827/head:pull/3827

PR: https://git.openjdk.java.net/jdk/pull/3827

From maurizio.cimadamore at oracle.com  Fri Apr 30 20:36:46 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 30 Apr 2021 21:36:46 +0100
Subject: 8252827: Caching Integer.toString just like Integer.valueOf
In-Reply-To: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
References: <87154920-0638-6163-63fa-6bcd764ca42f@gmail.com>
Message-ID: <1b10f20e-a4ea-bcc4-bf7e-411560e44499@oracle.com>

Ciao Raffaello,
another general consideration: caching sometimes makes certain 
optimizations harder to pull off.

Few years ago I've seen this talk at Fosdem:

https://archive.fosdem.org/2020/schedule/event/reducing_gc_times/

See minute 5:53 - where it shows that cached Integer values (as per 
Integer::valueOf) inhibit scalarization, and using `new Integer(...)` 
leads to superior performances.

It's a pattern I have observed several time when working with the 
Foreign Memory API, where most of the abstractions are immutable: 
attempting to cache things (e.g. MemoryAddress instances) often comes up 
with the same GC overhead (because these instances are escape analyzed 
away) and ends up with worse performance overall (loss of scalarization).

Of course this is not _always_ the case - but I wanted to add this 
particular angle to the discussion.

Cheers
Maurizio

On 16/04/2021 17:48, Raffaello Giulietti wrote:
> Hello,
>
> does the enhancement proposed in [1] make sense, both today and when 
> wrappers will be migrated to primitive classes?
> If so, it should be rather simple to add it and I could prepare a PR.
> If not, the issue might perhaps be closed.
>
>
> Greetings
> Raffaello
>
> ----
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8252827

From asemenyuk at openjdk.java.net  Fri Apr 30 20:43:51 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 30 Apr 2021 20:43:51 GMT
Subject: RFR: JDK-8266129:
 tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug
In-Reply-To: <TbV6qqUBcAZdOZN3fued0En-nAmMhWfuj4SHAOznxDU=.0c90a5ca-38ad-491d-a880-21212bac5ba5@github.com>
References: <TbV6qqUBcAZdOZN3fued0En-nAmMhWfuj4SHAOznxDU=.0c90a5ca-38ad-491d-a880-21212bac5ba5@github.com>
Message-ID: <pYmk-yXffMzls_zEbF2DipvGlnyZeYJ151qRubQC9Qs=.5a9acc6e-d54b-48de-bd19-6cc35c37bfc9@github.com>

On Fri, 30 Apr 2021 20:19:25 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug
> 
> just disabling this test when vm.debug

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3827

From rriggs at openjdk.java.net  Fri Apr 30 21:12:52 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 30 Apr 2021 21:12:52 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name
In-Reply-To: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
Message-ID: <RYTJa9vR1efK43zJfeAH9UveR4hSIXgaGDQCIi3q268=.fbe4c411-20d6-454e-8bf6-e6d91b539550@github.com>

On Wed, 28 Apr 2021 22:24:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

To support the statement that changing the property has no effect.
Please add it to the jdk.internal.util.StaticProperties cached values and an internal access method.

Otherwise looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From scolebourne at joda.org  Fri Apr 30 21:15:45 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 30 Apr 2021 22:15:45 +0100
Subject: Collection::getAny discussion
In-Reply-To: <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com>
References: <38af-60883900-4c5-3a732100@161619996>
 <dfa91cbb-ddd5-80a2-d83a-502e9591245d@oracle.com>
 <CADZL2=ty7C7A_L0jVsZGmNou+SqeYoyiBquBAe9jm22ZUoCYCw@mail.gmail.com>
 <838b3ee1-20ac-2baa-f477-03e92f4697c3@oracle.com>
Message-ID: <CACzrW9BOtbiSfz_68mC3py7v-JAB24ftmWq+9MhdbCZ5CdsPjg@mail.gmail.com>

On Fri, 30 Apr 2021 at 19:50, Stuart Marks <stuart.marks at oracle.com> wrote:
> You're asking for something that's somewhat different, which you called the "find
> the first element when there is only one" problem. Here, there's a precondition that
> the collection have a single element. (It's not clear to me what should happen if
> the collection has zero or more than one element.)

I think any get() or getAny() method on Collection is semantically
equivalent to iterator.next(). I'm not sure there is another viable
option.

>   * onlyElement -- if source has 1 element, returns it; throws NSEE if empty, IAE if > 1
>   * toOptional -- if source has 0 or 1 elements, returns an Optional; otherwise throws

These should be added to the JDK. They are useful.

Stephen

From almatvee at openjdk.java.net  Fri Apr 30 21:51:55 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 30 Apr 2021 21:51:55 GMT
Subject: RFR: JDK-8266227: Fix help text for --mac-signing-keychain
In-Reply-To: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com>
References: <-UNmpEVvS4xw89IjWDR7tIpjoNNBS3c9hq_L1TeTEvw=.5eba417e-10ef-4d06-a54c-88a93d177b17@github.com>
Message-ID: <Fjq8Yy1lPNJCFH8X_9hvy6CfHWLFJapT-yzoXDxXa5Q=.5a27a4f4-7022-480e-9e09-52851f70d94e@github.com>

On Fri, 30 Apr 2021 15:25:13 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8266227: Fix help text for --mac-signing-keychain

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3819

From almatvee at openjdk.java.net  Fri Apr 30 21:52:52 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 30 Apr 2021 21:52:52 GMT
Subject: RFR: JDK-8266129:
 tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug
In-Reply-To: <TbV6qqUBcAZdOZN3fued0En-nAmMhWfuj4SHAOznxDU=.0c90a5ca-38ad-491d-a880-21212bac5ba5@github.com>
References: <TbV6qqUBcAZdOZN3fued0En-nAmMhWfuj4SHAOznxDU=.0c90a5ca-38ad-491d-a880-21212bac5ba5@github.com>
Message-ID: <AKTPhIL-ROEVP2YaIig6XfpcTLUqH03_C4Pm_ea7TNQ=.45b36bc2-5651-4f6b-b08c-71cef158ff2a@github.com>

On Fri, 30 Apr 2021 20:19:25 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug
> 
> just disabling this test when vm.debug

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3827

From naoto at openjdk.java.net  Fri Apr 30 22:01:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Apr 2021 22:01:36 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name [v2]
In-Reply-To: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
Message-ID: <r-iz9E0rbcFT-7UDgsZ6ITmr5eUCZqZsk1ewFapXLPk=.8a684bae-6f74-422f-b7bc-45f3f7e03c06@github.com>

> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added internal getter for native.encoding

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3777/files
  - new: https://git.openjdk.java.net/jdk/pull/3777/files/fa5246c8..e76ff410

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3777&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3777&range=00-01

  Stats: 16 lines in 1 file changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3777.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3777/head:pull/3777

PR: https://git.openjdk.java.net/jdk/pull/3777

From naoto at openjdk.java.net  Fri Apr 30 22:01:37 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Apr 2021 22:01:37 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name [v2]
In-Reply-To: <RYTJa9vR1efK43zJfeAH9UveR4hSIXgaGDQCIi3q268=.fbe4c411-20d6-454e-8bf6-e6d91b539550@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
 <RYTJa9vR1efK43zJfeAH9UveR4hSIXgaGDQCIi3q268=.fbe4c411-20d6-454e-8bf6-e6d91b539550@github.com>
Message-ID: <xJ68odEG_wUraqiR_kpIExRIGDDmfbwwfzyUD_qyLms=.817f0c6b-be42-4568-83ca-c1448eb09b0f@github.com>

On Fri, 30 Apr 2021 21:09:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> To support the statement that changing the property has no effect.
> Please add it to the jdk.internal.util.StaticProperties cached values and an internal access method.

Thanks. Added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3777

From naoto at openjdk.java.net  Fri Apr 30 22:10:21 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Apr 2021 22:10:21 GMT
Subject: RFR: 8265989: System property for the native character encoding
 name [v3]
In-Reply-To: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
References: <sFLX1YMO7rRS-eYVn9ZBCReGoD9v3TVc8HeHrBacSgA=.525a8b47-14db-42d0-abe2-f9490646f3a5@github.com>
Message-ID: <4qrL7j7zaY2RHgH6-d6sZDfwxIa18T0dPWUQ9-RuqMo=.a031b233-9e74-4c82-8c1f-c5eb30fca4ab@github.com>

> After some internal discussion, we thought it was good to expose the native environment's default character encoding, which Charset.defaultCharset() is currently based on. This way applications will have a better migration path after the [JEP 400](https://openjdk.java.net/jeps/400) is implemented, in which Charset.defaultCharset() will return UTF-8, but the value of this new system property will remain intact. A [CSR](https://bugs.openjdk.java.net/browse/JDK-8266075) has been filed with more detailed information.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fixed a typo.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3777/files
  - new: https://git.openjdk.java.net/jdk/pull/3777/files/e76ff410..01b2ffc3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3777&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3777&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3777.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3777/head:pull/3777

PR: https://git.openjdk.java.net/jdk/pull/3777

From stuart.marks at oracle.com  Fri Apr 30 22:42:10 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 30 Apr 2021 15:42:10 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr>
 <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>
 <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr>
Message-ID: <e3d314ea-a7b5-87ef-ec48-3c6714e33cbe@oracle.com>



> You did not really answer to the real question, why should i use ReversibleCollection instead of a Collection as parameter.
> You said that it's a better type because you can not send a HashSet, but as i said, sending a HashSet of 0 or 1 element is perfectly valid.
> For me, we are not far from, it's typechecking for the sake of typechecking.

I thought I did answer it, but it might have been in response to a different message 
on a different part of the thread. But I'll make the case in a more explicit fashion 
here.

First, a couple background points related to this:

  - ReversibleCollection is not intended to, and indeed cannot represent all ordered 
collections. Queue is ordered and is not a ReversibleCollection, and there are 
likely other collections out there that are ordered but that implement Collection 
directly. Also, they might or might not be reversible.

  - I expect that few, if any Java SE APIs will be adjusted to use 
ReversibleCollection as a parameter type. Any APIs that use Collection but require 
an ordered type cannot be changed because of compatibility reasons.

Despite both of these points, I believe ReversibleCollection can be successful, and 
it can be useful in APIs as a parameter type. (The proposal itself uses 
ReversibleCollection and ReversibleSet as method return types.)

Consider the case of a large application or other system, one that's large enough to 
have lots of internal APIs, but that is built as a single unit, so 
release-to-release compatibility isn't an issue. Suppose there is some method

     processItemsInOrder(List<Item> items)

that has to process items in the order in which they occur, because processing of 
later items might depend the processing of earlier ones. The maintainer of this API 
chose to accept a List as a parameter, because it's a common interface and it's 
clearly an ordered collection.

Now consider a client that gets items from different places, keeping them in order, 
but removing duplicates. It might do something like this:

     var items = new LinkedHashSet<Item>();
     items.addAll(getItemsFromSomeplace());
     items.addAll(getItemsFromAnotherPlace());
     items.addAll(getItemsFromSomeplaceElse());
     processItemsInOrder(new ArrayList<>(items));

It turns out the copying of the items into an ArrayList is a performance bottleneck, 
so the maintainer of the client code asks the maintainer of the items processing 
code to change the API to accept Collection instead.

The items processing maintainer demurs, recalling that the API *did* accept 
Collection in the past, and a bug where somebody accidentally passed a HashSet 
resulted in a customer escalation because of item processing irregularities. In the 
aftermath of that escalation, the API was changed to List. The client maintainer 
reluctantly pursues alternatives for generating a deduplicated List.

But wait! Those Java guys added a ReversibleCollection interface in Java N. It has 
the desired property of being ordered, and conveniently it's a supertype of both 
List and LinkedHashSet. The items processing maintainer adjusts the API to consume 
ReversibleCollection, and the client maintainer removes the temporary ArrayList, and 
everybody is happy.

s'marks

From javalists at cbfiddle.com  Fri Apr 30 23:15:27 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 30 Apr 2021 16:15:27 -0700
Subject: ReversibleCollection proposal
In-Reply-To: <e3d314ea-a7b5-87ef-ec48-3c6714e33cbe@oracle.com>
References: <0d617e62-50bd-3390-840a-f60266330555@oracle.com>
 <568795941.1852589.1618678174378.JavaMail.zimbra@u-pem.fr>
 <f4d0c280-bb0c-36c4-4858-c41c2b5a93b3@oracle.com>
 <49170229.917372.1618873532286.JavaMail.zimbra@u-pem.fr>
 <b30251a7-cbfa-68ab-7f22-9a936d452ea8@oracle.com>
 <839698479.422241.1619098212148.JavaMail.zimbra@u-pem.fr>
 <7457433b-0836-f45e-4b51-4c2ecdf7e7da@oracle.com>
 <427897615.2057286.1619612437790.JavaMail.zimbra@u-pem.fr>
 <e3d314ea-a7b5-87ef-ec48-3c6714e33cbe@oracle.com>
Message-ID: <A9013ABC-E73E-4B44-B2A6-AEF5850BD5E8@cbfiddle.com>

It sounds like the items processing maintainer would be looking for OrderedCollection and might or might not find ReversibleCollection. :-)

I suspect you would agree that OrderedCollection by itself is too weak to justify being a type. It?s basically Iterable with the extra bit that the iteration order is not an implementation artifact.

In this example, using the type system to detect a bug like the old bug seems like overkill. Even if the parameter were Ordered, it still might not be the *right* order. The maintainer of the client code needs to understand that.

Suppose the items processor wants to require that the parameter collection not contain duplicates. Would you suggest adding a type for that? Clearly Set would be just as unnecessarily restrictive as List was for ordering. Absurdity approaches?

The issue of Reversible remains, above and beyond Ordered. Have you considered the alternative of a collection providing a Reversed view of itself, in the same sense that unmodifiable collections are views of an underlying collection?

  Alan



> On Apr 30, 2021, at 3:42 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Consider the case of a large application or other system, one that's large enough to have lots of internal APIs, but that is built as a single unit, so release-to-release compatibility isn't an issue. Suppose there is some method
> 
>    processItemsInOrder(List<Item> items)
> 
> that has to process items in the order in which they occur, because processing of later items might depend the processing of earlier ones. The maintainer of this API chose to accept a List as a parameter, because it's a common interface and it's clearly an ordered collection.
> 
> Now consider a client that gets items from different places, keeping them in order, but removing duplicates. It might do something like this:
> 
>    var items = new LinkedHashSet<Item>();
>    items.addAll(getItemsFromSomeplace());
>    items.addAll(getItemsFromAnotherPlace());
>    items.addAll(getItemsFromSomeplaceElse());
>    processItemsInOrder(new ArrayList<>(items));
> 
> It turns out the copying of the items into an ArrayList is a performance bottleneck, so the maintainer of the client code asks the maintainer of the items processing code to change the API to accept Collection instead.
> 
> The items processing maintainer demurs, recalling that the API *did* accept Collection in the past, and a bug where somebody accidentally passed a HashSet resulted in a customer escalation because of item processing irregularities. In the aftermath of that escalation, the API was changed to List. The client maintainer reluctantly pursues alternatives for generating a deduplicated List.
> 
> But wait! Those Java guys added a ReversibleCollection interface in Java N. It has the desired property of being ordered, and conveniently it's a supertype of both List and LinkedHashSet. The items processing maintainer adjusts the API to consume ReversibleCollection, and the client maintainer removes the temporary ArrayList, and everybody is happy.
> 
> s'marks
> 


From psandoz at openjdk.java.net  Fri Apr 30 23:37:52 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 23:37:52 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <-VJVRq98DoOIRYPdSB8b2k1oOAI2vHeyKgo00bvGbSE=.00ef20ca-d072-4426-9e8e-c0e5433d3440@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
 <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
 <-VJVRq98DoOIRYPdSB8b2k1oOAI2vHeyKgo00bvGbSE=.00ef20ca-d072-4426-9e8e-c0e5433d3440@github.com>
Message-ID: <ysTwtqvI0ilgSba2hO4nQgOaY6fFgIsQO6B6UNompEs=.425c083f-60de-418b-ac14-a59ca3fc1535@github.com>

On Fri, 30 Apr 2021 17:44:38 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > @PaulSandoz would it be possible for you to run this through your testing?
> 
> Started, will report back when done.

Tier 1 to 3 tests all pass on build profiles linux-x64 linux-aarch64 macosx-x64 windows-x64

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Fri Apr 30 23:47:52 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 23:47:52 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <ysTwtqvI0ilgSba2hO4nQgOaY6fFgIsQO6B6UNompEs=.425c083f-60de-418b-ac14-a59ca3fc1535@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
 <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
 <-VJVRq98DoOIRYPdSB8b2k1oOAI2vHeyKgo00bvGbSE=.00ef20ca-d072-4426-9e8e-c0e5433d3440@github.com>
 <ysTwtqvI0ilgSba2hO4nQgOaY6fFgIsQO6B6UNompEs=.425c083f-60de-418b-ac14-a59ca3fc1535@github.com>
Message-ID: <9rAKGIqXwGbYSc5i6a7t7Rgbdleyv1EBNvzJwU84GWc=.f64d2522-0576-43ac-8c32-ca748f8f83c5@github.com>

On Fri, 30 Apr 2021 23:34:15 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > > @PaulSandoz would it be possible for you to run this through your testing?
> > 
> > 
> > Started, will report back when done.
> 
> Tier 1 to 3 tests all pass on build profiles linux-x64 linux-aarch64 macosx-x64 windows-x64

@PaulSandoz Thanks a lot!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804