From duke at openjdk.java.net  Wed Jun  1 00:59:33 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 00:59:33 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v4]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <Gy3Z1gKq5Un6CkwwhXKkrF_EyOlz51JWtxd6FZAWVQE=.7ac7d906-5e1b-4341-ab22-fe1db85e0316@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

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

  Moved the tests test/jdk/jni/nullCaller.  Added to the jdk_other group
  which runs as part of tier2.  Made the other requested changes such as
  not using the bugid as the function name for the test and using the
  name of the main method being tested instead.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/f1406a45..7eb5dbcb

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

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

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

From xgong at openjdk.java.net  Wed Jun  1 01:34:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 1 Jun 2022 01:34:40 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v2]
In-Reply-To: <uJLpkCZdNUpfugjsnuUpiXQp29CS64WvqX98HsMMW-M=.9994429f-9e95-4cd9-b20f-7501cb647af1@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
 <uJLpkCZdNUpfugjsnuUpiXQp29CS64WvqX98HsMMW-M=.9994429f-9e95-4cd9-b20f-7501cb647af1@github.com>
Message-ID: <pHF4THNwC_DimG5TxMFnfEYKxTF6Wnm9JFGG-BJhVYU=.d21c0cce-aaad-4603-b5bd-d4c332223494@github.com>

On Mon, 30 May 2022 01:17:00 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrap the offset check into a static method
>
> @PaulSandoz, could you please help to check whether the current version is ok for you? Thanks so much!

> @XiaohongGong looks good, now the Vector API JEP has been integrated you will get a merge conflict, but it should be easier to resolve.

Great! I will resolve the conflict and update the patch, thanks so much!

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

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

From darcy at openjdk.java.net  Wed Jun  1 02:05:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Jun 2022 02:05:40 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
In-Reply-To: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
Message-ID: <DCfBtaWLqERj3BRvcqeJdPdOICLu8Bh48OnXyu8I7ig=.7b9e35af-e810-44be-aa81-c87dd026494c@github.com>

> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.

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

 - Respond to review feedback; make another pass to link methods to IEEE 754 operations.
 - Merge branch 'master' into JDK-8273346
 - Add floor and ceil.
 - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math and StrictMath

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8876/files
  - new: https://git.openjdk.java.net/jdk/pull/8876/files/050e6ecd..9169ad9e

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

  Stats: 46471 lines in 566 files changed: 22606 ins; 17922 del; 5943 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8876.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8876/head:pull/8876

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

From dholmes at openjdk.java.net  Wed Jun  1 02:25:33 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Jun 2022 02:25:33 GMT
Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main
 thread on macOS [v2]
In-Reply-To: <1PZgAXmfp27EHTdkT27VbWMHJQn-4BsbytSZBUgqhS0=.5ca7cb41-529e-4869-9a67-314e3e07ee22@github.com>
References: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>
 <1PZgAXmfp27EHTdkT27VbWMHJQn-4BsbytSZBUgqhS0=.5ca7cb41-529e-4869-9a67-314e3e07ee22@github.com>
Message-ID: <qom84fFR1U_PErWey6RtsoEwR3mhRCB1zlyMxhjRp7w=.e7231df9-523f-4177-8a70-ed197ac966f1@github.com>

On Tue, 31 May 2022 15:10:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is continuation of PR #4256 
>> 
>> The patch simply rounds up the specified stack size to multiple of the system page size, on systems where necessary.
>> The patch is based on the original PR/branch, with reflected remaining recommendations.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated Java mannpage

Thanks for the manpage update!

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

Marked as reviewed by dholmes (Reviewer).

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

From darcy at openjdk.java.net  Wed Jun  1 02:25:36 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Jun 2022 02:25:36 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
In-Reply-To: <DCfBtaWLqERj3BRvcqeJdPdOICLu8Bh48OnXyu8I7ig=.7b9e35af-e810-44be-aa81-c87dd026494c@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
 <DCfBtaWLqERj3BRvcqeJdPdOICLu8Bh48OnXyu8I7ig=.7b9e35af-e810-44be-aa81-c87dd026494c@github.com>
Message-ID: <wYemmgFUGZi7FXu6NKewfEeU2RAQYG7F-X0TrGUHV2c=.f42fc6d7-4a73-4c47-a960-4f8c8388d1ae@github.com>

On Wed, 1 Jun 2022 02:05:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Respond to review feedback; make another pass to link methods to IEEE 754 operations.
>  - Merge branch 'master' into JDK-8273346
>  - Add floor and ceil.
>  - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math and StrictMath

I look another pass over the methods in Float, Double, and Math for opportunities to link to IEEE 754 operations. At least for now, I choose not to link to abs since IEEE 754 abs can have different behavior for NaN values that java.lang.Math.abs. If a link is made, this difference would need to be noted.

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

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

From darcy at openjdk.java.net  Wed Jun  1 02:25:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Jun 2022 02:25:40 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
In-Reply-To: <fjkuVCnfgQI6M0tObWQ2TEuaZ2rhhdZMBL9-3WvdTRE=.23dfd09e-6760-418b-896c-376d507bd185@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
 <fjkuVCnfgQI6M0tObWQ2TEuaZ2rhhdZMBL9-3WvdTRE=.23dfd09e-6760-418b-896c-376d507bd185@github.com>
Message-ID: <SlzncyDzRjE3YWQvx2fq-ou_uPovqUI_FDP82DPVBFg=.64dc7d90-03ac-4751-b958-148845df9913@github.com>

On Wed, 25 May 2022 08:56:27 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Respond to review feedback; make another pass to link methods to IEEE 754 operations.
>>  - Merge branch 'master' into JDK-8273346
>>  - Add floor and ceil.
>>  - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math and StrictMath
>
> src/java.base/share/classes/java/lang/Math.java line 771:
> 
>> 769:      * This method corresponds to the convertToIntegerTiesToEven
>> 770:      * operation defined in IEEE 754.
>> 771:      *
> 
> IEEE `convertToIntegerTiesToEven` rounds ties to the even integer.
> The method's spec, however, requires ties to round toward positive infinity.
> Unfortunately, IEEE 754 doesn't offer a `convertToIntegerTiesToPositive`

Good catch; found a different 754 operation that seems to fit.

> src/java.base/share/classes/java/math/RoundingMode.java line 49:
> 
>> 47:  * exponent range of {@code BigDecimal}, the mathematical result will
>> 48:  * be exactly representable in the result precision or fall between
>> 49:  * two representable values. In the case of falling between two
> 
> Perhaps better would be
> `two adjacent representable values.`

Agreed; adjusted in subsequent push.

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

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

From mchung at openjdk.java.net  Wed Jun  1 02:45:25 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 02:45:25 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v4]
In-Reply-To: <Gy3Z1gKq5Un6CkwwhXKkrF_EyOlz51JWtxd6FZAWVQE=.7ac7d906-5e1b-4341-ab22-fe1db85e0316@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <Gy3Z1gKq5Un6CkwwhXKkrF_EyOlz51JWtxd6FZAWVQE=.7ac7d906-5e1b-4341-ab22-fe1db85e0316@github.com>
Message-ID: <61nkWjC5VtxN1XbFahrQXRUSI2vbRq_v-ArjhRYSFyg=.2bcd1526-3048-4cd0-9064-2e85109b20fb@github.com>

On Wed, 1 Jun 2022 00:59:33 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the tests test/jdk/jni/nullCaller.  Added to the jdk_other group
>   which runs as part of tier2.  Made the other requested changes such as
>   not using the bugid as the function name for the test and using the
>   name of the main method being tested instead.

jdk_other is for other modules.  jdk_lang may be an option  since this is to test when attached with JNI thread.

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

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

From duke at openjdk.java.net  Wed Jun  1 02:45:24 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 02:45:24 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v5]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <rWPdHuUalDMsqQ3Zw3CgTX7xauWNxWAMnWTuUUS8UiM=.fefad5d1-92cf-43ff-bd37-8bf0131ea11a@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

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

  improve comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/7eb5dbcb..777c4f5f

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

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

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

From duke at openjdk.java.net  Wed Jun  1 02:51:32 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 02:51:32 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v5]
In-Reply-To: <rWPdHuUalDMsqQ3Zw3CgTX7xauWNxWAMnWTuUUS8UiM=.fefad5d1-92cf-43ff-bd37-8bf0131ea11a@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <rWPdHuUalDMsqQ3Zw3CgTX7xauWNxWAMnWTuUUS8UiM=.fefad5d1-92cf-43ff-bd37-8bf0131ea11a@github.com>
Message-ID: <ojAuM8jTFWCHwAqeT_9rfyrew-K5Oeet9tz5AhspgoE=.fc9bdba0-6afc-43ac-89ba-dc77a1ef8afb@github.com>

On Wed, 1 Jun 2022 02:45:24 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comment

The tests are mostly java/lang, but also java/util so I was looking for something else.  The jdk_lang seems fairly reasonable and they run tier1 as the tests used to run before the move if I put them there.  I'll update TEST.groups.

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

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

From duke at openjdk.java.net  Wed Jun  1 03:01:35 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 03:01:35 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v6]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <7EHGNYrG5dROegqb9WUzfwcN1ho9UNc55vSWQvc2Af0=.47fcaf76-9b41-4f55-8140-1d7b98bd930b@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

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

  move jni/nullCaller tests to jdk_lang group

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/777c4f5f..8bf4f597

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

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

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

From darcy at openjdk.java.net  Wed Jun  1 03:18:44 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Jun 2022 03:18:44 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v4]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com>

> Time to start getting ready for JDK 20...

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

 - Adjust deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Respond to review feedback.
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - ... and 28 more: https://git.openjdk.java.net/jdk/compare/2ffc9a25...54e872b5

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/eedd36bd..54e872b5

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

  Stats: 1101 lines in 21 files changed: 708 ins; 170 del; 223 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

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

From jjg at openjdk.java.net  Wed Jun  1 03:27:40 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 1 Jun 2022 03:27:40 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3]
In-Reply-To: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
Message-ID: <GmyrRLk_MX9e34aqLobfdvQjpkjXU5kY0t2JSikbE9Y=.07123259-b005-4395-b546-bf105c719ba6@github.com>

On Tue, 31 May 2022 20:32:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:
> 
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbol information for JDK 19 b23.
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/44ff5c88...eedd36bd

langtools files look OK, although I did skim through the auto-generated new data/symbols files.

There are possibilities in the langtools file to simplify naming and default initialization of member fields in various places, in a separate PR, separate from these changes.

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

Marked as reviewed by jjg (Reviewer).

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

From duke at openjdk.java.net  Wed Jun  1 04:16:35 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 1 Jun 2022 04:16:35 GMT
Subject: RFR: 8287340: Refactor old code using StringTokenizer in locale
 related code
In-Reply-To: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
Message-ID: <RRoC2pBFKw9ok-hQaJtmhlDg2Lhwmm98ptM5FfBEhZQ=.6660fbcf-e88c-45bd-992c-6769717b094b@github.com>

On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 181:

> 179:                 .toArray(Locale[]::new);
> 180:         }
> 181:         return AVAILABLE_LOCALES;

This?should probably clone?the?cached?array:
Suggestion:

        return AVAILABLE_LOCALES.clone();


Matching?what `JRELocaleProviderAdapter`?does[^1], since?there?s no?guarantee that?the?result of?`getAvailableLocales()` won?t?be?mutated.

[^1]: https://github.com/openjdk/jdk/blob/6b1169e266b9d21864f886ef574dd64116fa2cb0/src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java#L430-L439

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

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

From dholmes at openjdk.java.net  Wed Jun  1 04:44:39 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Jun 2022 04:44:39 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v4]
In-Reply-To: <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com>
Message-ID: <p6o4WrONmMn3MP2XfJ7lN8SCQEe3QJk03gt_i5R7K04=.9c343d94-dc8b-48c5-9756-6552a7cb16f9@github.com>

On Wed, 1 Jun 2022 03:18:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 38 additional commits since the last revision:
> 
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 28 more: https://git.openjdk.java.net/jdk/compare/c1abb195...54e872b5

Updates look good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

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

From stuefe at openjdk.java.net  Wed Jun  1 04:46:41 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 1 Jun 2022 04:46:41 GMT
Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main
 thread on macOS [v2]
In-Reply-To: <1PZgAXmfp27EHTdkT27VbWMHJQn-4BsbytSZBUgqhS0=.5ca7cb41-529e-4869-9a67-314e3e07ee22@github.com>
References: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>
 <1PZgAXmfp27EHTdkT27VbWMHJQn-4BsbytSZBUgqhS0=.5ca7cb41-529e-4869-9a67-314e3e07ee22@github.com>
Message-ID: <SPVZRxAaLLLjp92K6dzV8E3eri19pyES64sm_-2Cjow=.803db7f0-caf7-4c52-9cce-5657353fabc2@github.com>

On Tue, 31 May 2022 15:10:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is continuation of PR #4256 
>> 
>> The patch simply rounds up the specified stack size to multiple of the system page size, on systems where necessary.
>> The patch is based on the original PR/branch, with reflected remaining recommendations.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated Java mannpage

Looks good.

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

Marked as reviewed by stuefe (Reviewer).

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

From duke at openjdk.java.net  Wed Jun  1 05:03:53 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 1 Jun 2022 05:03:53 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <H4nZJ6RTEc3DpQkv4QhvcJUUPU3jGbwhxHoW_vDYSxs=.c0843e5c-8080-4b31-985a-35ed172cd587@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
 <H4nZJ6RTEc3DpQkv4QhvcJUUPU3jGbwhxHoW_vDYSxs=.c0843e5c-8080-4b31-985a-35ed172cd587@github.com>
Message-ID: <c680UYmYwn0GfyCChQG2ivAMYpGjyMSJYVpGv2rbszY=.1fed602a-f7ce-4841-9e38-9aa000c2b63b@github.com>

On Tue, 31 May 2022 17:26:35 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
>> 
>>  - Target JDK 20 rather than 19.
>>  - Merge branch 'master' into JDK-8266670
>>  - Add mask values to constants' javadoc.
>>  - Implement review feedback from mlchung.
>>  - Fix type in @throws tag.
>>  - Merge branch 'master' into JDK-8266670
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - Make workding changes suggested in review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/db2b501c...05cf2d8b
>
> src/java.base/share/classes/java/lang/reflect/Member.java line 96:
> 
>> 94:      */
>> 95:     public default Set<AccessFlag> accessFlags() {
>> 96:         return Set.of();
> 
> Is is not better to throw a NoSuchMethodError instead of Set.of() if there is no implementation.

Or?`AbstractMethodError`, which?is?what `Executable::getParameterCount()`?does:
https://github.com/openjdk/jdk/blob/e751b7b1b6f7269a1fe20c07748c726536388f6d/src/java.base/share/classes/java/lang/reflect/Executable.java#L248-L258

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

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

From duke at openjdk.java.net  Wed Jun  1 05:13:35 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 1 Jun 2022 05:13:35 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <c680UYmYwn0GfyCChQG2ivAMYpGjyMSJYVpGv2rbszY=.1fed602a-f7ce-4841-9e38-9aa000c2b63b@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
 <H4nZJ6RTEc3DpQkv4QhvcJUUPU3jGbwhxHoW_vDYSxs=.c0843e5c-8080-4b31-985a-35ed172cd587@github.com>
 <c680UYmYwn0GfyCChQG2ivAMYpGjyMSJYVpGv2rbszY=.1fed602a-f7ce-4841-9e38-9aa000c2b63b@github.com>
Message-ID: <NlJuFo6hGmq9zM5oPS4vtHNc2gAJfOTIAyCtah6WXYE=.3b0d7a1f-9e67-4d37-bed1-11c86288ceb9@github.com>

On Wed, 1 Jun 2022 05:01:33 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/reflect/Member.java line 96:
>> 
>>> 94:      */
>>> 95:     public default Set<AccessFlag> accessFlags() {
>>> 96:         return Set.of();
>> 
>> Is is not better to throw a NoSuchMethodError instead of Set.of() if there is no implementation.
>
> Or?`AbstractMethodError`, which?is?what `Executable::getParameterCount()`?does:
> https://github.com/openjdk/jdk/blob/e751b7b1b6f7269a1fe20c07748c726536388f6d/src/java.base/share/classes/java/lang/reflect/Executable.java#L248-L258

Actually, it?should?probably be?`UnsupportedOperationException`?instead.

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

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

From alanb at openjdk.java.net  Wed Jun  1 06:04:14 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 1 Jun 2022 06:04:14 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v3]
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Fixed another typo in comment
 - Merge
 - Fix typos in comments
 - Allowing linking without intrinsic stub, contributed-by: rehn
 - Continuation clinit should fail if no continuations support
 - Fix merge issue with test
 - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
 - Update
 - Expend test coverage
 - Merge
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6

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

Changes: https://git.openjdk.java.net/jdk/pull/8939/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=02
  Stats: 747 lines in 72 files changed: 574 ins; 53 del; 120 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8939.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8939/head:pull/8939

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

From shade at openjdk.java.net  Wed Jun  1 06:05:39 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 06:05:39 GMT
Subject: Integrated: 8287520: Shrink x86_32 problemlists after JDK-8287437
In-Reply-To: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
Message-ID: <jIFGi8wjZIj-EwfNs7gLylJoHNocD_UjZEKWdMaZYPg=.cdc07e0e-b911-484f-a307-e27c97d8272f@github.com>

On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
> 
> Additional testing:
>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [x] GHA run

This pull request has now been integrated.

Changeset: 71599763
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/71599763359055c81afbe5e04d6034b7bb3f3606
Stats:     143 lines in 3 files changed: 0 ins; 142 del; 1 mod

8287520: Shrink x86_32 problemlists after JDK-8287437

Reviewed-by: alanb

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

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

From asotona at openjdk.java.net  Wed Jun  1 06:17:31 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 1 Jun 2022 06:17:31 GMT
Subject: Integrated: 8236569: -Xss not multiple of 4K does not work for the
 main thread on macOS
In-Reply-To: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>
References: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>
Message-ID: <uKxybYZgWvFsL5yWgWZybrjAGUSxpMJIj0oTSxAPWlg=.93c67bda-5cca-4fbe-98eb-1a6ca23aee6b@github.com>

On Tue, 31 May 2022 08:37:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is continuation of PR #4256 
> 
> The patch simply rounds up the specified stack size to multiple of the system page size, on systems where necessary.
> The patch is based on the original PR/branch, with reflected remaining recommendations.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 78469713
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/784697138182f104c30f8365b01f67be4d28083c
Stats:     43 lines in 4 files changed: 41 ins; 0 del; 2 mod

8236569: -Xss not multiple of 4K does not work for the main thread on macOS

Reviewed-by: dholmes, stuefe

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

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

From dholmes at openjdk.java.net  Wed Jun  1 06:29:29 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Jun 2022 06:29:29 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v3]
In-Reply-To: <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
Message-ID: <izG3NXAW6NwCwmQTofA082c5UWWdI7gfJe9gte1MHFY=.08f0d8a1-5c24-4f8c-bbd0-d334db7a9966@github.com>

On Wed, 1 Jun 2022 06:04:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fixed another typo in comment
>  - Merge
>  - Fix typos in comments
>  - Allowing linking without intrinsic stub, contributed-by: rehn
>  - Continuation clinit should fail if no continuations support
>  - Fix merge issue with test
>  - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
>  - Update
>  - Expend test coverage
>  - Merge
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6

src/java.base/share/classes/java/lang/Thread.java line 742:

> 740:      * @param name thread name, can be null
> 741:      * @param characteristics thread characteristics
> 742:      * @param bound true when bound to an OS thread

Nit: s/OS/VM/ ?

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

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

From duke at openjdk.java.net  Wed Jun  1 07:50:58 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 1 Jun 2022 07:50:58 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v9]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <pitf6I-ioejxwT2sXuSo6igIFjL-oZS-iPrBvzSif8g=.39b8154f-42d2-4b8c-ad47-35372026a9de@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

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

  8282662: Revert wrong copyright year change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7729/files
  - new: https://git.openjdk.java.net/jdk/pull/7729/files/b20c2703..7bb28667

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

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

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

From duke at openjdk.java.net  Wed Jun  1 08:45:35 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 1 Jun 2022 08:45:35 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
In-Reply-To: <DCfBtaWLqERj3BRvcqeJdPdOICLu8Bh48OnXyu8I7ig=.7b9e35af-e810-44be-aa81-c87dd026494c@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
 <DCfBtaWLqERj3BRvcqeJdPdOICLu8Bh48OnXyu8I7ig=.7b9e35af-e810-44be-aa81-c87dd026494c@github.com>
Message-ID: <ylGELIu3MVU0JFX5lApPApYg0wQ6_X5-wZB3wSSgLKw=.9f9bebcc-8750-41f8-a4f3-93907b7ae837@github.com>

On Wed, 1 Jun 2022 02:05:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Respond to review feedback; make another pass to link methods to IEEE 754 operations.
>  - Merge branch 'master' into JDK-8273346
>  - Add floor and ceil.
>  - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math and StrictMath

src/java.base/share/classes/java/lang/Math.java line 823:

> 821:      * @apiNote
> 822:      * This method corresponds to the convertTowardPositive operation
> 823:      * defined in IEEE 754.

Probably what is meant is IEEE `convertToIntegerTowardPositive` (not `convertTowardPositive`).
However, that's another kind of rounding, which always rounds any non-integral value toward positive infinity, not just ties. This is not what happens with this method.

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

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

From duke at openjdk.java.net  Wed Jun  1 09:03:39 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 1 Jun 2022 09:03:39 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <YyvIu3-afX0JFoKQMqGXf74FJx215KbHhjtlHavxiAE=.89870ec2-2706-47ff-aa3d-b4b5a2fb7331@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
 <YyvIu3-afX0JFoKQMqGXf74FJx215KbHhjtlHavxiAE=.89870ec2-2706-47ff-aa3d-b4b5a2fb7331@github.com>
Message-ID: <sqUDm-6R6LqoI9ngm56bl9C6C2enM5Pjtbb305J1eZY=.6c329bc7-1d7d-472b-9799-dc279ba44463@github.com>

On Tue, 31 May 2022 21:35:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 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/MathUtils.java line 38:
> 
>> 36:      *
>> 37:      *     Giulietti, "The Schubfach way to render doubles",
>> 38:      *     https://drive.google.com/file/d/1gp5xv4CAa78SVgCeWfGqqI4FfYYYuNFb
> 
> Even though not public, should the reference use the `<cite/>` tag and perhaps be in a `@see` annotation?
> 
> @see <a href=?https://drive.google.com/file/d/1gp5xv4CAa78SVgCeWfGqqI4FfYYYuNFb?>
>      <cite>The Schubfach way to render doubles</cite></a>

These references are inside a normal multi-line comment, so I'm not sure that Javadoc or html tags or have a well-defined semantics there.

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

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

From alanb at openjdk.java.net  Wed Jun  1 09:03:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 1 Jun 2022 09:03:39 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <sqUDm-6R6LqoI9ngm56bl9C6C2enM5Pjtbb305J1eZY=.6c329bc7-1d7d-472b-9799-dc279ba44463@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
 <YyvIu3-afX0JFoKQMqGXf74FJx215KbHhjtlHavxiAE=.89870ec2-2706-47ff-aa3d-b4b5a2fb7331@github.com>
 <sqUDm-6R6LqoI9ngm56bl9C6C2enM5Pjtbb305J1eZY=.6c329bc7-1d7d-472b-9799-dc279ba44463@github.com>
Message-ID: <9qZeFSQLSmoFwRF0XEjfQzMI1JysTHdHuSIcZjNU4sY=.dcb05bfd-ac8d-429e-842c-6c65a07314f7@github.com>

On Wed, 1 Jun 2022 08:56:38 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/jdk/internal/math/MathUtils.java line 38:
>> 
>>> 36:      *
>>> 37:      *     Giulietti, "The Schubfach way to render doubles",
>>> 38:      *     https://drive.google.com/file/d/1gp5xv4CAa78SVgCeWfGqqI4FfYYYuNFb
>> 
>> Even though not public, should the reference use the `<cite/>` tag and perhaps be in a `@see` annotation?
>> 
>> @see <a href=?https://drive.google.com/file/d/1gp5xv4CAa78SVgCeWfGqqI4FfYYYuNFb?>
>>      <cite>The Schubfach way to render doubles</cite></a>
>
> These references are inside a normal multi-line comment, so I'm not sure that Javadoc or html tags or have a well-defined semantics there.

I'm not sure about linking to a document on Google Drive, even from JDK internal classes. Is the paper uploaded to anywhere else that could be linked to instead?

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

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

From duke at openjdk.java.net  Wed Jun  1 09:25:38 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 1 Jun 2022 09:25:38 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <zaMLwUfbx_2XOvCd8FDgi6CSd73nfpoFwVbV7yOKgy4=.88f95354-f376-484e-9ae4-391513c1d913@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
 <zaMLwUfbx_2XOvCd8FDgi6CSd73nfpoFwVbV7yOKgy4=.88f95354-f376-484e-9ae4-391513c1d913@github.com>
Message-ID: <5Ry_357Z2pQDLAsflpN4LAuEf17Vt0eJTrZQ6fKIUgc=.7ead97d0-0e0d-41c8-9657-31ba7fc98bb4@github.com>

On Tue, 31 May 2022 21:57:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 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 118:
> 
>> 116:     private int index;
>> 117: 
>> 118:     private DoubleToDecimal() {
> 
> Maybe add a comment like
> 
>     /**
>      * Prevent instantiation.
>      */
> 
> or
> 
> // Prevent instantiation of this class.

The constructor _is_ invoked, so the comment would be inappropriate.

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

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

From sgehwolf at openjdk.java.net  Wed Jun  1 09:27:22 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 1 Jun 2022 09:27:22 GMT
Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout
 parsing code
Message-ID: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>

Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated
buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue
of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read.

While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From
a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be
there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is
meant to only use stringStream throughout the cgroups code.

Testing:
- [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2
- [x] Added tests, which I've verified also pass before the stringStream change

Thoughts?

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

Commit messages:
 - Add cgroups v2 java test
 - use stringStream in cgroups v2
 - Add gtest for cgroups v2 code path
 - 8287007: [cgroups] Consistently use stringStream throughout parsing code
 - 8287007: [cgroups] Consistently use stringStream throughout parsing code

Changes: https://git.openjdk.java.net/jdk/pull/8969/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8969&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287007
  Stats: 270 lines in 5 files changed: 235 ins; 19 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8969.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8969/head:pull/8969

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

From dfuchs at openjdk.java.net  Wed Jun  1 09:35:55 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 1 Jun 2022 09:35:55 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v4]
In-Reply-To: <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
Message-ID: <SCk0nSmI_5AWF8s0xgNAKd_mkPRHIvRnXUToOKPASpg=.bdc85642-c6de-4875-9275-543845d16588@github.com>

On Fri, 6 May 2022 22:05:35 GMT, liach <duke at openjdk.java.net> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Move tests
>  - Merge branch 'master' into fix/identityhashmap-default
>  - Fix assertions
>  - Revamp test and changes. Let ci run the tests
>  - Fix indent
>  - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)

src/java.base/share/classes/java/util/IdentityHashMap.java line 1392:

> 1390:      * and {@code value == v}, then this method removes the mapping
> 1391:      * for this key and returns {@code true}; otherwise it returns
> 1392:      * {@code false}.

The API documentation of containsKey() and containsValue() should probably be updated to mention reference equality too. This doesn't need to be carried out in this PR, but maybe a new issue should be logged to double check the completeness of the IdentityHashMap API documentation and see where adding some similar text makes sense.

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

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

From duke at openjdk.java.net  Wed Jun  1 09:42:37 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 1 Jun 2022 09:42:37 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <5Ry_357Z2pQDLAsflpN4LAuEf17Vt0eJTrZQ6fKIUgc=.7ead97d0-0e0d-41c8-9657-31ba7fc98bb4@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
 <zaMLwUfbx_2XOvCd8FDgi6CSd73nfpoFwVbV7yOKgy4=.88f95354-f376-484e-9ae4-391513c1d913@github.com>
 <5Ry_357Z2pQDLAsflpN4LAuEf17Vt0eJTrZQ6fKIUgc=.7ead97d0-0e0d-41c8-9657-31ba7fc98bb4@github.com>
Message-ID: <hDhX1MF2E0RKJGb8mLeEyv_wzlZY8KsO4KgFPeyaMyg=.8ac8a717-2659-4481-8b68-7c8afb7b5b62@github.com>

On Wed, 1 Jun 2022 09:21:43 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 118:
>> 
>>> 116:     private int index;
>>> 117: 
>>> 118:     private DoubleToDecimal() {
>> 
>> Maybe add a comment like
>> 
>>     /**
>>      * Prevent instantiation.
>>      */
>> 
>> or
>> 
>> // Prevent instantiation of this class.
>
> The constructor _is_ invoked, so the comment would be inappropriate.

... but I added a `throw` in the constructor of `MathUtils`

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

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

From duke at openjdk.java.net  Wed Jun  1 10:27:43 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 1 Jun 2022 10:27:43 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <zaMLwUfbx_2XOvCd8FDgi6CSd73nfpoFwVbV7yOKgy4=.88f95354-f376-484e-9ae4-391513c1d913@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
 <zaMLwUfbx_2XOvCd8FDgi6CSd73nfpoFwVbV7yOKgy4=.88f95354-f376-484e-9ae4-391513c1d913@github.com>
Message-ID: <qG5IXJnEyPYiG5UTWRscNXIBwt6sZClj86H-7PeHPxI=.e48df284-d3e1-42cf-8b75-85dcdfb5f779@github.com>

On Tue, 31 May 2022 21:55:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 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 97:
> 
>> 95:     private static final int MASK_28 = (1 << 28) - 1;
>> 96: 
>> 97:     private static final int NON_SPECIAL    = 0;
> 
> Would these constants be better as an enum?

An enum would make much sense if it were used by other parts of the codebase, and then it would be moved to `MathUtils`.
This might well happen in the near future, when this code could be enhanced to be used in formatting conversions, like in "`printf()`" and friends.

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

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

From duke at openjdk.java.net  Wed Jun  1 10:32:34 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 1 Jun 2022 10:32:34 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <mncUCyJ9LgMIQWmh6du5CpXX2M3OrXzlocDfE1yQAQs=.46da3a2f-14c7-41b7-96f6-9601a397b662@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
 <mncUCyJ9LgMIQWmh6du5CpXX2M3OrXzlocDfE1yQAQs=.46da3a2f-14c7-41b7-96f6-9601a397b662@github.com>
Message-ID: <2MEpvnpISkBFrZhxrw5sJcX9MdgluhymY_cScS2wSmw=.68971504-aa12-4fd8-b094-319a0925b430@github.com>

On Tue, 31 May 2022 22:11:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 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/FloatToDecimal.java line 97:
> 
>> 95:     private static final int MASK_28 = (1 << 28) - 1;
>> 96: 
>> 97:     private static final int NON_SPECIAL    = 0;
> 
> As these are shared with `DoubleToDecimal` would these constants be better moved to a common location, e.g., `MathUtils` whether converted to an `enum` or not?

As long as the values are constant `ints`, moving them to `MathUtils` is less robust. Changing any value would require remembering to recompile the "clients".
The move would make sense if these were an enum.

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

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

From duke at openjdk.java.net  Wed Jun  1 10:37:23 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 1 Jun 2022 10:37:23 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v15]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <-AP9X7rJrdRJzS6F4qxlReVZIxw07fwXTgoCiV1B2O4=.6f21a7da-522c-4a91-8c4e-7a2a5a6be853@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/ad146ec4..93711bae

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

  Stats: 618 lines in 1 file changed: 1 ins; 0 del; 617 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 aefimov at openjdk.java.net  Wed Jun  1 11:06:31 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 1 Jun 2022 11:06:31 GMT
Subject: RFR: 8281695: jtreg test
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
In-Reply-To: <jHdkloNkrJ2mCC1dn-wiI3Ca5-rXgko5u7VwFvIUXE0=.5d4fd48e-0351-475c-a45e-d9c6b41619a4@github.com>
References: <jHdkloNkrJ2mCC1dn-wiI3Ca5-rXgko5u7VwFvIUXE0=.5d4fd48e-0351-475c-a45e-d9c6b41619a4@github.com>
Message-ID: <40dKtZGYbPJ-_qoTZgxC5OrFg6KN8ZEywA-8WOyFOiA=.d84e7e85-eea0-4960-8895-2d0274efe2ca@github.com>

On Fri, 27 May 2022 15:24:46 GMT, Rob McKenna <robm at openjdk.org> wrote:

> Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work.

The change looks fine, given it is a temporary workaround until an alternative to the use of example.com is found.

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

Marked as reviewed by aefimov (Committer).

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

From redestad at openjdk.java.net  Wed Jun  1 13:03:38 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 1 Jun 2022 13:03:38 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v3]
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <X7J-WIu6Eq8vNldT9s1MUYtdxamj_kC0fSjhQEQcMZw=.ff2c0a7e-6286-4742-bf78-58ab77edbdc0@github.com>

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

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

  Improve bootstrap microbenchmark to include more shapes, reduce runtime

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8855/files
  - new: https://git.openjdk.java.net/jdk/pull/8855/files/263db625..4221b348

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

  Stats: 25 lines in 1 file changed: 19 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8855.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8855/head:pull/8855

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

From duke at openjdk.java.net  Wed Jun  1 13:16:36 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 1 Jun 2022 13:16:36 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v3]
In-Reply-To: <X7J-WIu6Eq8vNldT9s1MUYtdxamj_kC0fSjhQEQcMZw=.ff2c0a7e-6286-4742-bf78-58ab77edbdc0@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <X7J-WIu6Eq8vNldT9s1MUYtdxamj_kC0fSjhQEQcMZw=.ff2c0a7e-6286-4742-bf78-58ab77edbdc0@github.com>
Message-ID: <bgTAoGYHhwIcKDEhZeEaqH5ngI64i5ZZYNYz0viZtU0=.abd8f6f0-4011-4afb-9cc2-371424d74276@github.com>

On Wed, 1 Jun 2022 13:03:38 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
>> 
>> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
>> 
>> | Build      |    # classes    |   Runtime   |
>> | ----------- | ----------------- |  --------------- |
>> | Baseline |     31119       |     2.942s     |
>> | Patch      |     16208       |     1.958s     |
>> 
>> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
>> 
>> Baseline:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
>> 
>> This patch:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve bootstrap microbenchmark to include more shapes, reduce runtime

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 674:

> 672:                     1 + pos, 2 + pos, 3 + pos, 4 + pos // selected arguments
> 673:             );
> 674:         }

This?should?probably also?use a?switch like?the?above:
Suggestion:

        return switch (count) {
            case 1 -> MethodHandles.foldArgumentsWithCombiner(mh, 0, mix,
                    1 + pos // selected arguments
            );
            case 2 -> MethodHandles.foldArgumentsWithCombiner(mh, 0, mix,
                    1 + pos, 2 + pos // selected arguments
            );
            case 3 -> MethodHandles.foldArgumentsWithCombiner(mh, 0, mix,
                    1 + pos, 2 + pos, 3 + pos // selected arguments
            );
            case 4 -> MethodHandles.foldArgumentsWithCombiner(mh, 0, mix,
                    1 + pos, 2 + pos, 3 + pos, 4 + pos // selected arguments
            );
            default -> throw new AssertionError(count);
        }

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

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

From dfuchs at openjdk.java.net  Wed Jun  1 13:29:34 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 1 Jun 2022 13:29:34 GMT
Subject: RFR: 8281695: jtreg test
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
In-Reply-To: <jHdkloNkrJ2mCC1dn-wiI3Ca5-rXgko5u7VwFvIUXE0=.5d4fd48e-0351-475c-a45e-d9c6b41619a4@github.com>
References: <jHdkloNkrJ2mCC1dn-wiI3Ca5-rXgko5u7VwFvIUXE0=.5d4fd48e-0351-475c-a45e-d9c6b41619a4@github.com>
Message-ID: <j9Au6t8Hlx2qAKBiQVeOzDNkRNAv95eeTLAWtYJhJsM=.a2e831f4-55a5-453f-85a7-3d228db3be26@github.com>

On Fri, 27 May 2022 15:24:46 GMT, Rob McKenna <robm at openjdk.org> wrote:

> Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work.

test/jdk/com/sun/jndi/ldap/LdapTimeoutTest.java line 135:

> 133:                     failedCount++;
> 134:                     cause.printStackTrace(System.out);
> 135:                 }

Maybe this could be simplified as:


  Throwable cause = e.getCause();
  // don't fail if we get NoRouteToHostException
  if (cause instanceof NoRouteToHostException) continue;
  if (cause != null && cause.getCause() != null) cause = cause.getCause();
  if (cause instanceof NoRouteToHostException) continue;
  failedCount++;
  cause.printStackTrace(System.out);

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

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

From redestad at openjdk.java.net  Wed Jun  1 13:31:27 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 1 Jun 2022 13:31:27 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v4]
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <oy0ef3mKlEiVTnaxdMVZX_8Yn0nrKpzoMPcU0eEHMlM=.728dfb2e-4cd5-4ae5-bc85-91114f4fc913@github.com>

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

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

  Address review comments from @ExE-Boss

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8855/files
  - new: https://git.openjdk.java.net/jdk/pull/8855/files/4221b348..f1742a84

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

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

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

From duke at openjdk.java.net  Wed Jun  1 13:32:36 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Wed, 1 Jun 2022 13:32:36 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v6]
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

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

 - 8285838: Cleanup of trailing whitespace
 - 8285838: Corrected month comparison check for TZ DST

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/9e3b1bb4..87832663

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

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

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

From rriggs at openjdk.java.net  Wed Jun  1 13:32:47 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Jun 2022 13:32:47 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v9]
In-Reply-To: <pitf6I-ioejxwT2sXuSo6igIFjL-oZS-iPrBvzSif8g=.39b8154f-42d2-4b8c-ad47-35372026a9de@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <pitf6I-ioejxwT2sXuSo6igIFjL-oZS-iPrBvzSif8g=.39b8154f-42d2-4b8c-ad47-35372026a9de@github.com>
Message-ID: <LhfwNIF-X5d-rCxD6zfVXINWKrcDS3JMYc9l2yEJKFQ=.72e66580-4a2c-4c7f-abdb-34898a9f333f@github.com>

On Wed, 1 Jun 2022 07:50:58 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282662: Revert wrong copyright year change

Marked as reviewed by rriggs (Reviewer).

Thanks for the improvements.

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

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

From duke at openjdk.java.net  Wed Jun  1 13:35:13 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 1 Jun 2022 13:35:13 GMT
Subject: Integrated: 8282662: Use List.of() factory method to reduce memory
 consumption
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <aaJhGv-fyhi3UXKlfnYJbIhFULcZvse_BWu00DkPwHg=.fc7bc5de-4323-47ab-93ec-d955a967525d@github.com>

On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

This pull request has now been integrated.

Changeset: 168b226b
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/168b226b0f7a3b067bf11616e5a92908f63be450
Stats:     12 lines in 4 files changed: 1 ins; 2 del; 9 mod

8282662: Use List.of() factory method to reduce memory consumption

Reviewed-by: redestad, rriggs

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

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

From duke at openjdk.java.net  Wed Jun  1 13:36:33 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Wed, 1 Jun 2022 13:36:33 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v5]
In-Reply-To: <dbQFYDugzX8zNINu-4WJ6fAoSoTAdXa72GqkqKuBCCQ=.28a3eb2a-4d60-4dac-bc84-f0386dfad30f@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <7SpDwS0sWsYuaiBdJqhhqUPEyc7gcBcL4mExUW3RE_4=.a62ad8f9-7fe9-4d45-92b9-74222698e845@github.com>
 <dbQFYDugzX8zNINu-4WJ6fAoSoTAdXa72GqkqKuBCCQ=.28a3eb2a-4d60-4dac-bc84-f0386dfad30f@github.com>
Message-ID: <0gdQwqgXz3SqAZXXyMfFphDyae6uxLYZyH0aKQ14Ljo=.3be034af-ec1b-4ec2-bcd6-769240c9fb0e@github.com>

On Tue, 31 May 2022 22:34:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285838: Corrected month comparison check for TZ DST
>
> I tried out your patch on my local Linux machine, but the new test failed with the following exception:
> 
> ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]
> REASON: User specified action: run main/othervm CustomTzIDCheckDST 
> TIME:   1.564 seconds
> messages:
> command: main CustomTzIDCheckDST
> reason: User specified action: run main/othervm CustomTzIDCheckDST 
> Mode: othervm [/othervm specified]
> elapsed time (seconds): 1.564
> configuration:
> STDOUT:
> Command line: [/home/nsato/projects/jdk/git/jdk/build/linux-x64/images/jdk/bin/java -cp /home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/java/util/TimeZone/CustomTzIDCheckDST.d:/home/nsato/projects/jdk/git/jdk/open/test/jdk/java/util/TimeZone:/home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/test/lib:/home/nsato/projects/jdk/git/jdk/open/test/lib:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/javatest.jar:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/jtreg.jar CustomTzIDCheckDST runTZTest ]
> [2022-05-31T22:27:05.958567816Z] Gathering output for process 14771
> [2022-05-31T22:27:06.635595481Z] Waiting for completion for process 14771
> [2022-05-31T22:27:06.635976964Z] Waiting for completion finished for process 14771
> Output and diagnostic info for process 14771 was saved into 'pid-14771-output.log'
> [2022-05-31T22:27:06.663087767Z] Waiting for completion for process 14771
> [2022-05-31T22:27:06.663360403Z] Waiting for completion finished for process 14771
> [2022-05-31T22:27:06.663754609Z] Waiting for completion for process 14771
> [2022-05-31T22:27:06.663869034Z] Waiting for completion finished for process 14771
> STDERR:
>  stdout: [];
>  stderr: [Exception in thread "main" java.time.DateTimeException: Invalid ID for offset-based ZoneId: GMT-22:00
> 	at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:436)
> 	at java.base/java.time.ZoneId.of(ZoneId.java:406)
> 	at java.base/java.time.ZoneId.of(ZoneId.java:358)
> 	at java.base/java.time.ZoneId.of(ZoneId.java:314)
> 	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:581)
> 	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
> 	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:570)
> 	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
> 	at java.base/java.time.ZoneId.systemDefault(ZoneId.java:274)
> 	at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:64)
> 	at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:51)
> Caused by: java.time.DateTimeException: Zone offset hours not in valid range: value -22 is not in the range -18 to 18
> 	at java.base/java.time.ZoneOffset.validate(ZoneOffset.java:373)
> 	at java.base/java.time.ZoneOffset.ofHoursMinutesSeconds(ZoneOffset.java:326)
> 	at java.base/java.time.ZoneOffset.of(ZoneOffset.java:257)
> 	at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:430)
> 	... 10 more
> ]
>  exitValue = 1
> 
> java.lang.RuntimeException: Expected to get exit value of [0]
> 
> 	at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:489)
> 	at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:49)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:1585)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [0]
> 
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]

Hi @naotoj ,
I am unable to reproduce the above error you are seeing, and it is passing on my linux machine. What is the system default timezone on your local machine? Wondering if it will help me see what you are seeing (even though the timezone should be overriden via the TZ variable). Looks like the test is not even reaching the checks and failing at the point where its simply trying to retrieve the current time.

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

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

From brian.burkhalter at oracle.com  Wed Jun  1 15:35:41 2022
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 Jun 2022 15:35:41 +0000
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results [v14]
In-Reply-To: <5Ry_357Z2pQDLAsflpN4LAuEf17Vt0eJTrZQ6fKIUgc=.7ead97d0-0e0d-41c8-9657-31ba7fc98bb4@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
 <zaMLwUfbx_2XOvCd8FDgi6CSd73nfpoFwVbV7yOKgy4=.88f95354-f376-484e-9ae4-391513c1d913@github.com>
 <5Ry_357Z2pQDLAsflpN4LAuEf17Vt0eJTrZQ6fKIUgc=.7ead97d0-0e0d-41c8-9657-31ba7fc98bb4@github.com>
Message-ID: <867A4C46-6939-4DF4-BACE-02E879376701@oracle.com>



On Jun 1, 2022, at 2:25 AM, Raffaello Giulietti <duke at openjdk.java.net<mailto:duke at openjdk.java.net>> wrote:

On Tue, 31 May 2022 21:57:44 GMT, Brian Burkhalter <bpb at openjdk.org<mailto:bpb at openjdk.org>> wrote:

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 118:

116:     private int index;
117:
118:     private DoubleToDecimal() {

Maybe add a comment like

   /**
    * Prevent instantiation.
    */

or

// Prevent instantiation of this class.

The constructor _is_ invoked, so the comment would be inappropriate.

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

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

Mea culpa.

From brian.burkhalter at oracle.com  Wed Jun  1 15:36:41 2022
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 Jun 2022 15:36:41 +0000
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results [v14]
In-Reply-To: <2MEpvnpISkBFrZhxrw5sJcX9MdgluhymY_cScS2wSmw=.68971504-aa12-4fd8-b094-319a0925b430@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
 <mncUCyJ9LgMIQWmh6du5CpXX2M3OrXzlocDfE1yQAQs=.46da3a2f-14c7-41b7-96f6-9601a397b662@github.com>
 <2MEpvnpISkBFrZhxrw5sJcX9MdgluhymY_cScS2wSmw=.68971504-aa12-4fd8-b094-319a0925b430@github.com>
Message-ID: <A7238379-DCD2-4946-A0DA-4ACB532C7E29@oracle.com>



> On Jun 1, 2022, at 3:32 AM, Raffaello Giulietti <duke at openjdk.java.net> wrote:
> 
> On Tue, 31 May 2022 22:11:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
> 
>>> 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/FloatToDecimal.java line 97:
>> 
>>> 95:     private static final int MASK_28 = (1 << 28) - 1;
>>> 96: 
>>> 97:     private static final int NON_SPECIAL    = 0;
>> 
>> As these are shared with `DoubleToDecimal` would these constants be better moved to a common location, e.g., `MathUtils` whether converted to an `enum` or not?
> 
> As long as the values are constant `ints`, moving them to `MathUtils` is less robust. Changing any value would require remembering to recompile the "clients".
> The move would make sense if these were an enum.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3402

Understood. All of that can wait until later.

From robm at openjdk.java.net  Wed Jun  1 15:44:39 2022
From: robm at openjdk.java.net (Rob McKenna)
Date: Wed, 1 Jun 2022 15:44:39 GMT
Subject: Withdrawn: 8281695: jtreg test
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
In-Reply-To: <jHdkloNkrJ2mCC1dn-wiI3Ca5-rXgko5u7VwFvIUXE0=.5d4fd48e-0351-475c-a45e-d9c6b41619a4@github.com>
References: <jHdkloNkrJ2mCC1dn-wiI3Ca5-rXgko5u7VwFvIUXE0=.5d4fd48e-0351-475c-a45e-d9c6b41619a4@github.com>
Message-ID: <0F_jd0v-wPox43ZSWeAdzJWQgjKrJjRyL2WFVg7QmjM=.e6529130-3cd8-40df-b3f3-81d8d4c8a3a7@github.com>

On Fri, 27 May 2022 15:24:46 GMT, Rob McKenna <robm at openjdk.org> wrote:

> Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work.

This pull request has been closed without being integrated.

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

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

From robm at openjdk.java.net  Wed Jun  1 15:48:05 2022
From: robm at openjdk.java.net (Rob McKenna)
Date: Wed, 1 Jun 2022 15:48:05 GMT
Subject: RFR: 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java
 fails intermittently in nightly run
Message-ID: <Y3LKKXeWPYrjOsp6ndLH5bGfpnecF1SJq203Rd4iqjI=.a052a8d5-7870-4e48-9f38-3ebe19823251@github.com>

Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work.

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

Commit messages:
 - 8281695: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run

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

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

From dfuchs at openjdk.java.net  Wed Jun  1 16:18:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 1 Jun 2022 16:18:49 GMT
Subject: RFR: 8287672: jtreg test
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
In-Reply-To: <Y3LKKXeWPYrjOsp6ndLH5bGfpnecF1SJq203Rd4iqjI=.a052a8d5-7870-4e48-9f38-3ebe19823251@github.com>
References: <Y3LKKXeWPYrjOsp6ndLH5bGfpnecF1SJq203Rd4iqjI=.a052a8d5-7870-4e48-9f38-3ebe19823251@github.com>
Message-ID: <zXuACQboT4g6638rUGEtvVmDDQOVclJi4cKYCCHZy_o=.5be2dc5a-f24e-4684-a049-30b048576612@github.com>

On Wed, 1 Jun 2022 15:41:57 GMT, Rob McKenna <robm at openjdk.org> wrote:

> Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work.

Marked as reviewed by dfuchs (Reviewer).

test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java line 124:

> 122:             System.err.println("MSG RTE: " + msg);
> 123:             // assertCompletion may wrap a CommunicationException in an RTE
> 124:             assertTrue(msg != null);

LGTM. Nit: I believe there is an `assertNotNull()`

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

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

From naoto at openjdk.java.net  Wed Jun  1 16:34:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 16:34:44 GMT
Subject: RFR: 8287340: Refactor old code using StringTokenizer in locale
 related code [v2]
In-Reply-To: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
Message-ID: <fpyyN5DzjtBpa8DWu1FBS_Tw0oLxrkXBABB6reSA2FA=.4ac90777-442a-4410-88ae-6256d0e18278@github.com>

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

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

  Removed unnecessary clone() call

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8960/files
  - new: https://git.openjdk.java.net/jdk/pull/8960/files/6b1169e2..d1b00f10

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

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

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

From naoto at openjdk.java.net  Wed Jun  1 16:39:33 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 16:39:33 GMT
Subject: RFR: 8287340: Refactor old code using StringTokenizer in locale
 related code [v2]
In-Reply-To: <RRoC2pBFKw9ok-hQaJtmhlDg2Lhwmm98ptM5FfBEhZQ=.6660fbcf-e88c-45bd-992c-6769717b094b@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
 <RRoC2pBFKw9ok-hQaJtmhlDg2Lhwmm98ptM5FfBEhZQ=.6660fbcf-e88c-45bd-992c-6769717b094b@github.com>
Message-ID: <iZM1ghp3dm3o8W0FsSjnei9G9GzItEQ5tjBuUsIhTJI=.b85e1eb3-6a32-4a1a-bc47-4719372db764@github.com>

On Wed, 1 Jun 2022 04:10:03 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unnecessary clone() call
>
> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 181:
> 
>> 179:                 .toArray(Locale[]::new);
>> 180:         }
>> 181:         return AVAILABLE_LOCALES;
> 
> This?should probably clone?the?cached?array:
> Suggestion:
> 
>         return AVAILABLE_LOCALES.clone();
> 
> 
> Matching?what `JRELocaleProviderAdapter`?does[^1], since?there?s no?guarantee that?the?result of?`getAvailableLocales()` won?t?be?mutated.
> 
> [^1]: https://github.com/openjdk/jdk/blob/6b1169e266b9d21864f886ef574dd64116fa2cb0/src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java#L430-L439

Thanks for your comments. In fact, `clone()` in `JRELocaleProviderAdapter` is not necessary, as it will be subsumed into `Locale.getAvailableLocales()` and other `getAvailableLocales()` methods in locale sensitives services (such as `DateFormat`) where they are defensively cloned. Removed this `clone()` invocation.

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

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

From smarks at openjdk.java.net  Wed Jun  1 16:41:34 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 1 Jun 2022 16:41:34 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v14]
In-Reply-To: <6kUN9jU2_OUsSLBB_uw1H7b1qb_CGOxsYFNFgyK3hr8=.e791ec0e-64cb-4cf3-81e1-72079b15a151@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <vmYk6F4vkRB2HmpWMmGGHGb1r8W5btmkULpY0mxQGAQ=.0d068364-e67a-4f05-9194-f0044ce52496@github.com>
 <_gO04nLDvvjx4hHbiXzJaVMCe1JeV6u1wgTYMWg3S0E=.444ca8a9-2ceb-4ae1-ab14-9c90e6b040b6@github.com>
 <6kUN9jU2_OUsSLBB_uw1H7b1qb_CGOxsYFNFgyK3hr8=.e791ec0e-64cb-4cf3-81e1-72079b15a151@github.com>
Message-ID: <2HQbdZiJj7S2HW1KForVTRWO0uR-VdLFhNqZ0_F3pSI=.9e7cab1a-2d09-4197-91b0-9ea6deb3b8df@github.com>

On Fri, 27 May 2022 06:09:59 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> Thanks for the updates. I've made a couple minor changes to the specs; please merge the latest commit from this branch:
>> 
>> https://github.com/stuart-marks/jdk/tree/pull/8302
>> 
>> I've created a CSR and have included these changes in it. Please review: [JDK-8287419](https://bugs.openjdk.java.net/browse/JDK-8287419)
>> 
>> I'll look at the test changes later. I wanted to get the CSR moving first, since it will take a few days (and a long weekend in the US is coming up).
>
> @stuart-marks @liach done.

@XenoAmess Please merge the latest commit from https://github.com/stuart-marks/jdk/commits/pull/8302 which contains changes requested during the CSR review. Thanks.

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

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

From duke at openjdk.java.net  Wed Jun  1 16:49:34 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 1 Jun 2022 16:49:34 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <oPgxqmLOciqOKyyiyXij5NljzGJ9bvo1SJWczC4V5ls=.1cd484f7-78d4-4f5e-9563-6d5d5af802ac@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

'the new' fix should be applied to newHashMap etc. too.

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

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

From mchung at openjdk.java.net  Wed Jun  1 16:57:28 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 16:57:28 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v6]
In-Reply-To: <7EHGNYrG5dROegqb9WUzfwcN1ho9UNc55vSWQvc2Af0=.47fcaf76-9b41-4f55-8140-1d7b98bd930b@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <7EHGNYrG5dROegqb9WUzfwcN1ho9UNc55vSWQvc2Af0=.47fcaf76-9b41-4f55-8140-1d7b98bd930b@github.com>
Message-ID: <sfpAZ9gHY9Kx1AQM8qyHw8jtMSwCW2FdrF8kREVJ3Y0=.8816b9eb-00d3-4784-8f05-ea37718be8fa@github.com>

On Wed, 1 Jun 2022 03:01:35 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move jni/nullCaller tests to jdk_lang group

test/jdk/jni/nullCaller/exeNullCallerTest.cpp line 27:

> 25: 
> 26: /* Test for JDK-8280902
> 27:  * ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame

This comment isn't correct.  `ResourceBundle::getBundle` defaults to the system class loader if invoked by a null caller and I don't expect it may throw NPE.   Looks like you copy the summary of the JBS issue here, which isn't helpful to the readers.    I expect it a description of the test case.

Same comments to all other test cases.

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

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

From bpb at openjdk.java.net  Wed Jun  1 17:18:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 17:18:36 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v15]
In-Reply-To: <-AP9X7rJrdRJzS6F4qxlReVZIxw07fwXTgoCiV1B2O4=.6f21a7da-522c-4a91-8c4e-7a2a5a6be853@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <-AP9X7rJrdRJzS6F4qxlReVZIxw07fwXTgoCiV1B2O4=.6f21a7da-522c-4a91-8c4e-7a2a5a6be853@github.com>
Message-ID: <Xh56hlq-UAp0N4A9UiE3uob2p3yELPB25lR04u6xhRc=.0947a395-badf-45ba-8d29-368d0b23adcd@github.com>

On Wed, 1 Jun 2022 10:37:23 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

I think it's time for this excellent work to advance.

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

Marked as reviewed by bpb (Reviewer).

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

From tprinzing at openjdk.java.net  Wed Jun  1 17:20:24 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 17:20:24 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v7]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <l5GVl_4BlCXWrmaAE_4vVujeju3GcQ885lb9spQ_UrU=.de7cb409-acae-4fbe-a23f-16526b1a9ecd@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

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

  formatting cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/8bf4f597..865713fc

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

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

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

From smarks at openjdk.java.net  Wed Jun  1 17:37:34 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 1 Jun 2022 17:37:34 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <VKRNghK623T-nMkiS7j_8DfYfdjPBu6tCIhs1x7FaqU=.61db834f-12be-446c-a7d6-8523727ba920@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 441:

> 439:         }
> 440:     }
> 441: 

This unifies the test cases between the Set and Map factories, which accomplishes the primary goal. Good.

The unification is achieved through classic object-oriented polymorphism, which works fine, though which is rather verbose. This could probably be reduced with some tinkering on the model, but it's probably reaching the point where additional tinkering on the model isn't worth it. I'm ok with sticking with this approach for now. Maybe we can clean it up later, or maybe not -- it's at least fairly straightforward.

One issue that contributes to the verbosity is the repeated null checking. The null checking enables the test code to proceed and end up with -1 as the capacity if there's a null in there somewhere. This will cause the assertion to fail. This is good in that it will call attention to itself (as opposed to silently passing or something). However, if the test cases are set up properly, they should never run into null. If the null checking weren't done, an unexpected null will throw NPE, which will be caught be the framework and reported as an error.

That seems perfectly fine to me, so I'd suggest simply removing the null checking. That would also reduce the bulkiness of infrastructure.

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

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

From smarks at openjdk.java.net  Wed Jun  1 17:44:24 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 1 Jun 2022 17:44:24 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <IhiEBcMA2Zj0IWKO4jNpbCdAYbNvKP-GlA2bcbU7Yo0=.670eea02-4f1a-48db-996b-1cec9c1438e0@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks.

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

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

From naoto at openjdk.java.net  Wed Jun  1 18:23:36 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 18:23:36 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v6]
In-Reply-To: <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
Message-ID: <kUXgFvtwanvyJcAJGensAv2-epjXAvnCNWocxGzn_hg=.75529805-e19a-4964-b545-8c383db5864e@github.com>

On Wed, 1 Jun 2022 13:32:36 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8285838: Cleanup of trailing whitespace
>  - 8285838: Corrected month comparison check for TZ DST

The machine has `/etc/localtime` pointing to `/usr/share/zoneinfo/GMT`, thus the system zone is `GMT`. However, for some reason, I cannot reproduce it on that machine any longer. Could be some inconsistency in my repo. Will test in our CI system and let you know the result later.

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

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

From naoto at openjdk.java.net  Wed Jun  1 18:31:34 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 18:31:34 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Reviewed i18n-related changes and they look good. One minor suggestion in `Calendar`, but that can be applied later.

src/java.base/share/classes/java/util/Calendar.java line 2648:

> 2646:             set.add("gregory");
> 2647:             set.add("buddhist");
> 2648:             set.add("japanese");

This can be replaced with `SET = Set.of("gregory", "buddhist", "japanese");`.

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

Marked as reviewed by naoto (Reviewer).

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

From bpb at openjdk.java.net  Wed Jun  1 18:42:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 18:42:36 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <dh6Twe_QhgR3NgCROm40Rj2oJfp5V0EseBOq_y5IFUE=.4179a789-9937-4779-83fc-6ba845c17667@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

`java.io` and `java.nio` look all right.

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

Marked as reviewed by bpb (Reviewer).

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

From xuelei at openjdk.java.net  Wed Jun  1 19:17:02 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 1 Jun 2022 19:17:02 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC
Message-ID: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>

This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

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

Commit messages:
 - Remove trailing white space
 - 8287596: Reorg jdk.test.lib.util.ForceGC

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

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

From tprinzing at openjdk.java.net  Wed Jun  1 19:27:33 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 19:27:33 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v8]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <wdBGPAUgqbyql-GBG_9SWAQ6gIZuB-yABvYPZ5tv3XQ=.6372127f-109e-41ab-984c-082f696139a8@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

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

  comment changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/865713fc..30fd6e27

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

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

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

From mchung at openjdk.java.net  Wed Jun  1 19:43:44 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 19:43:44 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v8]
In-Reply-To: <wdBGPAUgqbyql-GBG_9SWAQ6gIZuB-yABvYPZ5tv3XQ=.6372127f-109e-41ab-984c-082f696139a8@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <wdBGPAUgqbyql-GBG_9SWAQ6gIZuB-yABvYPZ5tv3XQ=.6372127f-109e-41ab-984c-082f696139a8@github.com>
Message-ID: <nl_TmYMZl_GbCC_C1k9mlHEYDgI9yDLW99Wg2rpLIXI=.e98eb701-6a1e-445e-9c72-0aa804557a98@github.com>

On Wed, 1 Jun 2022 19:27:33 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment changes

Marked as reviewed by mchung (Reviewer).

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

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

From erikj at openjdk.java.net  Wed Jun  1 20:00:18 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 1 Jun 2022 20:00:18 GMT
Subject: RFR: 8233269: Improve handling of JAVA_ARGS
In-Reply-To: <sc-pQEHJQmawDVFDNrb-zV1SvlQTgY27QvJ-aWmDT14=.8865939e-2223-4e3b-ad61-17f9bdff0c34@github.com>
References: <sc-pQEHJQmawDVFDNrb-zV1SvlQTgY27QvJ-aWmDT14=.8865939e-2223-4e3b-ad61-17f9bdff0c34@github.com>
Message-ID: <E2fGfqc49pRvwC-SaQuW2SXfUaVkzuf9Tz5vfNXf4z8=.12324691-f76a-4714-944f-125ff89c80fb@github.com>

On Wed, 1 Jun 2022 13:52:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LauncherCommon.gmk is unfortunately defining JAVA_ARGS with `-J-ms8m` option for all JDK launchers, including java launcher.
> JAVA_ARGS  should not be defined for java launcher (in contrast to the other JDK launchers), and the command line option `-J-ms8m` is obsolete for java launcher.
> 
> Proposed patch removes JAVA_ARGS from java launcher, while keeping status quo for all other JDK launchers.
> The patch of LauncherCommon.gmk identifies java launcher by undefined MAIN_CLASS.
> 
> Thanks for review,
> Adam

Marked as reviewed by erikj (Reviewer).

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

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

From aturbanov at openjdk.java.net  Wed Jun  1 20:47:59 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 1 Jun 2022 20:47:59 GMT
Subject: RFR: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
Message-ID: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>

Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

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

Commit messages:
 - [PATCH] Avoid redundant Hashtable.containsKey call in JarVerifier

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

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

From mchung at openjdk.java.net  Wed Jun  1 20:49:32 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 20:49:32 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <2ELftDwTR4QUu5qIRT8uVYbe5YhDizwh1PAjyBhqmgg=.99c6e51e-53eb-4068-8d5a-3d05e23f4e3c@github.com>

On Wed, 1 Jun 2022 19:08:03 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

JDK-8287384 causes `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` to timeout when running with fastdebug VM.  I think this might be caused by more frequent GCs.

I tried your patch and the test fails.

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

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

From mchung at openjdk.java.net  Wed Jun  1 20:55:23 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 20:55:23 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v2]
In-Reply-To: <9Z7D5OqiJILYAXkjvBT3mphDB97T2osJ4Z7TcB9FnTw=.c4f95352-bffd-4f22-8dde-66259e0905e6@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <9Z7D5OqiJILYAXkjvBT3mphDB97T2osJ4Z7TcB9FnTw=.c4f95352-bffd-4f22-8dde-66259e0905e6@github.com>
Message-ID: <YCPd8o6zWSFN2-317zj2aiJ8pOpa28pDFFmNkTRVVoY=.78631be7-6191-4f70-9b5d-9160bf33580d@github.com>

On Mon, 30 May 2022 20:23:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
>> 
>> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
>> 
>> | Build      |    # classes    |   Runtime   |
>> | ----------- | ----------------- |  --------------- |
>> | Baseline |     31119       |     2.942s     |
>> | Patch      |     16208       |     1.958s     |
>> 
>> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
>> 
>> Baseline:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
>> 
>> This patch:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor stylistic cleanup

src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 204:

> 202:         static BasicType basicType(Class<?> type) {
> 203:             if (!type.isPrimitive())  return L_TYPE;
> 204:             return basicType(Wrapper.forPrimitiveType(type).basicTypeChar());

Suggestion:

            return basicType(Wrapper.basicTypeChar(type));

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

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

From mchung at openjdk.java.net  Wed Jun  1 20:55:24 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 20:55:24 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v4]
In-Reply-To: <oy0ef3mKlEiVTnaxdMVZX_8Yn0nrKpzoMPcU0eEHMlM=.728dfb2e-4cd5-4ae5-bc85-91114f4fc913@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <oy0ef3mKlEiVTnaxdMVZX_8Yn0nrKpzoMPcU0eEHMlM=.728dfb2e-4cd5-4ae5-bc85-91114f4fc913@github.com>
Message-ID: <0Q_mYz0a2AdCVtOS9lDAWFfVQQ8tKoyvCsP8nbejRmQ=.68096587-5683-4530-b0ea-804b048956e8@github.com>

On Wed, 1 Jun 2022 13:31:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
>> 
>> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
>> 
>> | Build      |    # classes    |   Runtime   |
>> | ----------- | ----------------- |  --------------- |
>> | Baseline |     31119       |     2.942s     |
>> | Patch      |     16208       |     1.958s     |
>> 
>> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
>> 
>> Baseline:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
>> 
>> This patch:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments from @ExE-Boss

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 459:

> 457:             String prefix = constants.get(0);
> 458:             if (prefix == null) {
> 459:                 if (suffix == null) {

Is it possible for prefix or suffix an empty string (non-null)?   The original code checks `if (constant.isEmpty())`

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

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

From xuelei at openjdk.java.net  Wed Jun  1 21:07:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 1 Jun 2022 21:07:16 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  back to wait 1 second

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8979/files
  - new: https://git.openjdk.java.net/jdk/pull/8979/files/a1d91596..f3d9eb82

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

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

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

From xuelei at openjdk.java.net  Wed Jun  1 21:07:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 1 Jun 2022 21:07:16 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC
In-Reply-To: <2ELftDwTR4QUu5qIRT8uVYbe5YhDizwh1PAjyBhqmgg=.99c6e51e-53eb-4068-8d5a-3d05e23f4e3c@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <2ELftDwTR4QUu5qIRT8uVYbe5YhDizwh1PAjyBhqmgg=.99c6e51e-53eb-4068-8d5a-3d05e23f4e3c@github.com>
Message-ID: <PF7YCImYJSiNfNDKpvjs63RfmL_biEmXYVp9l_Q74BU=.00248df8-4596-4c25-9464-52de009462b5@github.com>

On Wed, 1 Jun 2022 20:45:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> JDK-8287384 causes `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` to timeout when running with fastdebug VM. I think this might be caused by more frequent GCs.
> 
> I tried your patch and the test fails.

I updated the waiting time back to 1 second.  Would you please check again?

> JDK-8287384 causes `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` to timeout when running with fastdebug VM. I think this might be caused by more frequent GCs.
> 
> I tried your patch and the test fails.

I updated the waiting time back to 1 second.  Would you please check again?

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

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

From redestad at openjdk.java.net  Wed Jun  1 21:10:32 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 1 Jun 2022 21:10:32 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v4]
In-Reply-To: <0Q_mYz0a2AdCVtOS9lDAWFfVQQ8tKoyvCsP8nbejRmQ=.68096587-5683-4530-b0ea-804b048956e8@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <oy0ef3mKlEiVTnaxdMVZX_8Yn0nrKpzoMPcU0eEHMlM=.728dfb2e-4cd5-4ae5-bc85-91114f4fc913@github.com>
 <0Q_mYz0a2AdCVtOS9lDAWFfVQQ8tKoyvCsP8nbejRmQ=.68096587-5683-4530-b0ea-804b048956e8@github.com>
Message-ID: <mG_Xhj2zWyWxYirDsxf3g_Cbpp4KZ7xiHJrSSeNcJhk=.1b317d7e-3495-4902-9822-c171ef690d23@github.com>

On Wed, 1 Jun 2022 20:51:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments from @ExE-Boss
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 459:
> 
>> 457:             String prefix = constants.get(0);
>> 458:             if (prefix == null) {
>> 459:                 if (suffix == null) {
> 
> Is it possible for prefix or suffix an empty string (non-null)?   The original code checks `if (constant.isEmpty())`

No: Empty string constants would lead to adding a null to the list of constants in the prologue.

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

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

From mchung at openjdk.java.net  Wed Jun  1 21:12:21 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 21:12:21 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
Message-ID: <-revOIfNpbv7XdgrgMTcDwev4E8Px4P6rsage5ucfp0=.61219114-3b76-4610-9faf-af49d34a87fd@github.com>

On Wed, 1 Jun 2022 21:07:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   back to wait 1 second

No, it doesn't work.  You can build a fastdebug build with `configure --enable-debug`.  I reproduce it on macOS.   If I restore to the previous version without 8287384, the test passes.

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

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

From redestad at openjdk.java.net  Wed Jun  1 21:17:41 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 1 Jun 2022 21:17:41 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v5]
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <ef8Fn4vmA8Z4FtgeDacIXEBZIfh7c7EQ9VVFUG40ZfM=.dbb21d62-9ffb-4734-b477-097d02566cc9@github.com>

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

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

 - Mandy review comment #1: Cleanup LF.basicType a bit more.
 - Cleanup too generic String.valueOf lookups

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8855/files
  - new: https://git.openjdk.java.net/jdk/pull/8855/files/f1742a84..56bdc4c4

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

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

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

From mchung at openjdk.java.net  Wed Jun  1 21:17:43 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 21:17:43 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v4]
In-Reply-To: <oy0ef3mKlEiVTnaxdMVZX_8Yn0nrKpzoMPcU0eEHMlM=.728dfb2e-4cd5-4ae5-bc85-91114f4fc913@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <oy0ef3mKlEiVTnaxdMVZX_8Yn0nrKpzoMPcU0eEHMlM=.728dfb2e-4cd5-4ae5-bc85-91114f4fc913@github.com>
Message-ID: <PzEVZCgV8t_8-BWRNXI42QDM9XMqm1I3oFPVZcPifh0=.e9817742-a768-4ef9-be2f-3dd9083a5388@github.com>

On Wed, 1 Jun 2022 13:31:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
>> 
>> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
>> 
>> | Build      |    # classes    |   Runtime   |
>> | ----------- | ----------------- |  --------------- |
>> | Baseline |     31119       |     2.942s     |
>> | Patch      |     16208       |     1.958s     |
>> 
>> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
>> 
>> Baseline:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
>> 
>> This patch:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments from @ExE-Boss

The reduction of the LF classes is promising.  This looks okay with me.   This PR would rely on testing to catch issues that are not easily caught through code review.

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

Marked as reviewed by mchung (Reviewer).

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

From redestad at openjdk.java.net  Wed Jun  1 21:17:46 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 1 Jun 2022 21:17:46 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v2]
In-Reply-To: <YCPd8o6zWSFN2-317zj2aiJ8pOpa28pDFFmNkTRVVoY=.78631be7-6191-4f70-9b5d-9160bf33580d@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <9Z7D5OqiJILYAXkjvBT3mphDB97T2osJ4Z7TcB9FnTw=.c4f95352-bffd-4f22-8dde-66259e0905e6@github.com>
 <YCPd8o6zWSFN2-317zj2aiJ8pOpa28pDFFmNkTRVVoY=.78631be7-6191-4f70-9b5d-9160bf33580d@github.com>
Message-ID: <GKgi4QStJH2Pi34vPRD5_Q9sP4EPHaEdJcyrz-J2M0I=.a726938c-ddfc-4ff5-b0b2-ad9b4046a390@github.com>

On Tue, 31 May 2022 23:15:26 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor stylistic cleanup
>
> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 204:
> 
>> 202:         static BasicType basicType(Class<?> type) {
>> 203:             if (!type.isPrimitive())  return L_TYPE;
>> 204:             return basicType(Wrapper.forPrimitiveType(type).basicTypeChar());
> 
> Suggestion:
> 
>             return basicType(Wrapper.basicTypeChar(type));

I'll go one step further then and also remove the line before it too.

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

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

From rriggs at openjdk.java.net  Wed Jun  1 21:28:31 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Jun 2022 21:28:31 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v8]
In-Reply-To: <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
Message-ID: <GPrhQVdNs-gjQMu2Es0Gzj5YiClzoN7Fnb7-8gBgg7M=.9f5dccd2-063e-48a9-9d8f-285a0fd84ba9@github.com>

On Fri, 27 May 2022 22:09:22 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into remove-finalizers
>  - Threading-related fixes
>  - NOW it builds
>  - Fix the merge fix
>  - Fix merge
>  - Merge
>  - Rename inner class to EnumCtx ; use homeCtx() in AbstractLdapNamingEnumeration for consistencty ; new instance vars can be final
>  - fix whitespace
>  - Merge branch 'master' into remove-finalizers
>  - Test changes to test new cleaner code
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/ed8e8ac2...4af66bff

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 176:

> 174:             LdapResult newRes = homeCtx().getSearchReply(enumCtx.enumClnt, enumCtx.res);
> 175:             enumCtx.setRes(newRes);
> 176:             if (enumCtx.res == null) {

This looks odd, setting the value using synchronized, but reading it without.

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

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

From rriggs at openjdk.java.net  Wed Jun  1 21:47:31 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Jun 2022 21:47:31 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v8]
In-Reply-To: <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
Message-ID: <PFL3aPv2uvO_uKWB5HbM7KHJUBbMU1D-i-w2ZL-ZzmE=.f94c27c2-ca11-4e23-a930-6420f71f4793@github.com>

On Fri, 27 May 2022 22:09:22 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into remove-finalizers
>  - Threading-related fixes
>  - NOW it builds
>  - Fix the merge fix
>  - Fix merge
>  - Merge
>  - Rename inner class to EnumCtx ; use homeCtx() in AbstractLdapNamingEnumeration for consistencty ; new instance vars can be final
>  - fix whitespace
>  - Merge branch 'master' into remove-finalizers
>  - Test changes to test new cleaner code
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/ed8e8ac2...4af66bff

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 216:

> 214:         } finally {
> 215:             // Ensure Cleaner does not run until after this method completes
> 216:             Reference.reachabilityFence(this);

I don't think there is any benefit to the `try{} finally {fence}`.
The reachabilityFence has no executable code. Its only purpose is to keep the reference in scope alive.

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 409:

> 407:         } finally {
> 408:             // Ensure Cleaner does not run until after this method completes
> 409:             Reference.reachabilityFence(enumCtx);

Ditto, the try/finally is unnecessary.

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 440:

> 438:             listArg = ne.listArg;
> 439:         } finally {
> 440:             // Ensure Cleaner does not run until after this method completes

Ditto try/finally is unnecessary.

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

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

From darcy at openjdk.java.net  Wed Jun  1 21:51:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Jun 2022 21:51:42 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v15]
In-Reply-To: <-AP9X7rJrdRJzS6F4qxlReVZIxw07fwXTgoCiV1B2O4=.6f21a7da-522c-4a91-8c4e-7a2a5a6be853@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <-AP9X7rJrdRJzS6F4qxlReVZIxw07fwXTgoCiV1B2O4=.6f21a7da-522c-4a91-8c4e-7a2a5a6be853@github.com>
Message-ID: <atHuKA-uyzYJaNCi97kk2Em66MkSk3IMUZALzfCWAPY=.bcaeae32-d910-4869-ab7d-be78d0f9a92a@github.com>

On Wed, 1 Jun 2022 10:37:23 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

Marked as reviewed by darcy (Reviewer).

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

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

From duke at openjdk.java.net  Wed Jun  1 21:57:05 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 1 Jun 2022 21:57:05 GMT
Subject: Integrated: 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: <tihO_pLysYN2KZ9De3kndbgZQ2uLhfj57GqJsDTNu-M=.36d8034e-0a5a-4ee1-8244-48280da344fd@github.com>

On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Hello,
> 
> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
> 
> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
> 
> 
> Greetings
> Raffaello

This pull request has now been integrated.

Changeset: 72bcf2aa
Author:    Raffaello Giulietti <raffaello.giulietti at oracle.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/72bcf2aa03d53b0f68eb07a902575b4e8628d859
Stats:     4121 lines in 18 files changed: 4001 ins; 46 del; 74 mod

4511638: Double.toString(double) sometimes produces incorrect results

Reviewed-by: aturbanov, darcy, bpb

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

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

From sviswanathan at openjdk.java.net  Wed Jun  1 22:34:43 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 1 Jun 2022 22:34:43 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
Message-ID: <W1vfSjOi96GVQBbaO5lsuV4q1uNafDtpKEIOfLlE2Gg=.f24283d4-66f2-40d3-9f85-f0c038315914@github.com>

On Fri, 13 May 2022 08:58:12 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
>> 
>>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>>   ** missing constant: offsetInRange=Parm
>>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
>> 
>> 
>> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).
>
> You are right @PaulSandoz ! I ran the tests and benchmarks with your patch, and no failure and performance regression are found. I will update the patch soon. Thanks for the help!

@XiaohongGong Could you please rebase the branch and resolve conflicts?

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

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

From duke at openjdk.java.net  Wed Jun  1 22:53:14 2022
From: duke at openjdk.java.net (Chris Hennick)
Date: Wed, 1 Jun 2022 22:53:14 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v2]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <tLFnjsmh6nxUhe4loczFlRSfrId5nAolg3numbLsnxo=.9f749945-da45-4d0e-bd5d-916a4aec19e0@github.com>

> Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around 2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1); this fixes that by tracking the multiple of exponentialX0 as a long. (This changes the maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once `extra` reaches that amount, `x + extra == extra` due to the rounding error. This lowers the probability of reaching the maximum with an ideal PRNG from about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`).

Chris Hennick 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:

  Fix rounding error in computeNextExponential; use FMA
  
  Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution; this fixes that by tracking the multiple of exponentialX0 as a long.
  
  Add computeWinsorizedNextExponential for testability

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8131/files
  - new: https://git.openjdk.java.net/jdk/pull/8131/files/1fd959cc..fa340fb4

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

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

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

From duke at openjdk.java.net  Wed Jun  1 22:53:15 2022
From: duke at openjdk.java.net (Chris Hennick)
Date: Wed, 1 Jun 2022 22:53:15 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v2]
In-Reply-To: <nm1EHY6w6N2bcs7q8MylQmAg169c5jupAUbu6kVaZuc=.376dd38b-4f8c-447e-a079-06fa03b2b414@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GMGWQhNckhBCqioWrC4enqwuc-_w7QF349mOOcWNvzA=.c0e52085-98be-4401-8e13-2cb71536c0fa@github.com>
 <nm1EHY6w6N2bcs7q8MylQmAg169c5jupAUbu6kVaZuc=.376dd38b-4f8c-447e-a079-06fa03b2b414@github.com>
Message-ID: <25JHTcYsfLakiIJ519UylpghXRZ_5LO6aJjTPib5hyI=.682769e1-9106-4ef7-9404-9c4551829d9c@github.com>

On Mon, 23 May 2022 14:21:55 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1411:
>> 
>>> 1409:                 long U2 = (rng.nextLong() >>> 1);
>>> 1410:                 // Compute the actual x-coordinate of the randomly chosen point.
>>> 1411:                 x = Math.fma(X[j-1] - X[j], (double)U1, X[j] * 0x1.0p63));
>> 
>> Code is not compilable
>
> @Pr0methean As @turbanoff observes, I think there's a closing parentheses too much on L.1411 and one on L.1421.
> Which compiler are you using ;-)  ?

Should be fixed as of fa340fb47b1169805f21fb71cce0da3fc175d427. I haven't yet found a way for IntelliJ IDEA to use the project as its own JDK, so I've sanity-checked the syntax using the Rainbow Brackets plugin.

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

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

From duke at openjdk.java.net  Wed Jun  1 23:12:34 2022
From: duke at openjdk.java.net (Chris Hennick)
Date: Wed, 1 Jun 2022 23:12:34 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v2]
In-Reply-To: <25JHTcYsfLakiIJ519UylpghXRZ_5LO6aJjTPib5hyI=.682769e1-9106-4ef7-9404-9c4551829d9c@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GMGWQhNckhBCqioWrC4enqwuc-_w7QF349mOOcWNvzA=.c0e52085-98be-4401-8e13-2cb71536c0fa@github.com>
 <nm1EHY6w6N2bcs7q8MylQmAg169c5jupAUbu6kVaZuc=.376dd38b-4f8c-447e-a079-06fa03b2b414@github.com>
 <25JHTcYsfLakiIJ519UylpghXRZ_5LO6aJjTPib5hyI=.682769e1-9106-4ef7-9404-9c4551829d9c@github.com>
Message-ID: <ZGxJlLRDN4ACKSuwcA34PwXCJyRFECtdCtLx5X8_O8Y=.73876441-20fa-49fb-82f7-7b4624433b0f@github.com>

On Wed, 1 Jun 2022 22:49:01 GMT, Chris Hennick <duke at openjdk.java.net> wrote:

>> @Pr0methean As @turbanoff observes, I think there's a closing parentheses too much on L.1411 and one on L.1421.
>> Which compiler are you using ;-)  ?
>
> Should be fixed as of fa340fb47b1169805f21fb71cce0da3fc175d427. I haven't yet found a way for IntelliJ IDEA to use the project as its own JDK, so I've sanity-checked the syntax using the Rainbow Brackets plugin.

Update: successfully built `images` and `run-test-tier1` on my AL2 machine.

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

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

From hboehm at google.com  Thu Jun  2 01:19:29 2022
From: hboehm at google.com (Hans Boehm)
Date: Wed, 1 Jun 2022 18:19:29 -0700
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java
 finalizer to Cleaner [v8]
In-Reply-To: <PFL3aPv2uvO_uKWB5HbM7KHJUBbMU1D-i-w2ZL-ZzmE=.f94c27c2-ca11-4e23-a930-6420f71f4793@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
 <PFL3aPv2uvO_uKWB5HbM7KHJUBbMU1D-i-w2ZL-ZzmE=.f94c27c2-ca11-4e23-a930-6420f71f4793@github.com>
Message-ID: <CAMOCf+ixDEWgagFff0K+UgmKsfXH5iEGq7cDfzfbi0mXGSNzvQ@mail.gmail.com>

On Wed, Jun 1, 2022 at 2:47 PM Roger Riggs <rriggs at openjdk.java.net> wrote:

> ...
> > 214:         } finally {
> > 215:             // Ensure Cleaner does not run until after this method
> completes
> > 216:             Reference.reachabilityFence(this);
>
> I don't think there is any benefit to the `try{} finally {fence}`.
> The reachabilityFence has no executable code. Its only purpose is to keep
> the reference in scope alive.
>
> That's an interesting general question.

I agree that this is true with the right implementation assumptions, which
might conceivably be warranted here. But if there is a possibility that the
block throws after a point at which you need this to ensure reachability,
then I don't think this is spec-correct without the try-finally.  Consider

  tmp = a.field;
  use(field);  // Cleaner associated with a invalidates field
  if (moon_phase() == FULL) throw(...);
  Reference.reachabilityFence(a);

Consider the full moon case. The reachabilityFence spec says: "the
referenced object is not reclaimable by garbage collection at least until
after the invocation of this method." This method is not invoked, so there
is no guarantee, and hence this may fail.

And indeed, a compiler could conceivably rewrite this to

  if (moon_phase() != FULL) {
    tmp = a.field;
    use(field);  // Cleaner associated with a invalidates field
    Reference.reachabilityFence(a);
  } else {
    tmp = a.field;
    use(field);  // Cleaner associated with a invalidates field <--
potential crash
    throw(...);
  }

in which case this might, on very rare occasions, actually fail in the
throwing case, since the reference a may not be kept in the else clause.

Hans


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

From xgong at openjdk.java.net  Thu Jun  2 01:29:54 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 2 Jun 2022 01:29:54 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v3]
In-Reply-To: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
Message-ID: <z8emjRJh3LJXFKMfHJgm61Le01eenFzGzApO25zyH6s=.5553793a-5bd1-4fa8-8848-ae113223ffff@github.com>

> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
> 
> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
> 
> Benchmark                                   Before    After     Gain Units
> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
> 
> Similar performane gain can also be observed on ARM hardware.

Xiaohong Gong 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 'jdk:master' to JDK-8286279
 - Wrap the offset check into a static method
 - 8286279: [vectorapi] Only check index of masked lanes if offset is out of array boundary for masked store

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

Changes: https://git.openjdk.java.net/jdk/pull/8620/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8620&range=02
  Stats: 216 lines in 9 files changed: 179 ins; 0 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8620.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8620/head:pull/8620

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

From xgong at openjdk.java.net  Thu Jun  2 01:29:56 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 2 Jun 2022 01:29:56 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v2]
In-Reply-To: <1MDYeqST0lYsav_o10jKIr3Fgoqo1Fn9aKYP9kMpN0M=.0bc88db0-84b6-48d5-a021-2ba302a46d92@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
 <uJLpkCZdNUpfugjsnuUpiXQp29CS64WvqX98HsMMW-M=.9994429f-9e95-4cd9-b20f-7501cb647af1@github.com>
 <1MDYeqST0lYsav_o10jKIr3Fgoqo1Fn9aKYP9kMpN0M=.0bc88db0-84b6-48d5-a021-2ba302a46d92@github.com>
Message-ID: <vepoi3d1-ymntQ3SHpOsHgjhc8Z_qRRu39p9KYAAMJ4=.2ba7c6bd-5ee4-4713-bc3c-ee38095f1f04@github.com>

On Tue, 31 May 2022 16:48:27 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @PaulSandoz, could you please help to check whether the current version is ok for you? Thanks so much!
>
> @XiaohongGong looks good, now the Vector API JEP has been integrated you will get a merge conflict, but it should be easier to resolve.

Hi @PaulSandoz , I updated the patch and resolved the conflicts. Could you please take a look at it again? Thanks so much!

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

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

From xgong at openjdk.java.net  Thu Jun  2 01:52:35 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 2 Jun 2022 01:52:35 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
Message-ID: <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>

On Fri, 13 May 2022 08:58:12 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
>> 
>>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>>   ** missing constant: offsetInRange=Parm
>>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
>> 
>> 
>> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).
>
> You are right @PaulSandoz ! I ran the tests and benchmarks with your patch, and no failure and performance regression are found. I will update the patch soon. Thanks for the help!

> @XiaohongGong Could you please rebase the branch and resolve conflicts?

Sure, I'm working on this now. The patch will be updated soon. Thanks.

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

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

From duke at openjdk.java.net  Thu Jun  2 03:05:36 2022
From: duke at openjdk.java.net (Chris Hennick)
Date: Thu, 2 Jun 2022 03:05:36 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential; use
 Math.fma(); use bounded version in computeNextGaussian [v2]
In-Reply-To: <tLFnjsmh6nxUhe4loczFlRSfrId5nAolg3numbLsnxo=.9f749945-da45-4d0e-bd5d-916a4aec19e0@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <tLFnjsmh6nxUhe4loczFlRSfrId5nAolg3numbLsnxo=.9f749945-da45-4d0e-bd5d-916a4aec19e0@github.com>
Message-ID: <7m6K5gGQ5d7RT6B2NEs-yoTUf0MvFnHBYGliX-AzfTk=.2dc34336-0596-4ad6-b3ad-a453bbe54e55@github.com>

On Wed, 1 Jun 2022 22:53:14 GMT, Chris Hennick <duke at openjdk.java.net> wrote:

>> Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around 2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1); this fixes that by tracking the multiple of exponentialX0 as a long. (This changes the maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once `extra` reaches that amount, `x + extra == extra` due to the rounding error. This lowers the probability of reaching the maximum with an ideal PRNG from about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`).
>
> Chris Hennick 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:
> 
>   Fix rounding error in computeNextExponential; use FMA
>   
>   Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution; this fixes that by tracking the multiple of exponentialX0 as a long.
>   
>   Add computeWinsorizedNextExponential for testability

In addition to the changes discussed heretofore, I've also changed line 1382 to eliminate unneeded tail exploration; this should make `nextGaussian` faster at high percentiles (probably measurable at 99%ile; should definitely be measurable at  at 99.99%ile).

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

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

From xgong at openjdk.java.net  Thu Jun  2 03:27:59 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 2 Jun 2022 03:27:59 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>

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

Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'jdk:master' into JDK-8283667
 - Use integer constant for offsetInRange all the way through
 - Rename "use_predicate" to "needs_predicate"
 - Rename the "usePred" to "offsetInRange"
 - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

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

Changes: https://git.openjdk.java.net/jdk/pull/8035/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=04
  Stats: 447 lines in 43 files changed: 168 ins; 21 del; 258 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035

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

From xgong at openjdk.java.net  Thu Jun  2 03:28:00 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 2 Jun 2022 03:28:00 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
 <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>
Message-ID: <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>

On Thu, 2 Jun 2022 01:49:10 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > @XiaohongGong Could you please rebase the branch and resolve conflicts?
> 
> Sure, I'm working on this now. The patch will be updated soon. Thanks.

Resolved the conflicts. Thanks!

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

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

From almatvee at openjdk.java.net  Thu Jun  2 05:26:43 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 2 Jun 2022 05:26:43 GMT
Subject: RFR: 8286850: [macos] Add support for signing user provided app image
Message-ID: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>

- Added support for signing predefined application image.
 - Following command can be used to sign predefined application images: jpackage --type app-image --app-image Test.app --mac-sign [additional signing options]
 - Main class and if --mac-app-store was specified will be saved in .jpackage.xml. Both values are required for signing. Main class is to generate default identity and --mac-app-store to do correct signing for App Store.
 - Signing is done exactly same as when generating app bundle. Unsigned, signed or partially signed app images are supported. App image will be completely unsigned before signing.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8286850
 - 8286850: [macos] Add support for signing user provided app image

Changes: https://git.openjdk.java.net/jdk/pull/8987/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8987&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286850
  Stats: 960 lines in 27 files changed: 811 ins; 22 del; 127 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8987.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8987/head:pull/8987

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

From xuelei at openjdk.java.net  Thu Jun  2 05:35:32 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 2 Jun 2022 05:35:32 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
Message-ID: <nJiJ6AEz_kt36dwv6Sb0Pe8xdug2TiIjFzcTYW9V7_U=.cddd98f7-5514-4102-8226-17f34144cfdd@github.com>

On Wed, 1 Jun 2022 21:07:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   back to wait 1 second

My macOS (M1) and Linux (CentOS) may be too powerful to reproduce the failure.  I tried to set the JTREG time out to 60 seconds, and the timeout issue could be reproduced.  In `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java`, there are 6 calls to the method `assertFalse(unloader.tryUnload())`.  Each call to tryUnload() takes at least 10 seconds.  So the 6 calls takes 60 seconds at least.   If I set the regression timeout value to 70 seconds, the test still can pass.   It implies the rest part other than tryUnload() is pretty fast.

It looks like a regression introduced with the update for [JDK-8287384](https://bugs.openjdk.java.net/browse/JDK-8287384).  I did not fine the cause yet.  I will have more checking tomorrow.

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

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

From xuelei at openjdk.java.net  Thu Jun  2 05:50:20 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 2 Jun 2022 05:50:20 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v3]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <LT8QrMpAgzhJaOouM5JNYkTRnJbBynzthmuAmaZ7jiM=.586fdb8d-2429-4894-b79f-c90819bc5da6@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  rollback JDK-8287384

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8979/files
  - new: https://git.openjdk.java.net/jdk/pull/8979/files/f3d9eb82..a8768e09

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

  Stats: 55 lines in 1 file changed: 21 ins; 14 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

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

From xuelei at openjdk.java.net  Thu Jun  2 05:50:20 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 2 Jun 2022 05:50:20 GMT
Subject: Withdrawn: 8287596: Reorg jdk.test.lib.util.ForceGC
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <-ELnGoUjMMUsRA03S0T_LfBMH1hnO82BrJO6fcJN89c=.d38b34cb-d249-486a-b24c-97790578e5b7@github.com>

On Wed, 1 Jun 2022 19:08:03 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

This pull request has been closed without being integrated.

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

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

From asotona at openjdk.java.net  Thu Jun  2 06:24:32 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 2 Jun 2022 06:24:32 GMT
Subject: Integrated: 8233269: Improve handling of JAVA_ARGS
In-Reply-To: <sc-pQEHJQmawDVFDNrb-zV1SvlQTgY27QvJ-aWmDT14=.8865939e-2223-4e3b-ad61-17f9bdff0c34@github.com>
References: <sc-pQEHJQmawDVFDNrb-zV1SvlQTgY27QvJ-aWmDT14=.8865939e-2223-4e3b-ad61-17f9bdff0c34@github.com>
Message-ID: <sFEtcp4OVB-zBn2_b8DJC6clyizp6SaKGEjgojW2WqY=.55177867-1877-4ca3-be8c-5dcd2115a046@github.com>

On Wed, 1 Jun 2022 13:52:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LauncherCommon.gmk is unfortunately defining JAVA_ARGS with `-J-ms8m` option for all JDK launchers, including java launcher.
> JAVA_ARGS  should not be defined for java launcher (in contrast to the other JDK launchers), and the command line option `-J-ms8m` is obsolete for java launcher.
> 
> Proposed patch removes JAVA_ARGS from java launcher, while keeping status quo for all other JDK launchers.
> The patch of LauncherCommon.gmk identifies java launcher by undefined MAIN_CLASS.
> 
> Thanks for review,
> Adam

This pull request has now been integrated.

Changeset: a82417fa
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a82417fa190a132313f6734a75f1998858c164fd
Stats:     8 lines in 1 file changed: 4 ins; 1 del; 3 mod

8233269: Improve handling of JAVA_ARGS

Reviewed-by: erikj

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

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

From alanb at openjdk.java.net  Thu Jun  2 06:41:30 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 06:41:30 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v3]
In-Reply-To: <izG3NXAW6NwCwmQTofA082c5UWWdI7gfJe9gte1MHFY=.08f0d8a1-5c24-4f8c-bbd0-d334db7a9966@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
 <izG3NXAW6NwCwmQTofA082c5UWWdI7gfJe9gte1MHFY=.08f0d8a1-5c24-4f8c-bbd0-d334db7a9966@github.com>
Message-ID: <rUgQ27CwqqyovTcSRmPPnKVmoVfaxFQjFe0s2TMq77Q=.822ddd3c-5d0e-42db-87f0-b3b3651fabc8@github.com>

On Wed, 1 Jun 2022 06:26:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Fixed another typo in comment
>>  - Merge
>>  - Fix typos in comments
>>  - Allowing linking without intrinsic stub, contributed-by: rehn
>>  - Continuation clinit should fail if no continuations support
>>  - Fix merge issue with test
>>  - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
>>  - Update
>>  - Expend test coverage
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6
>
> src/java.base/share/classes/java/lang/Thread.java line 742:
> 
>> 740:      * @param name thread name, can be null
>> 741:      * @param characteristics thread characteristics
>> 742:      * @param bound true when bound to an OS thread
> 
> Nit: s/OS/VM/ ?

I think it would be confusing to use "VM" here. The intention is that "true" means the virtual thread will be bound to an OS thread once it has started. Yes, technically it's whatever the VM implements but I think that is too much to try to explain in the parameter description.

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

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

From mik3hall at gmail.com  Thu Jun  2 07:17:57 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 2 Jun 2022 02:17:57 -0500
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image
In-Reply-To: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
Message-ID: <1F5CF015-B805-43B4-AF77-80472F7C5054@gmail.com>


Thank you.


From duke at openjdk.java.net  Thu Jun  2 08:25:33 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 2 Jun 2022 08:25:33 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
In-Reply-To: <ylGELIu3MVU0JFX5lApPApYg0wQ6_X5-wZB3wSSgLKw=.9f9bebcc-8750-41f8-a4f3-93907b7ae837@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
 <DCfBtaWLqERj3BRvcqeJdPdOICLu8Bh48OnXyu8I7ig=.7b9e35af-e810-44be-aa81-c87dd026494c@github.com>
 <ylGELIu3MVU0JFX5lApPApYg0wQ6_X5-wZB3wSSgLKw=.9f9bebcc-8750-41f8-a4f3-93907b7ae837@github.com>
Message-ID: <PdaHqlgxfEyjktRzloppPJrZXS8eR15IDe0gnd5dyF0=.7de4b85f-5251-4ccf-8666-eb3ffb2333c5@github.com>

On Wed, 1 Jun 2022 08:39:44 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> not just ties
Plz. disregard this 3 words

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

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

From alanb at openjdk.java.net  Thu Jun  2 09:07:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 09:07:32 GMT
Subject: Integrated: 8287496: Alternative virtual thread implementation that
 maps to OS thread
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <yAA7004X8JTNUfpUTjv1JBp1c8kEgq3PdtdS_GQVtGI=.8606e198-0560-4119-a3c7-82dfb300b0ef@github.com>

On Sun, 29 May 2022 14:46:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

This pull request has now been integrated.

Changeset: 6ff2d89e
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6ff2d89ea11934bb13c8a419e7bad4fd40f76759
Stats:     747 lines in 72 files changed: 574 ins; 53 del; 120 mod

8287496: Alternative virtual thread implementation that maps to OS thread

Reviewed-by: rehn, mchung

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

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

From redestad at openjdk.java.net  Thu Jun  2 09:53:24 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 2 Jun 2022 09:53:24 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v6]
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <JEI91y4qjBGaMC65JNEo4_LXzdo3RLaGRM7y1YHj1-4=.76f4cb6b-2907-438f-b229-f6e03dcbca2f@github.com>

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

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

  Clarify that consts are always reduced to null, even if calling with constants. Also clarify that the number of constants is paramCount + 1 by refactoring to an array

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8855/files
  - new: https://git.openjdk.java.net/jdk/pull/8855/files/56bdc4c4..444cdd39

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

  Stats: 55 lines in 1 file changed: 15 ins; 13 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8855.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8855/head:pull/8855

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

From shade at openjdk.java.net  Thu Jun  2 09:58:37 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Jun 2022 09:58:37 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v3]
In-Reply-To: <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
Message-ID: <i5qtOVrZjpamRDsl8LE_YxezyL2v9JWHatlHjh1dISE=.0d920135-ce1b-492c-b031-c8c20881d2d0@github.com>

On Wed, 1 Jun 2022 06:04:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fixed another typo in comment
>  - Merge
>  - Fix typos in comments
>  - Allowing linking without intrinsic stub, contributed-by: rehn
>  - Continuation clinit should fail if no continuations support
>  - Fix merge issue with test
>  - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
>  - Update
>  - Expend test coverage
>  - Merge
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6

> A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

See #8990.

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

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

From dfuchs at openjdk.java.net  Thu Jun  2 10:33:19 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 2 Jun 2022 10:33:19 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <pBk0szIsy279wF9Amofquc9RB4SyYy1LkvBmdUdwFNU=.9c320114-bff4-4d0c-91ff-c56827cbf4d1@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Changes to `net` and `http` look good.

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

Marked as reviewed by dfuchs (Reviewer).

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

From aefimov at openjdk.java.net  Thu Jun  2 10:52:37 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 2 Jun 2022 10:52:37 GMT
Subject: RFR: 8287672: jtreg test
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
In-Reply-To: <Y3LKKXeWPYrjOsp6ndLH5bGfpnecF1SJq203Rd4iqjI=.a052a8d5-7870-4e48-9f38-3ebe19823251@github.com>
References: <Y3LKKXeWPYrjOsp6ndLH5bGfpnecF1SJq203Rd4iqjI=.a052a8d5-7870-4e48-9f38-3ebe19823251@github.com>
Message-ID: <WoO7u2c9WT15ipCnt853OFDvw7SxyEHc5pB1UNEWArM=.b478b77f-98bd-42d8-afe8-2915dcc64854@github.com>

On Wed, 1 Jun 2022 15:41:57 GMT, Rob McKenna <robm at openjdk.org> wrote:

> Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work.

Looks good to me ??

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

Marked as reviewed by aefimov (Committer).

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

From redestad at openjdk.java.net  Thu Jun  2 10:57:37 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 2 Jun 2022 10:57:37 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v7]
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <NhnsK8dZ5ld3l1nE0rKym0NRcNqkeBkw5ikoXP9hPmA=.a67abb59-08c2-49a0-bd46-8a6b2a918e75@github.com>

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

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

  We now don't need big Species classes for shorter concats, so on some tests the improvements meant more Species class generation. Adjusting HelloClasslist

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8855/files
  - new: https://git.openjdk.java.net/jdk/pull/8855/files/444cdd39..aaa442d5

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

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

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

From alanb at openjdk.java.net  Thu Jun  2 11:25:36 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 11:25:36 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v5]
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <oopQjIhFlclsuKBuKjqDTdd8zset_AHmTln1FZXV2Y0=.9b28ec8f-e71b-4e26-81dc-cf2a868fb963@github.com>

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

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

 - Add test directory to jdk_other so tests run in tier2
 - Merge
 - Fix typo in javadoc
 - Merge
 - Javadoc updates, add to jdk_loom test group
 - Add statement to close about thread termination
 - Use {@code ...}, replace task->subtask, fix typos, add jls ref
 - Merge
 - @ignore StructuredThreadDumpTest until test infra in place
 - Refresh
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/d40ed463...7f48656e

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8787/files
  - new: https://git.openjdk.java.net/jdk/pull/8787/files/d11b24bc..7f48656e

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

  Stats: 46596 lines in 447 files changed: 23349 ins; 17945 del; 5302 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8787/head:pull/8787

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

From rriggs at openjdk.java.net  Thu Jun  2 13:55:38 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Jun 2022 13:55:38 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v8]
In-Reply-To: <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
Message-ID: <9Gv1S_tRdhf88klOw-XN7F8KtUBTgQVXrjE41U57TtQ=.5a498b91-9526-4203-a351-e3109ab437fb@github.com>

On Fri, 27 May 2022 22:09:22 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into remove-finalizers
>  - Threading-related fixes
>  - NOW it builds
>  - Fix the merge fix
>  - Fix merge
>  - Merge
>  - Rename inner class to EnumCtx ; use homeCtx() in AbstractLdapNamingEnumeration for consistencty ; new instance vars can be final
>  - fix whitespace
>  - Merge branch 'master' into remove-finalizers
>  - Test changes to test new cleaner code
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/ed8e8ac2...4af66bff

Hans, thank for the detailed example. I had not fully considered the flow of control in the throwing case.

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

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

From duke at openjdk.java.net  Thu Jun  2 14:03:38 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 2 Jun 2022 14:03:38 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
Message-ID: <Ws2AqbtRShmtZ6W2BgbAzF_tHbEPiiNZ4Xcw0nlfEw8=.e19f2692-9aa8-4a1a-a441-d3dc728ef5e3@github.com>

On Fri, 27 May 2022 19:52:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments, eagerly convert sooner in tryFinally

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5462:

> 5460:         Objects.requireNonNull(target);
> 5461:         Objects.requireNonNull(newTypes);
> 5462:         return dropArgumentsToMatch(target, skip, newTypes.toArray(new Class<?>[0]).clone(), pos, false);

Do we really need to clone an array returned from `List.toArray()`? As far as I know from the JavaDoc of `List` if the passed array is not long enough to include all the items then the new array must be allocated. Here we always pass empty arrays, so the new ones are returned from `toArray()` method and we don't need `clone()`, right?

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

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

From dfuchs at openjdk.java.net  Thu Jun  2 14:29:26 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 2 Jun 2022 14:29:26 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <Ws2AqbtRShmtZ6W2BgbAzF_tHbEPiiNZ4Xcw0nlfEw8=.e19f2692-9aa8-4a1a-a441-d3dc728ef5e3@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
 <Ws2AqbtRShmtZ6W2BgbAzF_tHbEPiiNZ4Xcw0nlfEw8=.e19f2692-9aa8-4a1a-a441-d3dc728ef5e3@github.com>
Message-ID: <8FGyxpOq0tSnm78MjnJzMdYQSC17NaoesAgf_jipkB8=.4698511e-719d-4919-8bc3-355d626b6adb@github.com>

On Thu, 2 Jun 2022 13:59:50 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments, eagerly convert sooner in tryFinally
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5462:
> 
>> 5460:         Objects.requireNonNull(target);
>> 5461:         Objects.requireNonNull(newTypes);
>> 5462:         return dropArgumentsToMatch(target, skip, newTypes.toArray(new Class<?>[0]).clone(), pos, false);
> 
> Do we really need to clone an array returned from `List.toArray()`? As far as I know from the JavaDoc of `List` if the passed array is not long enough to include all the items then the new array must be allocated. Here we always pass empty arrays, so the new ones are returned from `toArray()` method and we don't need `clone()`, right?

The clone is needed - as the `List<Class<?>>` may be a custom implementation of List - so you cannot make any assumption on the concrete implementation of `toArray`.

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

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

From sgehwolf at openjdk.java.net  Thu Jun  2 14:40:58 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 2 Jun 2022 14:40:58 GMT
Subject: RFR: 8287663 Add a regression test for JDK-8287073
Message-ID: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>

This adds a regression test for a recent fix (JDK-8287073). I've restructured the linux specific JDK code to call a separate static function to enable this test. It'll help future tests too.

Testing:
- [x] Container tests continue to pass + GHA
- [x] New regression test fails prior the code fix of JDK-8287073 and passes with it

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

Commit messages:
 - 8287663 Add a regression test for JDK-8287073

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

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

From mkartashev at openjdk.java.net  Thu Jun  2 14:54:32 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 2 Jun 2022 14:54:32 GMT
Subject: RFR: 8287663 Add a regression test for JDK-8287073
In-Reply-To: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
References: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
Message-ID: <CBzbnugYuxNkZ-8mRrwlbQ7lv1a2NHXTiFxqKk1pNfM=.1353240c-cfd1-40f9-93aa-171abb1f421b@github.com>

On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This adds a regression test for a recent fix (JDK-8287073). I've restructured the linux specific JDK code to call a separate static function to enable this test. It'll help future tests too.
> 
> Testing:
> - [x] Container tests continue to pass + GHA
> - [x] New regression test fails prior the code fix of JDK-8287073 and passes with it

@jerboaa Thanks for taking care of the test! I'm not a reviewer, but FWIW the test looks good to me.

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

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

From duke at openjdk.java.net  Thu Jun  2 15:23:19 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 2 Jun 2022 15:23:19 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <8FGyxpOq0tSnm78MjnJzMdYQSC17NaoesAgf_jipkB8=.4698511e-719d-4919-8bc3-355d626b6adb@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
 <Ws2AqbtRShmtZ6W2BgbAzF_tHbEPiiNZ4Xcw0nlfEw8=.e19f2692-9aa8-4a1a-a441-d3dc728ef5e3@github.com>
 <8FGyxpOq0tSnm78MjnJzMdYQSC17NaoesAgf_jipkB8=.4698511e-719d-4919-8bc3-355d626b6adb@github.com>
Message-ID: <Xw1aGWPqTs6t3dyJr3T_U4JfIEFsXikfCZVVB4uQMnI=.092694a8-3e50-47b1-9bd7-a3e91dc4dd9b@github.com>

On Thu, 2 Jun 2022 14:25:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5462:
>> 
>>> 5460:         Objects.requireNonNull(target);
>>> 5461:         Objects.requireNonNull(newTypes);
>>> 5462:         return dropArgumentsToMatch(target, skip, newTypes.toArray(new Class<?>[0]).clone(), pos, false);
>> 
>> Do we really need to clone an array returned from `List.toArray()`? As far as I know from the JavaDoc of `List` if the passed array is not long enough to include all the items then the new array must be allocated. Here we always pass empty arrays, so the new ones are returned from `toArray()` method and we don't need `clone()`, right?
>
> The clone is needed - as the `List<Class<?>>` may be a custom implementation of List - so you cannot make any assumption on the concrete implementation of `toArray`.

But we can make an assumption on the behavior of particular method and the JavaDoc is clear about it. If a user passes an incorrect implementation of the `List` interface then it's their own responsibility.

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

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

From duke at openjdk.java.net  Thu Jun  2 16:15:20 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 2 Jun 2022 16:15:20 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <Xw1aGWPqTs6t3dyJr3T_U4JfIEFsXikfCZVVB4uQMnI=.092694a8-3e50-47b1-9bd7-a3e91dc4dd9b@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
 <Ws2AqbtRShmtZ6W2BgbAzF_tHbEPiiNZ4Xcw0nlfEw8=.e19f2692-9aa8-4a1a-a441-d3dc728ef5e3@github.com>
 <8FGyxpOq0tSnm78MjnJzMdYQSC17NaoesAgf_jipkB8=.4698511e-719d-4919-8bc3-355d626b6adb@github.com>
 <Xw1aGWPqTs6t3dyJr3T_U4JfIEFsXikfCZVVB4uQMnI=.092694a8-3e50-47b1-9bd7-a3e91dc4dd9b@github.com>
Message-ID: <s6kOX6E17taQh7OM5OjzCBeErVNBimeMXl3lwweGCKE=.640eec20-973f-4ff9-9f84-4a0dfd5c43c4@github.com>

On Thu, 2 Jun 2022 15:19:44 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> The clone is needed - as the `List<Class<?>>` may be a custom implementation of List - so you cannot make any assumption on the concrete implementation of `toArray`.
>
> But we can make an assumption on the behavior of particular method and the JavaDoc is clear about it. If a user passes an incorrect implementation of the `List` interface then it's their own responsibility.

We can't rule out malicious code holding the array reference it returns in toArray and updates that array to cause damage.

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

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

From tprinzing at openjdk.java.net  Thu Jun  2 16:49:33 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Jun 2022 16:49:33 GMT
Subject: Integrated: 8287171: Refactor null caller tests to a single directory
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <7EtpUri8E-MDJyVv5PR3FNvOMqe3pmxKrJ9G4tjXK5c=.c04e70d5-81f5-4dd1-ab6a-4f32d141ad1a@github.com>

On Sat, 28 May 2022 11:50:19 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

This pull request has now been integrated.

Changeset: e51ca1de
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e51ca1dee33d69c74f7f1dc2292db2f04c4ccf4c
Stats:     1303 lines in 19 files changed: 520 ins; 780 del; 3 mod

8287171: Refactor null caller tests to a single directory

Reviewed-by: ihse, mchung

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

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

From darcy at openjdk.java.net  Thu Jun  2 17:00:35 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Jun 2022 17:00:35 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>

> Time to start getting ready for JDK 20...

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

 - Update symbols for JDK 19 b25.
 - Merge branch 'master' into JDK-8284858
 - Adjust deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Respond to review feedback.
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7a25d65...e495a579

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/54e872b5..e495a579

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

  Stats: 7203 lines in 242 files changed: 5859 ins; 868 del; 476 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

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

From asemenyuk at openjdk.java.net  Thu Jun  2 17:25:50 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 2 Jun 2022 17:25:50 GMT
Subject: RFR: 8287125: [macos] Multiple jpackage tests fail/timeout on same
 host
In-Reply-To: <5-MS8JgYU2g0tklV4ccJGGdC1_LTP_RKPI2rTojZLW8=.a450b22c-32b4-4f61-ac1d-211767a03b8a@github.com>
References: <5-MS8JgYU2g0tklV4ccJGGdC1_LTP_RKPI2rTojZLW8=.a450b22c-32b4-4f61-ac1d-211767a03b8a@github.com>
Message-ID: <J0gMclvOnPhL-_4BDhdrSVY-QvwDqqokhKhB6DgeM0w=.f29cfe41-72d6-4f72-acb6-607a6d9b11f9@github.com>

On Fri, 27 May 2022 03:12:39 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Looks like regression from JDK-8277493. JDK-8277493 will always un-sign app image. Un-signing takes time since we enumerating all files and un-signing binaries one by one. Average increase 2-3 minutes for tests which generates multiple app images. Fixed by increasing timeout for reported tests.

Marked as reviewed by asemenyuk (Reviewer).

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

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

From asemenyuk at openjdk.java.net  Thu Jun  2 17:47:41 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 2 Jun 2022 17:47:41 GMT
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image
In-Reply-To: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
Message-ID: <r2TcYUqaeQpqqpRKr6ujL7QZH-ePQ2T5e-GpdaPZvzs=.5eb6ae6a-474c-4048-8b81-3c3518af3ca4@github.com>

On Thu, 2 Jun 2022 05:17:25 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added support for signing predefined application image.
>  - Following command can be used to sign predefined application images: jpackage --type app-image --app-image Test.app --mac-sign [additional signing options]
>  - Main class and if --mac-app-store was specified will be saved in .jpackage.xml. Both values are required for signing. Main class is to generate default identity and --mac-app-store to do correct signing for App Store.
>  - Signing is done exactly same as when generating app bundle. Unsigned, signed or partially signed app images are supported. App image will be completely unsigned before signing.

test/jdk/tools/jpackage/macosx/SigningAppImageTwoStepsTest.java line 69:

> 67:         SigningCheck.checkCertificates();
> 68: 
> 69:         Path appimageOutput = TKit.workDir().resolve("appimage");

This should be `TKit.createTempDirectory("appimage")` to allow subsequent invocations of the test to create a new "appimage" directory if the test work directory already contains "appimage" directory from the previous test run.

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

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

From naoto at openjdk.java.net  Thu Jun  2 18:09:43 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 2 Jun 2022 18:09:43 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v6]
In-Reply-To: <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
Message-ID: <hFv73VcpIbtvX371j7lSMPKZYTgIDPp0kqHrhMzCFRY=.a0d69f33-d35e-4214-8af6-2a0f2b32c027@github.com>

On Wed, 1 Jun 2022 13:32:36 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8285838: Cleanup of trailing whitespace
>  - 8285838: Corrected month comparison check for TZ DST

I tried several runs of CI tests and found no failures. Sorry for the false alarm. BTW, now I've looked the test more closely, the test can be simplified by using `SimpleTimeZone`, such as:

 new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0, Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(new Date())

This piece will check the current date is in DST, emulating `TZ=MEZ-1MESZ,M3.5.0,M10.5.0`

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

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

From asemenyuk at openjdk.java.net  Thu Jun  2 18:13:37 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 2 Jun 2022 18:13:37 GMT
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image
In-Reply-To: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
Message-ID: <OpTS4D66QzMTX3ALU5H077mvTT9staq0FhFw-oujkwI=.e582f692-a252-45a1-a0b4-cea589edaab5@github.com>

On Thu, 2 Jun 2022 05:17:25 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added support for signing predefined application image.
>  - Following command can be used to sign predefined application images: jpackage --type app-image --app-image Test.app --mac-sign [additional signing options]
>  - Main class and if --mac-app-store was specified will be saved in .jpackage.xml. Both values are required for signing. Main class is to generate default identity and --mac-app-store to do correct signing for App Store.
>  - Signing is done exactly same as when generating app bundle. Unsigned, signed or partially signed app images are supported. App image will be completely unsigned before signing.

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 672:

> 670:         return this;
> 671:     }
> 672: 

I guess the idea of this method is to prevent deletion of "." directory in `execute()` method when `--dest` argument of jpackage command is not set. We don't want "." directory deleted in any case. So instead of adding `noCleanupBeforeExec()` that makes sense only if `--dest` argument of jpackage command is not set, I'd rework the logic of `execute()` method and delete the output directory only when `--dest` argument is set.

test/jdk/tools/jpackage/macosx/SigningAppImageTwoStepsTest.java line 102:

> 100:                 .removeArgumentWithValue("--name")
> 101:                 .removeArgumentWithValue("--main-jar")
> 102:                 .removeArgumentWithValue("--main-class")

There is no point in calling `JPackageCommand.helloAppImage()` if later all arguments added by this call get deleted. Simply call JPackageCommand ctor instead.

test/jdk/tools/jpackage/share/jdk/jpackage/tests/PredefinedAppImageErrorTest.java line 59:

> 57:  *  --jpt-run=jdk.jpackage.tests.PredefinedAppImageErrorTest
> 58:  *  --jpt-before-run=jdk.jpackage.test.JPackageCommand.useToolProviderByDefault
> 59:  */

There is no  need to duplicate the whole jtreg test declaration, it supports multiple @run comments:

/*
 * @test
 * @summary Test jpackage output for erroneous input with --type "app-image" and --app-image
 * @library ../../../../helpers
 * @build jdk.jpackage.test.*
 * @modules jdk.jpackage/jdk.jpackage.internal
 * @compile PredefinedAppImageErrorTest.java
 * 
 * @run main/othervm/timeout=360 -Xmx512m jdk.jpackage.test.Main
 *  --jpt-run=jdk.jpackage.tests.PredefinedAppImageErrorTest
 *  --jpt-before-run=jdk.jpackage.test.JPackageCommand.useToolProviderByDefault
 * 
 * @run main/othervm/timeout=360 -Xmx512m jdk.jpackage.test.Main
 *  --jpt-run=jdk.jpackage.tests.PredefinedAppImageErrorTest
 *  --jpt-before-run=jdk.jpackage.test.JPackageCommand.useExecutableByDefault
 */

test/jdk/tools/jpackage/share/jdk/jpackage/tests/PredefinedAppImageErrorTest.java line 116:

> 114:         Path dummyAppFolder
> 115:             = TKit.workDir().resolve("DummyAppImage").toAbsolutePath();
> 116:         Files.createDirectory(dummyAppFolder);

Please use `TKit.createTempDirectory()` instead of `Files.createDirectory()` for the same reason as in `SigningAppImageTwoStepsTest.test()`

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

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

From duke at openjdk.java.net  Thu Jun  2 18:18:44 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Thu, 2 Jun 2022 18:18:44 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v6]
In-Reply-To: <hFv73VcpIbtvX371j7lSMPKZYTgIDPp0kqHrhMzCFRY=.a0d69f33-d35e-4214-8af6-2a0f2b32c027@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
 <hFv73VcpIbtvX371j7lSMPKZYTgIDPp0kqHrhMzCFRY=.a0d69f33-d35e-4214-8af6-2a0f2b32c027@github.com>
Message-ID: <4IqQwf-riLwaRfXuZg2TNxy72i2XnLYkp2rNlpwULS0=.6acd9f9e-80cd-440a-88e1-f4407460b573@github.com>

On Thu, 2 Jun 2022 18:07:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8285838: Cleanup of trailing whitespace
>>  - 8285838: Corrected month comparison check for TZ DST
>
> I tried several runs of CI tests and found no failures. Sorry for the false alarm. BTW, now I've looked the test more closely, the test can be simplified by using `SimpleTimeZone`, such as:
> 
>  new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0, Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(new Date())
> 
> This piece will check the current date is in DST, emulating `TZ=MEZ-1MESZ,M3.5.0,M10.5.0`

Hi @naotoj , 
Thanks for revisiting that and confirming it is all good. Initially the problem was brought to my attention through a third party client utilizing this particular TZ code, and that is where we got the basis for the need of the fix, where we are bypassing typical tzdb access to find named Timezones such as "Europe/Belgium" and trying to find the GMT offset and computing the time.

Is the suggestion here to substitute the setting of the TZ environment variable, and simply getting a date based off this `SimpleTimeZone` , so as to bypass the process creation and just have it as a more simpler test? This sounds perfectly fine as long as SimpleTimeZone is have the zone ID setup exactly as the `MEZ-1MESZ,M3.5.0,M10.5.0` indicated. I can try this out ... just wanted to confirm with you how to make use of the above instantiation.

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

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

From naoto at openjdk.java.net  Thu Jun  2 18:33:31 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 2 Jun 2022 18:33:31 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v6]
In-Reply-To: <4IqQwf-riLwaRfXuZg2TNxy72i2XnLYkp2rNlpwULS0=.6acd9f9e-80cd-440a-88e1-f4407460b573@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
 <hFv73VcpIbtvX371j7lSMPKZYTgIDPp0kqHrhMzCFRY=.a0d69f33-d35e-4214-8af6-2a0f2b32c027@github.com>
 <4IqQwf-riLwaRfXuZg2TNxy72i2XnLYkp2rNlpwULS0=.6acd9f9e-80cd-440a-88e1-f4407460b573@github.com>
Message-ID: <zhbMQ3qxxyCiL5aoDUHp5k8SC0F_wZTcQQOUsYBC-IY=.52014d9a-5cbf-4a1d-9e87-f21952c07e01@github.com>

On Thu, 2 Jun 2022 18:14:55 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

> Is the suggestion here to substitute the setting of the TZ environment variable, and simply getting a date based off this `SimpleTimeZone` , so as to bypass the process creation and just have it as a more simpler test?

No. The test process still has to be spawned with the TZ env variable set. The suggested piece is supposed to replace the following `if` in `runTZTest()` method:

        Calendar calendar = Calendar.getInstance();
        Date time = calendar.getTime();
        // Add 1 since getMonth() starts from 0.
        int month = time.getMonth() + 1;
        ZonedDateTime date = ZonedDateTime.ofInstant(time.toInstant(), ZoneId.systemDefault());
        if ((month > Month.MARCH.getValue() && month < Month.OCTOBER.getValue()) ||
                (month == Month.MARCH.getValue() && date.isAfter(getLastSundayOfMonth(date))) ||
                (month == Month.OCTOBER.getValue() && date.isBefore(getLastSundayOfMonth(date)))) {

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

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

From naoto at openjdk.java.net  Thu Jun  2 18:39:39 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 2 Jun 2022 18:39:39 GMT
Subject: Integrated: 8287340: Refactor old code using StringTokenizer in locale
 related code
In-Reply-To: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
Message-ID: <2HtX68mSoUnS33W_IV-wkJTMrM_WEmcmqLemJpLBpiM=.115f6c17-ae35-4a01-a3a7-4b8fa350ad9e@github.com>

On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

This pull request has now been integrated.

Changeset: 26d24263
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/26d24263c7db6d8f722afefc975b03cb575fa6ee
Stats:     177 lines in 4 files changed: 6 ins; 62 del; 109 mod

8287340: Refactor old code using StringTokenizer in locale related code

Reviewed-by: iris, joehw

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

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

From duke at openjdk.java.net  Thu Jun  2 18:52:33 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Thu, 2 Jun 2022 18:52:33 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v7]
In-Reply-To: <NhnsK8dZ5ld3l1nE0rKym0NRcNqkeBkw5ikoXP9hPmA=.a67abb59-08c2-49a0-bd46-8a6b2a918e75@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <NhnsK8dZ5ld3l1nE0rKym0NRcNqkeBkw5ikoXP9hPmA=.a67abb59-08c2-49a0-bd46-8a6b2a918e75@github.com>
Message-ID: <eUrJ3M2bKI3GgHUFYokUY224oH_U6ogJEodIm5BnXMw=.893791e0-e33d-46f6-96d0-dcbab2727221@github.com>

On Thu, 2 Jun 2022 10:57:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
>> 
>> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
>> 
>> | Build      |    # classes    |   Runtime   |
>> | ----------- | ----------------- |  --------------- |
>> | Baseline |     31119       |     2.942s     |
>> | Patch      |     16208       |     1.958s     |
>> 
>> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
>> 
>> Baseline:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
>> 
>> This patch:
>> 
>> Benchmark                                                      Mode  Cnt     Score      Error   Units
>> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We now don't need big Species classes for shorter concats, so on some tests the improvements meant more Species class generation. Adjusting HelloClasslist

make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 116:

> 114:         String CC     = "string" + c;
> 115:         String CCS    = "string" + c + s;
> 116:         String CSCC   = "string" + s + "string" + c;

I?m?pretty?sure that?`f` and?`c` will?be?inlined as?compile?time?constants in?the?String concat?recipes.

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

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

From mchung at openjdk.java.net  Thu Jun  2 19:10:44 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 2 Jun 2022 19:10:44 GMT
Subject: RFR: 8287746: ProblemList jni/nullCaller/NullCallerTest.java
Message-ID: <Pun9baBmjaImcFB4KiZBHtdoU-M_jZbO9Mel3y5PXys=.7ffb45ed-6681-4b92-b3cb-c2a065034b68@github.com>

8287746: ProblemList jni/nullCaller/NullCallerTest.java

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

Commit messages:
 - 8287746: ProblemList jni/nullCaller/NullCallerTest.java

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

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

From alanb at openjdk.java.net  Thu Jun  2 19:18:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 19:18:39 GMT
Subject: RFR: 8287746: ProblemList jni/nullCaller/NullCallerTest.java
In-Reply-To: <Pun9baBmjaImcFB4KiZBHtdoU-M_jZbO9Mel3y5PXys=.7ffb45ed-6681-4b92-b3cb-c2a065034b68@github.com>
References: <Pun9baBmjaImcFB4KiZBHtdoU-M_jZbO9Mel3y5PXys=.7ffb45ed-6681-4b92-b3cb-c2a065034b68@github.com>
Message-ID: <U8c-VOp12z1sT-edpVW10Jfoq9ju79L-SoaZIDaUnPA=.a5796bee-2ecf-4274-a9cb-8537b21b9dab@github.com>

On Thu, 2 Jun 2022 18:57:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> 8287746: ProblemList jni/nullCaller/NullCallerTest.java

Marked as reviewed by alanb (Reviewer).

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

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

From dcubed at openjdk.java.net  Thu Jun  2 19:18:41 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 2 Jun 2022 19:18:41 GMT
Subject: RFR: 8287746: ProblemList jni/nullCaller/NullCallerTest.java
In-Reply-To: <Pun9baBmjaImcFB4KiZBHtdoU-M_jZbO9Mel3y5PXys=.7ffb45ed-6681-4b92-b3cb-c2a065034b68@github.com>
References: <Pun9baBmjaImcFB4KiZBHtdoU-M_jZbO9Mel3y5PXys=.7ffb45ed-6681-4b92-b3cb-c2a065034b68@github.com>
Message-ID: <aAJlZpbNGLrqEK3AXP3zvXma8165VzniWbAehs__RW4=.9ef6f2f6-3af1-4212-ba11-cae10f765f42@github.com>

On Thu, 2 Jun 2022 18:57:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> 8287746: ProblemList jni/nullCaller/NullCallerTest.java

Marked as reviewed by dcubed (Reviewer).

test/jdk/ProblemList.txt line 500:

> 498: java/lang/invoke/lambda/LambdaFileEncodingSerialization.java    8249079 linux-x64
> 499: java/lang/invoke/RicochetTest.java                              8251969 generic-all
> 500: jni/nullCaller/NullCallerTest.java                              8287745 generic-all

Currently only fails on linux-x64, but that's in Tier1 so I don't know if it will
fail on other configs in higher tiers.

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

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

From mchung at openjdk.java.net  Thu Jun  2 19:18:43 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 2 Jun 2022 19:18:43 GMT
Subject: RFR: 8287746: ProblemList jni/nullCaller/NullCallerTest.java
In-Reply-To: <aAJlZpbNGLrqEK3AXP3zvXma8165VzniWbAehs__RW4=.9ef6f2f6-3af1-4212-ba11-cae10f765f42@github.com>
References: <Pun9baBmjaImcFB4KiZBHtdoU-M_jZbO9Mel3y5PXys=.7ffb45ed-6681-4b92-b3cb-c2a065034b68@github.com>
 <aAJlZpbNGLrqEK3AXP3zvXma8165VzniWbAehs__RW4=.9ef6f2f6-3af1-4212-ba11-cae10f765f42@github.com>
Message-ID: <yLpUWzutbS95RyVOCp9CyBKOl1xrvRbc6g74xdTXPko=.3e7d5c9d-3fbf-4d82-b042-980919778622@github.com>

On Thu, 2 Jun 2022 19:12:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> 8287746: ProblemList jni/nullCaller/NullCallerTest.java
>
> test/jdk/ProblemList.txt line 500:
> 
>> 498: java/lang/invoke/lambda/LambdaFileEncodingSerialization.java    8249079 linux-x64
>> 499: java/lang/invoke/RicochetTest.java                              8251969 generic-all
>> 500: jni/nullCaller/NullCallerTest.java                              8287745 generic-all
> 
> Currently only fails on linux-x64, but that's in Tier1 so I don't know if it will
> fail on other configs in higher tiers.

I tried to place safe to exclude it on all platforms.

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

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

From mchung at openjdk.java.net  Thu Jun  2 19:18:44 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 2 Jun 2022 19:18:44 GMT
Subject: Integrated: 8287746: ProblemList jni/nullCaller/NullCallerTest.java
In-Reply-To: <Pun9baBmjaImcFB4KiZBHtdoU-M_jZbO9Mel3y5PXys=.7ffb45ed-6681-4b92-b3cb-c2a065034b68@github.com>
References: <Pun9baBmjaImcFB4KiZBHtdoU-M_jZbO9Mel3y5PXys=.7ffb45ed-6681-4b92-b3cb-c2a065034b68@github.com>
Message-ID: <vDe2KG2xsJ2Ni2usyLp5tBKeA3W117ulpXfu65DiJo4=.01e46683-96fb-4d5a-a864-72b8928a690d@github.com>

On Thu, 2 Jun 2022 18:57:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> 8287746: ProblemList jni/nullCaller/NullCallerTest.java

This pull request has now been integrated.

Changeset: 37e1835b
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/37e1835be76f5f141ba0dc067578bfe767ca94ed
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8287746: ProblemList jni/nullCaller/NullCallerTest.java

Reviewed-by: alanb, dcubed

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

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

From redestad at openjdk.java.net  Thu Jun  2 20:05:23 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 2 Jun 2022 20:05:23 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v7]
In-Reply-To: <eUrJ3M2bKI3GgHUFYokUY224oH_U6ogJEodIm5BnXMw=.893791e0-e33d-46f6-96d0-dcbab2727221@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <NhnsK8dZ5ld3l1nE0rKym0NRcNqkeBkw5ikoXP9hPmA=.a67abb59-08c2-49a0-bd46-8a6b2a918e75@github.com>
 <eUrJ3M2bKI3GgHUFYokUY224oH_U6ogJEodIm5BnXMw=.893791e0-e33d-46f6-96d0-dcbab2727221@github.com>
Message-ID: <kK7QpOKeu7SFMPllNKn0Bjc-_b8hK720ekXoj322Ofo=.3f83600c-00de-4205-8c38-fee50d6d29e0@github.com>

On Thu, 2 Jun 2022 18:49:13 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   We now don't need big Species classes for shorter concats, so on some tests the improvements meant more Species class generation. Adjusting HelloClasslist
>
> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 116:
> 
>> 114:         String CC     = "string" + c;
>> 115:         String CCS    = "string" + c + s;
>> 116:         String CSCC   = "string" + s + "string" + c;
> 
> I?m?pretty?sure that?`f` and?`c` will?be?inlined as?compile?time?constants in?the?String concat?recipes.

You would think that, but javac doesn't do anything fancy once you store to a local

javap output for lines 108 through 111:

       449: ldc           #148                // float 0.1f
       451: fstore        31
       453: fload         31
       455: invokedynamic #149,  0            // InvokeDynamic #4:makeConcatWithConstants:(F)Ljava/lang/String;
       460: astore        32
       462: fload         31
       464: aload         4
       466: invokedynamic #152,  0            // InvokeDynamic #7:makeConcatWithConstants:(FLjava/lang/String;)Ljava/lang/String;
       471: astore        33
       473: aload         4
       475: fload         31
       477: invokedynamic #155,  0            // InvokeDynamic #10:makeConcatWithConstants:(Ljava/lang/String;F)Ljava/lang/String;

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

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

From mcimadamore at openjdk.java.net  Thu Jun  2 20:46:54 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Jun 2022 20:46:54 GMT
Subject: RFR: 8287748: Fix issues in java.lang.foreign package javadoc
Message-ID: <oHiBnQIaGbOeuPMGY1o-VPBPYV5X2YKEdgczyRHciHc=.b7733c53-917c-466b-8e39-d8d440c76ab1@github.com>

This patch fixes a couple of issues in the package-level javadoc of the foreign API.
I've also dropped uses of `var`, which I think are confusing so early in the game.

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

Commit messages:
 - Initial push

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

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

From iris at openjdk.java.net  Thu Jun  2 21:29:37 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 2 Jun 2022 21:29:37 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
In-Reply-To: <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
Message-ID: <JHtXFR9mN8psVmhAOvRFenF52uKdoxjuVefqcVw1M4s=.39da768e-4da9-4dc4-aad5-4b7460bef47b@github.com>

On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:
> 
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/5a6d202d...e495a579

Changes still look good.

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

Marked as reviewed by iris (Reviewer).

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

From almatvee at openjdk.java.net  Thu Jun  2 21:48:30 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 2 Jun 2022 21:48:30 GMT
Subject: Integrated: 8287125: [macos] Multiple jpackage tests fail/timeout on
 same host
In-Reply-To: <5-MS8JgYU2g0tklV4ccJGGdC1_LTP_RKPI2rTojZLW8=.a450b22c-32b4-4f61-ac1d-211767a03b8a@github.com>
References: <5-MS8JgYU2g0tklV4ccJGGdC1_LTP_RKPI2rTojZLW8=.a450b22c-32b4-4f61-ac1d-211767a03b8a@github.com>
Message-ID: <TfRby7X89KSgGfFSTwhiiQLyKrn6ks3UHQEx8Zq2VVU=.c30a8d84-0121-4432-a603-e08a17edbd1d@github.com>

On Fri, 27 May 2022 03:12:39 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Looks like regression from JDK-8277493. JDK-8277493 will always un-sign app image. Un-signing takes time since we enumerating all files and un-signing binaries one by one. Average increase 2-3 minutes for tests which generates multiple app images. Fixed by increasing timeout for reported tests.

This pull request has now been integrated.

Changeset: 409157d2
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/409157d2af0e124756bf8c0d996ba8658a9714b7
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8287125: [macos] Multiple jpackage tests fail/timeout on same host

Reviewed-by: asemenyuk

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

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

From sviswanathan at openjdk.java.net  Thu Jun  2 22:32:41 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Jun 2022 22:32:41 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
Message-ID: <Ln4gn237B93d4NmnHb8RXCcSIacUqYpLu6eMwJKFcLM=.4eaf44a7-c2a4-4d0e-84fd-d988d2b5904f@github.com>

On Thu, 2 Jun 2022 03:27:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

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

Marked as reviewed by sviswanathan (Reviewer).

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

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

From sviswanathan at openjdk.java.net  Thu Jun  2 22:32:42 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Jun 2022 22:32:42 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
 <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>
 <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>
Message-ID: <Z9-GLbZIT7wzq73_ua6b_JlddNTNYwwsQNnHxTPPULY=.79d8dfd4-834b-4a2f-9d8c-098f3854c9de@github.com>

On Thu, 2 Jun 2022 03:24:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> @XiaohongGong Could you please rebase the branch and resolve conflicts?
>> 
>> Sure, I'm working on this now. The patch will be updated soon. Thanks.
>
>> > @XiaohongGong Could you please rebase the branch and resolve conflicts?
>> 
>> Sure, I'm working on this now. The patch will be updated soon. Thanks.
> 
> Resolved the conflicts. Thanks!

@XiaohongGong You need one more review approval.

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

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

From jvernee at openjdk.java.net  Thu Jun  2 23:01:33 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 2 Jun 2022 23:01:33 GMT
Subject: RFR: 8287748: Fix issues in java.lang.foreign package javadoc
In-Reply-To: <oHiBnQIaGbOeuPMGY1o-VPBPYV5X2YKEdgczyRHciHc=.b7733c53-917c-466b-8e39-d8d440c76ab1@github.com>
References: <oHiBnQIaGbOeuPMGY1o-VPBPYV5X2YKEdgczyRHciHc=.b7733c53-917c-466b-8e39-d8d440c76ab1@github.com>
Message-ID: <ebWmhQN5KgZkvo0Id2LGqLCjQ2NJRBN3lSLwRV0epDE=.ad05e9ee-a814-497e-a970-4d8ec17d5061@github.com>

On Thu, 2 Jun 2022 20:41:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a couple of issues in the package-level javadoc of the foreign API.
> I've also dropped uses of `var`, which I think are confusing so early in the game.

Marked as reviewed by jvernee (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Fri Jun  3 00:21:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Jun 2022 00:21:31 GMT
Subject: Integrated: 8287748: Fix issues in java.lang.foreign package javadoc
In-Reply-To: <oHiBnQIaGbOeuPMGY1o-VPBPYV5X2YKEdgczyRHciHc=.b7733c53-917c-466b-8e39-d8d440c76ab1@github.com>
References: <oHiBnQIaGbOeuPMGY1o-VPBPYV5X2YKEdgczyRHciHc=.b7733c53-917c-466b-8e39-d8d440c76ab1@github.com>
Message-ID: <iWNVHax5Xu1Ugbx8Wris-_KveGMzJzVKFNIJPngWWuc=.244db717-f9d6-4093-8d72-6fd1e6f41dbc@github.com>

On Thu, 2 Jun 2022 20:41:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a couple of issues in the package-level javadoc of the foreign API.
> I've also dropped uses of `var`, which I think are confusing so early in the game.

This pull request has now been integrated.

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

8287748: Fix issues in java.lang.foreign package javadoc

Reviewed-by: jvernee

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

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

From tprinzing at openjdk.java.net  Fri Jun  3 01:27:59 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Fri, 3 Jun 2022 01:27:59 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the
 caller is null [v4]
In-Reply-To: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
Message-ID: <WoEi3uLFKaR5g3JVZ1hG47Fimh4WADDiFDveVzuEhuw=.3bcbed80-cd6d-48a8-aeea-5a534da210be@github.com>

> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Fixed the build of the native c++ test NullCallerTest to specify
   the c++ std library as part of the build.  Changed the test to
   use iostream instead of printf.  Enabled the test for Class::forName
   which is now located in test/jdk/jni/nullCaller (as part of the
   merge of JDK-8287171).
 - Merge branch 'master' into JDK-8281001
 - make javadoc consistent with other caller sensitve methods
 - Added javadoc comment
 - Merge branch 'master' into JDK-8281001
 - JDK-8281001 Examine the behavior of Class::forName if the caller is null

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

Changes: https://git.openjdk.java.net/jdk/pull/8711/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8711&range=03
  Stats: 19 lines in 5 files changed: 10 ins; 3 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

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

From almatvee at openjdk.java.net  Fri Jun  3 01:56:01 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 3 Jun 2022 01:56:01 GMT
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v2]
In-Reply-To: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
Message-ID: <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>

> - Added support for signing predefined application image.
>  - Following command can be used to sign predefined application images: jpackage --type app-image --app-image Test.app --mac-sign [additional signing options]
>  - Main class and if --mac-app-store was specified will be saved in .jpackage.xml. Both values are required for signing. Main class is to generate default identity and --mac-app-store to do correct signing for App Store.
>  - Signing is done exactly same as when generating app bundle. Unsigned, signed or partially signed app images are supported. App image will be completely unsigned before signing.

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

  8286850: [macos] Add support for signing user provided app image [v2]

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8987/files
  - new: https://git.openjdk.java.net/jdk/pull/8987/files/384738c1..65df10e9

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

  Stats: 37 lines in 3 files changed: 3 ins; 22 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8987.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8987/head:pull/8987

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

From almatvee at openjdk.java.net  Fri Jun  3 02:03:35 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 3 Jun 2022 02:03:35 GMT
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v3]
In-Reply-To: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
Message-ID: <hMF9dcg2vVVoI5odgJ9OQYIZSV8Mij7u7wIgE6uhYs4=.62d50496-2257-41e3-986f-e042daf75680@github.com>

> - Added support for signing predefined application image.
>  - Following command can be used to sign predefined application images: jpackage --type app-image --app-image Test.app --mac-sign [additional signing options]
>  - Main class and if --mac-app-store was specified will be saved in .jpackage.xml. Both values are required for signing. Main class is to generate default identity and --mac-app-store to do correct signing for App Store.
>  - Signing is done exactly same as when generating app bundle. Unsigned, signed or partially signed app images are supported. App image will be completely unsigned before signing.

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

  8286850: [macos] Add support for signing user provided app image [v3]

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8987/files
  - new: https://git.openjdk.java.net/jdk/pull/8987/files/65df10e9..598b576d

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

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

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

From almatvee at openjdk.java.net  Fri Jun  3 02:03:38 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 3 Jun 2022 02:03:38 GMT
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v2]
In-Reply-To: <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
Message-ID: <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>

On Fri, 3 Jun 2022 01:56:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added support for signing predefined application image.
>>  - Following command can be used to sign predefined application images: jpackage --type app-image --app-image Test.app --mac-sign [additional signing options]
>>  - Main class and if --mac-app-store was specified will be saved in .jpackage.xml. Both values are required for signing. Main class is to generate default identity and --mac-app-store to do correct signing for App Store.
>>  - Signing is done exactly same as when generating app bundle. Unsigned, signed or partially signed app images are supported. App image will be completely unsigned before signing.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286850: [macos] Add support for signing user provided app image [v2]

8286850: [macos] Add support for signing user provided app image [v2]
 - Fixed all comments from Alexey.
8286850: [macos] Add support for signing user provided app image [v3]
 - Fixed whitespace issues.

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

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

From xuelei at openjdk.java.net  Fri Jun  3 06:18:29 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 3 Jun 2022 06:18:29 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v4]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <9WrLY42PjdlE42K-lJ3bpc7s5cn758OHcPW7mSj9xW0=.ea88d631-b250-4ce8-a2f1-d7dd12c0ae78@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  rollback is not in this branch

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8979/files
  - new: https://git.openjdk.java.net/jdk/pull/8979/files/a8768e09..4a80db95

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

  Stats: 58 lines in 1 file changed: 17 ins; 24 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

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

From aturbanov at openjdk.java.net  Fri Jun  3 06:59:47 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 3 Jun 2022 06:59:47 GMT
Subject: RFR: 8287766: Unnecessary Vector usage in LdapClient
Message-ID: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>

In [JDK-8273098](https://bugs.openjdk.java.net/browse/JDK-8273098) I missed one place, where Vector could be replaced with ArrayList.
Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

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

Commit messages:
 - [PATCH] Unnecessary Vector usage in LdapClient

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

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

From dfuchs at openjdk.java.net  Fri Jun  3 08:31:32 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 3 Jun 2022 08:31:32 GMT
Subject: RFR: 8287766: Unnecessary Vector usage in LdapClient
In-Reply-To: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
References: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
Message-ID: <E1l2Ap36q5VtcF7GaEtxaDgQjjWnZkP4EQ4gz2zz-9U=.6df006af-cc4d-4529-ab11-d5b086e104b7@github.com>

On Sun, 29 May 2022 20:22:55 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> In [JDK-8273098](https://bugs.openjdk.java.net/browse/JDK-8273098) I missed one place, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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

From vtewari at openjdk.java.net  Fri Jun  3 08:53:32 2022
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Fri, 3 Jun 2022 08:53:32 GMT
Subject: RFR: 8287766: Unnecessary Vector usage in LdapClient
In-Reply-To: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
References: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
Message-ID: <4pIbyfjwud-jQfmx0jvq1HiAZ9OZ5tLQNLtEaxM7U7w=.d998bc67-32a2-464b-94a2-d432bdbd6bd4@github.com>

On Sun, 29 May 2022 20:22:55 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> In [JDK-8273098](https://bugs.openjdk.java.net/browse/JDK-8273098) I missed one place, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

Looks OK to me.

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

Marked as reviewed by vtewari (Committer).

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

From duke at openjdk.java.net  Fri Jun  3 11:22:33 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 3 Jun 2022 11:22:33 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v7]
In-Reply-To: <kK7QpOKeu7SFMPllNKn0Bjc-_b8hK720ekXoj322Ofo=.3f83600c-00de-4205-8c38-fee50d6d29e0@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <NhnsK8dZ5ld3l1nE0rKym0NRcNqkeBkw5ikoXP9hPmA=.a67abb59-08c2-49a0-bd46-8a6b2a918e75@github.com>
 <eUrJ3M2bKI3GgHUFYokUY224oH_U6ogJEodIm5BnXMw=.893791e0-e33d-46f6-96d0-dcbab2727221@github.com>
 <kK7QpOKeu7SFMPllNKn0Bjc-_b8hK720ekXoj322Ofo=.3f83600c-00de-4205-8c38-fee50d6d29e0@github.com>
Message-ID: <LV96km3NrBxlWCMQVDFxhTXfQc3uUfULRoqcGdZbbEE=.7198ffc7-b5ae-41b5-b744-e4b3dcf485d2@github.com>

On Thu, 2 Jun 2022 20:01:33 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 116:
>> 
>>> 114:         String CC     = "string" + c;
>>> 115:         String CCS    = "string" + c + s;
>>> 116:         String CSCC   = "string" + s + "string" + c;
>> 
>> I?m?pretty?sure that?`f` and?`c` will?be?inlined as?compile?time?constants in?the?String concat?recipes.
>
> You would think that, but javac doesn't do anything fancy once you store to a local
> 
> javap output for lines 108 through 111:
> 
>        449: ldc           #148                // float 0.1f
>        451: fstore        31
>        453: fload         31
>        455: invokedynamic #149,  0            // InvokeDynamic #4:makeConcatWithConstants:(F)Ljava/lang/String;
>        460: astore        32
>        462: fload         31
>        464: aload         4
>        466: invokedynamic #152,  0            // InvokeDynamic #7:makeConcatWithConstants:(FLjava/lang/String;)Ljava/lang/String;
>        471: astore        33
>        473: aload         4
>        475: fload         31
>        477: invokedynamic #155,  0            // InvokeDynamic #10:makeConcatWithConstants:(Ljava/lang/String;F)Ljava/lang/String;

I?guess it?only?happens for?`final`?locals.

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

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

From redestad at openjdk.java.net  Fri Jun  3 11:24:10 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 11:24:10 GMT
Subject: RFR: 8287785: Reduce runtime of java.lang.invoke microbenchmarks
Message-ID: <PZgf4z1DyIgjRrELDsPi3MFCr4ZOne0Ut62-5PN-Vms=.23b1464f-a2ca-46c6-8280-1a181891caf4@github.com>

- Add explicit run configurations to java.lang.invoke micros, aiming to reduce runtime while maintaining a decently high confidence that there's enough warmup to produce good enough data.

- Remove several trivial baseline micros, mainly those that only return a static object: It's reasonable to have baseline microbenchmarks when the baseline op is complex and you're mostly interested in checking the overhead of doing the same thing via some MH API, but blackhole operations are now shortcutting very quickly and timings doesn't differ from one type of object to another, so we don't need a multitude of such baseline tests.

Estimated runtime of `make test TEST=micro:java.lang.micro` (excluding build) drops from just above 28 to just above 3 hours.

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

Commit messages:
 - 8287785: Apply explicit run configuration to java.lang.invoke microbenchmarks

Changes: https://git.openjdk.java.net/jdk/pull/9012/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9012&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287785
  Stats: 429 lines in 47 files changed: 276 ins; 142 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9012.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9012/head:pull/9012

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

From redestad at openjdk.java.net  Fri Jun  3 12:19:34 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 12:19:34 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v7]
In-Reply-To: <LV96km3NrBxlWCMQVDFxhTXfQc3uUfULRoqcGdZbbEE=.7198ffc7-b5ae-41b5-b744-e4b3dcf485d2@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <NhnsK8dZ5ld3l1nE0rKym0NRcNqkeBkw5ikoXP9hPmA=.a67abb59-08c2-49a0-bd46-8a6b2a918e75@github.com>
 <eUrJ3M2bKI3GgHUFYokUY224oH_U6ogJEodIm5BnXMw=.893791e0-e33d-46f6-96d0-dcbab2727221@github.com>
 <kK7QpOKeu7SFMPllNKn0Bjc-_b8hK720ekXoj322Ofo=.3f83600c-00de-4205-8c38-fee50d6d29e0@github.com>
 <LV96km3NrBxlWCMQVDFxhTXfQc3uUfULRoqcGdZbbEE=.7198ffc7-b5ae-41b5-b744-e4b3dcf485d2@github.com>
Message-ID: <L7uyWB9wh35T-2_FiKayhFUWplsxSISigWfTjD8SiLI=.72d1d914-bd7d-49dd-ae69-1a6d8d3e517d@github.com>

On Fri, 3 Jun 2022 11:19:04 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> You would think that, but javac doesn't do anything fancy once you store to a local
>> 
>> javap output for lines 108 through 111:
>> 
>>        449: ldc           #148                // float 0.1f
>>        451: fstore        31
>>        453: fload         31
>>        455: invokedynamic #149,  0            // InvokeDynamic #4:makeConcatWithConstants:(F)Ljava/lang/String;
>>        460: astore        32
>>        462: fload         31
>>        464: aload         4
>>        466: invokedynamic #152,  0            // InvokeDynamic #7:makeConcatWithConstants:(FLjava/lang/String;)Ljava/lang/String;
>>        471: astore        33
>>        473: aload         4
>>        475: fload         31
>>        477: invokedynamic #155,  0            // InvokeDynamic #10:makeConcatWithConstants:(Ljava/lang/String;F)Ljava/lang/String;
>
> I?guess it?only?happens for?`final`?locals.

Yes, looks like javac does constant fold when the local is explicitly final:

		final float f = 0.1f;
		System.out.println("const folding? " + f);

javap:

         0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #3                  // String const folding? 0.1
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V


Maybe this constant folding is something javac could be enhanced to do on effectively final locals, though I think we can defer adjusting `HelloClasslist` to break that optimization when that time comes.

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

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

From duke at openjdk.java.net  Fri Jun  3 12:45:31 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 3 Jun 2022 12:45:31 GMT
Subject: RFR: 8287785: Reduce runtime of java.lang.invoke microbenchmarks
In-Reply-To: <PZgf4z1DyIgjRrELDsPi3MFCr4ZOne0Ut62-5PN-Vms=.23b1464f-a2ca-46c6-8280-1a181891caf4@github.com>
References: <PZgf4z1DyIgjRrELDsPi3MFCr4ZOne0Ut62-5PN-Vms=.23b1464f-a2ca-46c6-8280-1a181891caf4@github.com>
Message-ID: <wHmON3dB9ibfp60vBVjzAbW1-ZTfWhvSHe7tNDkHKSs=.cd21f75d-a335-44fe-b2c2-d6029c8c9377@github.com>

On Fri, 3 Jun 2022 11:16:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Add explicit run configurations to java.lang.invoke micros, aiming to reduce runtime while maintaining a decently high confidence that there's enough warmup to produce good enough data.
> 
> - Remove several trivial baseline micros, mainly those that only return a static object: It's reasonable to have baseline microbenchmarks when the baseline op is complex and you're mostly interested in checking the overhead of doing the same thing via some MH API, but blackhole operations are now shortcutting very quickly and timings doesn't differ from one type of object to another, so we don't need a multitude of such baseline tests.
> 
> Estimated runtime of `make test TEST=micro:java.lang.micro` (excluding build) drops from just above 28 to just above 3 hours.

test/micro/org/openjdk/bench/java/lang/invoke/LookupAcquire.java line 59:

> 57:     @Setup
> 58:     public void setup() {
> 59:         cached = MethodHandles.lookup();

Since the benchmark using the cached object is removed, should this field be removed as well?

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

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

From forax at univ-mlv.fr  Fri Jun  3 12:48:37 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 3 Jun 2022 14:48:37 +0200 (CEST)
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers
 in batches [v7]
In-Reply-To: <L7uyWB9wh35T-2_FiKayhFUWplsxSISigWfTjD8SiLI=.72d1d914-bd7d-49dd-ae69-1a6d8d3e517d@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
 <NhnsK8dZ5ld3l1nE0rKym0NRcNqkeBkw5ikoXP9hPmA=.a67abb59-08c2-49a0-bd46-8a6b2a918e75@github.com>
 <eUrJ3M2bKI3GgHUFYokUY224oH_U6ogJEodIm5BnXMw=.893791e0-e33d-46f6-96d0-dcbab2727221@github.com>
 <kK7QpOKeu7SFMPllNKn0Bjc-_b8hK720ekXoj322Ofo=.3f83600c-00de-4205-8c38-fee50d6d29e0@github.com>
 <LV96km3NrBxlWCMQVDFxhTXfQc3uUfULRoqcGdZbbEE=.7198ffc7-b5ae-41b5-b744-e4b3dcf485d2@github.com>
 <L7uyWB9wh35T-2_FiKayhFUWplsxSISigWfTjD8SiLI=.72d1d914-bd7d-49dd-ae69-1a6d8d3e517d@github.com>
Message-ID: <365705830.1569973.1654260517688.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Claes Redestad" <redestad at openjdk.java.net>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Friday, June 3, 2022 2:19:34 PM
> Subject: Re: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in batches [v7]

> On Fri, 3 Jun 2022 11:19:04 GMT, ExE Boss <duke at openjdk.java.net> wrote:
> 
>>> You would think that, but javac doesn't do anything fancy once you store to a
>>> local
>>> 
>>> javap output for lines 108 through 111:
>>> 
>>>        449: ldc           #148                // float 0.1f
>>>        451: fstore        31
>>>        453: fload         31
>>>        455: invokedynamic #149,  0            // InvokeDynamic
>>>        #4:makeConcatWithConstants:(F)Ljava/lang/String;
>>>        460: astore        32
>>>        462: fload         31
>>>        464: aload         4
>>>        466: invokedynamic #152,  0            // InvokeDynamic
>>>        #7:makeConcatWithConstants:(FLjava/lang/String;)Ljava/lang/String;
>>>        471: astore        33
>>>        473: aload         4
>>>        475: fload         31
>>>        477: invokedynamic #155,  0            // InvokeDynamic
>>>        #10:makeConcatWithConstants:(Ljava/lang/String;F)Ljava/lang/String;
>>
>> I?guess it?only?happens for?`final`?locals.
> 
> Yes, looks like javac does constant fold when the local is explicitly final:
> 
>		final float f = 0.1f;
>		System.out.println("const folding? " + f);
> 
> javap:
> 
>         0: getstatic     #2                  // Field
>         java/lang/System.out:Ljava/io/PrintStream;
>         3: ldc           #3                  // String const folding? 0.1
>         5: invokevirtual #4                  // Method
>         java/io/PrintStream.println:(Ljava/lang/String;)V
> 
> 
> Maybe this constant folding is something javac could be enhanced to do on
> effectively final locals, though I think we can defer adjusting
> `HelloClasslist` to break that optimization when that time comes.

The JLS defines final variables (and effectively final) here 
https://docs.oracle.com/javase/specs/jls/se18/html/jls-4.html#jls-4.12.4

Constant expressions does not list effectively final variables as constant, only final variables
https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29

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

regards,
R?mi

From redestad at openjdk.java.net  Fri Jun  3 12:53:38 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 12:53:38 GMT
Subject: RFR: 8287785: Reduce runtime of java.lang.invoke microbenchmarks
 [v2]
In-Reply-To: <PZgf4z1DyIgjRrELDsPi3MFCr4ZOne0Ut62-5PN-Vms=.23b1464f-a2ca-46c6-8280-1a181891caf4@github.com>
References: <PZgf4z1DyIgjRrELDsPi3MFCr4ZOne0Ut62-5PN-Vms=.23b1464f-a2ca-46c6-8280-1a181891caf4@github.com>
Message-ID: <pN4f0VvAXeAR6zVNqbG_Q4T0qH_tNIeIrtBjfdz4nZc=.ee79b386-eaf1-4242-95cd-c3de566a7af4@github.com>

> - Add explicit run configurations to java.lang.invoke micros, aiming to reduce runtime while maintaining a decently high confidence that there's enough warmup to produce good enough data.
> 
> - Remove several trivial baseline micros, mainly those that only return a static object: It's reasonable to have baseline microbenchmarks when the baseline op is complex and you're mostly interested in checking the overhead of doing the same thing via some MH API, but blackhole operations are now shortcutting very quickly and timings doesn't differ from one type of object to another, so we don't need a multitude of such baseline tests.
> 
> Estimated runtime of `make test TEST=micro:java.lang.micro` (excluding build) drops from just above 28 to just above 3 hours.

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

  Remove unused cached field in LookupAcquire

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9012/files
  - new: https://git.openjdk.java.net/jdk/pull/9012/files/f351ac70..0a1f7ec7

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

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

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

From redestad at openjdk.java.net  Fri Jun  3 12:53:40 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 12:53:40 GMT
Subject: RFR: 8287785: Reduce runtime of java.lang.invoke microbenchmarks
 [v2]
In-Reply-To: <wHmON3dB9ibfp60vBVjzAbW1-ZTfWhvSHe7tNDkHKSs=.cd21f75d-a335-44fe-b2c2-d6029c8c9377@github.com>
References: <PZgf4z1DyIgjRrELDsPi3MFCr4ZOne0Ut62-5PN-Vms=.23b1464f-a2ca-46c6-8280-1a181891caf4@github.com>
 <wHmON3dB9ibfp60vBVjzAbW1-ZTfWhvSHe7tNDkHKSs=.cd21f75d-a335-44fe-b2c2-d6029c8c9377@github.com>
Message-ID: <J8zKcKHZaEuX_vfcSf4DcJux50tJL9WovbQB-6zlMn8=.6a7b8e3f-60a2-4c47-92ba-f67b57706ee0@github.com>

On Fri, 3 Jun 2022 12:37:16 GMT, liach <duke at openjdk.java.net> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused cached field in LookupAcquire
>
> test/micro/org/openjdk/bench/java/lang/invoke/LookupAcquire.java line 59:
> 
>> 57:     @Setup
>> 58:     public void setup() {
>> 59:         cached = MethodHandles.lookup();
> 
> Since the benchmark using the cached object is removed, should this field be removed as well?

Fixed!

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

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

From redestad at openjdk.java.net  Fri Jun  3 12:58:05 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 12:58:05 GMT
Subject: RFR: 8287798: Reduce runtime in java.lang.reflect/runtime
 microbenchmarks
Message-ID: <NaBo8k0zTSOoSnLEf5Y02aM-Wk9VKdWKGKZs4-XUAL8=.9d68731f-95d7-43f9-ae6e-9aef656f68e8@github.com>

Add explicit run configurations to java.lang.reflect and .runtime micros, aiming to reduce runtime while maintaining a decently high confidence that there's enough warmup to produce good enough data.

Roughly halves runtime of running `java.lang.reflect|java.lang.runtime` from 159 to 78 minutes.

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

Commit messages:
 - Reduce runtime in java.lang.reflect/runtime microbenchmarks

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

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

From jvernee at openjdk.java.net  Fri Jun  3 14:59:37 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 3 Jun 2022 14:59:37 GMT
Subject: RFR: 8287798: Reduce runtime in java.lang.reflect/runtime
 microbenchmarks
In-Reply-To: <NaBo8k0zTSOoSnLEf5Y02aM-Wk9VKdWKGKZs4-XUAL8=.9d68731f-95d7-43f9-ae6e-9aef656f68e8@github.com>
References: <NaBo8k0zTSOoSnLEf5Y02aM-Wk9VKdWKGKZs4-XUAL8=.9d68731f-95d7-43f9-ae6e-9aef656f68e8@github.com>
Message-ID: <XXWWdbJILpbYOMEil_iJK3ru0DnLr0d61NTHNkvmqDA=.36d266a1-825a-4046-bfa9-c63a0b80331c@github.com>

On Fri, 3 Jun 2022 12:46:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Add explicit run configurations to java.lang.reflect and .runtime micros, aiming to reduce runtime while maintaining a decently high confidence that there's enough warmup to produce good enough data.
> 
> Roughly halves runtime of running `java.lang.reflect|java.lang.runtime` from 159 to 78 minutes.

Marked as reviewed by jvernee (Reviewer).

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

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

From redestad at openjdk.java.net  Fri Jun  3 15:12:12 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 15:12:12 GMT
Subject: RFR: 8287810: Reduce runtime of java.lang microbenchmarks
Message-ID: <4MFktMLic5pH0qFBPSPjy1HXpHuhoteAzYjBvo_dZPk=.63e4099c-1246-44ca-a16b-3445e84b6262@github.com>

- Reduce runtime by providing explicit configurations that try to run the micros as fast as possible while giving enough time for warmup.
- Remove some excessive parameters
- Remove some benchmarks testing experimental features (ObjectHashCode.mode_<non-default>) or were simply dubious at large (StringHttp)

This reduces runtime of running `java.lang.[A-Z]` (only java.lang, not java.lang.reflect etc..) from over 56 hours to 6:45.

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

Commit messages:
 - Reduce runtime of java.lang microbenchmarks

Changes: https://git.openjdk.java.net/jdk/pull/9015/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9015&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287810
  Stats: 293 lines in 39 files changed: 192 ins; 87 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9015.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9015/head:pull/9015

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

From raffaello.giulietti at oracle.com  Fri Jun  3 15:40:03 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 3 Jun 2022 15:40:03 +0000
Subject: RFR: [CSR] 8287376: BigDecimal(String) must allow a larger range for
 the exponent
Message-ID: <BY5PR10MB4002E5023FCA763637B6737E87A19@BY5PR10MB4002.namprd10.prod.outlook.com>

Hello,

anybody willing to review this small CSR?
https://bugs.openjdk.java.net/browse/JDK-8287376


Thanks
Raffaello

From jvernee at openjdk.java.net  Fri Jun  3 15:53:44 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 3 Jun 2022 15:53:44 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
Message-ID: <Ap4ltGR8lZizQgLoCIMG4wKBzX0ztEo0eGxOoEAYldo=.bf65f0a4-25b9-4485-b2ec-e110073d5459@github.com>

On Fri, 27 May 2022 19:52:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments, eagerly convert sooner in tryFinally

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5266:

> 5264:      */
> 5265:     public static MethodHandle dropArguments(MethodHandle target, int pos, List<Class<?>> valueTypes) {
> 5266:         return dropArguments(target, pos, valueTypes.toArray(new Class<?>[0]), false);

A bit unfortunate that we can't trust this `toArray` to do a copy. I was going to suggest Stream, but it has the same issue (someone might have a custom stream implementation).

I do think a manual copy of the array is possible by having a loop though:
Suggestion:

        Class<?>[] ptypes = new Class<?>[valueTypes.size()];
        for (int i = 0; i < ptypes.length; i++) {
            ptypes[i] = valueTypes.get(i);
        }
        return dropArguments(target, pos, ptypes, false);


(or, maybe extract such a loop to a helper method for clarity).

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5269:

> 5267:     }
> 5268: 
> 5269:     static MethodHandle dropArguments(MethodHandle target, int pos, Class<?>[] valueTypes, boolean trusted) {

Having a boolean that flips the behaviour makes it harder to know what that `true` or `false` literal at the call site does. I'd suggest splitting this into `dropArgumentsTrusted`, which doesn't clone the array, and `dropArguments` which always makes a copy (and the latter calls former). WDYT?

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

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

From jvernee at openjdk.java.net  Fri Jun  3 15:53:45 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 3 Jun 2022 15:53:45 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <Ap4ltGR8lZizQgLoCIMG4wKBzX0ztEo0eGxOoEAYldo=.bf65f0a4-25b9-4485-b2ec-e110073d5459@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
 <Ap4ltGR8lZizQgLoCIMG4wKBzX0ztEo0eGxOoEAYldo=.bf65f0a4-25b9-4485-b2ec-e110073d5459@github.com>
Message-ID: <kcxBs-gXeU7vs1bYro_HQDlUpIVECa2Om0vdnXz3pyA=.f1f5b862-f192-4b12-a6a1-870de55db00a@github.com>

On Fri, 3 Jun 2022 15:09:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments, eagerly convert sooner in tryFinally
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5266:
> 
>> 5264:      */
>> 5265:     public static MethodHandle dropArguments(MethodHandle target, int pos, List<Class<?>> valueTypes) {
>> 5266:         return dropArguments(target, pos, valueTypes.toArray(new Class<?>[0]), false);
> 
> A bit unfortunate that we can't trust this `toArray` to do a copy. I was going to suggest Stream, but it has the same issue (someone might have a custom stream implementation).
> 
> I do think a manual copy of the array is possible by having a loop though:
> Suggestion:
> 
>         Class<?>[] ptypes = new Class<?>[valueTypes.size()];
>         for (int i = 0; i < ptypes.length; i++) {
>             ptypes[i] = valueTypes.get(i);
>         }
>         return dropArguments(target, pos, ptypes, false);
> 
> 
> (or, maybe extract such a loop to a helper method for clarity).

The same could be done for the public `dropArgumentsToMatch` I think.

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

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

From asemenyuk at openjdk.java.net  Fri Jun  3 15:54:37 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 3 Jun 2022 15:54:37 GMT
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v3]
In-Reply-To: <hMF9dcg2vVVoI5odgJ9OQYIZSV8Mij7u7wIgE6uhYs4=.62d50496-2257-41e3-986f-e042daf75680@github.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <hMF9dcg2vVVoI5odgJ9OQYIZSV8Mij7u7wIgE6uhYs4=.62d50496-2257-41e3-986f-e042daf75680@github.com>
Message-ID: <uz_xUvOyh6d6Q2c9mR1aigR-TGpAFQG7-Sgcje4uCL0=.2e1e7362-c0bd-4f78-9f71-3a620ec91ec6@github.com>

On Fri, 3 Jun 2022 02:03:35 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added support for signing predefined application image.
>>  - Following command can be used to sign predefined application images: jpackage --type app-image --app-image Test.app --mac-sign [additional signing options]
>>  - Main class and if --mac-app-store was specified will be saved in .jpackage.xml. Both values are required for signing. Main class is to generate default identity and --mac-app-store to do correct signing for App Store.
>>  - Signing is done exactly same as when generating app bundle. Unsigned, signed or partially signed app images are supported. App image will be completely unsigned before signing.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286850: [macos] Add support for signing user provided app image [v3]

Marked as reviewed by asemenyuk (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Fri Jun  3 15:55:13 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Jun 2022 15:55:13 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
Message-ID: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>

This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).

I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).

`MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

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

Commit messages:
 - Add null check on Buffer::checkState
 - Add docs
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
 - Simplify readOnly check
 - Add @ForceInline in hot path from var handle access
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d5b6c7bd...68028fa4

Changes: https://git.openjdk.java.net/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9017&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287809
  Stats: 1752 lines in 39 files changed: 407 ins; 525 del; 820 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9017/head:pull/9017

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

From mcimadamore at openjdk.java.net  Fri Jun  3 15:55:13 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Jun 2022 15:55:13 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <AgqwxT-Tw5SRrC3fkr33yz5v709cCPjTuPTDYsdxpfQ=.68b76852-db8f-4aea-a185-abf8f460ece7@github.com>

On Fri, 3 Jun 2022 15:47:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Note: other cleanups are possible - such as flattening `ResourceList` into `MemorySession.State`. While that is possible, that's a tricky step, given that the session state can be registered against a cleaner. One option, which I explored, would be to use `MemorySessionImpl` for reachability - which then has an impact on `ScopedMemoryAccess`, as we would have to add reachability fences on the session, as well as on the session state. In any case, I'd like to proceed by steps, since this cleanup was already getting big enough.

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

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

From redestad at openjdk.java.net  Fri Jun  3 16:47:33 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 16:47:33 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <kcxBs-gXeU7vs1bYro_HQDlUpIVECa2Om0vdnXz3pyA=.f1f5b862-f192-4b12-a6a1-870de55db00a@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
 <Ap4ltGR8lZizQgLoCIMG4wKBzX0ztEo0eGxOoEAYldo=.bf65f0a4-25b9-4485-b2ec-e110073d5459@github.com>
 <kcxBs-gXeU7vs1bYro_HQDlUpIVECa2Om0vdnXz3pyA=.f1f5b862-f192-4b12-a6a1-870de55db00a@github.com>
Message-ID: <xdylQSlfFxdoGT_SlaYyIjUUgDt9y-9FeSjKIFS82qA=.e60783bd-34fc-432a-ba28-e21f189dfb0a@github.com>

On Fri, 3 Jun 2022 15:18:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5266:
>> 
>>> 5264:      */
>>> 5265:     public static MethodHandle dropArguments(MethodHandle target, int pos, List<Class<?>> valueTypes) {
>>> 5266:         return dropArguments(target, pos, valueTypes.toArray(new Class<?>[0]), false);
>> 
>> A bit unfortunate that we can't trust this `toArray` to do a copy. I was going to suggest Stream, but it has the same issue (someone might have a custom stream implementation).
>> 
>> I do think a manual copy of the array is possible by having a loop though:
>> Suggestion:
>> 
>>         Class<?>[] ptypes = new Class<?>[valueTypes.size()];
>>         for (int i = 0; i < ptypes.length; i++) {
>>             ptypes[i] = valueTypes.get(i);
>>         }
>>         return dropArguments(target, pos, ptypes, false);
>> 
>> 
>> (or, maybe extract such a loop to a helper method for clarity).
>
> The same could be done for the public `dropArgumentsToMatch` I think.

I'm not so sure. 

First of all we're no worse than before with the defensive copying here. Second of an optimizing compiler might theoretically be able to see that the array we get from the toArray is always fresh and not escaping anywhere in any well-behaved collection, so the clone could be elided. But if not then both toArray and clone are intrinsified operations that are heavily optimized and pretty fast even when interpreting, so emulating it with an external loop might end up taking more time even at peak. While likely taking longer to reach that peak. Using dumb, shared and common code (especially things that get JITted early anyhow) is nice in areas that see most action during startup/warmup.

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

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

From redestad at openjdk.java.net  Fri Jun  3 16:47:37 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 16:47:37 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <Ap4ltGR8lZizQgLoCIMG4wKBzX0ztEo0eGxOoEAYldo=.bf65f0a4-25b9-4485-b2ec-e110073d5459@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
 <Ap4ltGR8lZizQgLoCIMG4wKBzX0ztEo0eGxOoEAYldo=.bf65f0a4-25b9-4485-b2ec-e110073d5459@github.com>
Message-ID: <ykzQJeoJ_sQ7pmIt6HsWUVO6-SbXgK9sz3iCIYbQII8=.96eff23b-f89f-4db6-90fc-c7a9dcb18467@github.com>

On Fri, 3 Jun 2022 15:06:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments, eagerly convert sooner in tryFinally
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5269:
> 
>> 5267:     }
>> 5268: 
>> 5269:     static MethodHandle dropArguments(MethodHandle target, int pos, Class<?>[] valueTypes, boolean trusted) {
> 
> Having a boolean that flips the behaviour makes it harder to know what that `true` or `false` literal at the call site does. I'd suggest splitting this into `dropArgumentsTrusted`, which doesn't clone the array, and `dropArguments` which always makes a copy (and the latter calls former). WDYT?

Yeah, that sounds better.

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

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

From jvernee at openjdk.java.net  Fri Jun  3 16:52:35 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 3 Jun 2022 16:52:35 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <xdylQSlfFxdoGT_SlaYyIjUUgDt9y-9FeSjKIFS82qA=.e60783bd-34fc-432a-ba28-e21f189dfb0a@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
 <Ap4ltGR8lZizQgLoCIMG4wKBzX0ztEo0eGxOoEAYldo=.bf65f0a4-25b9-4485-b2ec-e110073d5459@github.com>
 <kcxBs-gXeU7vs1bYro_HQDlUpIVECa2Om0vdnXz3pyA=.f1f5b862-f192-4b12-a6a1-870de55db00a@github.com>
 <xdylQSlfFxdoGT_SlaYyIjUUgDt9y-9FeSjKIFS82qA=.e60783bd-34fc-432a-ba28-e21f189dfb0a@github.com>
Message-ID: <Lng4ANX-IUM2FCqebLoupvGMme1vHA8SPSH38RP8VL0=.f760d3c0-bb34-4298-8738-d499657cdd6f@github.com>

On Fri, 3 Jun 2022 16:43:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The same could be done for the public `dropArgumentsToMatch` I think.
>
> I'm not so sure. 
> 
> First of all we're no worse than before with the defensive copying here. Second of an optimizing compiler might theoretically be able to see that the array we get from the toArray is always fresh and not escaping anywhere in any well-behaved collection, so the clone could be elided. But if not then both toArray and clone are intrinsified operations that are heavily optimized and pretty fast even when interpreting, so emulating it with an external loop might end up taking more time even at peak. While likely taking longer to reach that peak. Using dumb, shared and common code (especially things that get JITted early anyhow) is nice in areas that see most action during startup/warmup.

Ok, please keep it the way it is in your current patch then.

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

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

From naoto at openjdk.java.net  Fri Jun  3 16:58:07 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 3 Jun 2022 16:58:07 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for charset
 "windows-1252"
Message-ID: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>

The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

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

Commit messages:
 - 8287541: Files.writeString fails to throw IOException for charset "windows-1252"

Changes: https://git.openjdk.java.net/jdk/pull/9019/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9019&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287541
  Stats: 22 lines in 2 files changed: 4 ins; 11 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9019/head:pull/9019

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

From redestad at openjdk.java.net  Fri Jun  3 16:59:47 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 16:59:47 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <Lng4ANX-IUM2FCqebLoupvGMme1vHA8SPSH38RP8VL0=.f760d3c0-bb34-4298-8738-d499657cdd6f@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>
 <Ap4ltGR8lZizQgLoCIMG4wKBzX0ztEo0eGxOoEAYldo=.bf65f0a4-25b9-4485-b2ec-e110073d5459@github.com>
 <kcxBs-gXeU7vs1bYro_HQDlUpIVECa2Om0vdnXz3pyA=.f1f5b862-f192-4b12-a6a1-870de55db00a@github.com>
 <xdylQSlfFxdoGT_SlaYyIjUUgDt9y-9FeSjKIFS82qA=.e60783bd-34fc-432a-ba28-e21f189dfb0a@github.com>
 <Lng4ANX-IUM2FCqebLoupvGMme1vHA8SPSH38RP8VL0=.f760d3c0-bb34-4298-8738-d499657cdd6f@github.com>
Message-ID: <tpDUb3BO9thNu5CKp_JaeOnGvIsmmma8DqpHLaTQpRE=.b948bbc5-ce6b-4509-98ce-2311a2420f5e@github.com>

On Fri, 3 Jun 2022 16:48:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I'm not so sure. 
>> 
>> First of all we're no worse than before with the defensive copying here. Second of an optimizing compiler might theoretically be able to see that the array we get from the toArray is always fresh and not escaping anywhere in any well-behaved collection, so the clone could be elided. But if not then both toArray and clone are intrinsified operations that are heavily optimized and pretty fast even when interpreting, so emulating it with an external loop might end up taking more time even at peak. While likely taking longer to reach that peak. Using dumb, shared and common code (especially things that get JITted early anyhow) is nice in areas that see most action during startup/warmup.
>
> Ok, please keep it the way it is in your current patch then.

Correction: `toArray` isn't intrinsified, but common `List` implementations are likely to implement it with a `System.arraycopy`, which is.

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

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

From redestad at openjdk.java.net  Fri Jun  3 17:05:19 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 3 Jun 2022 17:05:19 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v3]
In-Reply-To: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
Message-ID: <uq8t9cDWM6yyA7VBtaw48zAIcmLT8RqOc3-8_7ouyU8=.41316334-c88e-405e-bd02-0f6d5c342a91@github.com>

> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.

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

  Jorn review: Drop boolean, rename internal variant dropArgumentsTrusted

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8923/files
  - new: https://git.openjdk.java.net/jdk/pull/8923/files/15ff2125..c590f0dd

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

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

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

From jvernee at openjdk.java.net  Fri Jun  3 17:23:29 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 3 Jun 2022 17:23:29 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v3]
In-Reply-To: <uq8t9cDWM6yyA7VBtaw48zAIcmLT8RqOc3-8_7ouyU8=.41316334-c88e-405e-bd02-0f6d5c342a91@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <uq8t9cDWM6yyA7VBtaw48zAIcmLT8RqOc3-8_7ouyU8=.41316334-c88e-405e-bd02-0f6d5c342a91@github.com>
Message-ID: <5m0gsdpYiWl9vzGXxQYp-NRJ6rIE9YK7-8lOVwvCkoM=.ba716f36-fd82-45f2-83ea-a675176d0198@github.com>

On Fri, 3 Jun 2022 17:05:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Jorn review: Drop boolean, rename internal variant dropArgumentsTrusted

Marked as reviewed by jvernee (Reviewer).

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

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

From iris at openjdk.java.net  Fri Jun  3 17:24:34 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 3 Jun 2022 17:24:34 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <6Yy8ZhSU6dPNfyfUAbjO2gYLy7R4moFZaX1fwbA9K98=.1e16f29b-4541-4af7-a9f3-8510ccdcedf5@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by iris (Reviewer).

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

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

From bchristi at openjdk.java.net  Fri Jun  3 17:56:44 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 3 Jun 2022 17:56:44 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v9]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <5e99FzjvfzNZST2o0wQ1OEs4WnUtyruwGPhHIm5Ft8U=.f21e042c-8138-44a7-8d1a-ceef7d5d3a4c@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

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

 - Update .ldap capture file
 - Check that cleanup was performed correctly

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8311/files
  - new: https://git.openjdk.java.net/jdk/pull/8311/files/4af66bff..3941e6f1

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

  Stats: 86 lines in 2 files changed: 34 ins; 38 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

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

From bchristi at openjdk.java.net  Fri Jun  3 17:56:49 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 3 Jun 2022 17:56:49 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v8]
In-Reply-To: <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
Message-ID: <rCstr0UCWrmNu75rO857LApM2iIzD6Ja0gp3I_nJuvk=.ce364656-6a0a-42de-91f6-4f5dbe4badea@github.com>

On Fri, 27 May 2022 22:09:22 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into remove-finalizers
>  - Threading-related fixes
>  - NOW it builds
>  - Fix the merge fix
>  - Fix merge
>  - Merge
>  - Rename inner class to EnumCtx ; use homeCtx() in AbstractLdapNamingEnumeration for consistencty ; new instance vars can be final
>  - fix whitespace
>  - Merge branch 'master' into remove-finalizers
>  - Test changes to test new cleaner code
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/ed8e8ac2...4af66bff

I've updated the test case to confirm that cleanup is performed correctly, by inspecting the enumCount within the LdapCtx.

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

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

From mchung at openjdk.java.net  Fri Jun  3 18:14:09 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 3 Jun 2022 18:14:09 GMT
Subject: RFR: JDK-8287671: Adjust ForceGC to invoke System::gc fewer times for
 negative case
Message-ID: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>

This reapplies JDK-8287384 and adjust the number of GCs for negative case, i.e. the condition is never met that is used to verify a reference is not GC'ed.

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

Commit messages:
 - JDK-8287671: Adjust ForceGC to invoke System::gc fewer times for negative case

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

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

From bpb at openjdk.java.net  Fri Jun  3 18:15:32 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 3 Jun 2022 18:15:32 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <j4NejE-TvPMjkn9pRPrWyT-vl3EBHDJ2tQA4sz1xBAU=.25df0968-23f7-4643-8a00-c3695b94706b@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by bpb (Reviewer).

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

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

From joehw at openjdk.java.net  Fri Jun  3 18:26:06 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 3 Jun 2022 18:26:06 GMT
Subject: RFR: 8285081: Improve XPath operators count accuracy
Message-ID: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>

Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. 

Test:  
     Tier2 passed;
     JCK XML tests passed.

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

Commit messages:
 - 8285081: Improve XPath operators count accuracy

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

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

From mchung at openjdk.java.net  Fri Jun  3 18:31:33 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 3 Jun 2022 18:31:33 GMT
Subject: RFR: 8287798: Reduce runtime of java.lang.reflect/runtime
 microbenchmarks
In-Reply-To: <NaBo8k0zTSOoSnLEf5Y02aM-Wk9VKdWKGKZs4-XUAL8=.9d68731f-95d7-43f9-ae6e-9aef656f68e8@github.com>
References: <NaBo8k0zTSOoSnLEf5Y02aM-Wk9VKdWKGKZs4-XUAL8=.9d68731f-95d7-43f9-ae6e-9aef656f68e8@github.com>
Message-ID: <y7ntB7UtPWX2ZdW0pn0s7GOEkRXJ22VnlJbcDaPLtS4=.0a17e309-e25d-442e-8e1b-94f3cca99f05@github.com>

On Fri, 3 Jun 2022 12:46:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Add explicit run configurations to java.lang.reflect and .runtime micros, aiming to reduce runtime while maintaining a decently high confidence that there's enough warmup to produce good enough data.
> 
> Roughly halves runtime of running `java.lang.reflect|java.lang.runtime` from 159 to 78 minutes.

Marked as reviewed by mchung (Reviewer).

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

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

From rriggs at openjdk.java.net  Fri Jun  3 18:58:31 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 3 Jun 2022 18:58:31 GMT
Subject: RFR: JDK-8287671: Adjust ForceGC to invoke System::gc fewer times
 for negative case
In-Reply-To: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
References: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
Message-ID: <Y75H_-waL28Qt4aDgcYZKvp50iF-5fKcRUg_o5ymPG0=.bc8ac02a-1ba8-4eef-81db-edc277e027d7@github.com>

On Fri, 3 Jun 2022 18:05:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This reapplies JDK-8287384 and adjust the number of GCs for negative case, i.e. the condition is never met that is used to verify a reference is not GC'ed.

Marked as reviewed by rriggs (Reviewer).

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

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

From mchung at openjdk.java.net  Fri Jun  3 19:06:34 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 3 Jun 2022 19:06:34 GMT
Subject: RFR: 8287785: Reduce runtime of java.lang.invoke microbenchmarks
 [v2]
In-Reply-To: <pN4f0VvAXeAR6zVNqbG_Q4T0qH_tNIeIrtBjfdz4nZc=.ee79b386-eaf1-4242-95cd-c3de566a7af4@github.com>
References: <PZgf4z1DyIgjRrELDsPi3MFCr4ZOne0Ut62-5PN-Vms=.23b1464f-a2ca-46c6-8280-1a181891caf4@github.com>
 <pN4f0VvAXeAR6zVNqbG_Q4T0qH_tNIeIrtBjfdz4nZc=.ee79b386-eaf1-4242-95cd-c3de566a7af4@github.com>
Message-ID: <GRQC2pAmO0iA8oRIX3kXuhJcQyu3B_kP1-lbGuFnD-o=.8aa8e9bc-f422-481d-8cdf-b970b151e826@github.com>

On Fri, 3 Jun 2022 12:53:38 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Add explicit run configurations to java.lang.invoke micros, aiming to reduce runtime while maintaining a decently high confidence that there's enough warmup to produce good enough data.
>> 
>> - Remove several trivial baseline micros, mainly those that only return a static object: It's reasonable to have baseline microbenchmarks when the baseline op is complex and you're mostly interested in checking the overhead of doing the same thing via some MH API, but blackhole operations are now shortcutting very quickly and timings doesn't differ from one type of object to another, so we don't need a multitude of such baseline tests.
>> 
>> Estimated runtime of `make test TEST=micro:java.lang.micro` (excluding build) drops from just above 28 to just above 3 hours.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused cached field in LookupAcquire

Marked as reviewed by mchung (Reviewer).

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

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

From mchung at openjdk.java.net  Fri Jun  3 19:11:33 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 3 Jun 2022 19:11:33 GMT
Subject: RFR: 8287810: Reduce runtime of java.lang microbenchmarks
In-Reply-To: <4MFktMLic5pH0qFBPSPjy1HXpHuhoteAzYjBvo_dZPk=.63e4099c-1246-44ca-a16b-3445e84b6262@github.com>
References: <4MFktMLic5pH0qFBPSPjy1HXpHuhoteAzYjBvo_dZPk=.63e4099c-1246-44ca-a16b-3445e84b6262@github.com>
Message-ID: <tqhMsZXLpKBDN9tlVsb526_JelJn18I6VoIrQ9GUffg=.ed2df21d-dca3-4e52-b097-b1b672a35df6@github.com>

On Fri, 3 Jun 2022 15:05:33 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Reduce runtime by providing explicit configurations that try to run the micros as fast as possible while giving enough time for warmup.
> - Remove some excessive parameters
> - Remove some benchmarks testing experimental features (ObjectHashCode.mode_<non-default>) or were simply dubious at large (StringHttp)
> 
> This reduces runtime of running `java.lang.[A-Z]` (only java.lang, not java.lang.reflect etc..) from over 56 hours to 6:45.

Marked as reviewed by mchung (Reviewer).

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

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

From alanb at openjdk.java.net  Fri Jun  3 20:14:22 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Jun 2022 20:14:22 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <-3KWDzj6Iv4PU_dBq8eT-9dOZX3i0CDQ8pUlGWeD2-M=.dfc0c643-49e7-4578-9aeb-11810d20cedf@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by alanb (Reviewer).

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

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

From almatvee at openjdk.java.net  Fri Jun  3 20:30:41 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 3 Jun 2022 20:30:41 GMT
Subject: Integrated: 8286850: [macos] Add support for signing user provided app
 image
In-Reply-To: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
Message-ID: <bZhPtx87JmfKNsBfQYHyrJFZQxDrfXSa5bBt3h-kyEM=.004595cc-305a-4354-b0f3-b29edeec4256@github.com>

On Thu, 2 Jun 2022 05:17:25 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added support for signing predefined application image.
>  - Following command can be used to sign predefined application images: jpackage --type app-image --app-image Test.app --mac-sign [additional signing options]
>  - Main class and if --mac-app-store was specified will be saved in .jpackage.xml. Both values are required for signing. Main class is to generate default identity and --mac-app-store to do correct signing for App Store.
>  - Signing is done exactly same as when generating app bundle. Unsigned, signed or partially signed app images are supported. App image will be completely unsigned before signing.

This pull request has now been integrated.

Changeset: 7a0c8b14
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7a0c8b14aaf3573f5ea2bd2cc759c854825e6893
Stats:     941 lines in 27 files changed: 792 ins; 22 del; 127 mod

8286850: [macos] Add support for signing user provided app image

Reviewed-by: asemenyuk

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

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

From aturbanov at openjdk.java.net  Fri Jun  3 20:38:36 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 3 Jun 2022 20:38:36 GMT
Subject: RFR: 8285285: Avoid redundant allocations in WindowsPreferences
In-Reply-To: <8-W0hk5YK-0sIJewKJLikzklE6V--uui3wCgQLS4suI=.0194a658-1b8d-4deb-b177-0d402d590b5b@github.com>
References: <8-W0hk5YK-0sIJewKJLikzklE6V--uui3wCgQLS4suI=.0194a658-1b8d-4deb-b177-0d402d590b5b@github.com>
Message-ID: <ZXaAoMv7wpiUiUm1rMhw3UPMTo7OwodjRo4fLuJElx8=.643cc5f8-d969-480d-9aa5-32e686a3a452@github.com>

On Wed, 20 Apr 2022 19:16:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 1. No need to call `String.substring` if you need need to compare start of string with some constant. `String.startWith` suites better.
> 2. Unused String array is allocated in `childrenNamesSpi` method

I believe it's pretty obvious changes. I will integrate at Monday, if there will be no more comments.

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

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

From naoto at openjdk.java.net  Fri Jun  3 21:56:40 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 3 Jun 2022 21:56:40 GMT
Subject: RFR: 8285081: Improve XPath operators count accuracy
In-Reply-To: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
References: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
Message-ID: <dQPx_kcLOi_TA0FcnyiW-TA8MCmu_CANr2n6rsQMbVY=.1ffdc093-5e34-46f4-af15-d98ecf0c3fa8@github.com>

On Fri, 3 Jun 2022 18:17:55 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. 
> 
> Test:  
>      Tier2 passed;
>      JCK XML tests passed.

src/java.xml/share/classes/com/sun/java_cup/internal/runtime/lr_parser.java line 152:

> 150:     private int opCount = 0;
> 151:     private int totalOpCount = 0;
> 152:     private int lastSym;

`lastSym` is never initialized. It's OK for the first time, but should this be reset for the next use (if any), e.g. somewhere around line 595?

src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/sym.java line 99:

> 97:   public static final int[] OPERATORS = {GT, GE, EQ, NE, LT, LE, SLASH, DSLASH,
> 98:       DOT, DDOT, ATSIGN, DCOLON, PLUS, MINUS, STAR, DIV, MOD, AND, OR, LPAREN,
> 99:       LBRACK, VBAR, DOLLAR, NODE, TEXT, PI, PIPARAM};

Any reason for re-shuffling the order of operators? I'd expect new ones are appended to the existing ones, or appear in the order of their declarations above?
(or is this automatically generated, as described in the comment?)

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java line 351:

> 349:         {
> 350:           nesting++;
> 351:           if (!isLiteral) {

`if (isLiteral) {` might be more readable.

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java line 377:

> 375:         else if ((Token.LPAREN != c) && (Token.LBRACK != c) && (Token.RPAREN != c)
> 376:                 && (Token.RBRACK != c) && (Token.COLON != c) && (Token.COMMA != c)) {
> 377:             if (Token.STAR == c) {

Could be 

    if (Token.STAR != c || !isAxis) {
        incrementCount(c);
    }

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java line 476:

> 474:   }
> 475: 
> 476:   private void incrementCount(char c) {

`c` is not used.

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

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

From bchristi at openjdk.java.net  Fri Jun  3 21:59:33 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 3 Jun 2022 21:59:33 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v10]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <f-klney2pJZgi-tLU8EEiisA8K_YwAqmvWcnu0H0k0M=.05e1a5ca-14e7-4f16-951d-98b5625ad894@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

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

 - added getters to EnumCtx, and moved it to top level ; use getters + local variables to reduce code changes
 - test comment udpate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8311/files
  - new: https://git.openjdk.java.net/jdk/pull/8311/files/3941e6f1..e34e888f

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

  Stats: 125 lines in 5 files changed: 50 ins; 36 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

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

From bchristi at openjdk.java.net  Fri Jun  3 21:59:40 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 3 Jun 2022 21:59:40 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v8]
In-Reply-To: <GPrhQVdNs-gjQMu2Es0Gzj5YiClzoN7Fnb7-8gBgg7M=.9f5dccd2-063e-48a9-9d8f-285a0fd84ba9@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>
 <GPrhQVdNs-gjQMu2Es0Gzj5YiClzoN7Fnb7-8gBgg7M=.9f5dccd2-063e-48a9-9d8f-285a0fd84ba9@github.com>
Message-ID: <A-YDq8J3SKhF3o8Jh5AH1GtyxF-x8v0rkB9JiSsK5iA=.c50b0961-3eb1-4e4d-a712-8bacd3a12eb4@github.com>

On Wed, 1 Jun 2022 21:25:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into remove-finalizers
>>  - Threading-related fixes
>>  - NOW it builds
>>  - Fix the merge fix
>>  - Fix merge
>>  - Merge
>>  - Rename inner class to EnumCtx ; use homeCtx() in AbstractLdapNamingEnumeration for consistencty ; new instance vars can be final
>>  - fix whitespace
>>  - Merge branch 'master' into remove-finalizers
>>  - Test changes to test new cleaner code
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/ed8e8ac2...4af66bff
>
> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 176:
> 
>> 174:             LdapResult newRes = homeCtx().getSearchReply(enumCtx.enumClnt, enumCtx.res);
>> 175:             enumCtx.setRes(newRes);
>> 176:             if (enumCtx.res == null) {
> 
> This looks odd, setting the value using synchronized, but reading it without.

I've added getters to EnumCtx, and a comment explaining why only setters are synchronized.

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

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

From asemenyuk at openjdk.java.net  Fri Jun  3 22:14:23 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 3 Jun 2022 22:14:23 GMT
Subject: RFR: 8250950: Allow per-user and system wide configuration of a
 jpackaged app
Message-ID: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>

8250950: Allow per-user and system wide configuration of a jpackaged app

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

Commit messages:
 - Trailing white space removed
 - EOLs converted
 - Trailing white space removed
 - 8250950: Allow per-user and system wide configuration of a jpackaged app

Changes: https://git.openjdk.java.net/jdk/pull/9025/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9025&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250950
  Stats: 568 lines in 14 files changed: 512 ins; 36 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9025.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9025/head:pull/9025

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

From joehw at openjdk.java.net  Fri Jun  3 22:34:35 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 3 Jun 2022 22:34:35 GMT
Subject: RFR: 8285081: Improve XPath operators count accuracy
In-Reply-To: <dQPx_kcLOi_TA0FcnyiW-TA8MCmu_CANr2n6rsQMbVY=.1ffdc093-5e34-46f4-af15-d98ecf0c3fa8@github.com>
References: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
 <dQPx_kcLOi_TA0FcnyiW-TA8MCmu_CANr2n6rsQMbVY=.1ffdc093-5e34-46f4-af15-d98ecf0c3fa8@github.com>
Message-ID: <pItGICCvpO_O0HhLjxX3ZXxPYf2h3MrgEs6bnh8s_XU=.3ee30a2e-8a05-4587-b05d-ce912de7cfdd@github.com>

On Fri, 3 Jun 2022 21:08:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. 
>> 
>> Test:  
>>      Tier2 passed;
>>      JCK XML tests passed.
>
> src/java.xml/share/classes/com/sun/java_cup/internal/runtime/lr_parser.java line 152:
> 
>> 150:     private int opCount = 0;
>> 151:     private int totalOpCount = 0;
>> 152:     private int lastSym;
> 
> `lastSym` is never initialized. It's OK for the first time, but should this be reset for the next use (if any), e.g. somewhere around line 595?

Right, -1 would be appropriate as 0 indicates EOF.

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

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

From bchristi at openjdk.java.net  Fri Jun  3 22:35:38 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 3 Jun 2022 22:35:38 GMT
Subject: RFR: JDK-8287671: Adjust ForceGC to invoke System::gc fewer times
 for negative case
In-Reply-To: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
References: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
Message-ID: <oojM7wjeo7Zu95he6xtfQW1ESLQ2oDvraGHvnYQHQnA=.844af60a-b64d-480f-bc11-0037b436ac42@github.com>

On Fri, 3 Jun 2022 18:05:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This reapplies JDK-8287384 and adjust the number of GCs for negative case, i.e. the condition is never met that is used to verify a reference is not GC'ed.

Marked as reviewed by bchristi (Reviewer).

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

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

From joehw at openjdk.java.net  Fri Jun  3 22:39:35 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 3 Jun 2022 22:39:35 GMT
Subject: RFR: 8285081: Improve XPath operators count accuracy
In-Reply-To: <dQPx_kcLOi_TA0FcnyiW-TA8MCmu_CANr2n6rsQMbVY=.1ffdc093-5e34-46f4-af15-d98ecf0c3fa8@github.com>
References: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
 <dQPx_kcLOi_TA0FcnyiW-TA8MCmu_CANr2n6rsQMbVY=.1ffdc093-5e34-46f4-af15-d98ecf0c3fa8@github.com>
Message-ID: <OmUmjj0nDzaY57my_yMhMx5yAIKX7WJaO9eqxbcE2JQ=.43bcc426-077e-4444-8476-2b3c1eacd37f@github.com>

On Fri, 3 Jun 2022 21:11:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. 
>> 
>> Test:  
>>      Tier2 passed;
>>      JCK XML tests passed.
>
> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/sym.java line 99:
> 
>> 97:   public static final int[] OPERATORS = {GT, GE, EQ, NE, LT, LE, SLASH, DSLASH,
>> 98:       DOT, DDOT, ATSIGN, DCOLON, PLUS, MINUS, STAR, DIV, MOD, AND, OR, LPAREN,
>> 99:       LBRACK, VBAR, DOLLAR, NODE, TEXT, PI, PIPARAM};
> 
> Any reason for re-shuffling the order of operators? I'd expect new ones are appended to the existing ones, or appear in the order of their declarations above?
> (or is this automatically generated, as described in the comment?)

The order is not significant for this process as the lexer takes care of creating the right symbol. I re-grouped them to put operators of the same category together so that it's easier to see what might be missing.

> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java line 476:
> 
>> 474:   }
>> 475: 
>> 476:   private void incrementCount(char c) {
> 
> `c` is not used.

Will remove it.

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

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

From joehw at openjdk.java.net  Fri Jun  3 23:18:08 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 3 Jun 2022 23:18:08 GMT
Subject: RFR: 8285081: Improve XPath operators count accuracy [v2]
In-Reply-To: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
References: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
Message-ID: <z428oCBMix5CmRfyHjLrL4TyDhAKMEU08ypWBUYanXg=.917730b6-e91a-4f52-9b3b-51d119489b85@github.com>

> Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. 
> 
> Test:  
>      Tier2 passed;
>      JCK XML tests passed.

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

  review update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9022/files
  - new: https://git.openjdk.java.net/jdk/pull/9022/files/f840e840..e1e3deb2

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

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

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

From joehw at openjdk.java.net  Fri Jun  3 23:18:09 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 3 Jun 2022 23:18:09 GMT
Subject: RFR: 8285081: Improve XPath operators count accuracy [v2]
In-Reply-To: <dQPx_kcLOi_TA0FcnyiW-TA8MCmu_CANr2n6rsQMbVY=.1ffdc093-5e34-46f4-af15-d98ecf0c3fa8@github.com>
References: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
 <dQPx_kcLOi_TA0FcnyiW-TA8MCmu_CANr2n6rsQMbVY=.1ffdc093-5e34-46f4-af15-d98ecf0c3fa8@github.com>
Message-ID: <2-zixoUNYoCCKxaP5M8fJpTnl5z8FCuRjwwP1yLrlKg=.37ec6e0e-6b98-44f5-ab52-83ff858f41ac@github.com>

On Fri, 3 Jun 2022 21:52:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review update
>
> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java line 377:
> 
>> 375:         else if ((Token.LPAREN != c) && (Token.LBRACK != c) && (Token.RPAREN != c)
>> 376:                 && (Token.RBRACK != c) && (Token.COLON != c) && (Token.COMMA != c)) {
>> 377:             if (Token.STAR == c) {
> 
> Could be 
> 
>     if (Token.STAR != c || !isAxis) {
>         incrementCount(c);
>     }

Thanks Naoto!  Updated as commented.

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

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

From joehw at openjdk.java.net  Fri Jun  3 23:56:31 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 3 Jun 2022 23:56:31 GMT
Subject: RFR: 8285081: Improve XPath operators count accuracy [v3]
In-Reply-To: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
References: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
Message-ID: <AkKJqZgQXH2yQT5MtC9qLtFkZqHc6UEd77Q9BkQWnTc=.f14c9a77-659f-47fb-b54e-489f1a1fcd03@github.com>

> Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. 
> 
> Test:  
>      Tier2 passed;
>      JCK XML tests passed.

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

  remove unused parameter

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9022/files
  - new: https://git.openjdk.java.net/jdk/pull/9022/files/e1e3deb2..6dc1cc2c

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

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

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

From darcy at openjdk.java.net  Sat Jun  4 00:23:41 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 4 Jun 2022 00:23:41 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v5]
In-Reply-To: <oopQjIhFlclsuKBuKjqDTdd8zset_AHmTln1FZXV2Y0=.9b28ec8f-e71b-4e26-81dc-cf2a868fb963@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <oopQjIhFlclsuKBuKjqDTdd8zset_AHmTln1FZXV2Y0=.9b28ec8f-e71b-4e26-81dc-cf2a868fb963@github.com>
Message-ID: <kZx-iXLx47sElRhBp0mVvazv3ZiWHYz1e1Cl6DwlKrw=.d92b3837-e165-48d8-8d58-3aea38a04402@github.com>

On Thu, 2 Jun 2022 11:25:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>> 
>> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Add test directory to jdk_other so tests run in tier2
>  - Merge
>  - Fix typo in javadoc
>  - Merge
>  - Javadoc updates, add to jdk_loom test group
>  - Add statement to close about thread termination
>  - Use {@code ...}, replace task->subtask, fix typos, add jls ref
>  - Merge
>  - @ignore StructuredThreadDumpTest until test infra in place
>  - Refresh
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/3c34c506...7f48656e

Marked as reviewed by darcy (Reviewer).

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

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

From almatvee at openjdk.java.net  Sat Jun  4 02:10:29 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 4 Jun 2022 02:10:29 GMT
Subject: RFR: 8250950: Allow per-user and system wide configuration of a
 jpackaged app
In-Reply-To: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
References: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
Message-ID: <tLb7neHlTNBIxNA9heT2WhhfmF-LORo2Xq2yBfWPR88=.fe1969d1-dca1-4395-8365-4e7ad3964f98@github.com>

On Fri, 3 Jun 2022 21:07:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8250950: Allow per-user and system wide configuration of a jpackaged app

test/jdk/tools/jpackage/share/PerUserCfgTest.java line 174:

> 172:             action.accept(cmd);
> 173:         } finally {
> 174:             Files.deleteIfExists(targetCfgFile);

Should we delete parent directory as well?

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

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

From xuelei at openjdk.java.net  Sat Jun  4 05:11:28 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 4 Jun 2022 05:11:28 GMT
Subject: RFR: JDK-8287671: Adjust ForceGC to invoke System::gc fewer times
 for negative case
In-Reply-To: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
References: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
Message-ID: <fvW1S1-arjWrNn7oCX5VK-T-SlexpIT5cfAG_HN5JxE=.2be0c086-e8b8-4b48-8b60-4a0366fe27e0@github.com>

On Fri, 3 Jun 2022 18:05:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This reapplies JDK-8287384 and adjust the number of GCs for negative case, i.e. the condition is never met that is used to verify a reference is not GC'ed.

Marked as reviewed by xuelei (Reviewer).

@mlchung Thank you for pick up and fix the issue.

The waiting time now is reduced from 10 seconds to 1 seconds.  As most of the tests intermittent fail, the failure may be more popular now.  Alternatively, it might be OK to run less cases in UnloadingTest.java (for example one or two call to tryUnload() in one test by separating the case into a few).  But let's see if the intermittent failure is still rare enough.

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

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

From alanb at openjdk.java.net  Sat Jun  4 06:18:37 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 4 Jun 2022 06:18:37 GMT
Subject: Integrated: 8284199: Implementation of Structured Concurrency
 (Incubator)
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <O1F-Fp3SF9JQAc-7H4LPQmM3FTXEShy42aL63-Qq-Mg=.e5e24bd9-30c5-4e24-a68a-41a0e2de420a@github.com>

On Thu, 19 May 2022 13:05:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

This pull request has now been integrated.

Changeset: e4e1e8f6
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e4e1e8f66c9b0321cdb1aaf3b1c5d9b67224b210
Stats:     2816 lines in 11 files changed: 2815 ins; 0 del; 1 mod

8284199: Implementation of Structured Concurrency (Incubator)

Co-authored-by: Ron Pressler <rpressler at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Brian Goetz <briangoetz at openjdk.org>
Co-authored-by: Paul Sandoz <psandoz at openjdk.org>
Reviewed-by: psandoz, mcimadamore, darcy

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

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

From aturbanov at openjdk.java.net  Sat Jun  4 11:30:16 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sat, 4 Jun 2022 11:30:16 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <tP13YR4kuRlnwDNmLarYlJOxC5uJzgndoDUNQy8bu4E=.73908ccb-b81f-40ab-8981-e1854c462562@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

src/java.base/share/classes/java/lang/String.java line 849:

> 847:         int en = scale(len, ce.maxBytesPerChar());
> 848:         // fastpath with ArrayEncoder implies `doReplace`.
> 849:         if (ce instanceof ArrayEncoder ae && doReplace) {

Wouldn't it be more readable (and perphaps faster) if we do check boolean flag first?

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

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

From asemenyuk at openjdk.java.net  Sat Jun  4 15:19:26 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Sat, 4 Jun 2022 15:19:26 GMT
Subject: RFR: 8250950: Allow per-user and system wide configuration of a
 jpackaged app
In-Reply-To: <tLb7neHlTNBIxNA9heT2WhhfmF-LORo2Xq2yBfWPR88=.fe1969d1-dca1-4395-8365-4e7ad3964f98@github.com>
References: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
 <tLb7neHlTNBIxNA9heT2WhhfmF-LORo2Xq2yBfWPR88=.fe1969d1-dca1-4395-8365-4e7ad3964f98@github.com>
Message-ID: <GLFvRJqT17preGlqnkqcqIByIivHqsHbgzAkcS6KtkU=.efa6b66e-f00a-4114-b921-936405325309@github.com>

On Sat, 4 Jun 2022 01:45:21 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> 8250950: Allow per-user and system wide configuration of a jpackaged app
>
> test/jdk/tools/jpackage/share/PerUserCfgTest.java line 174:
> 
>> 172:             action.accept(cmd);
>> 173:         } finally {
>> 174:             Files.deleteIfExists(targetCfgFile);
> 
> Should we delete parent directory as well?

Correct. We should delete all directories that got created in the preceding `Files.createDirectories()` call. Will fix this.

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

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

From mik3hall at gmail.com  Sun Jun  5 13:56:29 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 5 Jun 2022 08:56:29 -0500
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v2]
In-Reply-To: <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
Message-ID: <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>


Fwiw, I was going to take a look at this but my build failed.

=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_liblcms_cmstypes.o:
/Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
                                                                                                                                   ^
/Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
                                                                                                                            ^
2 errors generated.


OS/X 12.4

2.4 GHz Quad-Core Intel Core i5

If I should post that somewhere else let me know.


From dcubed at openjdk.java.net  Sun Jun  5 14:12:11 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 5 Jun 2022 14:12:11 GMT
Subject: Integrated: 8287837: ProblemList
 java/lang/ref/OOMEInReferenceHandler.java in -Xcomp
Message-ID: <ehCSvUkikXxsaL_nN0oa6mFiMFeHswfCEnhhPoqKxkY=.2292c274-ae67-4860-a8c4-4bca4020e839@github.com>

A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp.

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

Commit messages:
 - 8287837: ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp

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

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

From rriggs at openjdk.java.net  Sun Jun  5 14:12:11 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Sun, 5 Jun 2022 14:12:11 GMT
Subject: Integrated: 8287837: ProblemList
 java/lang/ref/OOMEInReferenceHandler.java in -Xcomp
In-Reply-To: <ehCSvUkikXxsaL_nN0oa6mFiMFeHswfCEnhhPoqKxkY=.2292c274-ae67-4860-a8c4-4bca4020e839@github.com>
References: <ehCSvUkikXxsaL_nN0oa6mFiMFeHswfCEnhhPoqKxkY=.2292c274-ae67-4860-a8c4-4bca4020e839@github.com>
Message-ID: <Q1ukoJnN0e4dN9aFk_qqU1bDljGisQdT4waIwFDiFq8=.60de16a4-b253-4341-85b9-e08e4472e50c@github.com>

On Sun, 5 Jun 2022 14:00:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp.

Marked as reviewed by rriggs (Reviewer).

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

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

From dcubed at openjdk.java.net  Sun Jun  5 14:12:11 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 5 Jun 2022 14:12:11 GMT
Subject: Integrated: 8287837: ProblemList
 java/lang/ref/OOMEInReferenceHandler.java in -Xcomp
In-Reply-To: <Q1ukoJnN0e4dN9aFk_qqU1bDljGisQdT4waIwFDiFq8=.60de16a4-b253-4341-85b9-e08e4472e50c@github.com>
References: <ehCSvUkikXxsaL_nN0oa6mFiMFeHswfCEnhhPoqKxkY=.2292c274-ae67-4860-a8c4-4bca4020e839@github.com>
 <Q1ukoJnN0e4dN9aFk_qqU1bDljGisQdT4waIwFDiFq8=.60de16a4-b253-4341-85b9-e08e4472e50c@github.com>
Message-ID: <AvFmarpSrxJ1S-1C7cHsRHPxHJ7SVKjivurWHGQ609s=.fa58e2d3-d05c-41fb-9347-a0c7f3347691@github.com>

On Sun, 5 Jun 2022 14:05:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp.
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs - Thanks for the fast review! Especially early on a Sunday!!

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

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

From dcubed at openjdk.java.net  Sun Jun  5 14:12:11 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 5 Jun 2022 14:12:11 GMT
Subject: Integrated: 8287837: ProblemList
 java/lang/ref/OOMEInReferenceHandler.java in -Xcomp
In-Reply-To: <ehCSvUkikXxsaL_nN0oa6mFiMFeHswfCEnhhPoqKxkY=.2292c274-ae67-4860-a8c4-4bca4020e839@github.com>
References: <ehCSvUkikXxsaL_nN0oa6mFiMFeHswfCEnhhPoqKxkY=.2292c274-ae67-4860-a8c4-4bca4020e839@github.com>
Message-ID: <Fsau8XrptOIJcVu6GddCz-JYR8fcsFpZMcPIlfD_HbM=.73c2e4d9-635e-4615-8fe8-c424307dd2a1@github.com>

On Sun, 5 Jun 2022 14:00:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp.

This pull request has now been integrated.

Changeset: 3df4b034
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3df4b034fbb49b9d9b3153807192fc999d7371ad
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8287837: ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp

Reviewed-by: rriggs

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

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

From duke at openjdk.java.net  Sun Jun  5 17:42:29 2022
From: duke at openjdk.java.net (Chris Hennick)
Date: Sun, 5 Jun 2022 17:42:29 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v3]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <jlL9XA3ub0nM-weJHaxNiNNSBnvzIjJhr9c9yWPX3LQ=.861574f0-fb0e-4a2c-98d8-fdedcf3af81a@github.com>

> Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around 2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1); this fixes that by tracking the multiple of exponentialX0 as a long. (This changes the maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once `extra` reaches that amount, `x + extra == extra` due to the rounding error. This lowers the probability of reaching the maximum with an ideal PRNG from about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`).

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

 - Merge branch 'openjdk:master' into patch-1
 - Fix rounding error in computeNextExponential; use FMA
   
   Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution; this fixes that by tracking the multiple of exponentialX0 as a long.
   
   Add computeWinsorizedNextExponential for testability

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8131/files
  - new: https://git.openjdk.java.net/jdk/pull/8131/files/fa340fb4..c5a28f98

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

  Stats: 505696 lines in 6376 files changed: 341007 ins; 100192 del; 64497 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8131/head:pull/8131

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

From darcy at openjdk.java.net  Sun Jun  5 21:27:10 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sun, 5 Jun 2022 21:27:10 GMT
Subject: RFR: JDK-8287838: Update Float and Double to use snippets
Message-ID: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>

Various code blocks in Float and Double would be better as snippets.

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

Commit messages:
 - JDK-8287838: Update Float and Double to use snippets

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

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

From mik3hall at gmail.com  Sun Jun  5 22:06:25 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 5 Jun 2022 17:06:25 -0500
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v2]
In-Reply-To: <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
Message-ID: <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>



> On Jun 5, 2022, at 8:56 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> Fwiw, I was going to take a look at this but my build failed.
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_liblcms_cmstypes.o:
> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
> void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
>                                                                                                                                   ^
> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
> void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
>                                                                                                                            ^
> 2 errors generated.
> 
> 
> OS/X 12.4
> 
> 2.4 GHz Quad-Core Intel Core i5
> 
> If I should post that somewhere else let me know.
> 

Again fwiw, I commented out references to SizeOfTag in the two methods and got a good build.

./build/*/images/jdk/bin/jpackage --app-image ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)"
Bundler Mac DMG Package skipped because of a configuration problem: When using an external app image you must specify the app name. 
Advice to fix: Set the app name via the -name CLI flag, the fx:application/@name ANT attribute, or via the 'appName' bundler argument.

./build/*/images/jdk/bin/jpackage --app-image ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)" --name HalfPipe
Warning: Using unsigned app-image to build signed dmg.

*** The app-image was actually a signed one. I?m not sure that matters. Also since this would normally be my intention should there be a warning? ***

 codesign -v --verbose=4 ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: valid on disk
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: satisfies its Designated Requirement

*** Seems successful ***

Thanks again.


From aefimov at openjdk.java.net  Sun Jun  5 23:26:20 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Sun, 5 Jun 2022 23:26:20 GMT
Subject: RFR: 8287766: Unnecessary Vector usage in LdapClient
In-Reply-To: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
References: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
Message-ID: <djO4eBfFPVqL7jOkf9aeODKKFbBcMK5ZTdCTnBOXYE4=.0cf66c04-fc0a-4278-bd7c-dc6877baf6f7@github.com>

On Sun, 29 May 2022 20:22:55 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> In [JDK-8273098](https://bugs.openjdk.java.net/browse/JDK-8273098) I missed one place, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

Looks good ??

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

Marked as reviewed by aefimov (Committer).

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

From mik3hall at gmail.com  Mon Jun  6 00:58:16 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 5 Jun 2022 19:58:16 -0500
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v2]
In-Reply-To: <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
Message-ID: <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>

> 
> ./build/*/images/jdk/bin/jpackage --app-image ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)"
> Bundler Mac DMG Package skipped because of a configuration problem: When using an external app image you must specify the app name. 
> Advice to fix: Set the app name via the -name CLI flag, the fx:application/@name ANT attribute, or via the 'appName' bundler argument.
> 
> ./build/*/images/jdk/bin/jpackage --app-image ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)" --name HalfPipe
> Warning: Using unsigned app-image to build signed dmg.
> 
> *** The app-image was actually a signed one. I?m not sure that matters. Also since this would normally be my intention should there be a warning? ***
> 
> codesign -v --verbose=4 ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
> /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: valid on disk
> /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: satisfies its Designated Requirement
> 
> *** Seems successful ***
> 
> Thanks again.
> 

Possibly my mistake somehow but codesign seems to flag something if the application is actually unsigned.

${PACKAGER} \
	--verbose \
    --add-modules java.desktop,java.prefs,java.se \
    --type app-image \
	--input ./input \
	--app-version 1.0  \
	--name BlackJack\ Blastoff_Unsigned \
	--main-jar bjb.jar \
	--main-class org.bjb.BlackJackApp \
	--java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50  -Dapple.laf.useScreenMenuBar=true -Dcom.apple.mrj.application.apple.menu.about.name=BlackjackBlastoff -Dapple.awt.application.name=Blackjack\ Blastoff? 

[19:41:02.231] Creating app package: BlackJack Blastoff_Unsigned.app in /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg
[19:41:05.516] Command [PID: -1]:
    jlink --output /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack Blastoff_Unsigned.app/Contents/runtime/Contents/Home --module-path /Library/Java/JavaVirtualMachines/jdk-18.jdk/Contents/Home/jmods --add-modules java.desktop,java.prefs,java.se --strip-native-commands --strip-debug --no-man-pages --no-header-files
[19:41:05.517] Output:
    
[19:41:05.518] Returned: 0

[19:41:05.545] Using default package resource JavaApp.icns [icon] (add BlackJack Blastoff_Unsigned.icns to the resource-dir to customize).
[19:41:05.547] Preparing Info.plist: /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack Blastoff_Unsigned.app/Contents/Info.plist.
[19:41:05.547] Using default package resource Info-lite.plist.template [Application Info.plist] (add Info.plist to the resource-dir to customize).
[19:41:05.550] Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize).
[19:41:05.551] Succeeded in building Mac Application Image package

./build/*/images/jdk/bin/jpackage --app-image ~/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack\ Blastoff_Unsigned.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)" --name BlackJack_Blastoff_Unsigned
Warning: Using unsigned app-image to build signed dmg.

 open BlackJack_Blastoff_Unsigned-1.0.dmg           
                                          
codesign -v --verbose=4 /Volumes/BlackJack_Blastoff_Unsigned/BlackJack\ Blastoff_Unsigned.app
/Volumes/BlackJack_Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: code has no resources but signature indicates they must be present

I am using the installed jdk18 to create the app-image. Would that need to be done with the same jdk with the changes applied? 

From xgong at openjdk.java.net  Mon Jun  6 01:38:29 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 6 Jun 2022 01:38:29 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
 <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>
 <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>
Message-ID: <ISDc8AYKbO25Ifkr3Y06wmmwwXn7n_jMo41lMN_ivgI=.fe4d2691-f6b8-4ed6-9d08-c39a339a8d79@github.com>

On Thu, 2 Jun 2022 03:24:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> @XiaohongGong Could you please rebase the branch and resolve conflicts?
>> 
>> Sure, I'm working on this now. The patch will be updated soon. Thanks.
>
>> > @XiaohongGong Could you please rebase the branch and resolve conflicts?
>> 
>> Sure, I'm working on this now. The patch will be updated soon. Thanks.
> 
> Resolved the conflicts. Thanks!

> @XiaohongGong You need one more review approval.

Sure! Thanks a lot for the review!

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

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

From xgong at openjdk.java.net  Mon Jun  6 01:38:31 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 6 Jun 2022 01:38:31 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
Message-ID: <qyQ0J7SUfPXP3d7jUJ3YnbyNBvgkEsJAqZjl1I5rkOY=.408e2c88-2463-48e5-83e3-d2136e7b3582@github.com>

On Thu, 12 May 2022 16:07:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename "use_predicate" to "needs_predicate"
>
> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
> 
>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>   ** missing constant: offsetInRange=Parm
>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
> 
> 
> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).

Hi @PaulSandoz , could you please take a look at this PR again? Thanks so much!

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

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

From alanb at openjdk.java.net  Mon Jun  6 05:32:25 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Jun 2022 05:32:25 GMT
Subject: RFR: JDK-8287838: Update Float and Double to use snippets
In-Reply-To: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
References: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
Message-ID: <AEKNpDe0b9R7xLHhNR_82GYBJ4ChPe775oUA9ViyhkE=.d07f6f9d-4995-4065-8cf3-a20b1e3d68d4@github.com>

On Sun, 5 Jun 2022 21:19:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Various code blocks in Float and Double would be better as snippets.

One other thing you could do is link Pattern.matches in the snippet to the matches method.

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

Marked as reviewed by alanb (Reviewer).

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

From jai.forums2013 at gmail.com  Mon Jun  6 07:01:47 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 6 Jun 2022 12:31:47 +0530
Subject: JDK-8186958 - Behaviour of large values for numMapping in
 WeakHashMap.newWeakHashMap API
Message-ID: <9f177593-b040-53bb-22ba-23b2e19cfc39@gmail.com>

In a recent enhancement we added new APIs to construct LinkedHashMap, 
HashMap and WeakHashMap instances as part of 
https://bugs.openjdk.java.net/browse/JDK-8186958.

Since we missed adding tests for that change, I have been working on 
adding some basic tests for this change as part of 
https://bugs.openjdk.java.net/browse/JDK-8285405. The draft PR is here 
https://github.com/openjdk/jdk/pull/9036.

It's in draft state because it has uncovered an aspect of this change 
that we might have to address or document for these new APIs. 
Specifically, the tests I added now have a test which does the 
equivalent of:

// numMappings = 2147483647
var w = WeakHashMap.newWeakHashMap(Integer.MAX_VALUE);

Similar tests have been added for HashMap and LinkedHashMap too, but for 
the sake of this discussion, I'll focus on WeakHashMap. Running this 
code/test runs into:

test NewWeakHashMap.testNewWeakHashMapNonNegative(2147483647): failure
java.lang.OutOfMemoryError: Java heap space
 ?? ?at java.base/java.util.WeakHashMap.newTable(WeakHashMap.java:194)
 ?? ?at java.base/java.util.WeakHashMap.<init>(WeakHashMap.java:221)
 ?? ?at java.base/java.util.WeakHashMap.<init>(WeakHashMap.java:238)
 ?? ?at 
java.base/java.util.WeakHashMap.newWeakHashMap(WeakHashMap.java:1363)
 ?? ?at NewWeakHashMap.testNewWeakHashMapNonNegative(NewWeakHashMap.java:69)


This exception happens with only WeakHashMap. LinkedHashMap and HashMap 
don't show this behaviour. It appears that WeakHashMap eagerly creates 
an large array (of length 1073741824 in this case) in the newTable 
method which gets called by its constructor.

This raises a few questions about these new APIs - these APIs take an 
integer and the document allows positive values. So the current 
Integer.MAX_VALUE in theory is a valid integer value for this API. 
Should these APIs document what might happen when such a large 
numMapping is passed to it? Should that documentation be different for 
different classes (as seen the HashMap and LinkedHashMap behave 
differently as compared to WeakHashMap)? Should this "numMappings" be 
considered a hard value? In other words, the current documentation of 
this new API states:

"Creates a new, empty WeakHashMap suitable for the expected number of 
mappings
....
and its initial capacity is generally large enough so that the expected 
number
of mappings can be added without resizing the map."

The documentation doesn't seem to guarantee that the resizing won't 
occur. So in cases like these where the numMappings is a very large 
value, should the implementation(s) have logic which doesn't trigger 
this OOM error?

-Jaikiran



From alanb at openjdk.java.net  Mon Jun  6 07:19:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Jun 2022 07:19:32 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
Message-ID: <kldcMhqfseCCQTxeaZcUuIzyRSwXRNN64ynB-nBdxLk=.d7d5d1c4-101f-4873-a940-5b2cd5ab846a@github.com>

On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed missing BufferedInputStream

Can this PR be closed or returned to daft?

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

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

From jbhateja at openjdk.java.net  Mon Jun  6 10:44:50 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 6 Jun 2022 10:44:50 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
Message-ID: <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>

On Thu, 2 Jun 2022 03:27:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

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

test/micro/org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java line 97:

> 95:     public void byteLoadArrayMaskIOOBE() {
> 96:         for (int i = 0; i < inSize; i += bspecies.length()) {
> 97:             VectorMask<Byte> mask = VectorMask.fromArray(bspecies, m, i);

For other case "if (offset >= 0 && offset <= (a.length - species.length())) )" we are anyways intrinsifying, should we limit this micro to work only for newly optimized case.

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

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

From adinn at openjdk.java.net  Mon Jun  6 12:05:37 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 6 Jun 2022 12:05:37 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v15]
In-Reply-To: <-AP9X7rJrdRJzS6F4qxlReVZIxw07fwXTgoCiV1B2O4=.6f21a7da-522c-4a91-8c4e-7a2a5a6be853@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <-AP9X7rJrdRJzS6F4qxlReVZIxw07fwXTgoCiV1B2O4=.6f21a7da-522c-4a91-8c4e-7a2a5a6be853@github.com>
Message-ID: <-1fP_bLO6MOHoVqxpdPZIhe70GQci6qqH0Ahz1lZST0=.16d9d502-2b6b-4b38-86f6-9c14fae472de@github.com>

On Wed, 1 Jun 2022 10:37:23 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

Hallelujah!

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

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

From duke at openjdk.java.net  Mon Jun  6 13:05:10 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 13:05:10 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale
Message-ID: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>

- cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
- `defaultLocale` field is read multiple times in `initDefault()`
- `isoLanguages` is accessed multiple times in `getISOLanguages()`
- `languageTag` is read twice in `toLanguageTag()`

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

Commit messages:
 - 8287860: Revise usage of volatile in j.u.Locale

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

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

From jpai at openjdk.java.net  Mon Jun  6 13:19:57 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 6 Jun 2022 13:19:57 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <xZUKGdJD4aQf8b-5HcP5e8o0yoFtJx8U5Odk2RNKlV8=.ea2599da-ce1b-4c23-9521-a0fb375f376b@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by jpai (Reviewer).

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

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

From duke at openjdk.java.net  Mon Jun  6 13:23:40 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 6 Jun 2022 13:23:40 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale
In-Reply-To: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
Message-ID: <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>

On Mon, 6 Jun 2022 12:58:39 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
> - `defaultLocale` field is read multiple times in `initDefault()`
> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`

src/java.base/share/classes/java/util/Locale.java line 2260:

> 2258:      * Calculated hashcode
> 2259:      */
> 2260:     private transient volatile int hashCodeValue;

We can additionally annotate such cache fields with `@Stable` so as to enable constant-folding optimizations from the hotspot JIT.

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

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

From jpai at openjdk.java.net  Mon Jun  6 13:30:41 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 6 Jun 2022 13:30:41 GMT
Subject: RFR: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
In-Reply-To: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
References: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
Message-ID: <RlYRLnnZQdpHHHd8YqHHaFnL-zbEAnJ3hxcpcUh3Zi0=.631176fa-4d9f-4cc3-800c-e3a95ff1cf93@github.com>

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

Looks fine to me. Please wait for another review before merging.

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

Marked as reviewed by jpai (Reviewer).

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

From duke at openjdk.java.net  Mon Jun  6 13:30:53 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 13:30:53 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale
In-Reply-To: <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
Message-ID: <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>

On Mon, 6 Jun 2022 13:20:31 GMT, liach <duke at openjdk.java.net> wrote:

>> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
>> - `defaultLocale` field is read multiple times in `initDefault()`
>> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
>> - `languageTag` is read twice in `toLanguageTag()`
>
> src/java.base/share/classes/java/util/Locale.java line 2260:
> 
>> 2258:      * Calculated hashcode
>> 2259:      */
>> 2260:     private transient volatile int hashCodeValue;
> 
> We can additionally annotate such cache fields with `@Stable` so as to enable constant-folding optimizations from the hotspot JIT.

Shouldn't the fields annotated with `@Stable` be `final` as well?

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

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

From duke at openjdk.java.net  Mon Jun  6 13:36:53 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 6 Jun 2022 13:36:53 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale
In-Reply-To: <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
 <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>
Message-ID: <D1-tfdaeVuBYn-hbEAuchSlpDNnZCX69k0BLWcyiIbs=.ccf96252-9c46-4356-8abd-0a2c98bb7e2c@github.com>

On Mon, 6 Jun 2022 13:28:44 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 2260:
>> 
>>> 2258:      * Calculated hashcode
>>> 2259:      */
>>> 2260:     private transient volatile int hashCodeValue;
>> 
>> We can additionally annotate such cache fields with `@Stable` so as to enable constant-folding optimizations from the hotspot JIT.
>
> Shouldn't the fields annotated with `@Stable` be `final` as well?

These fields can only be written once besides the default values, but they don't have to be written in the static initializer or constructor. So when a non-zero hash code is written, it's cached as if it's a final field. For a zero value, it would always undergo extra calculations like before and write multiple times, but the writes don't matter as it would only write zero, which would not yield false hash code if a previously written 0 value is cached.

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

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

From duke at openjdk.java.net  Mon Jun  6 13:36:54 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 6 Jun 2022 13:36:54 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale
In-Reply-To: <D1-tfdaeVuBYn-hbEAuchSlpDNnZCX69k0BLWcyiIbs=.ccf96252-9c46-4356-8abd-0a2c98bb7e2c@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
 <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>
 <D1-tfdaeVuBYn-hbEAuchSlpDNnZCX69k0BLWcyiIbs=.ccf96252-9c46-4356-8abd-0a2c98bb7e2c@github.com>
Message-ID: <7rNyXMbX0726bJEVVqPzt_11kBrVK9Y-d51Z9nmaEeI=.05a0a3eb-f0ad-4085-a2bb-473da56275a3@github.com>

On Mon, 6 Jun 2022 13:32:21 GMT, liach <duke at openjdk.java.net> wrote:

>> Shouldn't the fields annotated with `@Stable` be `final` as well?
>
> These fields can only be written once besides the default values, but they don't have to be written in the static initializer or constructor. So when a non-zero hash code is written, it's cached as if it's a final field. For a zero value, it would always undergo extra calculations like before and write multiple times, but the writes don't matter as it would only write zero, which would not yield false hash code if a previously written 0 value is cached.

> Shouldn't the fields annotated with `@Stable` be `final` as well?

You might have seen `@Stable final` fields. Those are only meaningful for arrays, where such caching happens at each array index. For non-arrays, `@Stable final` is simply equivalent to `final`, and simple `@Stable` acts as what I said above.

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

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

From duke at openjdk.java.net  Mon Jun  6 13:47:40 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 6 Jun 2022 13:47:40 GMT
Subject: RFR: JDK-8287838: Update Float and Double to use snippets
In-Reply-To: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
References: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
Message-ID: <6VGqKVZK_-QvvVHwpQJe80sJbRUeb-d0m7qp7zpNO0o=.ae645f87-d146-4c1f-a412-1f9a37951b5b@github.com>

On Sun, 5 Jun 2022 21:19:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Various code blocks in Float and Double would be better as snippets.

src/java.base/share/classes/java/lang/Double.java line 643:

> 641:      * expression below can be used to screen the input string:
> 642:      *
> 643:      *  {@snippet lang="java" :

Mind remove the extra space before `{`?

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

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

From jpai at openjdk.java.net  Mon Jun  6 13:53:52 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 6 Jun 2022 13:53:52 GMT
Subject: RFR: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException
In-Reply-To: <aCZW2JjQSmaVH6Ow9D177gQHBa_q6R6k1tYYfRmSY9c=.64cf3e3b-3ec3-437d-b7c7-59c922c57791@github.com>
References: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
 <aCZW2JjQSmaVH6Ow9D177gQHBa_q6R6k1tYYfRmSY9c=.64cf3e3b-3ec3-437d-b7c7-59c922c57791@github.com>
Message-ID: <g4noYFFKLpbvumVPgqJaN1_kKUPx-zBFBwengHg1GP4=.9b3515d1-6f00-41bf-b4d6-4e1d59e01089@github.com>

On Wed, 27 Apr 2022 13:33:29 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException
>
> If this is a valid change, could someone please create a Jira issue to link to it?

Hello @Thihup, overall this change looks fine to me. Can you please update the copyright year on that file's header to `Copyright (c) 1995, 2022,`?

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

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

From duke at openjdk.java.net  Mon Jun  6 14:36:03 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 14:36:03 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale [v2]
In-Reply-To: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
Message-ID: <KibQ69PG_ptQjnEavrpaTSMyg2wJ42lCpJcP_-dmLp8=.0b8f5990-bfe4-47a3-8919-5232bb2a613b@github.com>

> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
> - `defaultLocale` field is read multiple times in `initDefault()`
> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`

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

  8287860: Mark hash fields with @Stable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9041/files
  - new: https://git.openjdk.java.net/jdk/pull/9041/files/d64917f1..d4534346

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

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

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

From duke at openjdk.java.net  Mon Jun  6 14:36:05 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 14:36:05 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale [v2]
In-Reply-To: <7rNyXMbX0726bJEVVqPzt_11kBrVK9Y-d51Z9nmaEeI=.05a0a3eb-f0ad-4085-a2bb-473da56275a3@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
 <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>
 <D1-tfdaeVuBYn-hbEAuchSlpDNnZCX69k0BLWcyiIbs=.ccf96252-9c46-4356-8abd-0a2c98bb7e2c@github.com>
 <7rNyXMbX0726bJEVVqPzt_11kBrVK9Y-d51Z9nmaEeI=.05a0a3eb-f0ad-4085-a2bb-473da56275a3@github.com>
Message-ID: <QtlR0tRSkZ3FRD_PWQyz8F4WLPOJ-KuTl9Kfp2jm0VM=.a59e1d6d-35af-4df3-ae66-cbeabfedbcaf@github.com>

On Mon, 6 Jun 2022 13:34:27 GMT, liach <duke at openjdk.java.net> wrote:

>> These fields can only be written once besides the default values, but they don't have to be written in the static initializer or constructor. So when a non-zero hash code is written, it's cached as if it's a final field. For a zero value, it would always undergo extra calculations like before and write multiple times, but the writes don't matter as it would only write zero, which would not yield false hash code if a previously written 0 value is cached.
>
>> Shouldn't the fields annotated with `@Stable` be `final` as well?
> 
> You might have seen `@Stable final` fields. Those are only meaningful for arrays, where such caching happens at each array index. For non-arrays, `@Stable final` is simply equivalent to `final`, and simple `@Stable` acts as what I said above.

Done!

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

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

From duke at openjdk.java.net  Mon Jun  6 14:53:47 2022
From: duke at openjdk.java.net (Markus KARG)
Date: Mon, 6 Jun 2022 14:53:47 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
Message-ID: <hjfe4GhKuminQJTG8yYMatNhw27LiJm_eJFfyNwcq5Y=.e8b3bd14-be0d-4420-a2b6-cccb593238f4@github.com>

On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed missing BufferedInputStream

I think we should turn it back to draft.

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

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

From duke at openjdk.java.net  Mon Jun  6 14:58:25 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Mon, 6 Jun 2022 14:58:25 GMT
Subject: RFR: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException [v3]
In-Reply-To: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
References: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
Message-ID: <zKY2VNJDlNEtFYMUXsXVkv83dZwnMuwMFa3jfdN-FFI=.2fd544c5-67da-4ee3-9192-21d89cbe0efb@github.com>

> 8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8400/files
  - new: https://git.openjdk.java.net/jdk/pull/8400/files/f83dde2f..876f45c5

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

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

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

From duke at openjdk.java.net  Mon Jun  6 14:58:25 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Mon, 6 Jun 2022 14:58:25 GMT
Subject: RFR: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException
In-Reply-To: <aCZW2JjQSmaVH6Ow9D177gQHBa_q6R6k1tYYfRmSY9c=.64cf3e3b-3ec3-437d-b7c7-59c922c57791@github.com>
References: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
 <aCZW2JjQSmaVH6Ow9D177gQHBa_q6R6k1tYYfRmSY9c=.64cf3e3b-3ec3-437d-b7c7-59c922c57791@github.com>
Message-ID: <B8NPlk_VY1NGFB3FWNAlgadlAZn2mY4lYYNw2lzEEKk=.4809f254-59bd-4276-9b40-7cd06ff7d195@github.com>

On Wed, 27 Apr 2022 13:33:29 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException
>
> If this is a valid change, could someone please create a Jira issue to link to it?

@Thihup Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more information.

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

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

From lancea at openjdk.java.net  Mon Jun  6 15:15:44 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 6 Jun 2022 15:15:44 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <PIUXlHL_c4nBilt6NRtOkjiwQILSo6UP-qsdQGWcukE=.75873fa5-6034-49b9-96b3-6ab4ccc14732@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by lancea (Reviewer).

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

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

From jpai at openjdk.java.net  Mon Jun  6 15:40:02 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 6 Jun 2022 15:40:02 GMT
Subject: RFR: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException [v3]
In-Reply-To: <zKY2VNJDlNEtFYMUXsXVkv83dZwnMuwMFa3jfdN-FFI=.2fd544c5-67da-4ee3-9192-21d89cbe0efb@github.com>
References: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
 <zKY2VNJDlNEtFYMUXsXVkv83dZwnMuwMFa3jfdN-FFI=.2fd544c5-67da-4ee3-9192-21d89cbe0efb@github.com>
Message-ID: <60r27iXDArPD-jh2U_MiWvyuhOcwqonThVlhKz9n7Zs=.0bb2a4c0-d672-4dab-ba91-9e863ee6d6c6@github.com>

On Mon, 6 Jun 2022 14:58:25 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by jpai (Reviewer).

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

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

From psandoz at openjdk.java.net  Mon Jun  6 15:44:50 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 6 Jun 2022 15:44:50 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
Message-ID: <C-9nZ4OWaMHiiPyXSIo6ecFnlPLO1PYQLOBXENrkvqY=.942859a4-2e63-4ed2-8528-a7945c0d35bd@github.com>

On Thu, 2 Jun 2022 03:27:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

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

Looks good. As a follow on PR I think it would be useful to add constants `OFFSET_IN_RANGE` and `OFFSET_OUT_OF_RANGE`, then it becomes much clearer in source and you can drop the `/* offsetInRange */` comment on the argument.

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

Marked as reviewed by psandoz (Reviewer).

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

From psandoz at openjdk.java.net  Mon Jun  6 15:46:44 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 6 Jun 2022 15:46:44 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v3]
In-Reply-To: <z8emjRJh3LJXFKMfHJgm61Le01eenFzGzApO25zyH6s=.5553793a-5bd1-4fa8-8848-ae113223ffff@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <z8emjRJh3LJXFKMfHJgm61Le01eenFzGzApO25zyH6s=.5553793a-5bd1-4fa8-8848-ae113223ffff@github.com>
Message-ID: <lG90w9lR8JleFLGRS91SwSti7sTKLma7h-jXfbji80c=.b1945271-8331-4f88-bab6-b6471afa4600@github.com>

On Thu, 2 Jun 2022 01:29:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
>> 
>> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
>> 
>> Benchmark                                   Before    After     Gain Units
>> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
>> 
>> Similar performane gain can also be observed on ARM hardware.
>
> Xiaohong Gong 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 'jdk:master' to JDK-8286279
>  - Wrap the offset check into a static method
>  - 8286279: [vectorapi] Only check index of masked lanes if offset is out of array boundary for masked store

Marked as reviewed by psandoz (Reviewer).

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

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

From naoto at openjdk.java.net  Mon Jun  6 15:50:39 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Jun 2022 15:50:39 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252" [v2]
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <2nrJW64dS7XJIqFiHzSVQ6lrZqwTF5yi6JxUWQyQPFc=.d5acfba0-a78a-4b59-8429-f7698ecb80c1@github.com>

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

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

  Changed per suggestion

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9019/files
  - new: https://git.openjdk.java.net/jdk/pull/9019/files/72d27809..51ce3615

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

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

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

From naoto at openjdk.java.net  Mon Jun  6 15:50:42 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Jun 2022 15:50:42 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252" [v2]
In-Reply-To: <tP13YR4kuRlnwDNmLarYlJOxC5uJzgndoDUNQy8bu4E=.73908ccb-b81f-40ab-8981-e1854c462562@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
 <tP13YR4kuRlnwDNmLarYlJOxC5uJzgndoDUNQy8bu4E=.73908ccb-b81f-40ab-8981-e1854c462562@github.com>
Message-ID: <ypNlEHC_fV9UQINB_f6N9wPpPiEHzCwVU74ivIjtIbU=.e023d50b-f51c-48ae-98fa-8a14fa37df03@github.com>

On Sat, 4 Jun 2022 11:27:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed per suggestion
>
> src/java.base/share/classes/java/lang/String.java line 849:
> 
>> 847:         int en = scale(len, ce.maxBytesPerChar());
>> 848:         // fastpath with ArrayEncoder implies `doReplace`.
>> 849:         if (ce instanceof ArrayEncoder ae && doReplace) {
> 
> Wouldn't it be more readable (and perphaps faster) if we do check boolean flag first?

Fixed.

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

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

From duke at openjdk.java.net  Mon Jun  6 15:52:43 2022
From: duke at openjdk.java.net (Chris Hennick)
Date: Mon, 6 Jun 2022 15:52:43 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v4]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <SYAplxJqDptLONrqCj68EFdT0imRaa5CC_uFEJWiKhE=.845cbffe-5709-4c53-813c-22c9cce1a04d@github.com>

> Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around 2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1); this fixes that by tracking the multiple of exponentialX0 as a long. (This changes the maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once `extra` reaches that amount, `x + extra == extra` due to the rounding error. This lowers the probability of reaching the maximum with an ideal PRNG from about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`).

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

 - Merge branch 'openjdk:master' into patch-1
 - Merge branch 'openjdk:master' into patch-1
 - Fix rounding error in computeNextExponential; use FMA
   
   Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution; this fixes that by tracking the multiple of exponentialX0 as a long.
   
   Add computeWinsorizedNextExponential for testability

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8131/files
  - new: https://git.openjdk.java.net/jdk/pull/8131/files/c5a28f98..1daaadac

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

  Stats: 1548 lines in 42 files changed: 1399 ins; 60 del; 89 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8131/head:pull/8131

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

From duke at openjdk.java.net  Mon Jun  6 15:52:46 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Mon, 6 Jun 2022 15:52:46 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v2]
In-Reply-To: <7m6K5gGQ5d7RT6B2NEs-yoTUf0MvFnHBYGliX-AzfTk=.2dc34336-0596-4ad6-b3ad-a453bbe54e55@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <tLFnjsmh6nxUhe4loczFlRSfrId5nAolg3numbLsnxo=.9f749945-da45-4d0e-bd5d-916a4aec19e0@github.com>
 <7m6K5gGQ5d7RT6B2NEs-yoTUf0MvFnHBYGliX-AzfTk=.2dc34336-0596-4ad6-b3ad-a453bbe54e55@github.com>
Message-ID: <8cIIjWFD24fQzn-qET8Wy7sMlksve2E2LBZEAfP_q00=.615990a2-ad98-4ad7-92ba-16f16456b252@github.com>

On Thu, 2 Jun 2022 03:00:32 GMT, Chris Hennick <duke at openjdk.java.net> wrote:

>> Chris Hennick 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:
>> 
>>   Fix rounding error in computeNextExponential; use FMA
>>   
>>   Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution; this fixes that by tracking the multiple of exponentialX0 as a long.
>>   
>>   Add computeWinsorizedNextExponential for testability
>
> In addition to the changes discussed heretofore, I've also changed line 1382 to eliminate unneeded tail exploration; this should make `nextGaussian` faster at high percentiles (probably measurable at 99%ile; should definitely be measurable at  at 99.99%ile).

@Pr0methean Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more information.

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

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

From lp.coolbeans at proton.me  Sun Jun  5 07:59:59 2022
From: lp.coolbeans at proton.me (LP)
Date: Sun, 05 Jun 2022 07:59:59 +0000
Subject: Questions about Float.toString(float)
Message-ID: <d4gVPmIbWaLOQ1LXcwhAjAHhjL9IJqxJILc7AQp74ZaAbHd9o00nOOZPJ0jQ6dvrLYDLg1sQJa7YL8HJnyDvxJtNVGgjUYcqlyGP2chg2QU=@proton.me>

Hi,

(1)
float f = Float.intBitsToFloat(260046848);

JDK 17: Float.toString(f) -> 1.26217745E-29
master: Float.toString(f) -> 1.2621775E-29

BigDecimal.valueOf(Float.intBitsToFloat(260046847)) -> 1.2621773731219804E-29
BigDecimal.valueOf(Float.intBitsToFloat(260046848)) -> 1.2621774483536189E-29
BigDecimal.valueOf(Float.intBitsToFloat(260046849)) -> 1.2621775988168958E-29

What about 1.2621774E-29? I believe both 1.2621774E-29 and 1.2621775E-29 satisfy the Javadoc of Float.toString(float), so maybe it doesn't matter, but 1.2621774E-29 is closer to f.

(2)
float f = Float.intBitsToFloat(1291845637);

JDK 17: Float.toString(f) -> 1.34217808E8
master: Float.toString(f) -> 1.3421781E8

BigDecimal.valueOf(Float.intBitsToFloat(1291845636)) -> 134217792
BigDecimal.valueOf(Float.intBitsToFloat(1291845637)) -> 134217808
BigDecimal.valueOf(Float.intBitsToFloat(1291845638)) -> 134217824

What about 1.342178E8? 1.3421781E8 is an improvement over 1.34217808E8, but it's still not conforming to the Javadoc if 1.342178E8 is valid.

Apologies if I misunderstood something.

Thanks,
LP

From raffaello.giulietti at oracle.com  Mon Jun  6 16:36:41 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Mon, 6 Jun 2022 18:36:41 +0200
Subject: Questions about Float.toString(float)
In-Reply-To: <d4gVPmIbWaLOQ1LXcwhAjAHhjL9IJqxJILc7AQp74ZaAbHd9o00nOOZPJ0jQ6dvrLYDLg1sQJa7YL8HJnyDvxJtNVGgjUYcqlyGP2chg2QU=@proton.me>
References: <d4gVPmIbWaLOQ1LXcwhAjAHhjL9IJqxJILc7AQp74ZaAbHd9o00nOOZPJ0jQ6dvrLYDLg1sQJa7YL8HJnyDvxJtNVGgjUYcqlyGP2chg2QU=@proton.me>
Message-ID: <c2102e6f-076c-d36a-3ee7-588eef7559f6@oracle.com>



On 2022-06-05 09:59, LP wrote:
> Hi,
> 
> (1)
> float f = Float.intBitsToFloat(260046848);
> 
> JDK 17: Float.toString(f) -> 1.26217745E-29
> master: Float.toString(f) -> 1.2621775E-29
> 
> BigDecimal.valueOf(Float.intBitsToFloat(260046847)) -> 1.2621773731219804E-29
> BigDecimal.valueOf(Float.intBitsToFloat(260046848)) -> 1.2621774483536189E-29
> BigDecimal.valueOf(Float.intBitsToFloat(260046849)) -> 1.2621775988168958E-29
> 
> What about 1.2621774E-29? I believe both 1.2621774E-29 and 1.2621775E-29 satisfy the Javadoc of Float.toString(float), so maybe it doesn't matter, but 1.2621774E-29 is closer to f.
> 

In addition to f above, let
float g = Float.intBitsToFloat(260046847);

Then
f == 1.2621775E-29f  -> true
g == 1.2621774E-29f  -> true

Hence, 1.2621774E-29f rounded to the closest float is g, not f.
1.2621775E-29f is indeed the shortest decimal that rounds to f. Other 
equally long decimals like 1.2621774E-29f or 1.2621776E-29f do not round 
to f but to other floats.

So, no, 1.2621774E-29 does not satisfy the spec for f. Only 
1.2621775E-29 does.


> (2)
> float f = Float.intBitsToFloat(1291845637);
> 
> JDK 17: Float.toString(f) -> 1.34217808E8
> master: Float.toString(f) -> 1.3421781E8
> 
> BigDecimal.valueOf(Float.intBitsToFloat(1291845636)) -> 134217792
> BigDecimal.valueOf(Float.intBitsToFloat(1291845637)) -> 134217808
> BigDecimal.valueOf(Float.intBitsToFloat(1291845638)) -> 134217824
> 
> What about 1.342178E8? 1.3421781E8 is an improvement over 1.34217808E8, but it's still not conforming to the Javadoc if 1.342178E8 is valid.
> 

Again, 1.342178E8f < 1.3421781E8f, so these are decimals representing 
two different floats. Only 1.3421781E8f rounds to your f, whereas 
1.342178E8f rounds to
float g = Float.intBitsToFloat(1291845636);




> Apologies if I misunderstood something.
> 
> Thanks,
> LP

From duke at openjdk.java.net  Mon Jun  6 20:37:00 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 20:37:00 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale [v3]
In-Reply-To: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
Message-ID: <hup7l7k0liltzsNfvr2t5LZICKpaxt_NO1GnxpCQDKA=.f618c8b6-df4f-4892-a1c9-e1f3080b277e@github.com>

> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
> - `defaultLocale` field is read multiple times in `initDefault()`
> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`

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

  8287860: Rename local vars

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9041/files
  - new: https://git.openjdk.java.net/jdk/pull/9041/files/d4534346..454621d4

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

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

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

From naoto at openjdk.java.net  Mon Jun  6 20:37:02 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Jun 2022 20:37:02 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale [v3]
In-Reply-To: <hup7l7k0liltzsNfvr2t5LZICKpaxt_NO1GnxpCQDKA=.f618c8b6-df4f-4892-a1c9-e1f3080b277e@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <hup7l7k0liltzsNfvr2t5LZICKpaxt_NO1GnxpCQDKA=.f618c8b6-df4f-4892-a1c9-e1f3080b277e@github.com>
Message-ID: <KfTjMp1o3yKgnYdVV7Oh1YUxHeF-U4Z4FOwbX-n6aPU=.777415ac-9838-4abd-8160-009128de59be@github.com>

On Mon, 6 Jun 2022 20:19:22 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
>> - `defaultLocale` field is read multiple times in `initDefault()`
>> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
>> - `languageTag` is read twice in `toLanguageTag()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287860: Rename local vars

Looks good. Thanks for fixing this.

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

Marked as reviewed by naoto (Reviewer).

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

From naoto at openjdk.java.net  Mon Jun  6 20:37:15 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Jun 2022 20:37:15 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale [v2]
In-Reply-To: <KibQ69PG_ptQjnEavrpaTSMyg2wJ42lCpJcP_-dmLp8=.0b8f5990-bfe4-47a3-8919-5232bb2a613b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <KibQ69PG_ptQjnEavrpaTSMyg2wJ42lCpJcP_-dmLp8=.0b8f5990-bfe4-47a3-8919-5232bb2a613b@github.com>
Message-ID: <sj-KZHlLb0p9flbo28uNbAsBWTt9oQHSRglH9OKKNi0=.36bf5b9b-70f0-49cb-8b3b-310f8d96dd3c@github.com>

On Mon, 6 Jun 2022 14:36:03 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
>> - `defaultLocale` field is read multiple times in `initDefault()`
>> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
>> - `languageTag` is read twice in `toLanguageTag()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287860: Mark hash fields with @Stable

src/java.base/share/classes/java/util/Locale.java line 1084:

> 1082:         Properties props = GetPropertyAction.privilegedGetProperties();
> 1083: 
> 1084:         Locale defaultLocale = Locale.defaultLocale;

I'd use a different local variable name so that it won't clash with the field name. The same holds for other locations (`isoLanguages` and `languageTag`)

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

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

From duke at openjdk.java.net  Mon Jun  6 20:37:18 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 20:37:18 GMT
Subject: RFR: 8287860: Revise usage of volatile in j.u.Locale [v2]
In-Reply-To: <sj-KZHlLb0p9flbo28uNbAsBWTt9oQHSRglH9OKKNi0=.36bf5b9b-70f0-49cb-8b3b-310f8d96dd3c@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <KibQ69PG_ptQjnEavrpaTSMyg2wJ42lCpJcP_-dmLp8=.0b8f5990-bfe4-47a3-8919-5232bb2a613b@github.com>
 <sj-KZHlLb0p9flbo28uNbAsBWTt9oQHSRglH9OKKNi0=.36bf5b9b-70f0-49cb-8b3b-310f8d96dd3c@github.com>
Message-ID: <P_GiK8drzCndNgnzZWV33P0BreOas5dBEIdz-ZybPUY=.b283a39e-5651-4662-8130-d195ad9d177f@github.com>

On Mon, 6 Jun 2022 17:31:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8287860: Mark hash fields with @Stable
>
> src/java.base/share/classes/java/util/Locale.java line 1084:
> 
>> 1082:         Properties props = GetPropertyAction.privilegedGetProperties();
>> 1083: 
>> 1084:         Locale defaultLocale = Locale.defaultLocale;
> 
> I'd use a different local variable name so that it won't clash with the field name. The same holds for other locations (`isoLanguages` and `languageTag`)

Done!

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

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

From xuelei at openjdk.java.net  Mon Jun  6 20:38:20 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 6 Jun 2022 20:38:20 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v5]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <xOgN-k_MY3oiveTMmUpQivTsB_PexA1Zb5yof1of3ZY=.22bc88bf-e18f-4618-8abd-c0fe23277209@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge
 - add timeout parameter
 - rollback is not in this branch
 - rollback JDK-8287384
 - back to wait 1 second
 - Remove trailing white space
 - 8287596: Reorg jdk.test.lib.util.ForceGC

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

Changes: https://git.openjdk.java.net/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=04
  Stats: 87 lines in 10 files changed: 19 ins; 25 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

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

From xuelei at openjdk.java.net  Mon Jun  6 20:38:22 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 6 Jun 2022 20:38:22 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <-revOIfNpbv7XdgrgMTcDwev4E8Px4P6rsage5ucfp0=.61219114-3b76-4610-9faf-af49d34a87fd@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <mapgHsfT5roQkOKhI6TnnAG5Npr-FZ6PnwFW8f5bDhg=.e80e5c06-4123-4bfe-b85b-833fbc8307a2@github.com>
 <-revOIfNpbv7XdgrgMTcDwev4E8Px4P6rsage5ucfp0=.61219114-3b76-4610-9faf-af49d34a87fd@github.com>
Message-ID: <d6pUAXBWdlyaG-JdcZsqdPtLRqDGHDRMRJMhzKGCybM=.c801c828-9033-4903-819e-fa7291da2ccd@github.com>

On Wed, 1 Jun 2022 21:09:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   back to wait 1 second
>
> No, it doesn't work.  You can build a fastdebug build with `configure --enable-debug`.  I reproduce it on macOS.   If I restore to the previous version without 8287384, the test passes.

Inspired by @mlchung (See https://github.com/openjdk/jdk/pull/9021), use less waiting time for  UnloadingTest and re-open this PR.

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

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

From mchung at openjdk.java.net  Mon Jun  6 20:55:01 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 6 Jun 2022 20:55:01 GMT
Subject: RFR: JDK-8287671: Adjust ForceGC to invoke System::gc fewer times
 for negative case
In-Reply-To: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
References: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
Message-ID: <9SBrxC-ibmguvvkKgccQFGO5-Rb71RGvWkiIK0R5KpA=.4305e0f1-f5b3-4904-b5e1-d663471131ce@github.com>

On Fri, 3 Jun 2022 18:05:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This reapplies JDK-8287384 and adjust the number of GCs for negative case, i.e. the condition is never met that is used to verify a reference is not GC'ed.

JDK-8287384 affects the tests using ForceGC for negative cases only.  It will return with a fewer GC cycles of a shortened wait time between each cycle.  It will be okay since a strongly reachable reference will never be GC'ed.

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

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

From naoto at openjdk.java.net  Mon Jun  6 20:55:07 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Jun 2022 20:55:07 GMT
Subject: RFR: 8285081: Improve XPath operators count accuracy [v3]
In-Reply-To: <AkKJqZgQXH2yQT5MtC9qLtFkZqHc6UEd77Q9BkQWnTc=.f14c9a77-659f-47fb-b54e-489f1a1fcd03@github.com>
References: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
 <AkKJqZgQXH2yQT5MtC9qLtFkZqHc6UEd77Q9BkQWnTc=.f14c9a77-659f-47fb-b54e-489f1a1fcd03@github.com>
Message-ID: <HdrXymaRFmSRffhaPxy2TglsLDjy_SP-U2ijsDiJ6N4=.88554b30-f428-4c35-a04e-8651ac263ee9@github.com>

On Fri, 3 Jun 2022 23:56:31 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. 
>> 
>> Test:  
>>      Tier2 passed;
>>      JCK XML tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused parameter

LGTM

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

Marked as reviewed by naoto (Reviewer).

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

From darcy at openjdk.java.net  Mon Jun  6 20:55:53 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Jun 2022 20:55:53 GMT
Subject: RFR: JDK-8287838: Update Float and Double to use snippets [v2]
In-Reply-To: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
References: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
Message-ID: <0dyivtrOQZ3DegpzOqf6aHGtZBeW7FHXX3dixtDEGio=.947eccf1-008b-4274-b1e8-1881311835c2@github.com>

> Various code blocks in Float and Double would be better as snippets.

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

 - Use idiom for shorter lines
 - Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9034/files
  - new: https://git.openjdk.java.net/jdk/pull/9034/files/255fbb15..56abd0ac

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

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

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

From darcy at openjdk.java.net  Mon Jun  6 20:55:56 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Jun 2022 20:55:56 GMT
Subject: RFR: JDK-8287838: Update Float and Double to use snippets [v2]
In-Reply-To: <AEKNpDe0b9R7xLHhNR_82GYBJ4ChPe775oUA9ViyhkE=.d07f6f9d-4995-4065-8cf3-a20b1e3d68d4@github.com>
References: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
 <AEKNpDe0b9R7xLHhNR_82GYBJ4ChPe775oUA9ViyhkE=.d07f6f9d-4995-4065-8cf3-a20b1e3d68d4@github.com>
Message-ID: <uySlbc3bsln0K9Lrzd0KWGab8cAyEbwyNj5p8ltUoOQ=.0f4e53e7-1138-4c0b-a63f-94d5b8c8f833@github.com>

On Mon, 6 Jun 2022 05:29:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One other thing you could do is link Pattern.matches in the snippet to the matches method.

Suggestion made in subsequent push; thanks.

> src/java.base/share/classes/java/lang/Double.java line 683:
> 
>> 681:      *       "[\\x00-\\x20]*");// Optional trailing "whitespace"
>> 682:      *
>> 683:      *  if (Pattern.matches(fpRegex, myString)) // @link substring="Pattern.matches" target ="java.util.regex.Pattern#matches"
> 
> If you want to avoid the annoyingly long line then you can put the "// @link ..." on the previous line if you want.

It can be done with a snippet region like this:


     *  // @link region substring="Pattern.matches" target ="java.util.regex.Pattern#matches"
     *  if (Pattern.matches(fpRegex, myString))
     *      Double.valueOf(myString); // Will not throw NumberFormatException
     * // @end

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

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

From alanb at openjdk.java.net  Mon Jun  6 20:55:57 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Jun 2022 20:55:57 GMT
Subject: RFR: JDK-8287838: Update Float and Double to use snippets [v2]
In-Reply-To: <0dyivtrOQZ3DegpzOqf6aHGtZBeW7FHXX3dixtDEGio=.947eccf1-008b-4274-b1e8-1881311835c2@github.com>
References: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
 <0dyivtrOQZ3DegpzOqf6aHGtZBeW7FHXX3dixtDEGio=.947eccf1-008b-4274-b1e8-1881311835c2@github.com>
Message-ID: <hH7Szcz5kgKiWyHUJn6nR5FuQa0EbHLM122R67_V638=.04b73533-51e9-4410-99ce-23aa84bcd2d2@github.com>

On Mon, 6 Jun 2022 20:37:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Various code blocks in Float and Double would be better as snippets.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use idiom for shorter lines
>  - Respond to review feedback.

src/java.base/share/classes/java/lang/Double.java line 683:

> 681:      *       "[\\x00-\\x20]*");// Optional trailing "whitespace"
> 682:      *
> 683:      *  if (Pattern.matches(fpRegex, myString)) // @link substring="Pattern.matches" target ="java.util.regex.Pattern#matches"

If you want to avoid the annoyingly long line then you can put the "// @link ..." on the previous line if you want.

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

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

From asemenyuk at openjdk.java.net  Mon Jun  6 20:56:35 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 6 Jun 2022 20:56:35 GMT
Subject: RFR: 8250950: Allow per-user and system wide configuration of a
 jpackaged app [v2]
In-Reply-To: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
References: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
Message-ID: <QkM7o4VlfNQawRndrYbNnc6ok8IJAWyDOw4I7vvYAaw=.72ba651c-fac7-45c3-b261-a9f42c8675d3@github.com>

> 8250950: Allow per-user and system wide configuration of a jpackaged app

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

  Add TKit.createDirectories() method that will delete created nonexistent directories.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9025/files
  - new: https://git.openjdk.java.net/jdk/pull/9025/files/af2708b4..1f512ff1

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

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

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

From almatvee at openjdk.java.net  Mon Jun  6 20:56:36 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 6 Jun 2022 20:56:36 GMT
Subject: RFR: 8250950: Allow per-user and system wide configuration of a
 jpackaged app [v2]
In-Reply-To: <QkM7o4VlfNQawRndrYbNnc6ok8IJAWyDOw4I7vvYAaw=.72ba651c-fac7-45c3-b261-a9f42c8675d3@github.com>
References: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
 <QkM7o4VlfNQawRndrYbNnc6ok8IJAWyDOw4I7vvYAaw=.72ba651c-fac7-45c3-b261-a9f42c8675d3@github.com>
Message-ID: <CTyJ9ZdjYy5jvYdKS06Ef977mMLfm2CcBKeWaHWKAYg=.30f68c50-8418-4b67-b117-62cf98dc909a@github.com>

On Mon, 6 Jun 2022 20:37:11 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> 8250950: Allow per-user and system wide configuration of a jpackaged app
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add TKit.createDirectories() method that will delete created nonexistent directories.

Marked as reviewed by almatvee (Reviewer).

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

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

From asemenyuk at openjdk.java.net  Mon Jun  6 20:56:40 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 6 Jun 2022 20:56:40 GMT
Subject: RFR: 8250950: Allow per-user and system wide configuration of a
 jpackaged app
In-Reply-To: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
References: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
Message-ID: <0vWcfnm0ypzssvlXK2dtFRXVZG5T_ar7U431CHPFp0M=.ccdd0101-8839-4a42-b7bc-2b055c8a1223@github.com>

On Fri, 3 Jun 2022 21:07:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8250950: Allow per-user and system wide configuration of a jpackaged app

@sashamatveev please resume the review

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

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

From bchristi at openjdk.java.net  Mon Jun  6 20:57:18 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 6 Jun 2022 20:57:18 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v11]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <LYD3AVtUOswO-r7BPwp_2Dkucwm9z-R9xUVjVB1hCwQ=.e2465d1c-9ec3-46cd-8d7e-19aed4cb16fd@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

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

 - Restore comments in ldap capture file
 - Update test files - add copyright, etc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8311/files
  - new: https://git.openjdk.java.net/jdk/pull/8311/files/e34e888f..0f729619

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

  Stats: 44 lines in 1 file changed: 33 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

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

From aturbanov at openjdk.java.net  Mon Jun  6 21:03:44 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 6 Jun 2022 21:03:44 GMT
Subject: RFR: 8287766: Unnecessary Vector usage in LdapClient
In-Reply-To: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
References: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
Message-ID: <fajyUbplvECaViHrcJswdCEchCxeZsI5jFUdAwJdjks=.f8cf1696-9a94-413e-937a-d9652e8137e0@github.com>

On Sun, 29 May 2022 20:22:55 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> In [JDK-8273098](https://bugs.openjdk.java.net/browse/JDK-8273098) I missed one place, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

Thank you for review!

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

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

From aturbanov at openjdk.java.net  Mon Jun  6 21:03:50 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 6 Jun 2022 21:03:50 GMT
Subject: RFR: 8285285: Avoid redundant allocations in WindowsPreferences
In-Reply-To: <8-W0hk5YK-0sIJewKJLikzklE6V--uui3wCgQLS4suI=.0194a658-1b8d-4deb-b177-0d402d590b5b@github.com>
References: <8-W0hk5YK-0sIJewKJLikzklE6V--uui3wCgQLS4suI=.0194a658-1b8d-4deb-b177-0d402d590b5b@github.com>
Message-ID: <G7VK9JNbv5B60Yx5lHR65NvbtjvzFI07irrSDdqjrI8=.3cd75a2b-37c4-4187-8fd6-bf12482cbcd2@github.com>

On Wed, 20 Apr 2022 19:16:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 1. No need to call `String.substring` if you need need to compare start of string with some constant. `String.startWith` suites better.
> 2. Unused String array is allocated in `childrenNamesSpi` method

Thank you for review!

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

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

From mchung at openjdk.java.net  Mon Jun  6 21:15:11 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 6 Jun 2022 21:15:11 GMT
Subject: Integrated: JDK-8287671: Adjust ForceGC to invoke System::gc fewer
 times for negative case
In-Reply-To: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
References: <JdWTPaObTT3xprkc5CMy1WQLKDgqfjATeHCt35VHRcY=.0c984f0b-550c-405a-8ee9-6b82a91623a5@github.com>
Message-ID: <FzwRCh7URbtr0F7SnNF4WhFnSbNZcXwoBQcwfdw4gEQ=.16952e21-0d06-4c2b-bc6a-b8ad00dee6fd@github.com>

On Fri, 3 Jun 2022 18:05:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This reapplies JDK-8287384 and adjust the number of GCs for negative case, i.e. the condition is never met that is used to verify a reference is not GC'ed.

This pull request has now been integrated.

Changeset: 2e332c27
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2e332c276052554540da0998316a5a99bc350cd6
Stats:     19 lines in 1 file changed: 11 ins; 0 del; 8 mod

8287671: Adjust ForceGC to invoke System::gc fewer times for negative case

Reviewed-by: rriggs, bchristi, xuelei

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

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

From aturbanov at openjdk.java.net  Mon Jun  6 21:18:13 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 6 Jun 2022 21:18:13 GMT
Subject: Integrated: 8287766: Unnecessary Vector usage in LdapClient
In-Reply-To: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
References: <9BF0T4_EihIp23pRjap_Ck5aZoUsPdfodc7NV23DVLs=.afc6dec0-653d-4b9c-8595-36f9892b61b7@github.com>
Message-ID: <ozOqP4EdxJISfxINO1kVm6IIP1n5zBu53xW4y34yZco=.f7da8687-d22b-4654-b01b-e48bd03a2db7@github.com>

On Sun, 29 May 2022 20:22:55 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> In [JDK-8273098](https://bugs.openjdk.java.net/browse/JDK-8273098) I missed one place, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.

This pull request has now been integrated.

Changeset: 3eb49fec
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3eb49feceabe8253b78b794a3d8fdc0556d8f2e2
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8287766: Unnecessary Vector usage in LdapClient

Reviewed-by: dfuchs, vtewari, aefimov

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

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

From aturbanov at openjdk.java.net  Mon Jun  6 21:19:32 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 6 Jun 2022 21:19:32 GMT
Subject: Integrated: 8285285: Avoid redundant allocations in WindowsPreferences
In-Reply-To: <8-W0hk5YK-0sIJewKJLikzklE6V--uui3wCgQLS4suI=.0194a658-1b8d-4deb-b177-0d402d590b5b@github.com>
References: <8-W0hk5YK-0sIJewKJLikzklE6V--uui3wCgQLS4suI=.0194a658-1b8d-4deb-b177-0d402d590b5b@github.com>
Message-ID: <6Psq8sRzwuCRfZTVX5qT3ga_0rvRIT07SioqNYlXE4I=.6bd811f6-8245-4626-ae85-eb9b050dfbc1@github.com>

On Wed, 20 Apr 2022 19:16:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 1. No need to call `String.substring` if you need need to compare start of string with some constant. `String.startWith` suites better.
> 2. Unused String array is allocated in `childrenNamesSpi` method

This pull request has now been integrated.

Changeset: e94b05c7
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e94b05c72046cfc52898917e835794bb1aec548a
Stats:     18 lines in 1 file changed: 0 ins; 2 del; 16 mod

8285285: Avoid redundant allocations in WindowsPreferences

Reviewed-by: jpai

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

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

From darcy at openjdk.java.net  Mon Jun  6 21:30:14 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Jun 2022 21:30:14 GMT
Subject: Integrated: JDK-8287838: Update Float and Double to use snippets
In-Reply-To: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
References: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
Message-ID: <3Uu5RM6DzcxCz19hGQZ2QRM58oVfvY8x7L4xBprifj0=.44295385-8ce1-49ce-b2e1-632d942d05ab@github.com>

On Sun, 5 Jun 2022 21:19:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Various code blocks in Float and Double would be better as snippets.

This pull request has now been integrated.

Changeset: 0e06bf3b
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0e06bf3b04f69c57120d32106a3ae5f69030934d
Stats:     8 lines in 2 files changed: 1 ins; 0 del; 7 mod

8287838: Update Float and Double to use snippets

Reviewed-by: alanb

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

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

From xuelei at openjdk.java.net  Mon Jun  6 21:32:18 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 6 Jun 2022 21:32:18 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v6]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <B6hh39zblVjqpI2us39gKILVNvqU_kJ2LMlAk0yfiok=.1db9f495-f089-4fa8-89bf-513503addc01@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge master
 - Merge
 - add timeout parameter
 - rollback is not in this branch
 - rollback JDK-8287384
 - back to wait 1 second
 - Remove trailing white space
 - 8287596: Reorg jdk.test.lib.util.ForceGC

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

Changes: https://git.openjdk.java.net/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=05
  Stats: 86 lines in 10 files changed: 12 ins; 29 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

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

From darcy at openjdk.java.net  Mon Jun  6 21:56:15 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Jun 2022 21:56:15 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v3]
In-Reply-To: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
Message-ID: <dDpOYbD8kfPxVCgpur-_wvmdbg7GLGyGObMahA59Ulg=.6794dc28-d168-4560-9cf8-119b0239ca69@github.com>

> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.

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

 - Merge branch 'master' into JDK-8273346
 - Merge branch 'master' into JDK-8273346
 - Respond to review feedback; make another pass to link methods to IEEE 754 operations.
 - Merge branch 'master' into JDK-8273346
 - Add floor and ceil.
 - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math and StrictMath

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8876/files
  - new: https://git.openjdk.java.net/jdk/pull/8876/files/9169ad9e..be81f60b

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

  Stats: 17707 lines in 455 files changed: 14288 ins; 2165 del; 1254 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8876.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8876/head:pull/8876

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

From bchristi at openjdk.java.net  Mon Jun  6 21:59:56 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 6 Jun 2022 21:59:56 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v12]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <4GGIocVg1KkEaRWJ28Eda6lsHOzNW-97NsPMyehbc1Y=.4c641ae5-6c35-4908-9a63-e49de8dccbd0@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

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

  Restore EnumCtx to being an inner class, to keep all the state together in the code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8311/files
  - new: https://git.openjdk.java.net/jdk/pull/8311/files/0f729619..c8bdac44

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

  Stats: 90 lines in 1 file changed: 44 ins; 45 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

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

From mchung at openjdk.java.net  Mon Jun  6 22:05:49 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 6 Jun 2022 22:05:49 GMT
Subject: RFR: JDK-8287867: Bad merge of jdk/test/lib/util/ForceGC.java causing
 test compilation error
Message-ID: <yX38UzenO2cthmt-4Bgv0eryJiXMfktNEMXosHpE_IQ=.9c885879-3223-4e23-9605-6064addb5e72@github.com>

A typo in ForceGC.java causes several test failing due to compilation error.

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

Commit messages:
 - JDK-8287867: Bad merge of jdk/test/lib/util/ForceGC.java causing compilation error

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

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

From dcubed at openjdk.java.net  Mon Jun  6 22:19:05 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 6 Jun 2022 22:19:05 GMT
Subject: RFR: JDK-8287867: Bad merge of jdk/test/lib/util/ForceGC.java
 causing test compilation error
In-Reply-To: <yX38UzenO2cthmt-4Bgv0eryJiXMfktNEMXosHpE_IQ=.9c885879-3223-4e23-9605-6064addb5e72@github.com>
References: <yX38UzenO2cthmt-4Bgv0eryJiXMfktNEMXosHpE_IQ=.9c885879-3223-4e23-9605-6064addb5e72@github.com>
Message-ID: <QqQWeoFb5hdol5mQCDviHZt02jNlOL4gow3CP56RhKk=.5a0509b0-a3d8-451b-9acd-e25c35d2b982@github.com>

On Mon, 6 Jun 2022 21:58:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A typo in ForceGC.java causes several test failing due to compilation error.

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

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

From mchung at openjdk.java.net  Mon Jun  6 22:19:06 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 6 Jun 2022 22:19:06 GMT
Subject: RFR: JDK-8287867: Bad merge of jdk/test/lib/util/ForceGC.java
 causing test compilation error
In-Reply-To: <yX38UzenO2cthmt-4Bgv0eryJiXMfktNEMXosHpE_IQ=.9c885879-3223-4e23-9605-6064addb5e72@github.com>
References: <yX38UzenO2cthmt-4Bgv0eryJiXMfktNEMXosHpE_IQ=.9c885879-3223-4e23-9605-6064addb5e72@github.com>
Message-ID: <imVGB05zdCoRl_RBvf0z1hGD_qYYTgIp6q1koO2M4rM=.54daf41b-bf5e-4079-b32e-1f132b2fdcf1@github.com>

On Mon, 6 Jun 2022 21:58:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A typo in ForceGC.java causes several test failing due to compilation error.

thanks for the prompt review.

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

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

From asemenyuk at openjdk.java.net  Mon Jun  6 22:21:59 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 6 Jun 2022 22:21:59 GMT
Subject: Integrated: 8250950: Allow per-user and system wide configuration of a
 jpackaged app
In-Reply-To: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
References: <K_D-c-nBKM05kluFqL3F-lEtNDklWRNgqhGeZAzboK8=.cc73c987-9992-4ed1-a42f-c8b6b65ce230@github.com>
Message-ID: <Dbzr1WYW8i1Fgv3DPb0AfbpppeuUDwrU3FRXi__ybRM=.4f6dd780-209a-4bea-b124-ce4d8b2d7645@github.com>

On Fri, 3 Jun 2022 21:07:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8250950: Allow per-user and system wide configuration of a jpackaged app

This pull request has now been integrated.

Changeset: c37c8e5d
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c37c8e5d34905ff2df34a93aa53dd3369e164596
Stats:     599 lines in 15 files changed: 543 ins; 36 del; 20 mod

8250950: Allow per-user and system wide configuration of a jpackaged app

Reviewed-by: almatvee

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

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

From darcy at openjdk.java.net  Mon Jun  6 22:24:03 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Jun 2022 22:24:03 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v4]
In-Reply-To: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
Message-ID: <y8tZqF1yIwtK6wGCdbajacXxMOjhZs2sxU7FITBLc-U=.54049c00-2e23-4d10-b812-c2e2c5e0c683@github.com>

> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.

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/8876/files
  - new: https://git.openjdk.java.net/jdk/pull/8876/files/be81f60b..ba3e9a75

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

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

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

From darcy at openjdk.java.net  Mon Jun  6 22:24:05 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Jun 2022 22:24:05 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
In-Reply-To: <PdaHqlgxfEyjktRzloppPJrZXS8eR15IDe0gnd5dyF0=.7de4b85f-5251-4ccf-8666-eb3ffb2333c5@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
 <DCfBtaWLqERj3BRvcqeJdPdOICLu8Bh48OnXyu8I7ig=.7b9e35af-e810-44be-aa81-c87dd026494c@github.com>
 <ylGELIu3MVU0JFX5lApPApYg0wQ6_X5-wZB3wSSgLKw=.9f9bebcc-8750-41f8-a4f3-93907b7ae837@github.com>
 <PdaHqlgxfEyjktRzloppPJrZXS8eR15IDe0gnd5dyF0=.7de4b85f-5251-4ccf-8666-eb3ffb2333c5@github.com>
Message-ID: <YJDH9kfzBtCX_LbTCQjtD33zJSC7Vfe_JWXmnse4LgQ=.9a723bce-f5ab-4104-a527-72d21dd18da0@github.com>

On Thu, 2 Jun 2022 08:22:11 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/Math.java line 823:
>> 
>>> 821:      * @apiNote
>>> 822:      * This method corresponds to the convertTowardPositive operation
>>> 823:      * defined in IEEE 754.
>> 
>> Probably what is meant is IEEE `convertToIntegerTowardPositive` (not `convertTowardPositive`).
>> However, that's another kind of rounding, which always rounds any non-integral value toward positive infinity, not just ties. This is not what happens with this method.
>
>> not just ties
> Plz. disregard this 3 words

Okay, checking the IEEE 754-2019 spec again, there are operations to round a floating-point value to an integral-valued floating-point value (roundToIntegral{$ROUNDING_DIRECTION_ATTRIBUTE} and separately operations to round from a floating-point value to a value in an integer format (convertToInteger{$ROUNDING_DIRECTION_ATTRIBUTE} ). However, as noted, there is no IEEE 754 operations for rounding up only for ties. I'll remove the API notes for the round methods; thanks for catching this.

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

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

From mchung at openjdk.java.net  Mon Jun  6 22:37:06 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 6 Jun 2022 22:37:06 GMT
Subject: Integrated: JDK-8287867: Bad merge of jdk/test/lib/util/ForceGC.java
 causing test compilation error
In-Reply-To: <yX38UzenO2cthmt-4Bgv0eryJiXMfktNEMXosHpE_IQ=.9c885879-3223-4e23-9605-6064addb5e72@github.com>
References: <yX38UzenO2cthmt-4Bgv0eryJiXMfktNEMXosHpE_IQ=.9c885879-3223-4e23-9605-6064addb5e72@github.com>
Message-ID: <TEGcW2B-R2R8a6bZFi6zps105nGHn8BpN2Jdq8H8eNA=.c31132dc-f486-4d7c-b706-f7834c020216@github.com>

On Mon, 6 Jun 2022 21:58:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A typo in ForceGC.java causes several test failing due to compilation error.

This pull request has now been integrated.

Changeset: a50b06e8
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a50b06e85124f61b5133189a2a2e461753d5d9e7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8287867: Bad merge of jdk/test/lib/util/ForceGC.java causing test compilation error

Reviewed-by: dcubed

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

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

From iklam at openjdk.java.net  Mon Jun  6 23:07:05 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 6 Jun 2022 23:07:05 GMT
Subject: RFR: 8287663 Add a regression test for JDK-8287073
In-Reply-To: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
References: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
Message-ID: <19v69JgA7_1WyTEE9cfjXQALChal5tSCjHjv5qs72aA=.fce83484-c139-4b76-906c-e454d340568f@github.com>

On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This adds a regression test for a recent fix (JDK-8287073). I've restructured the linux specific JDK code to call a separate static function to enable this test. It'll help future tests too.
> 
> Testing:
> - [x] Container tests continue to pass + GHA
> - [x] New regression test fails prior the code fix of JDK-8287073 and passes with it

LGTM.

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

Marked as reviewed by iklam (Reviewer).

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

From iklam at openjdk.java.net  Mon Jun  6 23:09:11 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 6 Jun 2022 23:09:11 GMT
Subject: RFR: 8287663 Add a regression test for JDK-8287073
In-Reply-To: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
References: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
Message-ID: <J4aTInngsxd-X9LDvxRelbyDRMC6x6f5k73ygI1wCyM=.336ad5b1-cd75-454d-8e59-eda0aa766844@github.com>

On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This adds a regression test for a recent fix (JDK-8287073). I've restructured the linux specific JDK code to call a separate static function to enable this test. It'll help future tests too.
> 
> Testing:
> - [x] Container tests continue to pass + GHA
> - [x] New regression test fails prior the code fix of JDK-8287073 and passes with it

Not specific to this PR, but we have a general problem with lots of duplication between these two files. E.g.,


https://github.com/openjdk/jdk/blob/a50b06e85124f61b5133189a2a2e461753d5d9e7/test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java#L132-L143

https://github.com/openjdk/jdk/blob/a50b06e85124f61b5133189a2a2e461753d5d9e7/test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java#L130-L143

We should try to consolidate these test cases to improve maintainability.

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

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

From stuart.marks at oracle.com  Tue Jun  7 00:52:41 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 6 Jun 2022 17:52:41 -0700
Subject: CVF: new Core Libraries Group member: Naoto Sato
Message-ID: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>

I hereby nominate Naoto Sato [1] to membership in the Core Libraries Group [2].

Naoto Sato has been on the Core Libraries team for over a decade and has contributed 
hundreds of changes to the JDK project [3]. His most significant recent contribution 
is JEP 400: UTF-8 by Default [4]. Naoto is also lead of the Internationalization 
Group [5] and a Reviewer on the JDK project.

Votes are due by June 20, 2022, 23:59 PDT.

Only current members of the Core Libraries Group [6] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list, as 
described here [7]. Results are determined by lazy consensus [8].

s'marks


[1] https://openjdk.java.net/census#naoto
[2] https://openjdk.java.net/groups/core-libs/
[3] https://github.com/openjdk/jdk/search?q=author-name%3Anaoto&type=commits
[4] https://openjdk.java.net/jeps/400
[5] https://openjdk.java.net/groups/i18n/
[6] https://openjdk.java.net/census#core-libs
[7] https://openjdk.java.net/groups/#member-vote
[8] https://openjdk.java.net/bylaws#lazy-consensus



From duke at openjdk.java.net  Tue Jun  7 00:54:27 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Tue, 7 Jun 2022 00:54:27 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used
Message-ID: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>

8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

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

Commit messages:
 - 8287760: Keep do-not-resolve-by-default flag

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

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

From xgong at openjdk.java.net  Tue Jun  7 01:18:13 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 01:18:13 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v2]
In-Reply-To: <1MDYeqST0lYsav_o10jKIr3Fgoqo1Fn9aKYP9kMpN0M=.0bc88db0-84b6-48d5-a021-2ba302a46d92@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
 <uJLpkCZdNUpfugjsnuUpiXQp29CS64WvqX98HsMMW-M=.9994429f-9e95-4cd9-b20f-7501cb647af1@github.com>
 <1MDYeqST0lYsav_o10jKIr3Fgoqo1Fn9aKYP9kMpN0M=.0bc88db0-84b6-48d5-a021-2ba302a46d92@github.com>
Message-ID: <tdF5X_vlNpW_CzNXEbAoW6rkK28F2xNyieMdnHCoaY8=.90ecd9c2-4b8a-4693-9592-cec76dce423b@github.com>

On Tue, 31 May 2022 16:48:27 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @PaulSandoz, could you please help to check whether the current version is ok for you? Thanks so much!
>
> @XiaohongGong looks good, now the Vector API JEP has been integrated you will get a merge conflict, but it should be easier to resolve.

Thanks for the review @PaulSandoz @merykitty !

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

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

From xgong at openjdk.java.net  Tue Jun  7 01:21:11 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 01:21:11 GMT
Subject: Integrated: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store
In-Reply-To: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
Message-ID: <s5LMKcPjLgagrvThmhccCkJFzxVt9l2wYluIHXHgfpA=.e6ee8f9b-a08b-45eb-8cb4-d5d412d5dac1@github.com>

On Tue, 10 May 2022 01:23:55 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
> 
> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
> 
> Benchmark                                   Before    After     Gain Units
> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
> 
> Similar performane gain can also be observed on ARM hardware.

This pull request has now been integrated.

Changeset: ef7cc210
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ef7cc2105c66de443d3a9af706220272018a0d8d
Stats:     216 lines in 9 files changed: 179 ins; 0 del; 37 mod

8286279: [vectorapi] Only check index of masked lanes if offset is out of array boundary for masked store

Reviewed-by: psandoz

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

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

From joe.darcy at oracle.com  Tue Jun  7 02:04:04 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 6 Jun 2022 19:04:04 -0700
Subject: CVF: new Core Libraries Group member: Naoto Sato
In-Reply-To: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
References: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
Message-ID: <eaec41e2-93b8-1d51-fe1e-d335ab03bd17@oracle.com>

Vote: yes

-joe

On 6/6/2022 5:52 PM, Stuart Marks wrote:
> I hereby nominate Naoto Sato [1] to membership in the Core Libraries 
> Group [2].
>
> Naoto Sato has been on the Core Libraries team for over a decade and 
> has contributed hundreds of changes to the JDK project [3]. His most 
> significant recent contribution is JEP 400: UTF-8 by Default [4]. 
> Naoto is also lead of the Internationalization Group [5] and a 
> Reviewer on the JDK project.
>
> Votes are due by June 20, 2022, 23:59 PDT.
>
> Only current members of the Core Libraries Group [6] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list, as described here [7]. Results are determined by 
> lazy consensus [8].
>
> s'marks
>
>
> [1] https://openjdk.java.net/census#naoto
> [2] https://openjdk.java.net/groups/core-libs/
> [3] 
> https://github.com/openjdk/jdk/search?q=author-name%3Anaoto&type=commits
> [4] https://openjdk.java.net/jeps/400
> [5] https://openjdk.java.net/groups/i18n/
> [6] https://openjdk.java.net/census#core-libs
> [7] https://openjdk.java.net/groups/#member-vote
> [8] https://openjdk.java.net/bylaws#lazy-consensus
>
>

From xgong at openjdk.java.net  Tue Jun  7 02:26:13 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 02:26:13 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
 <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>
Message-ID: <fRSu6f8-3UQhTSh4thyyd_oArM9ccW3ASbdBAVjKgH4=.c284e308-2e74-4eda-8c23-0bba163c8ab1@github.com>

On Mon, 6 Jun 2022 10:40:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'jdk:master' into JDK-8283667
>>  - Use integer constant for offsetInRange all the way through
>>  - Rename "use_predicate" to "needs_predicate"
>>  - Rename the "usePred" to "offsetInRange"
>>  - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java line 97:
> 
>> 95:     public void byteLoadArrayMaskIOOBE() {
>> 96:         for (int i = 0; i < inSize; i += bspecies.length()) {
>> 97:             VectorMask<Byte> mask = VectorMask.fromArray(bspecies, m, i);
> 
> For other case "if (offset >= 0 && offset <= (a.length - species.length())) )" we are anyways intrinsifying, should we limit this micro to work only for newly optimized case.

Yeah, thanks and it's really a good suggestion to limit this benchmark only for the IOOBE cases. I locally modified the tests to make sure only the IOOBE case happens and the results show good as well. But do you think it's better to keep as it is since we can also see the performance of the common cases to make sure no regressions happen? As the current benchmarks can also show the performance gain by this PR.

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

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

From bpb at openjdk.java.net  Tue Jun  7 02:59:06 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 7 Jun 2022 02:59:06 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v4]
In-Reply-To: <y8tZqF1yIwtK6wGCdbajacXxMOjhZs2sxU7FITBLc-U=.54049c00-2e23-4d10-b812-c2e2c5e0c683@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
 <y8tZqF1yIwtK6wGCdbajacXxMOjhZs2sxU7FITBLc-U=.54049c00-2e23-4d10-b812-c2e2c5e0c683@github.com>
Message-ID: <w5PuQ9HNq2_PA3UtazDRLpb5-COtJZscmciOMNGaia0=.f7f958a1-1279-46b6-b79c-48ef3e2f0372@github.com>

On Mon, 6 Jun 2022 22:24:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Approved assuming comments will be addressed prior to integration.

src/java.base/share/classes/java/math/RoundingMode.java line 53:

> 51:  * two bracketing values is the result. For in-range real numbers, for
> 52:  * a given set of representable values, a rounding policy maps a
> 53:  * continuous segment of real number line to a single representable

"the" real number line

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

Marked as reviewed by bpb (Reviewer).

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

From iris.clark at oracle.com  Tue Jun  7 03:52:13 2022
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 7 Jun 2022 03:52:13 +0000
Subject: CVF: new Core Libraries Group member: Naoto Sato
In-Reply-To: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
References: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
Message-ID: <SJ0PR10MB5440773778671D066FE26F48FBA59@SJ0PR10MB5440.namprd10.prod.outlook.com>

Vote yes

Iris

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Stuart Marks <stuart.marks at oracle.com>
Sent: Monday, June 6, 2022 5:52 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: CVF: new Core Libraries Group member: Naoto Sato

I hereby nominate Naoto Sato [1] to membership in the Core Libraries Group [2].

Naoto Sato has been on the Core Libraries team for over a decade and has contributed
hundreds of changes to the JDK project [3]. His most significant recent contribution
is JEP 400: UTF-8 by Default [4]. Naoto is also lead of the Internationalization
Group [5] and a Reviewer on the JDK project.

Votes are due by June 20, 2022, 23:59 PDT.

Only current members of the Core Libraries Group [6] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing list, as
described here [7]. Results are determined by lazy consensus [8].

s'marks


[1] https://openjdk.java.net/census#naoto
[2] https://openjdk.java.net/groups/core-libs/
[3] https://github.com/openjdk/jdk/search?q=author-name%3Anaoto&type=commits
[4] https://openjdk.java.net/jeps/400
[5] https://openjdk.java.net/groups/i18n/
[6] https://openjdk.java.net/census#core-libs
[7] https://openjdk.java.net/groups/#member-vote
[8] https://openjdk.java.net/bylaws#lazy-consensus



From stuart.marks at oracle.com  Tue Jun  7 04:09:53 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 6 Jun 2022 21:09:53 -0700
Subject: JDK-8186958 - Behaviour of large values for numMapping in
 WeakHashMap.newWeakHashMap API
In-Reply-To: <9f177593-b040-53bb-22ba-23b2e19cfc39@gmail.com>
References: <9f177593-b040-53bb-22ba-23b2e19cfc39@gmail.com>
Message-ID: <8acd08ef-55d9-9fae-6959-94fa6264127e@oracle.com>

Hi Jai,

The error

     java.lang.OutOfMemoryError: Java heap space

indicates that the VM really has run out of memory. Presumably if you increased the 
heap size, it would actually be able to allocate that memory. You might have to add 
the /othervm test directive and add JVM options to require a larger heap.

The table size must be a power of two, so the largest table size that will be 
allocated is 1 << 30 or 1073741824 as you noted. That will take about 8GB of heap 
(in the no-compressed-OOP case). That's not terribly large, but we might want to 
check to see if there are other tests that require that much memory.

As you also noted, WeakHashMap eagerly allocates its table whereas LinkedHashMap and 
HashMap do not. I think this is an acceptable behavior variation. Note that we had 
to avoid this case in WhiteboxResizeTest:

https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/HashMap/WhiteBoxResizeTest.java#L167

We might have to make similar special cases here for WHM.

I don't think we need to document this behavior difference. More precisely: this 
kind of implementation variation doesn't need to be specified. In the future we 
might change WHM to allocate lazily.

The API should accommodate extremely large values of numMappings. Even if it's 
larger than 1 << 30 and the table size is allocated at 1 << 30, it's still possible 
to add numMappings mappings without resizing. (Memory permitting, of course.) Doing 
so will violate the load factor invariant, and it might result in more collisions 
than one would like, but it should still work.

I think we just need to decide whether we want to have a test that allocates this 
much memory, and if so, to apply the necessary settings to make sure the JVM has 
enough heap.

s'marks


On 6/6/22 12:01 AM, Jaikiran Pai wrote:
> In a recent enhancement we added new APIs to construct LinkedHashMap, HashMap and 
> WeakHashMap instances as part of https://bugs.openjdk.java.net/browse/JDK-8186958.
> 
> Since we missed adding tests for that change, I have been working on adding some 
> basic tests for this change as part of 
> https://bugs.openjdk.java.net/browse/JDK-8285405. The draft PR is here 
> https://github.com/openjdk/jdk/pull/9036.
> 
> It's in draft state because it has uncovered an aspect of this change that we might 
> have to address or document for these new APIs. Specifically, the tests I added now 
> have a test which does the equivalent of:
> 
> // numMappings = 2147483647
> var w = WeakHashMap.newWeakHashMap(Integer.MAX_VALUE);
> 
> Similar tests have been added for HashMap and LinkedHashMap too, but for the sake of 
> this discussion, I'll focus on WeakHashMap. Running this code/test runs into:
> 
> test NewWeakHashMap.testNewWeakHashMapNonNegative(2147483647): failure
> java.lang.OutOfMemoryError: Java heap space
>  ?? ?at java.base/java.util.WeakHashMap.newTable(WeakHashMap.java:194)
>  ?? ?at java.base/java.util.WeakHashMap.<init>(WeakHashMap.java:221)
>  ?? ?at java.base/java.util.WeakHashMap.<init>(WeakHashMap.java:238)
>  ?? ?at java.base/java.util.WeakHashMap.newWeakHashMap(WeakHashMap.java:1363)
>  ?? ?at NewWeakHashMap.testNewWeakHashMapNonNegative(NewWeakHashMap.java:69)
> 
> 
> This exception happens with only WeakHashMap. LinkedHashMap and HashMap don't show 
> this behaviour. It appears that WeakHashMap eagerly creates an large array (of 
> length 1073741824 in this case) in the newTable method which gets called by its 
> constructor.
> 
> This raises a few questions about these new APIs - these APIs take an integer and 
> the document allows positive values. So the current Integer.MAX_VALUE in theory is a 
> valid integer value for this API. Should these APIs document what might happen when 
> such a large numMapping is passed to it? Should that documentation be different for 
> different classes (as seen the HashMap and LinkedHashMap behave differently as 
> compared to WeakHashMap)? Should this "numMappings" be considered a hard value? In 
> other words, the current documentation of this new API states:
> 
> "Creates a new, empty WeakHashMap suitable for the expected number of mappings
> ....
> and its initial capacity is generally large enough so that the expected number
> of mappings can be added without resizing the map."
> 
> The documentation doesn't seem to guarantee that the resizing won't occur. So in 
> cases like these where the numMappings is a very large value, should the 
> implementation(s) have logic which doesn't trigger this OOM error?
> 
> -Jaikiran
> 
> 

From alexander.matveev at oracle.com  Tue Jun  7 04:12:10 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 7 Jun 2022 04:12:10 +0000
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v2]
In-Reply-To: <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
Message-ID: <8F525730-ABA2-455D-A6A7-FE37557F6D04@oracle.com>

Hi Michael,

Printing "Warning: Using unsigned app-image to build signed dmg.? with signed application should be fixed with JDK-8286850. Did you reproduce it on build containing JDK-8286850?

Thanks,
Alexander

> On Jun 5, 2022, at 3:06 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jun 5, 2022, at 8:56 AM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>> 
>> Fwiw, I was going to take a look at this but my build failed.
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_liblcms_cmstypes.o:
>> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
>> void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
>>                                                                                                                                  ^
>> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
>> void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
>>                                                                                                                           ^
>> 2 errors generated.
>> 
>> 
>> OS/X 12.4
>> 
>> 2.4 GHz Quad-Core Intel Core i5
>> 
>> If I should post that somewhere else let me know.
>> 
> 
> Again fwiw, I commented out references to SizeOfTag in the two methods and got a good build.
> 
> ./build/*/images/jdk/bin/jpackage --app-image ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)"
> Bundler Mac DMG Package skipped because of a configuration problem: When using an external app image you must specify the app name. 
> Advice to fix: Set the app name via the -name CLI flag, the fx:application/@name ANT attribute, or via the 'appName' bundler argument.
> 
> ./build/*/images/jdk/bin/jpackage --app-image ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)" --name HalfPipe
> Warning: Using unsigned app-image to build signed dmg.
> 
> *** The app-image was actually a signed one. I?m not sure that matters. Also since this would normally be my intention should there be a warning? ***
> 
> codesign -v --verbose=4 ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
> /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: valid on disk
> /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: satisfies its Designated Requirement
> 
> *** Seems successful ***
> 
> Thanks again.
> 


From iklam at openjdk.java.net  Tue Jun  7 04:21:05 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 7 Jun 2022 04:21:05 GMT
Subject: RFR: 8287663 Add a regression test for JDK-8287073
In-Reply-To: <J4aTInngsxd-X9LDvxRelbyDRMC6x6f5k73ygI1wCyM=.336ad5b1-cd75-454d-8e59-eda0aa766844@github.com>
References: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
 <J4aTInngsxd-X9LDvxRelbyDRMC6x6f5k73ygI1wCyM=.336ad5b1-cd75-454d-8e59-eda0aa766844@github.com>
Message-ID: <xSWAUet5i5iywCHndtE412NqrgaV8-DYHRcexWMIGWI=.606f2b73-478a-408b-a983-1e84d9076df3@github.com>

On Mon, 6 Jun 2022 23:07:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We should try to consolidate these test cases to improve maintainability.

I filed [JDK-8287185](https://bugs.openjdk.org/browse/JDK-8287185)

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

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

From xgong at openjdk.java.net  Tue Jun  7 04:29:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 04:29:40 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v6]
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <l6X4hVC2YiPB1RZH385njZVoD01lK8Kd0lusJqLmHIU=.9ac46aa1-c452-4a37-a7b9-e7bee40c0482@github.com>

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

Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Add constant OFFSET_IN_RANGE and OFFSET_OUT_OF_RANGE
 - Merge branch 'jdk:master' into JDK-8283667
 - Merge branch 'jdk:master' into JDK-8283667
 - Use integer constant for offsetInRange all the way through
 - Rename "use_predicate" to "needs_predicate"
 - Rename the "usePred" to "offsetInRange"
 - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

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

Changes: https://git.openjdk.java.net/jdk/pull/8035/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=05
  Stats: 453 lines in 44 files changed: 174 ins; 21 del; 258 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035

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

From xgong at openjdk.java.net  Tue Jun  7 04:31:55 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 04:31:55 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <C-9nZ4OWaMHiiPyXSIo6ecFnlPLO1PYQLOBXENrkvqY=.942859a4-2e63-4ed2-8528-a7945c0d35bd@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
 <C-9nZ4OWaMHiiPyXSIo6ecFnlPLO1PYQLOBXENrkvqY=.942859a4-2e63-4ed2-8528-a7945c0d35bd@github.com>
Message-ID: <HTIV2NffqoJEA8scGT14YtTsLdvs4c85rEJxfDCMqNM=.64e56311-dfa8-4343-9e6c-37f15e19f617@github.com>

On Mon, 6 Jun 2022 15:41:06 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Looks good. As a follow on PR I think it would be useful to add constants `OFFSET_IN_RANGE` and `OFFSET_OUT_OF_RANGE`, then it becomes much clearer in source and you can drop the `/* offsetInRange */` comment on the argument.

Hi @PaulSandoz , thanks for the advice! I'v rebased the codes and added these two constants in the latest patch. Thanks again for the review!

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

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

From alexander.matveev at oracle.com  Tue Jun  7 05:26:20 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 7 Jun 2022 05:26:20 +0000
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v2]
In-Reply-To: <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
Message-ID: <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>

Hi Michael,

See below.

On Jun 5, 2022, at 5:58 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:


./build/*/images/jdk/bin/jpackage --app-image ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)"
Bundler Mac DMG Package skipped because of a configuration problem: When using an external app image you must specify the app name.
Advice to fix: Set the app name via the -name CLI flag, the fx:application/@name ANT attribute, or via the 'appName' bundler argument.

./build/*/images/jdk/bin/jpackage --app-image ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)" --name HalfPipe
Warning: Using unsigned app-image to build signed dmg.

*** The app-image was actually a signed one. I?m not sure that matters. Also since this would normally be my intention should there be a warning? ***

codesign -v --verbose=4 ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: valid on disk
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: satisfies its Designated Requirement

*** Seems successful ***

Thanks again.


Possibly my mistake somehow but codesign seems to flag something if the application is actually unsigned.

${PACKAGER} \
--verbose \
   --add-modules java.desktop,java.prefs,java.se<http://java.se> \
   --type app-image \
--input ./input \
--app-version 1.0  \
--name BlackJack\ Blastoff_Unsigned \
--main-jar bjb.jar \
--main-class org.bjb.BlackJackApp \
--java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50  -Dapple.laf.useScreenMenuBar=true -Dcom.apple.mrj.application.apple.menu.about.name=BlackjackBlastoff -Dapple.awt.application.name=Blackjack\ Blastoff?

[19:41:02.231] Creating app package: BlackJack Blastoff_Unsigned.app in /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg
[19:41:05.516] Command [PID: -1]:
   jlink --output /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack Blastoff_Unsigned.app/Contents/runtime/Contents/Home --module-path /Library/Java/JavaVirtualMachines/jdk-18.jdk/Contents/Home/jmods --add-modules java.desktop,java.prefs,java.se<http://java.se> --strip-native-commands --strip-debug --no-man-pages --no-header-files
[19:41:05.517] Output:

[19:41:05.518] Returned: 0

[19:41:05.545] Using default package resource JavaApp.icns [icon] (add BlackJack Blastoff_Unsigned.icns to the resource-dir to customize).
[19:41:05.547] Preparing Info.plist: /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack Blastoff_Unsigned.app/Contents/Info.plist.
[19:41:05.547] Using default package resource Info-lite.plist.template [Application Info.plist] (add Info.plist to the resource-dir to customize).
[19:41:05.550] Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize).
[19:41:05.551] Succeeded in building Mac Application Image package

./build/*/images/jdk/bin/jpackage --app-image ~/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack\ Blastoff_Unsigned.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)" --name BlackJack_Blastoff_Unsigned
Warning: Using unsigned app-image to build signed dmg.

open BlackJack_Blastoff_Unsigned-1.0.dmg

codesign -v --verbose=4 /Volumes/BlackJack_Blastoff_Unsigned/BlackJack\ Blastoff_Unsigned.app
/Volumes/BlackJack_Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: code has no resources but signature indicates they must be present
This is correct. You generated unsigned application image and then package it into DMG with signing enabled. In this case we will not sign app image. Only installer package will get signed and it applies only to PKG. DMG does not have any signing. This is was same behavior as before JDK-8286850.

You need to sign app image first:
./build/*/images/jdk/bin/jpackage --type app-image --app-image ~/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack\ Blastoff_Unsigned.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)" --name BlackJack_Blastoff_Unsigned

Then run command to generate DMG or PKG. Enable signing if you want PKG to be signed. No need to specify it for DMG if you generating DMG from predefined application image.

As for "code has no resources but signature indicates they must be present? I believe it is due to JDK-8277493 and it was fixed in JDK 19.


I am using the installed jdk18 to create the app-image. Would that need to be done with the same jdk with the changes applied?
Yes, if you need to sign app image after post processing it should be generated with JDK version which contains JDK-8286850 fix. Unless something will change jpackage from JDK 20 should able to sign app image generated by JDK 19, but JDK 19 jpackage will not able to sign app image generated by JDK 18.

This is do to additional values are stored inside .jpackage.xml. As work around add following values into .jpackage.xml:
<main-class>MainClass</main-class> <- Your main class
<app-store>false</app-store> <- true if app image was generated with ?mac-app-store.

Thanks,
Alexander





From alanb at openjdk.java.net  Tue Jun  7 06:34:10 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Jun 2022 06:34:10 GMT
Subject: RFR: JDK-8287838: Update Float and Double to use snippets [v2]
In-Reply-To: <uySlbc3bsln0K9Lrzd0KWGab8cAyEbwyNj5p8ltUoOQ=.0f4e53e7-1138-4c0b-a63f-94d5b8c8f833@github.com>
References: <po3xdM_Ly9CRubJi8EH-i5BSUuh41I6RD0J3NFVlBsA=.2c2fb481-5e28-4c22-ba05-20042e1ebe7d@github.com>
 <AEKNpDe0b9R7xLHhNR_82GYBJ4ChPe775oUA9ViyhkE=.d07f6f9d-4995-4065-8cf3-a20b1e3d68d4@github.com>
 <uySlbc3bsln0K9Lrzd0KWGab8cAyEbwyNj5p8ltUoOQ=.0f4e53e7-1138-4c0b-a63f-94d5b8c8f833@github.com>
Message-ID: <GQOT2X7U6LL-S6HUg88m7tsXTZ7TVB0MYZWxWkwG2z8=.9299d478-1584-4330-9b61-574399bf5bb7@github.com>

On Mon, 6 Jun 2022 16:54:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Double.java line 683:
>> 
>>> 681:      *       "[\\x00-\\x20]*");// Optional trailing "whitespace"
>>> 682:      *
>>> 683:      *  if (Pattern.matches(fpRegex, myString)) // @link substring="Pattern.matches" target ="java.util.regex.Pattern#matches"
>> 
>> If you want to avoid the annoyingly long line then you can put the "// @link ..." on the previous line if you want.
>
> It can be done with a snippet region like this:
> 
> 
>      *  // @link region substring="Pattern.matches" target ="java.util.regex.Pattern#matches"
>      *  if (Pattern.matches(fpRegex, myString))
>      *      Double.valueOf(myString); // Will not throw NumberFormatException
>      * // @end

Yes, that works. The alternative is to terminate the comment line with a colon (:) and that applies markup tag to the line that follows. In this case, it would be:

 ```
// @link substring="Pattern.matches" target ="java.util.regex.Pattern#matches" :

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

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

From xgong at openjdk.java.net  Tue Jun  7 06:46:16 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 06:46:16 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <BEWMR9rnq3SWLMQxkU_pvOIxapWVHXfC-GC5fpZyepI=.e036cb56-bbbb-4a3f-b8cc-5124bc29fb31@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
 <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>
 <fRSu6f8-3UQhTSh4thyyd_oArM9ccW3ASbdBAVjKgH4=.c284e308-2e74-4eda-8c23-0bba163c8ab1@github.com>
 <BEWMR9rnq3SWLMQxkU_pvOIxapWVHXfC-GC5fpZyepI=.e036cb56-bbbb-4a3f-b8cc-5124bc29fb31@github.com>
Message-ID: <rRZwR8URWPw-MKd8mFXM7lzGTj8K1uRywm6PwJuhsZA=.b9611a8f-66a3-4032-a6a6-9e8fb60ae7c5@github.com>

On Tue, 7 Jun 2022 06:41:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yeah, thanks and it's really a good suggestion to limit this benchmark only for the IOOBE cases. I locally modified the tests to make sure only the IOOBE case happens and the results show good as well. But do you think it's better to keep as it is since we can also see the performance of the common cases to make sure no regressions happen? As the current benchmarks can also show the performance gain by this PR.
>
> It was just to remove the noise from a targeted micro benchmark. But we can keep it as it is.

OK, thanks!

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

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

From jbhateja at openjdk.java.net  Tue Jun  7 06:46:15 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 7 Jun 2022 06:46:15 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <fRSu6f8-3UQhTSh4thyyd_oArM9ccW3ASbdBAVjKgH4=.c284e308-2e74-4eda-8c23-0bba163c8ab1@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
 <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>
 <fRSu6f8-3UQhTSh4thyyd_oArM9ccW3ASbdBAVjKgH4=.c284e308-2e74-4eda-8c23-0bba163c8ab1@github.com>
Message-ID: <BEWMR9rnq3SWLMQxkU_pvOIxapWVHXfC-GC5fpZyepI=.e036cb56-bbbb-4a3f-b8cc-5124bc29fb31@github.com>

On Tue, 7 Jun 2022 02:22:53 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java line 97:
>> 
>>> 95:     public void byteLoadArrayMaskIOOBE() {
>>> 96:         for (int i = 0; i < inSize; i += bspecies.length()) {
>>> 97:             VectorMask<Byte> mask = VectorMask.fromArray(bspecies, m, i);
>> 
>> For other case "if (offset >= 0 && offset <= (a.length - species.length())) )" we are anyways intrinsifying, should we limit this micro to work only for newly optimized case.
>
> Yeah, thanks and it's really a good suggestion to limit this benchmark only for the IOOBE cases. I locally modified the tests to make sure only the IOOBE case happens and the results show good as well. But do you think it's better to keep as it is since we can also see the performance of the common cases to make sure no regressions happen? As the current benchmarks can also show the performance gain by this PR.

It was just to remove the noise from a targeted micro benchmark. But we can keep it as it is.

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

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

From Alan.Bateman at oracle.com  Tue Jun  7 06:51:53 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Jun 2022 07:51:53 +0100
Subject: CVF: new Core Libraries Group member: Naoto Sato
In-Reply-To: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
References: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
Message-ID: <8bc2d7f0-a2a2-2d3b-1198-11cf4996b20e@oracle.com>

Vote: yes

From mik3hall at gmail.com  Tue Jun  7 07:00:39 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 7 Jun 2022 02:00:39 -0500
Subject: RFR: 8286850: [macos] Add support for signing user provided app
 image [v2]
In-Reply-To: <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
Message-ID: <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>

Alexander,

I had an existing local GitHub repo for the jdk I updated that appeared to accept the parameters you indicated. It generated a jdk 19. 

If you are saying I?m not getting the main branch or the update for some reason has dependencies I?m not getting I would have to determine how to correctly get these, or, I guess wait for a release that has all the necessary. Determining if this worked as expected before a release seemed like it would be a good idea.

Yes, the point of my original suggestion was to allow generating the application unsigned, then do post-processing - like modify the default Info.plist, and finally separately sign.

I thought your change provided the means to do this by first generating an unsigned image using ?type app-image, then on a separate invocation indicate the app-image and sign and package it. 

> ./build/*/images/jdk/bin/jpackage --type app-image --app-image

If I follow you now it isn?t a two step but a three step process.

1) Generate unsigned application and do post-processing.

2) Sign modified app-image

3) DMG or PKG the modified and signed app-image

Is this correct?

Thanks,
Mike

From alanb at openjdk.java.net  Tue Jun  7 07:15:12 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Jun 2022 07:15:12 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <7FbQ0t2ZDkLR2vH7Jju8sG7EsY9-kTwVnP_epkxESb0=.f69a5c18-bf10-4e27-a998-857927f40edc@github.com>

On Tue, 7 Jun 2022 00:45:17 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

The change looks okay but I think we should add a test. You'll have to check the test tree to see if there are existing tests for incubator modules packages as JAR files, there may not be as it's an unusual setup.

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

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

From redestad at openjdk.java.net  Tue Jun  7 07:26:08 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 7 Jun 2022 07:26:08 GMT
Subject: Integrated: 8287798: Reduce runtime of java.lang.reflect/runtime
 microbenchmarks
In-Reply-To: <NaBo8k0zTSOoSnLEf5Y02aM-Wk9VKdWKGKZs4-XUAL8=.9d68731f-95d7-43f9-ae6e-9aef656f68e8@github.com>
References: <NaBo8k0zTSOoSnLEf5Y02aM-Wk9VKdWKGKZs4-XUAL8=.9d68731f-95d7-43f9-ae6e-9aef656f68e8@github.com>
Message-ID: <J34pmr2NfEKbSmt-GkwSSLtjdpewP-n9gFFO06lLknk=.04117394-75f6-4586-898f-cdf7054491ce@github.com>

On Fri, 3 Jun 2022 12:46:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Add explicit run configurations to java.lang.reflect and .runtime micros, aiming to reduce runtime while maintaining a decently high confidence that there's enough warmup to produce good enough data.
> 
> Roughly halves runtime of running `java.lang.reflect|java.lang.runtime` from 159 to 78 minutes.

This pull request has now been integrated.

Changeset: aa6c568a
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aa6c568a06fa92263d4b74ff979eb521ae953bc8
Stats:     27 lines in 4 files changed: 25 ins; 2 del; 0 mod

8287798: Reduce runtime of java.lang.reflect/runtime microbenchmarks

Reviewed-by: jvernee, mchung

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

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

From redestad at openjdk.java.net  Tue Jun  7 07:26:10 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 7 Jun 2022 07:26:10 GMT
Subject: Integrated: 8287810: Reduce runtime of java.lang microbenchmarks
In-Reply-To: <4MFktMLic5pH0qFBPSPjy1HXpHuhoteAzYjBvo_dZPk=.63e4099c-1246-44ca-a16b-3445e84b6262@github.com>
References: <4MFktMLic5pH0qFBPSPjy1HXpHuhoteAzYjBvo_dZPk=.63e4099c-1246-44ca-a16b-3445e84b6262@github.com>
Message-ID: <ubWJaB5mBGa_C3yf-2g-GVRXcxtGbxSGxpbuSzJj1K4=.72509b59-4da3-4e88-bb79-24aeae8fd0e9@github.com>

On Fri, 3 Jun 2022 15:05:33 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Reduce runtime by providing explicit configurations that try to run the micros as fast as possible while giving enough time for warmup.
> - Remove some excessive parameters
> - Remove some benchmarks testing experimental features (ObjectHashCode.mode_<non-default>) or were simply dubious at large (StringHttp)
> 
> This reduces runtime of running `java.lang.[A-Z]` (only java.lang, not java.lang.reflect etc..) from over 56 hours to 6:45.

This pull request has now been integrated.

Changeset: 778ed1a7
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/778ed1a760d8f673811914b75e5d14e465881c91
Stats:     293 lines in 39 files changed: 192 ins; 87 del; 14 mod

8287810: Reduce runtime of java.lang microbenchmarks

Reviewed-by: mchung

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

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

From redestad at openjdk.java.net  Tue Jun  7 07:29:10 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 7 Jun 2022 07:29:10 GMT
Subject: Integrated: 8287785: Reduce runtime of java.lang.invoke
 microbenchmarks
In-Reply-To: <PZgf4z1DyIgjRrELDsPi3MFCr4ZOne0Ut62-5PN-Vms=.23b1464f-a2ca-46c6-8280-1a181891caf4@github.com>
References: <PZgf4z1DyIgjRrELDsPi3MFCr4ZOne0Ut62-5PN-Vms=.23b1464f-a2ca-46c6-8280-1a181891caf4@github.com>
Message-ID: <Pe8G1x4VUYdPXbnnGbWC_zweon21121TINjFbkbunMw=.53a8fb61-4d09-4e3a-9a42-49fc82a63916@github.com>

On Fri, 3 Jun 2022 11:16:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Add explicit run configurations to java.lang.invoke micros, aiming to reduce runtime while maintaining a decently high confidence that there's enough warmup to produce good enough data.
> 
> - Remove several trivial baseline micros, mainly those that only return a static object: It's reasonable to have baseline microbenchmarks when the baseline op is complex and you're mostly interested in checking the overhead of doing the same thing via some MH API, but blackhole operations are now shortcutting very quickly and timings doesn't differ from one type of object to another, so we don't need a multitude of such baseline tests.
> 
> Estimated runtime of `make test TEST=micro:java.lang.micro` (excluding build) drops from just above 28 to just above 3 hours.

This pull request has now been integrated.

Changeset: 42261d75
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42261d752a140325496ffdd40d9ad62b189d1b3e
Stats:     439 lines in 47 files changed: 276 ins; 153 del; 10 mod

8287785: Reduce runtime of java.lang.invoke microbenchmarks

Reviewed-by: mchung

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

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

From jbhateja at openjdk.java.net  Tue Jun  7 07:42:20 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 7 Jun 2022 07:42:20 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v6]
In-Reply-To: <l6X4hVC2YiPB1RZH385njZVoD01lK8Kd0lusJqLmHIU=.9ac46aa1-c452-4a37-a7b9-e7bee40c0482@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <l6X4hVC2YiPB1RZH385njZVoD01lK8Kd0lusJqLmHIU=.9ac46aa1-c452-4a37-a7b9-e7bee40c0482@github.com>
Message-ID: <wgu9HcMaOkw21i79JHaHszJs92ECJZ7scMSC7UUKUOQ=.fc972169-ae4f-411d-8c1f-e0de0ed58fcb@github.com>

On Tue, 7 Jun 2022 04:29:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

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

LGTM.

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

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

From xgong at openjdk.java.net  Tue Jun  7 07:42:22 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 07:42:22 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
Message-ID: <b2nHT9XvhX7tUfkcYAfuUjUHL2DG2VSpa9-H4FowQEw=.04925f22-9d62-49ab-9127-6b15d20ddcac@github.com>

On Thu, 12 May 2022 16:07:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename "use_predicate" to "needs_predicate"
>
> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
> 
>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>   ** missing constant: offsetInRange=Parm
>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
> 
> 
> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).

Thanks for the review @PaulSandoz  @sviswa7 @jatin-bhateja @merykitty ?

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

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

From xgong at openjdk.java.net  Tue Jun  7 07:45:23 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 07:45:23 GMT
Subject: Integrated: 8283667: [vectorapi] Vectorization for masked load with
 IOOBE with predicate feature
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <U6H5H5beZcLBNVGEKgaGRyVwQhDykSWyekdZbBIunt4=.fd6a7a40-4cd6-4eea-9e09-8601d66f25f5@github.com>

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

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

This pull request has now been integrated.

Changeset: 39fa52b5
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/39fa52b5f7504eca7399b863b0fb934bdce37f7e
Stats:     453 lines in 44 files changed: 174 ins; 21 del; 258 mod

8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

Reviewed-by: sviswanathan, psandoz

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

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

From duke at openjdk.java.net  Tue Jun  7 08:23:06 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 7 Jun 2022 08:23:06 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v4]
In-Reply-To: <y8tZqF1yIwtK6wGCdbajacXxMOjhZs2sxU7FITBLc-U=.54049c00-2e23-4d10-b812-c2e2c5e0c683@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
 <y8tZqF1yIwtK6wGCdbajacXxMOjhZs2sxU7FITBLc-U=.54049c00-2e23-4d10-b812-c2e2c5e0c683@github.com>
Message-ID: <RPDbtoHCV80EPpzioiTvdVeXyPy4gCFjfuMTt9GpxTU=.7a3c75a9-4162-41bb-90de-55ce93132795@github.com>

On Mon, 6 Jun 2022 22:24:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

LGTM

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

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

From redestad at openjdk.java.net  Tue Jun  7 08:25:11 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 7 Jun 2022 08:25:11 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v8]
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <9o9RlXHtDzx5wNhV5HGwxCUrHTxPESVRgLAxICRcEi4=.45049507-5321-42dd-a9fd-ab1a5d9a3914@github.com>

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

Claes Redestad 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 17 additional commits since the last revision:

 - Merge branch 'master' into scf_chunked
 - We now don't need big Species classes for shorter concats, so on some tests the improvements meant more Species class generation. Adjusting HelloClasslist
 - Clarify that consts are always reduced to null, even if calling with constants. Also clarify that the number of constants is paramCount + 1 by refactoring to an array
 - Mandy review comment #1: Cleanup LF.basicType a bit more.
 - Cleanup too generic String.valueOf lookups
 - Address review comments from @ExE-Boss
 - Improve bootstrap microbenchmark to include more shapes, reduce runtime
 - Minor stylistic cleanup
 - Revert change to HelloClasslist (doesn't affect generation)
 - Reduce allocation adding in mixers by extracting constant arg lists and caching double arg mixers
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/98404245...afe61394

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8855/files
  - new: https://git.openjdk.java.net/jdk/pull/8855/files/aaa442d5..afe61394

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

  Stats: 59296 lines in 765 files changed: 33676 ins; 19450 del; 6170 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8855.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8855/head:pull/8855

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

From duke at openjdk.java.net  Tue Jun  7 08:42:05 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 7 Jun 2022 08:42:05 GMT
Subject: RFR: 8233760: Result of BigDecimal.toString throws overflow
 exception on new BigDecimal(str) [v2]
In-Reply-To: <hUxp38C5zmOoZ1yOPZsLZEDkWfW8xBuPV2eY8k4091A=.50baa789-82bc-4c15-89cb-e399caf9cffd@github.com>
References: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
 <hUxp38C5zmOoZ1yOPZsLZEDkWfW8xBuPV2eY8k4091A=.50baa789-82bc-4c15-89cb-e399caf9cffd@github.com>
Message-ID: <-WjHTJF4t07G5r67d7FZpYEUXQrqyAjiW28pykcCpEA=.3070a320-fba0-4714-ae4d-bc68adc89ef6@github.com>

On Fri, 27 May 2022 22:59:47 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> BigDecimal(String) currently fails to accept some strings produced by BigDecimal.toString(). This PR removes this limitation.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)

Hello,

here's an explanation of the changes in `BigDecimal`.

Rather than keeping track of a local `int scl` (scale) and a local `long exp` (exponent), the change only keeps track of a `long scl`, adapting it accordingly. It checks the range of `scl` before initializing the fields. This makes for a simpler code.

In addition, I couldn't resist changing C-style arrays to Java style over the whole class.

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

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

From sgehwolf at openjdk.java.net  Tue Jun  7 08:43:07 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 7 Jun 2022 08:43:07 GMT
Subject: RFR: 8287663 Add a regression test for JDK-8287073
In-Reply-To: <xSWAUet5i5iywCHndtE412NqrgaV8-DYHRcexWMIGWI=.606f2b73-478a-408b-a983-1e84d9076df3@github.com>
References: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
 <J4aTInngsxd-X9LDvxRelbyDRMC6x6f5k73ygI1wCyM=.336ad5b1-cd75-454d-8e59-eda0aa766844@github.com>
 <xSWAUet5i5iywCHndtE412NqrgaV8-DYHRcexWMIGWI=.606f2b73-478a-408b-a983-1e84d9076df3@github.com>
Message-ID: <nQBG8lkSRCIdchjbq2_FOIcIcqQB7YMz82iod1k3Ckw=.55df8f78-57aa-4132-a8e2-728b52a1721b@github.com>

On Tue, 7 Jun 2022 04:17:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > We should try to consolidate these test cases to improve maintainability.
> 
> I filed [JDK-8287185](https://bugs.openjdk.org/browse/JDK-8287185)

Agreed. Thanks for the review @iklam

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

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

From sgehwolf at openjdk.java.net  Tue Jun  7 08:43:09 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 7 Jun 2022 08:43:09 GMT
Subject: Integrated: 8287663 Add a regression test for JDK-8287073
In-Reply-To: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
References: <kNL64EYv26QUTQejHVbipjtlkkBGVfGG7e4tITFmDi4=.3169d70c-999a-4ac2-b5be-da1fdacab545@github.com>
Message-ID: <sw2q6MYibaHIGbdIpPCkWeLrYf9wnPVjtNFyp-7zIrA=.645aba3c-c453-42eb-b102-e1395c5261ee@github.com>

On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This adds a regression test for a recent fix (JDK-8287073). I've restructured the linux specific JDK code to call a separate static function to enable this test. It'll help future tests too.
> 
> Testing:
> - [x] Container tests continue to pass + GHA
> - [x] New regression test fails prior the code fix of JDK-8287073 and passes with it

This pull request has now been integrated.

Changeset: 2d8c6490
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2d8c6490540e3ccea23b81129b2e4073915071e0
Stats:     36 lines in 2 files changed: 35 ins; 0 del; 1 mod

8287663: Add a regression test for JDK-8287073

Reviewed-by: iklam

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

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

From sgehwolf at openjdk.java.net  Tue Jun  7 08:49:07 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 7 Jun 2022 08:49:07 GMT
Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout
 parsing code
In-Reply-To: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
References: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
Message-ID: <N8npntyd4lSThX59uNa7tOa0EIQOxRQ1NcrLz4xAJ08=.4bf6136f-e4a4-433f-b75d-e1cd660ff3b3@github.com>

On Wed, 1 Jun 2022 09:18:38 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated
> buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue
> of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read.
> 
> While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From
> a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be
> there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is
> meant to only use stringStream throughout the cgroups code.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2
> - [x] Added tests, which I've verified also pass before the stringStream change
> 
> Thoughts?

@iklam Would you have some cycles to review this, please?

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

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

From duke at openjdk.java.net  Tue Jun  7 08:56:05 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 7 Jun 2022 08:56:05 GMT
Subject: RFR: 8202449: overflow handling in Random.doubles [v3]
In-Reply-To: <S9k1SfnSYAzoiTlxdQ5fBpdMt4Uu8mlNWHSYJhWTI0g=.2e023744-7ed1-40a0-8075-31d8f2ede9ec@github.com>
References: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>
 <S9k1SfnSYAzoiTlxdQ5fBpdMt4Uu8mlNWHSYJhWTI0g=.2e023744-7ed1-40a0-8075-31d8f2ede9ec@github.com>
Message-ID: <MB44AhV0HGVyyFnof4bODYWuLRaI1S2SlKmzS8DobfQ=.aacabee1-12b1-4061-bbb4-03bf1e068a1c@github.com>

On Tue, 24 May 2022 12:58:45 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Extend the range of Random.doubles(double, double) and similar methods.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8202449: overflow handling in Random.doubles

Hi,

the major code changes are in `RandomSupport` in methods

checkRange(float,float)
checkRange(double,double)

where the checks are more tolerant, and in

boundedNextDouble(RandomGenerator,double,double)
boundedNextFloat(RandomGenerator,float,float)


that extend the accepted range. In case the range size overflows, the methods half the range, generate a value inside the reduced range and finally double the outcome.

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

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

From ihse at openjdk.java.net  Tue Jun  7 10:23:54 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 7 Jun 2022 10:23:54 GMT
Subject: RFR: 8287896: PropertiesTest.sh fail on msys2
Message-ID: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>

The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2, since it does not properly detect this environment.

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

Commit messages:
 - 8287896: PropertiesTest.sh fail on msys2

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

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

From asotona at openjdk.java.net  Tue Jun  7 10:38:28 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 7 Jun 2022 10:38:28 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <rf0rq-MkHDg3YqICbKmxWFoX04tWrifwRTbLZDZwMQI=.c984bf9b-1c58-47d0-a335-74aaa2cba1d0@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/187b34b0...05cf2d8b

Marked as reviewed by asotona (Committer).

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

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

From naoto at openjdk.java.net  Tue Jun  7 11:45:18 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 7 Jun 2022 11:45:18 GMT
Subject: RFR: 8287896: PropertiesTest.sh fail on msys2
In-Reply-To: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>
References: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>
Message-ID: <UaWILe0ypr8n14MNs07MtVtCHhHYfq72fTKsCCKbysk=.01047403-a519-445a-a978-78386cabfb82@github.com>

On Tue, 7 Jun 2022 10:14:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2, since it does not properly detect this environment.

Looks good. Thanks for the change.

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

Marked as reviewed by naoto (Reviewer).

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

From duke at openjdk.java.net  Tue Jun  7 11:50:22 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Jun 2022 11:50:22 GMT
Subject: Integrated: 8287860: Revise usage of volatile in j.u.Locale
In-Reply-To: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
Message-ID: <_IWq0ve7avn9TEdgpYq_plxYzJV3X2RtBAXDvmHsAHQ=.f0eba0e0-29e6-4deb-b6e3-5bb69d5d783d@github.com>

On Mon, 6 Jun 2022 12:58:39 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
> - `defaultLocale` field is read multiple times in `initDefault()`
> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`

This pull request has now been integrated.

Changeset: 4fe0ca9e
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4fe0ca9ec3b995eb113ac214219cae22f83333c9
Stats:     24 lines in 2 files changed: 5 ins; 0 del; 19 mod

8287860: Revise usage of volatile in j.u.Locale

Reviewed-by: naoto

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

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

From ihse at openjdk.java.net  Tue Jun  7 11:57:18 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 7 Jun 2022 11:57:18 GMT
Subject: Integrated: 8287896: PropertiesTest.sh fail on msys2
In-Reply-To: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>
References: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>
Message-ID: <yLk6BwfQRE8P4jSozNKLNKamxN8j57LWiUagyP14hew=.6aa1de83-65e7-4d64-8710-344761c0e0e9@github.com>

On Tue, 7 Jun 2022 10:14:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2, since it does not properly detect this environment.

This pull request has now been integrated.

Changeset: f1dd559e
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1dd559e20342b892d0c1ed0314e5bba451bc5d3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8287896: PropertiesTest.sh fail on msys2

Reviewed-by: naoto

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

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

From ihse at openjdk.java.net  Tue Jun  7 12:28:32 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 7 Jun 2022 12:28:32 GMT
Subject: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not
 working reliably on Windows
Message-ID: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>

The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.

This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.

The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.

What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.

Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

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

Commit messages:
 - 8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows

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

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

From sgehwolf at openjdk.java.net  Tue Jun  7 12:42:26 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 7 Jun 2022 12:42:26 GMT
Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout
 parsing code [v2]
In-Reply-To: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
References: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
Message-ID: <duy2SyNs9tQ-YTciNLt2xBSqGe9wv3YxsYErsoMxJzg=.6d0bfe9f-3bff-4deb-8fb4-fb4b18021d85@github.com>

> Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated
> buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue
> of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read.
> 
> While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From
> a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be
> there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is
> meant to only use stringStream throughout the cgroups code.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2
> - [x] Added tests, which I've verified also pass before the stringStream change
> 
> Thoughts?

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

 - Merge branch 'master' into jdk-8287007-string-stream
 - Add cgroups v2 java test
 - use stringStream in cgroups v2
 - Add gtest for cgroups v2 code path
   
   Also fixes the bug when cgroup path is '/'.
 - 8287007: [cgroups] Consistently use stringStream throughout parsing code
 - 8287007: [cgroups] Consistently use stringStream throughout parsing code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8969/files
  - new: https://git.openjdk.java.net/jdk/pull/8969/files/a7b156a4..8047fe37

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

  Stats: 60055 lines in 839 files changed: 34126 ins; 19620 del; 6309 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8969.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8969/head:pull/8969

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

From redestad at openjdk.java.net  Tue Jun  7 12:44:42 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 7 Jun 2022 12:44:42 GMT
Subject: RFR: 8287903: Reduce runtime of java.math microbenchmarks
Message-ID: <MJ3QClsZ3coUPGAOuz9nftNN-UPveIQGFquTmnfRGGc=.256c9385-d24d-40c7-8ccd-ec2b8d502fa9@github.com>

- Reduce runtime by running fewer forks, fewer iterations, less warmup. All micros tested in this group appear to stabilize very quickly.
- Refactor BigIntegers to avoid re-running some (most) micros over and over with parameter values that don't affect them.

Expected runtime down from 14 hours to 15 minutes.

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

Commit messages:
 - Cleanup SmallShifts, reduce param space
 - Annotations not cascading to static nested class
 - Warmup/Measurement not cascading to static nested class
 - Reduce runtime of java.math micros
 - Reduce runtime of java.math micros

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

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

From mcimadamore at openjdk.java.net  Tue Jun  7 13:00:37 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 7 Jun 2022 13:00:37 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Add null check on Buffer::checkState
 - Add docs
   Simplify liveness check in Buffer
   Drop redundant import in DirectBuffer
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
   Improve direct buffer code with isImplicit predicate
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
 - Simplify readOnly check
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8d28734e...5b8f7246

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

Changes: https://git.openjdk.java.net/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9017&range=01
  Stats: 1752 lines in 39 files changed: 407 ins; 525 del; 820 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9017/head:pull/9017

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

From duke at openjdk.java.net  Tue Jun  7 13:16:04 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Tue, 7 Jun 2022 13:16:04 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v2]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <nx072PA7iMz2mi6k8BQxuA-ls_XCnCzxMOCV31MIId4=.5e5d584c-1c46-4057-8762-883bef588df5@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/cd25d8ad..544ee0f7

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

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

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

From duke at openjdk.java.net  Tue Jun  7 13:30:50 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Tue, 7 Jun 2022 13:30:50 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v3]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <A6Jv-1uGhDEGi-hHqFjkxK2lbkckMP5xjr9RtQAaswY=.f1dc641f-4ba7-490a-909e-548742761512@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner 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:

  Fix copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/544ee0f7..2acbedb1

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

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

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

From duke at openjdk.java.net  Tue Jun  7 13:35:06 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Tue, 7 Jun 2022 13:35:06 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v3]
In-Reply-To: <A6Jv-1uGhDEGi-hHqFjkxK2lbkckMP5xjr9RtQAaswY=.f1dc641f-4ba7-490a-909e-548742761512@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <A6Jv-1uGhDEGi-hHqFjkxK2lbkckMP5xjr9RtQAaswY=.f1dc641f-4ba7-490a-909e-548742761512@github.com>
Message-ID: <xeeIg9KgJE073zxqHpVNhjPEUTZa8E93UyKTbVi551g=.0e69be65-6c73-406e-8b70-0bad6ca3c20e@github.com>

On Tue, 7 Jun 2022 13:30:50 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner 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:
> 
>   Fix copyright year

@Thihup Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more information.

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

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

From jlahoda at openjdk.java.net  Tue Jun  7 13:36:07 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 7 Jun 2022 13:36:07 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <yYgK7XFgOkNtqPtMNG8aMIbFEmKiunZ5Dtf0MWPa17I=.c561ff0a-2a9c-451a-a810-f2282f411e55@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

Looks like a reasonable compromise to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From asotona at openjdk.java.net  Tue Jun  7 13:43:07 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 7 Jun 2022 13:43:07 GMT
Subject: Integrated: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option
In-Reply-To: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
Message-ID: <XIBv73swJLhV6unhWIpCxdwKBnyNnl4edElggHH4fm0=.c0f4b6d3-3cee-430a-9775-370247944777@github.com>

On Tue, 17 May 2022 12:47:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ### Problem description
> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
> fails to run java source launcher correctly (for example when --source N is specified).
> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
> 
> ### Root cause
> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
> 
> ### Alternative patch
> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
> 
> ### Proposed fix
> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
> Plus added specific test case.
> 
> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 905bcbe3
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/905bcbe34eb9750f6f7f12a577733c71a31d7972
Stats:     76 lines in 3 files changed: 29 ins; 37 del; 10 mod

8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option

Reviewed-by: jlahoda

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

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

From ecaspole at openjdk.java.net  Tue Jun  7 13:52:05 2022
From: ecaspole at openjdk.java.net (Eric Caspole)
Date: Tue, 7 Jun 2022 13:52:05 GMT
Subject: RFR: 8287903: Reduce runtime of java.math microbenchmarks
In-Reply-To: <MJ3QClsZ3coUPGAOuz9nftNN-UPveIQGFquTmnfRGGc=.256c9385-d24d-40c7-8ccd-ec2b8d502fa9@github.com>
References: <MJ3QClsZ3coUPGAOuz9nftNN-UPveIQGFquTmnfRGGc=.256c9385-d24d-40c7-8ccd-ec2b8d502fa9@github.com>
Message-ID: <mRPhTi-Reoe4pyI7NRQcFHb64zo8zir3QVsVMYASqco=.0ad34080-15e2-4b4e-8fd9-da665a199f06@github.com>

On Tue, 7 Jun 2022 12:34:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Reduce runtime by running fewer forks, fewer iterations, less warmup. All micros tested in this group appear to stabilize very quickly.
> - Refactor BigIntegers to avoid re-running some (most) micros over and over with parameter values that don't affect them.
> 
> Expected runtime down from 14 hours to 15 minutes.

Looks good. Will make these so much more practical to use.

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

Marked as reviewed by ecaspole (Committer).

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

From duke at openjdk.java.net  Tue Jun  7 13:52:35 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Jun 2022 13:52:35 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
Message-ID: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>

Instead of `Executable.getParameterTypes()` we could use `Executable.getSharedParameterTypes()` in trusted code. Same is applicable for `Executable.getExceptionTypes()`.

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

Commit messages:
 - 8287908: Use non-cloning reflection methods where acceptable

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

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

From duke at openjdk.java.net  Tue Jun  7 14:15:55 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 7 Jun 2022 14:15:55 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v7]
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <mhpnjoL_era4xeDDmX7VzNdmFlcVkg6QKVcQWfNgcPo=.c144beee-dc9e-4b08-9b82-eeaca5ff36df@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

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

  8285838: Simplified Daylight period checks for test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/87832663..f855493a

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

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

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

From duke at openjdk.java.net  Tue Jun  7 14:15:56 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 7 Jun 2022 14:15:56 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v6]
In-Reply-To: <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
Message-ID: <TbTxwyRJSfC1Qofi9ljuBiQ7w7jTAx5uaufbqi6X4uo=.fbbf7714-ee16-4a19-9e94-82381fd485f8@github.com>

On Wed, 1 Jun 2022 13:32:36 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8285838: Cleanup of trailing whitespace
>  - 8285838: Corrected month comparison check for TZ DST

Appreciate the suggestion, I fixed up my test and simplified it as you said, and checked against a few spawned LocalDate(s) to verify the functionality is still good.

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

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

From duke at openjdk.java.net  Tue Jun  7 14:18:52 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Tue, 7 Jun 2022 14:18:52 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v6]
In-Reply-To: <TbTxwyRJSfC1Qofi9ljuBiQ7w7jTAx5uaufbqi6X4uo=.fbbf7714-ee16-4a19-9e94-82381fd485f8@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
 <TbTxwyRJSfC1Qofi9ljuBiQ7w7jTAx5uaufbqi6X4uo=.fbbf7714-ee16-4a19-9e94-82381fd485f8@github.com>
Message-ID: <C_mKUFXh_euKcPiIOSwazbkIcQ5wcXDDlopAKnPXZuE=.fe341e2c-b7c0-46cd-94f7-82232a2af1d8@github.com>

On Tue, 7 Jun 2022 14:11:57 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8285838: Cleanup of trailing whitespace
>>  - 8285838: Corrected month comparison check for TZ DST
>
> Appreciate the suggestion, I fixed up my test and simplified it as you said, and checked against a few spawned LocalDate(s) to verify the functionality is still good.

@Deigue Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more information.

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

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

From aturbanov at openjdk.java.net  Tue Jun  7 14:50:38 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 7 Jun 2022 14:50:38 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252" [v2]
In-Reply-To: <2nrJW64dS7XJIqFiHzSVQ6lrZqwTF5yi6JxUWQyQPFc=.d5acfba0-a78a-4b59-8429-f7698ecb80c1@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
 <2nrJW64dS7XJIqFiHzSVQ6lrZqwTF5yi6JxUWQyQPFc=.d5acfba0-a78a-4b59-8429-f7698ecb80c1@github.com>
Message-ID: <vkH0gFP7mEmqnf3w4qrn7wQ9zEOGDVQUoif57jdtScg=.dc476ea6-fb67-44ff-88cb-0b271bb1a320@github.com>

On Mon, 6 Jun 2022 15:50:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed per suggestion

Marked as reviewed by aturbanov (Committer).

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

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

From roger.riggs at oracle.com  Tue Jun  7 14:50:46 2022
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 7 Jun 2022 10:50:46 -0400
Subject: CVF: new Core Libraries Group member: Naoto Sato
In-Reply-To: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
References: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
Message-ID: <49e099d3-9c12-c082-f6c5-3b0cce4ff7a4@oracle.com>

Vote: Yes

On 6/6/22 8:52 PM, Stuart Marks wrote:
> I hereby nominate Naoto Sato [1] to membership in the Core Libraries 
> Group [2]. 


From darcy at openjdk.java.net  Tue Jun  7 16:15:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 7 Jun 2022 16:15:40 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations [v5]
In-Reply-To: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
Message-ID: <5sQZYwKEoy6L5gHoDH8kmp6Db6A6jZxrHtWRofHGzmk=.3c58e572-0b08-43bf-8c27-26672cfd93ab@github.com>

> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.

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

  Correct typo found in review and reflow paragraph.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8876/files
  - new: https://git.openjdk.java.net/jdk/pull/8876/files/ba3e9a75..b82f2668

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

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

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

From darcy at openjdk.java.net  Tue Jun  7 16:16:50 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 7 Jun 2022 16:16:50 GMT
Subject: Integrated: 8273346: Expand library mappings to IEEE 754 operations
In-Reply-To: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
Message-ID: <oLFEVzd2SzILw-RfpV1zAseyK6nHi4BAv7Dd54VVnrA=.7ab4eab0-ef02-4af7-880a-08edca028d84@github.com>

On Wed, 25 May 2022 00:19:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.

This pull request has now been integrated.

Changeset: 5d4ea9b9
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d4ea9b9549b762b7c207e5c2ee65bc51591433b
Stats:     156 lines in 4 files changed: 143 ins; 0 del; 13 mod

8273346: Expand library mappings to IEEE 754 operations

Reviewed-by: bpb

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

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

From duke at openjdk.java.net  Tue Jun  7 16:35:22 2022
From: duke at openjdk.java.net (LifeIsStrange)
Date: Tue, 7 Jun 2022 16:35:22 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v11]
In-Reply-To: <RwZu85T8y4RTeOuKm5lsHUrmltpZsIsJBXvGrcy3rHU=.39605412-e908-490a-98fa-c32cf5895e9b@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
 <JDuuPV5lM4UaPp4ZQjJTbupPgG-ecI7Oza7ufSC_MY8=.200e7794-f115-46a3-850c-10cba46dacca@github.com>
 <RwZu85T8y4RTeOuKm5lsHUrmltpZsIsJBXvGrcy3rHU=.39605412-e908-490a-98fa-c32cf5895e9b@github.com>
Message-ID: <b0Yf_QeIyP6VvDgPmxA5wV_HEDLCEA5jSjDHEngSxUc=.d14d9629-ea34-4ac6-b77e-25595eabd731@github.com>

On Mon, 9 May 2022 12:50:31 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Marked as reviewed by limck599 at github.com (no known OpenJDK username).
>
> @limck599
> While we at OpenJDK appreciate constructive reviews from GitHub users not registered in the [census](https://openjdk.java.net/census), only officially nominated reviewers have the authority to approve this PR.

@rgiulietti friendly ping, noob question: Do you believe some parts of the algorithm could exploit explicit SIMD instructions (via the high level [Vector API](https://openjdk.java.net/jeps/417))  for even better performance (such as https://github.com/wrandelshofer/FastDoubleParser ) ?

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

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

From mandy.chung at oracle.com  Tue Jun  7 17:00:26 2022
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 7 Jun 2022 10:00:26 -0700
Subject: CVF: new Core Libraries Group member: Naoto Sato
In-Reply-To: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
References: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
Message-ID: <57e8f510-ba26-adee-11ad-d3959704b631@oracle.com>

Vote: yes

Mandy

From raffaello.giulietti at oracle.com  Tue Jun  7 17:11:32 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Tue, 7 Jun 2022 19:11:32 +0200
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results [v11]
In-Reply-To: <b0Yf_QeIyP6VvDgPmxA5wV_HEDLCEA5jSjDHEngSxUc=.d14d9629-ea34-4ac6-b77e-25595eabd731@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
 <JDuuPV5lM4UaPp4ZQjJTbupPgG-ecI7Oza7ufSC_MY8=.200e7794-f115-46a3-850c-10cba46dacca@github.com>
 <RwZu85T8y4RTeOuKm5lsHUrmltpZsIsJBXvGrcy3rHU=.39605412-e908-490a-98fa-c32cf5895e9b@github.com>
 <b0Yf_QeIyP6VvDgPmxA5wV_HEDLCEA5jSjDHEngSxUc=.d14d9629-ea34-4ac6-b77e-25595eabd731@github.com>
Message-ID: <fb42b3be-60db-6b90-5208-2a52d3187613@oracle.com>

Hi,

the aim of this PR was firstly to have a correct implementation of the 
spec. Speed improvement was a secondary goal, which was intentionally 
pursued with conventional Java arithmetic and just a few calls to simple 
methods in the standard library.

Whether the Vector API (which is still in incubation phase) might help 
in this specific case remains to be explored.

As a first impression, there seem to be no good spots to parallelize 
using SIMD instructions. But engineers with more SIMD experience might 
find creative ways to make good use of them.


HTH
Raffaello



On 2022-06-07 18:35, LifeIsStrange wrote:
> On Mon, 9 May 2022 12:50:31 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:
> 
>>> Marked as reviewed by limck599 at github.com (no known OpenJDK username).
>>
>> @limck599
>> While we at OpenJDK appreciate constructive reviews from GitHub users not registered in the [census](https://openjdk.java.net/census), only officially nominated reviewers have the authority to approve this PR.
> 
> @rgiulietti friendly ping, noob question: Do you believe some parts of the algorithm could exploit explicit SIMD instructions (via the high level [Vector API](https://openjdk.java.net/jeps/417))  for even better performance (such as https://github.com/wrandelshofer/FastDoubleParser ) ?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3402

From duke at openjdk.java.net  Tue Jun  7 17:19:45 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 7 Jun 2022 17:19:45 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compare method in Integer and Long
Message-ID: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>

Hi,

This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .

Thank you very much.

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

Commit messages:
 - format
 - compare unsigned

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

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

From stuart.marks at oracle.com  Tue Jun  7 17:43:46 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 7 Jun 2022 10:43:46 -0700
Subject: CFV: new Core Libraries Group member: Roger Riggs
Message-ID: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>

I hereby nominate Roger Riggs [1] to membership in the Core Libraries Group [2].

Roger has been a member of the Oracle Core Libraries team since 2014. He has made 
significant contributions in the areas of java.time, Legacy Serialization and 
Serialization Filtering, Processes, and many others. He has integrated hundreds of 
changes into the JDK project [3], and he is also a Reviewer on the JDK project.

Votes are due by June 21, 2022, 23:59 PDT.

Only current members of the Core Libraries Group [4] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list, as 
described here [5]. Results are determined by lazy consensus [6].

s'marks


[1] https://openjdk.java.net/census#rriggs
[2] https://openjdk.java.net/groups/core-libs/
[3] 
https://github.com/search?q=author-name%3A%22Roger%20Riggs%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits
[4] https://openjdk.java.net/census#core-libs
[5] https://openjdk.java.net/groups/#member-vote
[6] https://openjdk.java.net/bylaws#lazy-consensus


From kvn at openjdk.java.net  Tue Jun  7 18:14:19 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 18:14:19 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <atMhzgk19V6PQ5x0C8ALF0oJbrdFMj7OTQG9KMpQ1Mk=.a127e16d-dfcc-4222-8383-b9c22e26dead@github.com>

On Tue, 7 Jun 2022 17:14:18 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

Please add microbenchmark and show its results.

src/hotspot/share/opto/subnode.hpp line 217:

> 215: //------------------------------CmpU3Node--------------------------------------
> 216: // Compare 2 unsigned values, returning integer value (-1, 0 or 1).
> 217: class CmpU3Node : public CmpUNode {

Place it after `CmpUNode` class.

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

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

From xuelei at openjdk.java.net  Tue Jun  7 18:14:55 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 7 Jun 2022 18:14:55 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v7]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <pqDIz146EyleM3TZeY8WcgjAG9ze7NhE7g7B0bt_K1M=.6fde489c-efb8-4726-861a-38ee6a75fc2d@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge
 - Merge master
 - Merge
 - add timeout parameter
 - rollback is not in this branch
 - rollback JDK-8287384
 - back to wait 1 second
 - Remove trailing white space
 - 8287596: Reorg jdk.test.lib.util.ForceGC

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

Changes: https://git.openjdk.java.net/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8979&range=06
  Stats: 86 lines in 10 files changed: 12 ins; 29 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979

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

From rriggs at openjdk.java.net  Tue Jun  7 18:48:25 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 7 Jun 2022 18:48:25 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v12]
In-Reply-To: <4GGIocVg1KkEaRWJ28Eda6lsHOzNW-97NsPMyehbc1Y=.4c641ae5-6c35-4908-9a63-e49de8dccbd0@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <4GGIocVg1KkEaRWJ28Eda6lsHOzNW-97NsPMyehbc1Y=.4c641ae5-6c35-4908-9a63-e49de8dccbd0@github.com>
Message-ID: <Xpt9TO6FI0kiXmbxRW-tTUdth8PuBdR1L3fdDqqXrYo=.57da95b7-87e9-4003-9cbd-038389214c08@github.com>

On Mon, 6 Jun 2022 21:59:56 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore EnumCtx to being an inner class, to keep all the state together in the code

trivial comments.
The commented out printf/println's should be removed before committing.

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 152:

> 150:             // Ensures that context won't get closed from underneath us
> 151:             this.enumCtx.homeCtx.incEnumCount();
> 152:             this.cleanable = LDAP_CLEANER.register(this, enumCtx);

Use  `enumCtx.getHomeCts()` above.
Use `this.enumCtx` in call to `register`.
For consistency.

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

Marked as reviewed by rriggs (Reviewer).

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

From Alan.Bateman at oracle.com  Tue Jun  7 18:55:48 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Jun 2022 19:55:48 +0100
Subject: CFV: new Core Libraries Group member: Roger Riggs
In-Reply-To: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
References: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
Message-ID: <276c4bde-d99b-59a7-fbe8-314fe31901cc@oracle.com>

Vote: yes

From iris.clark at oracle.com  Tue Jun  7 19:18:52 2022
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 7 Jun 2022 19:18:52 +0000
Subject: CFV: new Core Libraries Group member: Roger Riggs
In-Reply-To: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
References: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
Message-ID: <SJ0PR10MB5440B8EE47507E7500A497E2FBA59@SJ0PR10MB5440.namprd10.prod.outlook.com>

Vote: yes

Iris



From lancea at openjdk.java.net  Tue Jun  7 19:26:51 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 7 Jun 2022 19:26:51 GMT
Subject: RFR: 8285081: Improve XPath operators count accuracy [v3]
In-Reply-To: <AkKJqZgQXH2yQT5MtC9qLtFkZqHc6UEd77Q9BkQWnTc=.f14c9a77-659f-47fb-b54e-489f1a1fcd03@github.com>
References: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
 <AkKJqZgQXH2yQT5MtC9qLtFkZqHc6UEd77Q9BkQWnTc=.f14c9a77-659f-47fb-b54e-489f1a1fcd03@github.com>
Message-ID: <BbSzTbOgsAwhsltuMYqTDGZy5kMcaq8YkVzBjxXthyE=.58442422-7ded-4270-91a7-8dee1f04f35b@github.com>

On Fri, 3 Jun 2022 23:56:31 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. 
>> 
>> Test:  
>>      Tier2 passed;
>>      JCK XML tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused parameter

Marked as reviewed by lancea (Reviewer).

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

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

From mandy.chung at oracle.com  Tue Jun  7 19:39:24 2022
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 7 Jun 2022 12:39:24 -0700
Subject: CFV: new Core Libraries Group member: Roger Riggs
In-Reply-To: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
References: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
Message-ID: <669bcb1d-6091-f2ef-b254-cf1a6cbb8759@oracle.com>

Vote: yes

Mandy

From joehw at openjdk.java.net  Tue Jun  7 20:52:57 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 7 Jun 2022 20:52:57 GMT
Subject: Integrated: 8285081: Improve XPath operators count accuracy
In-Reply-To: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
References: <jSFK_Jj6o7EsStJeQzXOS9wFGDQVtyjUt1fO6e5xbJM=.8b530043-072c-4305-a344-98b1b6554feb@github.com>
Message-ID: <dnsQ39RnypeWrsINxRo5P0PCKDbG-PmnMsnnmASS_eQ=.5f590839-3234-4ce5-a3fb-7716a1a4e227@github.com>

On Fri, 3 Jun 2022 18:17:55 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. 
> 
> Test:  
>      Tier2 passed;
>      JCK XML tests passed.

This pull request has now been integrated.

Changeset: 8e078391
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e0783917975075aae5d586f0076d5093afb0b62
Stats:     63 lines in 3 files changed: 40 ins; 3 del; 20 mod

8285081: Improve XPath operators count accuracy

Reviewed-by: naoto, lancea

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

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

From bchristi at openjdk.java.net  Tue Jun  7 21:22:34 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 7 Jun 2022 21:22:34 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v12]
In-Reply-To: <Xpt9TO6FI0kiXmbxRW-tTUdth8PuBdR1L3fdDqqXrYo=.57da95b7-87e9-4003-9cbd-038389214c08@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <4GGIocVg1KkEaRWJ28Eda6lsHOzNW-97NsPMyehbc1Y=.4c641ae5-6c35-4908-9a63-e49de8dccbd0@github.com>
 <Xpt9TO6FI0kiXmbxRW-tTUdth8PuBdR1L3fdDqqXrYo=.57da95b7-87e9-4003-9cbd-038389214c08@github.com>
Message-ID: <wizqh0hl_W6xO6ZJ0J_Qa3JmpJgCuR4D_gJ8URbHfv0=.71c26bcf-e0b2-40ac-b97f-fd5bb4d54fe7@github.com>

On Tue, 7 Jun 2022 18:45:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The commented out printf/println's should be removed before committing.

Do you mean the pre-existing `println`s in LdapSearchEnumeration.java?

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

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

From bchristi at openjdk.java.net  Tue Jun  7 21:31:38 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 7 Jun 2022 21:31:38 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v13]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <6DF1pZKdCmgZCIPl3rV021haDIwNCjxS7jJv_-lEgJw=.639c7881-6c5c-4580-b8fb-9025f1352ee1@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

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

 - Merge branch 'master' into remove-finalizers
 - reference emunCtx and homeCtx consistently in constructor
 - Restore EnumCtx to being an inner class, to keep all the state together in the code
 - Restore comments in ldap capture file
 - Update test files - add copyright, etc
 - added getters to EnumCtx, and moved it to top level ; use getters + local variables to reduce code changes
 - test comment udpate
 - Update .ldap capture file
 - Check that cleanup was performed correctly
 - Merge branch 'master' into remove-finalizers
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/b7a34f72...afd1c9b5

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

Changes: https://git.openjdk.java.net/jdk/pull/8311/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=12
  Stats: 623 lines in 6 files changed: 352 ins; 103 del; 168 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

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

From rriggs at openjdk.java.net  Tue Jun  7 21:31:40 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 7 Jun 2022 21:31:40 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v12]
In-Reply-To: <wizqh0hl_W6xO6ZJ0J_Qa3JmpJgCuR4D_gJ8URbHfv0=.71c26bcf-e0b2-40ac-b97f-fd5bb4d54fe7@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <4GGIocVg1KkEaRWJ28Eda6lsHOzNW-97NsPMyehbc1Y=.4c641ae5-6c35-4908-9a63-e49de8dccbd0@github.com>
 <Xpt9TO6FI0kiXmbxRW-tTUdth8PuBdR1L3fdDqqXrYo=.57da95b7-87e9-4003-9cbd-038389214c08@github.com>
 <wizqh0hl_W6xO6ZJ0J_Qa3JmpJgCuR4D_gJ8URbHfv0=.71c26bcf-e0b2-40ac-b97f-fd5bb4d54fe7@github.com>
Message-ID: <S-tKvfPtFtjkcjvA_emTcyyuKLfFnocgI6qHPEBrNtM=.9882cf2f-3afe-489d-a35b-42836eb8a3d2@github.com>

On Tue, 7 Jun 2022 21:19:02 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> > The commented out printf/println's should be removed before committing.
> 
> Do you mean the pre-existing `println`s in LdapSearchEnumeration.java?
Usually, I would mean any that were added for this issue.
The changes in indentation (as presented by Github) mislead me.
Keep them if they were there before.

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

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

From stuart.marks at oracle.com  Tue Jun  7 23:11:02 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 7 Jun 2022 16:11:02 -0700
Subject: CVF: new Core Libraries Group member: Naoto Sato
In-Reply-To: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
References: <0c2293a2-baa9-0442-7d89-90c0027ec0de@oracle.com>
Message-ID: <e527e64b-f7c4-48ad-12f7-142d2e040d0e@oracle.com>

Vote: yes

On 6/6/22 5:52 PM, Stuart Marks wrote:
> I hereby nominate Naoto Sato [1] to membership in the Core Libraries Group [2].
> 
> Naoto Sato has been on the Core Libraries team for over a decade and has contributed 
> hundreds of changes to the JDK project [3]. His most significant recent contribution 
> is JEP 400: UTF-8 by Default [4]. Naoto is also lead of the Internationalization 
> Group [5] and a Reviewer on the JDK project.
> 
> Votes are due by June 20, 2022, 23:59 PDT.
> 
> Only current members of the Core Libraries Group [6] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing list, as 
> described here [7]. Results are determined by lazy consensus [8].
> 
> s'marks
> 
> 
> [1] https://openjdk.java.net/census#naoto
> [2] https://openjdk.java.net/groups/core-libs/
> [3] https://github.com/openjdk/jdk/search?q=author-name%3Anaoto&type=commits
> [4] https://openjdk.java.net/jeps/400
> [5] https://openjdk.java.net/groups/i18n/
> [6] https://openjdk.java.net/census#core-libs
> [7] https://openjdk.java.net/groups/#member-vote
> [8] https://openjdk.java.net/bylaws#lazy-consensus
> 
> 

From stuart.marks at oracle.com  Tue Jun  7 23:11:22 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 7 Jun 2022 16:11:22 -0700
Subject: CFV: new Core Libraries Group member: Roger Riggs
In-Reply-To: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
References: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
Message-ID: <62eaf0bb-8b49-9d57-0050-c22c506fb9cf@oracle.com>

Vote: yes

On 6/7/22 10:43 AM, Stuart Marks wrote:
> I hereby nominate Roger Riggs [1] to membership in the Core Libraries Group [2].
> 
> Roger has been a member of the Oracle Core Libraries team since 2014. He has made 
> significant contributions in the areas of java.time, Legacy Serialization and 
> Serialization Filtering, Processes, and many others. He has integrated hundreds of 
> changes into the JDK project [3], and he is also a Reviewer on the JDK project.
> 
> Votes are due by June 21, 2022, 23:59 PDT.
> 
> Only current members of the Core Libraries Group [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing list, as 
> described here [5]. Results are determined by lazy consensus [6].
> 
> s'marks
> 
> 
> [1] https://openjdk.java.net/census#rriggs
> [2] https://openjdk.java.net/groups/core-libs/
> [3] 
> https://github.com/search?q=author-name%3A%22Roger%20Riggs%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits 
> 
> [4] https://openjdk.java.net/census#core-libs
> [5] https://openjdk.java.net/groups/#member-vote
> [6] https://openjdk.java.net/bylaws#lazy-consensus
> 

From joe.darcy at oracle.com  Tue Jun  7 23:53:41 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 7 Jun 2022 16:53:41 -0700
Subject: CFV: new Core Libraries Group member: Roger Riggs
In-Reply-To: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
References: <0ce8256d-4ea4-fc73-a9aa-c9c148af8a08@oracle.com>
Message-ID: <19a507e7-f9b1-f78f-12de-54637d00fef7@oracle.com>

Vote: yes

-Joe



From darcy at openjdk.java.net  Wed Jun  8 01:22:32 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 8 Jun 2022 01:22:32 GMT
Subject: RFR: 8202449: overflow handling in Random.doubles [v3]
In-Reply-To: <S9k1SfnSYAzoiTlxdQ5fBpdMt4Uu8mlNWHSYJhWTI0g=.2e023744-7ed1-40a0-8075-31d8f2ede9ec@github.com>
References: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>
 <S9k1SfnSYAzoiTlxdQ5fBpdMt4Uu8mlNWHSYJhWTI0g=.2e023744-7ed1-40a0-8075-31d8f2ede9ec@github.com>
Message-ID: <0lVIDgjIjTw47O7asfpsjg6ndZfYzu6T13cXGX16-Aw=.cb6cfe1c-f9fb-407e-9305-2fefa8c358a9@github.com>

On Tue, 24 May 2022 12:58:45 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Extend the range of Random.doubles(double, double) and similar methods.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8202449: overflow handling in Random.doubles

Marked as reviewed by darcy (Reviewer).

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 733:

> 731:                 /* avoids overflow at the cost of 3 more multiplications */
> 732:                 float halfOrigin = 0.5f * origin;
> 733:                 r = (r * (0.5f * bound - halfOrigin) + halfOrigin) * 2.0f;

This could be done in double arithmetic, but I think it is better to keep it in float arithmetic for similarity with the code in the double version of the method.

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

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

From alexander.matveev at oracle.com  Wed Jun  8 02:21:35 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 8 Jun 2022 02:21:35 +0000
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
Message-ID: <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>

Hi Michael,

Yes, this is correct. It is a three step process as you outlined it below.

Thanks,
Alexander

On Jun 7, 2022, at 12:00 AM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:

Alexander,

I had an existing local GitHub repo for the jdk I updated that appeared to accept the parameters you indicated. It generated a jdk 19.

If you are saying I?m not getting the main branch or the update for some reason has dependencies I?m not getting I would have to determine how to correctly get these, or, I guess wait for a release that has all the necessary. Determining if this worked as expected before a release seemed like it would be a good idea.

Yes, the point of my original suggestion was to allow generating the application unsigned, then do post-processing - like modify the default Info.plist, and finally separately sign.

I thought your change provided the means to do this by first generating an unsigned image using ?type app-image, then on a separate invocation indicate the app-image and sign and package it.

./build/*/images/jdk/bin/jpackage --type app-image --app-image

If I follow you now it isn?t a two step but a three step process.

1) Generate unsigned application and do post-processing.

2) Sign modified app-image

3) DMG or PKG the modified and signed app-image

Is this correct?

Thanks,
Mike


From tprinzing at openjdk.java.net  Wed Jun  8 02:40:15 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Wed, 8 Jun 2022 02:40:15 GMT
Subject: RFR: JDK-8281001 Class::forName(String) defaults to system class
 loader if the caller is null [v5]
In-Reply-To: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
Message-ID: <E337Lydc10veWEum4cjKTRqZUUO_j8hkSKqauoGy8FY=.0c762e80-07fa-40c1-a9dd-197cb6019176@github.com>

> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - formatting improvement
 - Merge branch 'master' into JDK-8281001
 - Fixed the build of the native c++ test NullCallerTest to specify
   the c++ std library as part of the build.  Changed the test to
   use iostream instead of printf.  Enabled the test for Class::forName
   which is now located in test/jdk/jni/nullCaller (as part of the
   merge of JDK-8287171).
 - Merge branch 'master' into JDK-8281001
 - make javadoc consistent with other caller sensitve methods
 - Added javadoc comment
 - Merge branch 'master' into JDK-8281001
 - JDK-8281001 Examine the behavior of Class::forName if the caller is null

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

Changes: https://git.openjdk.java.net/jdk/pull/8711/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8711&range=04
  Stats: 15 lines in 4 files changed: 8 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

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

From duke at openjdk.java.net  Wed Jun  8 04:11:25 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Wed, 8 Jun 2022 04:11:25 GMT
Subject: Integrated: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException
In-Reply-To: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
References: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
Message-ID: <5tM_TOjeQangeC5cNvDjEjf22Gk9T3cIQdowBjKWTl8=.5b988a4f-861a-4f3d-9305-43d654752cf0@github.com>

On Tue, 26 Apr 2022 15:04:15 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

> 8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException

This pull request has now been integrated.

Changeset: 7df48f97
Author:    Thiago Henrique H?pner <thihup at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7df48f97d23fdeba032ddec51b6a6e6ad02d14cd
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException

Reviewed-by: jpai

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

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

From mchung at openjdk.java.net  Wed Jun  8 04:47:17 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 8 Jun 2022 04:47:17 GMT
Subject: RFR: JDK-8281001 Class::forName(String) defaults to system class
 loader if the caller is null [v5]
In-Reply-To: <E337Lydc10veWEum4cjKTRqZUUO_j8hkSKqauoGy8FY=.0c762e80-07fa-40c1-a9dd-197cb6019176@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
 <E337Lydc10veWEum4cjKTRqZUUO_j8hkSKqauoGy8FY=.0c762e80-07fa-40c1-a9dd-197cb6019176@github.com>
Message-ID: <9mEIy_zkV4Pm4N0VnEvbYxbRF30Y1zLiwZKls43yF2M=.dce16318-11ad-409a-8486-39db4ac2e1f6@github.com>

On Wed, 8 Jun 2022 02:40:15 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - formatting improvement
>  - Merge branch 'master' into JDK-8281001
>  - Fixed the build of the native c++ test NullCallerTest to specify
>    the c++ std library as part of the build.  Changed the test to
>    use iostream instead of printf.  Enabled the test for Class::forName
>    which is now located in test/jdk/jni/nullCaller (as part of the
>    merge of JDK-8287171).
>  - Merge branch 'master' into JDK-8281001
>  - make javadoc consistent with other caller sensitve methods
>  - Added javadoc comment
>  - Merge branch 'master' into JDK-8281001
>  - JDK-8281001 Examine the behavior of Class::forName if the caller is null

Looks good.  Thanks for refactoring the tests, making the addition of a new test case much cleaner.

test/jdk/jni/nullCaller/NullCallerTest.java line 27:

> 25: /**
> 26:  * @test
> 27:  * @bug 8280902 8281000 8281001 8281003 8281006

nit: append the bug rather than keeping the list in an increasing order.

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

Marked as reviewed by mchung (Reviewer).

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

From darcy at openjdk.java.net  Wed Jun  8 05:17:22 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 8 Jun 2022 05:17:22 GMT
Subject: RFR: 8233760: Result of BigDecimal.toString throws overflow
 exception on new BigDecimal(str) [v2]
In-Reply-To: <hUxp38C5zmOoZ1yOPZsLZEDkWfW8xBuPV2eY8k4091A=.50baa789-82bc-4c15-89cb-e399caf9cffd@github.com>
References: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
 <hUxp38C5zmOoZ1yOPZsLZEDkWfW8xBuPV2eY8k4091A=.50baa789-82bc-4c15-89cb-e399caf9cffd@github.com>
Message-ID: <KOyw0410ullovoMDVlgTZ5_G1mjN_M63QeAH4axRMrk=.881f6687-c91b-4013-82fc-3ff10d6ce35d@github.com>

On Fri, 27 May 2022 22:59:47 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> BigDecimal(String) currently fails to accept some strings produced by BigDecimal.toString(). This PR removes this limitation.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)

Marked as reviewed by darcy (Reviewer).

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

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

From jpai at openjdk.java.net  Wed Jun  8 06:08:17 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 8 Jun 2022 06:08:17 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
Message-ID: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>

Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?

I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class.

For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations.

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

Commit messages:
 - 8285405: add test and check for negative argument to HashMap::newHashMap et al

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

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

From jai.forums2013 at gmail.com  Wed Jun  8 06:08:27 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 8 Jun 2022 11:38:27 +0530
Subject: JDK-8186958 - Behaviour of large values for numMapping in
 WeakHashMap.newWeakHashMap API
In-Reply-To: <8acd08ef-55d9-9fae-6959-94fa6264127e@oracle.com>
References: <9f177593-b040-53bb-22ba-23b2e19cfc39@gmail.com>
 <8acd08ef-55d9-9fae-6959-94fa6264127e@oracle.com>
Message-ID: <915e6311-845d-f177-26ee-a5fab9623610@gmail.com>


On 07/06/22 9:39 am, Stuart Marks wrote:
> Hi Jai,
>
> The error
>
> ??? java.lang.OutOfMemoryError: Java heap space
>
> indicates that the VM really has run out of memory. Presumably if you 
> increased the heap size, it would actually be able to allocate that 
> memory. You might have to add the /othervm test directive and add JVM 
> options to require a larger heap.
>
> The table size must be a power of two, so the largest table size that 
> will be allocated is 1 << 30 or 1073741824 as you noted. That will 
> take about 8GB of heap (in the no-compressed-OOP case). That's not 
> terribly large, but we might want to check to see if there are other 
> tests that require that much memory.
>
> As you also noted, WeakHashMap eagerly allocates its table whereas 
> LinkedHashMap and HashMap do not. I think this is an acceptable 
> behavior variation. Note that we had to avoid this case in 
> WhiteboxResizeTest:
>
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/HashMap/WhiteBoxResizeTest.java#L167 
>
>
> We might have to make similar special cases here for WHM.
>
> I don't think we need to document this behavior difference. More 
> precisely: this kind of implementation variation doesn't need to be 
> specified. In the future we might change WHM to allocate lazily.
>
> The API should accommodate extremely large values of numMappings. Even 
> if it's larger than 1 << 30 and the table size is allocated at 1 << 
> 30, it's still possible to add numMappings mappings without resizing. 
> (Memory permitting, of course.) Doing so will violate the load factor 
> invariant, and it might result in more collisions than one would like, 
> but it should still work.

Thank you for those inputs, Stuart.


>
> I think we just need to decide whether we want to have a test that 
> allocates this much memory, and if so, to apply the necessary settings 
> to make sure the JVM has enough heap.

As a start, I've removed the large value testing in these basic tests 
and moved the PR out of the draft state.

-Jaikiran

From mik3hall at gmail.com  Wed Jun  8 06:47:51 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 8 Jun 2022 01:47:51 -0500
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
Message-ID: <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>



> On Jun 7, 2022, at 9:21 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
> Yes, this is correct. It is a three step process as you outlined it below.
> 

Alexander,

Could you post an example of the three invocations, without needing to include any post-processing, to 1) create app-image 2) sign 3) add to DMG
Or indicate any tests included, or that will be included, in the jdk source where something similar is done. 
There are not yet that I know of any documentation pages for the command? 

Thanks,
Mike


From redestad at openjdk.java.net  Wed Jun  8 07:21:34 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 8 Jun 2022 07:21:34 GMT
Subject: Integrated: 8287522: StringConcatFactory: Add in prependers and mixers
 in batches
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <aK6nRxEWerNXmDZQt4xzRejnrT2XDJerL0TaInFafr0=.29471d86-6757-4bb7-a60a-e5dc9a21e206@github.com>

On Mon, 23 May 2022 20:03:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

This pull request has now been integrated.

Changeset: 5c39a366
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5c39a3664186b91512c6a6cfcd8aa0e9860614ea
Stats:     468 lines in 4 files changed: 268 ins; 114 del; 86 mod

8287522: StringConcatFactory: Add in prependers and mixers in batches

Reviewed-by: jlaskey, mchung

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

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

From iklam at openjdk.java.net  Wed Jun  8 07:21:34 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 8 Jun 2022 07:21:34 GMT
Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout
 parsing code [v2]
In-Reply-To: <duy2SyNs9tQ-YTciNLt2xBSqGe9wv3YxsYErsoMxJzg=.6d0bfe9f-3bff-4deb-8fb4-fb4b18021d85@github.com>
References: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
 <duy2SyNs9tQ-YTciNLt2xBSqGe9wv3YxsYErsoMxJzg=.6d0bfe9f-3bff-4deb-8fb4-fb4b18021d85@github.com>
Message-ID: <ofI-jgjZ9jTNvg2UxD8AfnBpQZGzfDUetjf6wu52NLo=.174c7401-ffc4-4c18-82e9-5c5d72d12c1b@github.com>

On Tue, 7 Jun 2022 12:42:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue
>> of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read.
>> 
>> While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From
>> a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be
>> there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is
>> meant to only use stringStream throughout the cgroups code.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2
>> - [x] Added tests, which I've verified also pass before the stringStream change
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8287007-string-stream
>  - Add cgroups v2 java test
>  - use stringStream in cgroups v2
>  - Add gtest for cgroups v2 code path
>    
>    Also fixes the bug when cgroup path is '/'.
>  - 8287007: [cgroups] Consistently use stringStream throughout parsing code
>  - 8287007: [cgroups] Consistently use stringStream throughout parsing code

Changes requested by iklam (Reviewer).

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54:

> 52:       } else {
> 53:         char *p = strstr(cgroup_path, _root);
> 54:         if (p != NULL && p == cgroup_path) {

I think this change should be done in a separate bug, because it will cause the `if` block to be executed. Previously the `if` block is never executed (unless `cgroup_path == _root` ??, but then it will just set `_path` to the same string as `_mount_point`) -- so we don't even know if this change of behavior might do something harmful.

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

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

From redestad at openjdk.java.net  Wed Jun  8 07:22:25 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 8 Jun 2022 07:22:25 GMT
Subject: Integrated: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles
In-Reply-To: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
Message-ID: <3NnDOvAl7BIGNIzXM7vaG47YFQalANcNO3XyiCjkn-U=.52d6c7bb-7f6a-4d43-8e66-4547323fe0ce@github.com>

On Fri, 27 May 2022 14:18:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.

This pull request has now been integrated.

Changeset: ecf00785
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ecf00785f21125d88f5cc18311f586a7bb6ddc56
Stats:     49 lines in 3 files changed: 9 ins; 6 del; 34 mod

8287442: Reduce list to array conversions in java.lang.invoke.MethodHandles

Reviewed-by: jvernee

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

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

From aph at openjdk.java.net  Wed Jun  8 08:06:31 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 8 Jun 2022 08:06:31 GMT
Subject: RFR: 8287903: Reduce runtime of java.math microbenchmarks
In-Reply-To: <MJ3QClsZ3coUPGAOuz9nftNN-UPveIQGFquTmnfRGGc=.256c9385-d24d-40c7-8ccd-ec2b8d502fa9@github.com>
References: <MJ3QClsZ3coUPGAOuz9nftNN-UPveIQGFquTmnfRGGc=.256c9385-d24d-40c7-8ccd-ec2b8d502fa9@github.com>
Message-ID: <6dJJ1EmuX98GyD1dGI9wedSIgIU8DBqlynli1_Gbpys=.662230b9-a380-4851-8acc-964b8f01e0e8@github.com>

On Tue, 7 Jun 2022 12:34:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Reduce runtime by running fewer forks, fewer iterations, less warmup. All micros tested in this group appear to stabilize very quickly.
> - Refactor BigIntegers to avoid re-running some (most) micros over and over with parameter values that don't affect them.
> 
> Expected runtime down from 14 hours to 15 minutes.

Marked as reviewed by aph (Reviewer).

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

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

From sgehwolf at openjdk.java.net  Wed Jun  8 08:28:28 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 8 Jun 2022 08:28:28 GMT
Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout
 parsing code [v2]
In-Reply-To: <ofI-jgjZ9jTNvg2UxD8AfnBpQZGzfDUetjf6wu52NLo=.174c7401-ffc4-4c18-82e9-5c5d72d12c1b@github.com>
References: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
 <duy2SyNs9tQ-YTciNLt2xBSqGe9wv3YxsYErsoMxJzg=.6d0bfe9f-3bff-4deb-8fb4-fb4b18021d85@github.com>
 <ofI-jgjZ9jTNvg2UxD8AfnBpQZGzfDUetjf6wu52NLo=.174c7401-ffc4-4c18-82e9-5c5d72d12c1b@github.com>
Message-ID: <0krw577dlrL32YtjeZSAyIncQF6ysf4lFl6q-NhCnP8=.b563344f-66db-4e8a-b725-92aab096e4c5@github.com>

On Wed, 8 Jun 2022 07:13:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8287007-string-stream
>>  - Add cgroups v2 java test
>>  - use stringStream in cgroups v2
>>  - Add gtest for cgroups v2 code path
>>    
>>    Also fixes the bug when cgroup path is '/'.
>>  - 8287007: [cgroups] Consistently use stringStream throughout parsing code
>>  - 8287007: [cgroups] Consistently use stringStream throughout parsing code
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54:
> 
>> 52:       } else {
>> 53:         char *p = strstr(cgroup_path, _root);
>> 54:         if (p != NULL && p == cgroup_path) {
> 
> I think this change should be done in a separate bug, because it will cause the `if` block to be executed. Previously the `if` block is never executed (unless `cgroup_path == _root` ??, but then it will just set `_path` to the same string as `_mount_point`) -- so we don't even know if this change of behavior might do something harmful.

OK. Then this will remain to be dead code and I'll remove the corresponding test case in the new `gtests` too (as they'd otherwise fail in contrast to the Java code).

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

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

From duke at openjdk.java.net  Wed Jun  8 09:39:23 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 8 Jun 2022 09:39:23 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v2]
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - remove comments
 - review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9068/files
  - new: https://git.openjdk.java.net/jdk/pull/9068/files/01c0a07c..b5627135

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

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

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

From duke at openjdk.java.net  Wed Jun  8 09:39:23 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 8 Jun 2022 09:39:23 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v2]
In-Reply-To: <atMhzgk19V6PQ5x0C8ALF0oJbrdFMj7OTQG9KMpQ1Mk=.a127e16d-dfcc-4222-8383-b9c22e26dead@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <atMhzgk19V6PQ5x0C8ALF0oJbrdFMj7OTQG9KMpQ1Mk=.a127e16d-dfcc-4222-8383-b9c22e26dead@github.com>
Message-ID: <L6oamAMB9cHdshHkUyEG3Bd7C62TTN1Ff8f7R3X6YSk=.e1c24d38-cac1-482b-9654-a9f69861ba46@github.com>

On Tue, 7 Jun 2022 17:41:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove comments
>>  - review comments
>
> src/hotspot/share/opto/subnode.hpp line 217:
> 
>> 215: //------------------------------CmpU3Node--------------------------------------
>> 216: // Compare 2 unsigned values, returning integer value (-1, 0 or 1).
>> 217: class CmpU3Node : public CmpUNode {
> 
> Place it after `CmpUNode` class.

Done

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

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

From duke at openjdk.java.net  Wed Jun  8 09:42:32 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 8 Jun 2022 09:42:32 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <yEpPoRr2VaIYoQ69FtoVXgtI2e2psS2LpdQOuGHgTzI=.0f1efe28-f560-48f1-b327-182c888d14fa@github.com>

On Tue, 7 Jun 2022 17:14:18 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

I have added a benchmark for the intrinsic. The result is as follows, thanks a lot:

                                                    Before          After
    Benchmark                 (size)  Mode  Cnt  Score   Error  Score   Error  Units
    Integers.compareUnsigned     500  avgt   15  0.527 ? 0.002  0.498 ? 0.011  us/op
    Longs.compareUnsigned        500  avgt   15  0.677 ? 0.014  0.561 ? 0.006  us/op

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

PR: https://git.openjdk.java.net/jdk/pull/9068

From ihse at openjdk.java.net  Wed Jun  8 10:10:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Jun 2022 10:10:38 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
In-Reply-To: <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
Message-ID: <K3UtWQx-QAzR5uRkyvaJvzkgJFFMuJ2Rx8xSSgxDxFs=.c4e57ba0-3320-480c-9dd2-1d00bb5d08d3@github.com>

On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:
> 
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/6a77da51...e495a579

Build changes look good. Thanks for fixing the bug in `generate-symbol-data.sh`.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8236

From redestad at openjdk.java.net  Wed Jun  8 10:30:18 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 8 Jun 2022 10:30:18 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of stringifiers
Message-ID: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>

To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.

The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 

This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)

-------------

Commit messages:
 - StringConcatFactory: Split application of stringifiers

Changes: https://git.openjdk.java.net/jdk/pull/9082/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9082&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288011
  Stats: 27 lines in 1 file changed: 16 ins; 3 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9082/head:pull/9082

PR: https://git.openjdk.java.net/jdk/pull/9082

From duke at openjdk.java.net  Wed Jun  8 10:58:30 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 8 Jun 2022 10:58:30 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v2]
In-Reply-To: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
Message-ID: <i7ttqg9j_Ma_hFqj-bg-kSvpnm2xbl6fEVC6DTWLSWM=.cd3ad1fe-5e65-4d85-9c55-8866c8ab199b@github.com>

> Instead of `Executable.getParameterTypes()` we could use `Executable.getSharedParameterTypes()` in trusted code. Same is applicable for `Executable.getExceptionTypes()`.

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8287908
 - 8287908: Use non-cloning reflection methods where acceptable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9064/files
  - new: https://git.openjdk.java.net/jdk/pull/9064/files/a6715257..635854b2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9064&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9064&range=00-01

  Stats: 1833 lines in 92 files changed: 1180 ins; 242 del; 411 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9064.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9064/head:pull/9064

PR: https://git.openjdk.java.net/jdk/pull/9064

From akasko at openjdk.java.net  Wed Jun  8 11:55:56 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Wed, 8 Jun 2022 11:55:56 GMT
Subject: RFR: 8288013: jpackage: test utility Windows registry enhancement
Message-ID: <lFIf18LPCwDIoTtS2foBhR9ZZ-1LElZjPKcTDtktjOE=.dd399490-2bd0-4286-a256-d5d9cb61f1e3@github.com>

In jpackage test suite there is a test utility WindowsHelper.queryRegistryValue . It is used to verify changes to Windows registry that can be done by installer packages. It spawns `reg.exe query` process and parses its output. This patch adds support for quering empty values and additional REG_* datatypes.

Correctness was verified manually with the following registry values:


        //    (Default)    REG_SZ    test1
        //    string_val    REG_SZ    test2
        //    string_val_empty    REG_SZ
        //    bin_val    REG_BINARY    4242
        //    bin_val_empty    REG_BINARY
        //    dword_val    REG_DWORD    0x2a
        //    qword_val    REG_QWORD    0x2a
        //    multi_string_val    REG_MULTI_SZ    test3\0test4
        //    multi_string_val_empty    REG_MULTI_SZ
        //    expand_string_val    REG_EXPAND_SZ    test5
        //    expand_string_val_empty    REG_EXPAND_SZ


Corresponding utility output:


[04:36:38.190] TRACE: Registry value [] at [...] path is [test1]
[04:36:38.220] TRACE: Registry value [string_val] at [...] path is [test2]
[04:36:38.251] TRACE: Registry value [string_val_empty] at [...] path is []
[04:36:38.282] TRACE: Registry value [bin_val] at [...] path is [4242]
[04:36:38.315] TRACE: Registry value [bin_val_empty] at [...] path is []
[04:36:38.347] TRACE: Registry value [dword_val] at [...] path is [0x2a]
[04:36:38.378] TRACE: Registry value [qword_val] at [...] path is [0x2a]
[04:36:38.410] TRACE: Registry value [multi_string_val] at [...] path is [test3\\0test4]
[04:36:38.441] TRACE: Registry value [multi_string_val_empty] at [...] path is []
[04:36:38.473] TRACE: Registry value [expand_string_val] at [...] path is [test5]
[04:36:38.506] TRACE: Registry value [expand_string_val_empty] at [...] path is []


Testing:

 - [x] ran "jtreg:jdk/tools/jpackage/windows" before and after the patch

-------------

Commit messages:
 - 8288013: jpackage: test utility Windows registry enhancement

Changes: https://git.openjdk.java.net/jdk/pull/9083/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9083&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288013
  Stats: 20 lines in 1 file changed: 17 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9083.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9083/head:pull/9083

PR: https://git.openjdk.java.net/jdk/pull/9083

From sgehwolf at openjdk.java.net  Wed Jun  8 12:09:27 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 8 Jun 2022 12:09:27 GMT
Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout
 parsing code [v3]
In-Reply-To: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
References: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
Message-ID: <drxPtaMvSc3oDk3ZeKarVsMmGN8GKNmrJMxDhO-KsYo=.f5b25e16-8303-4754-b0c5-477f727429d3@github.com>

> Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated
> buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue
> of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read.
> 
> While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From
> a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be
> there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is
> meant to only use stringStream throughout the cgroups code.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2
> - [x] Added tests, which I've verified also pass before the stringStream change
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Remove fix for substring match

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8969/files
  - new: https://git.openjdk.java.net/jdk/pull/8969/files/8047fe37..84d952b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8969&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8969&range=01-02

  Stats: 10 lines in 2 files changed: 0 ins; 7 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8969.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8969/head:pull/8969

PR: https://git.openjdk.java.net/jdk/pull/8969

From sgehwolf at openjdk.java.net  Wed Jun  8 12:12:36 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 8 Jun 2022 12:12:36 GMT
Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout
 parsing code [v2]
In-Reply-To: <0krw577dlrL32YtjeZSAyIncQF6ysf4lFl6q-NhCnP8=.b563344f-66db-4e8a-b725-92aab096e4c5@github.com>
References: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
 <duy2SyNs9tQ-YTciNLt2xBSqGe9wv3YxsYErsoMxJzg=.6d0bfe9f-3bff-4deb-8fb4-fb4b18021d85@github.com>
 <ofI-jgjZ9jTNvg2UxD8AfnBpQZGzfDUetjf6wu52NLo=.174c7401-ffc4-4c18-82e9-5c5d72d12c1b@github.com>
 <0krw577dlrL32YtjeZSAyIncQF6ysf4lFl6q-NhCnP8=.b563344f-66db-4e8a-b725-92aab096e4c5@github.com>
Message-ID: <MI-ASPtrsldxrJh1RJ38w76rrCifTOiZ4eQjUfcN6g0=.23357fbf-c15c-45eb-b577-07009cfad23a@github.com>

On Wed, 8 Jun 2022 08:25:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54:
>> 
>>> 52:       } else {
>>> 53:         char *p = strstr(cgroup_path, _root);
>>> 54:         if (p != NULL && p == cgroup_path) {
>> 
>> I think this change should be done in a separate bug, because it will cause the `if` block to be executed. Previously the `if` block is never executed (unless `cgroup_path == _root` ??, but then it will just set `_path` to the same string as `_mount_point`) -- so we don't even know if this change of behavior might do something harmful.
>
> OK. Then this will remain to be dead code and I'll remove the corresponding test case in the new `gtests` too (as they'd otherwise fail in contrast to the Java code).

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8969

From duke at openjdk.java.net  Wed Jun  8 12:13:43 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 8 Jun 2022 12:13:43 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of
 stringifiers
In-Reply-To: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
Message-ID: <w2k_6dDlZsVBIvKIz3gMF1uMneXqdli3lWb1Wp8dQdA=.3e4c1516-9d86-41cd-924e-e08338c0c618@github.com>

On Wed, 8 Jun 2022 10:20:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.
> 
> The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 
> 
> This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 509:

> 507:                     doubleFilters = new MethodHandle[ptypes.length];
> 508:                 }
> 509:                 doubleFilters[i] = doubleStringifier();

Why do we have `ptypes[i] = int.class` for `int` and `short`, `ptypes[i] = String.class` for `float`, `double` and `Object` and none for `boolean` and `char`? ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/9082

From tprinzing at openjdk.java.net  Wed Jun  8 13:07:20 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Wed, 8 Jun 2022 13:07:20 GMT
Subject: RFR: JDK-8281001 Class::forName(String) defaults to system class
 loader if the caller is null [v6]
In-Reply-To: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
Message-ID: <1dsdhELN4b8_aJiSCG_hA2_M6K0oL8UgMlQizUPYG_8=.f078919a-89ca-4564-8cff-259fd5581c02@github.com>

> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  append bug id being fixed rather than sorted insert

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8711/files
  - new: https://git.openjdk.java.net/jdk/pull/8711/files/3ce3a61a..95d7044d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8711&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8711&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711

From redestad at openjdk.java.net  Wed Jun  8 13:15:20 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 8 Jun 2022 13:15:20 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of
 stringifiers
In-Reply-To: <w2k_6dDlZsVBIvKIz3gMF1uMneXqdli3lWb1Wp8dQdA=.3e4c1516-9d86-41cd-924e-e08338c0c618@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
 <w2k_6dDlZsVBIvKIz3gMF1uMneXqdli3lWb1Wp8dQdA=.3e4c1516-9d86-41cd-924e-e08338c0c618@github.com>
Message-ID: <SkT-43z6cjlZt1IWEn6RqveIKhq5q0ywu8J_VBw0AT0=.b062ba69-0719-4ccf-9f21-f9f389883589@github.com>

On Wed, 8 Jun 2022 12:11:30 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.
>> 
>> The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 
>> 
>> This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 509:
> 
>> 507:                     doubleFilters = new MethodHandle[ptypes.length];
>> 508:                 }
>> 509:                 doubleFilters[i] = doubleStringifier();
> 
> Why do we have `ptypes[i] = int.class` for `int` and `short`, `ptypes[i] = String.class` for `float`, `double` and `Object` and none for `boolean` and `char`? ??

`Object`, `float` and `double` arguments are all eagerly transformed to `String` (this is what the "stringifiers" do). Since we apply these as filters as a last step (which means that's the first thing that will run) we then must change the internal type to `String`. Ultimately means we have fewer types to worry about in the combinator.

We also widen integral subword types to `int` (`short` and `byte`). This doesn't need to be adapted by filtering but can lean on implicit conversion (subword primitives are widened to int anyhow, what we care about is matching the correct logic). This mainly matters insofar that the same direct method handle will be used for these three types, as it can (and will) be adapted without modification by the `viewAsType` call that ensures the `MH` returned from the BSM has the exact type asked for. 

`boolean` and `char` types can't use the `int` mixers/prependers and instead have specialized methods that will be adapted into the concat MH tree. This means the parameter type stays `boolean` and `char` throughout, respectively.

-------------

PR: https://git.openjdk.java.net/jdk/pull/9082

From duke at openjdk.java.net  Wed Jun  8 13:18:51 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 8 Jun 2022 13:18:51 GMT
Subject: RFR: 8288021: Add hard test cases to
 jdk.internal.math.DoubleToDecimalChecker
Message-ID: <09ta5J6B7B3tppzLNexTDnumh-XBIs629Q7saT4o70E=.7354d628-33e3-4602-ab97-6830c306c5c1@github.com>

These 19'545 doubles were generated on purpose by Paul Zimmermann of INRIA as hard test cases.

-------------

Commit messages:
 - 8288021: Add hard test cases to jdk.internal.math.DoubleToDecimalChecker

Changes: https://git.openjdk.java.net/jdk/pull/9084/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9084&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288021
  Stats: 19594 lines in 1 file changed: 19594 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9084.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9084/head:pull/9084

PR: https://git.openjdk.java.net/jdk/pull/9084

From jvernee at openjdk.java.net  Wed Jun  8 13:45:32 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 8 Jun 2022 13:45:32 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of
 stringifiers
In-Reply-To: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
Message-ID: <c566FhGqf1ZI9UZHYg1OYHNXEyY5jWbPb2hKLyVVrdE=.c4c51f67-9b66-49c8-a7b5-1bc8caa34e9c@github.com>

On Wed, 8 Jun 2022 10:20:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.
> 
> The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 
> 
> This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)

This looks good to me, but...

Looking at the code in MethodHandles::filterArguments, and this optimization. It seems that for multiple filters we could potentially always generate just a single new lambda form if we wanted, not just for repeated filters.

It would be similar to `LambdaFormEditor::makeRepeatedFilterForm`. Just need to extend the species data with one new `L_TYPE` field for each unique filter, generate a new getCombiner `Name` for each unique combiner, pass in an array of combiner types instead of just a single one, and pass in an additional array of ints that marks the combiner used by each argument position. Then do similar wiring up as we do now, but calling the corresponding combiner for each argument pos. Right?

(If I'm right about that, maybe that's even a more interesting direction to explore, since it would benefit everyone, and the code in StringConcatFactory could stay the same)

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9082

From redestad at openjdk.java.net  Wed Jun  8 14:32:35 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 8 Jun 2022 14:32:35 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of
 stringifiers
In-Reply-To: <c566FhGqf1ZI9UZHYg1OYHNXEyY5jWbPb2hKLyVVrdE=.c4c51f67-9b66-49c8-a7b5-1bc8caa34e9c@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
 <c566FhGqf1ZI9UZHYg1OYHNXEyY5jWbPb2hKLyVVrdE=.c4c51f67-9b66-49c8-a7b5-1bc8caa34e9c@github.com>
Message-ID: <vDL66rD5msyoRM3OEzQFMgvhtsjRfsvElH2QOVy_gro=.55a0144d-1339-49d6-8ed8-861cccfdeb62@github.com>

On Wed, 8 Jun 2022 13:42:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Looking at the code in MethodHandles::filterArguments, and this optimization. It seems that for multiple filters we could potentially always generate just a single new lambda form if we wanted, not just for repeated filters.
> 
> It would be similar to `LambdaFormEditor::makeRepeatedFilterForm`. Just need to extend the species data with one new `L_TYPE` field for each unique filter, generate a new getCombiner `Name` for each unique combiner, pass in an array of combiner types instead of just a single one, and pass in an additional array of ints that marks the combiner used by each argument position. Then do similar wiring up as we do now, but calling the corresponding combiner for each argument pos. Right?
> 
> (If I'm right about that, maybe that's even a more interesting direction to explore, since it would benefit everyone, and the code in StringConcatFactory could stay the same)

You're right, but I think such a transform would add quite a bit of complexity. 

Back when I added the `makeRepeatedFilterForm` optimization (for the benefit of `StringConcatFactory` ?? ) I sought to strike a balance between the simple repeatedly-create-`filterArgumentForm`s transform we would do before and more complex forms that would remove more intermediates. I was also a bit concerned that such "shortcutting" transforms could mean we eliminate sharing, and the more complex we make things the harder it gets to reason about. Example:


...
mh1 = filterArgument(baseMH, 0, filter);
mh1 = filterArgument(mh1, 0, filter);

mh2 = filterArgument(baseMH, 0, filter, filter);

mh1.form() == mh2.form(); // false


The two different pathways end up with two different LFs, since `makeRepeatedFilterForm` shortcuts. In practice this might be a non-issue, but I figured it'd be nice if we could have a reasonable pathway to resolve mh1.form() and mh2.form() to the same thing in the future.

-------------

PR: https://git.openjdk.java.net/jdk/pull/9082

From jlaskey at openjdk.java.net  Wed Jun  8 14:48:35 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 8 Jun 2022 14:48:35 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of
 stringifiers
In-Reply-To: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
Message-ID: <tl8vAlUHj2NFdb62NzJ9wqs4lJekLeHgV-BjBtVWDLk=.f5ae1de3-9ef7-4e43-b27a-8c0d16b74d92@github.com>

On Wed, 8 Jun 2022 10:20:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.
> 
> The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 
> 
> This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)

I make heavy use of the `mh = filterArgument(baseMH, 0, arrayOfFilters);` pattern. I assumed it generated fewer LF than making individual calls. Am I wrong?

-------------

PR: https://git.openjdk.java.net/jdk/pull/9082

From duke at openjdk.java.net  Wed Jun  8 14:48:36 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Wed, 8 Jun 2022 14:48:36 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v4]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <bKDy4tvzC2xuyqZGGtRJy4rvuOHtejFuQWvGAGXlU1M=.7fdd47c1-a068-4132-a705-c05bfd48aeb9@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Add tests

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/2acbedb1..c4a719e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=02-03

  Stats: 129 lines in 1 file changed: 129 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.java.net/jdk/pull/9049

From duke at openjdk.java.net  Wed Jun  8 14:51:59 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Wed, 8 Jun 2022 14:51:59 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v5]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Fix test message

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/c4a719e3..c88bc754

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.java.net/jdk/pull/9049

From alanb at openjdk.java.net  Wed Jun  8 15:01:36 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 8 Jun 2022 15:01:36 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v5]
In-Reply-To: <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>
Message-ID: <7uelBMnhTcrFYlWR5QJwEsVI99wtnr_CQ2jYsvcrzbs=.474db124-8328-4c95-8996-0ffb17a25583@github.com>

On Wed, 8 Jun 2022 14:51:59 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test message

test/jdk/tools/jar/modularJar/Basic.java line 1050:

> 1048:      */
> 1049:     @Test(dataProvider = "resolutionNames")
> 1050:     public void updateFooModuleResolutionDoNotResolveByDefaultAndWarnIfResolved(String resolutionName, Predicate<ModuleResolution> hasWarning) throws IOException {

Update the existing tests is good but overly long lines make it too hard to read (it will make future side-by-side view impossible). Can you trim all these lines down to something closer to the existing tests in this file?

-------------

PR: https://git.openjdk.java.net/jdk/pull/9049

From redestad at openjdk.java.net  Wed Jun  8 15:06:31 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 8 Jun 2022 15:06:31 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of
 stringifiers
In-Reply-To: <tl8vAlUHj2NFdb62NzJ9wqs4lJekLeHgV-BjBtVWDLk=.f5ae1de3-9ef7-4e43-b27a-8c0d16b74d92@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
 <tl8vAlUHj2NFdb62NzJ9wqs4lJekLeHgV-BjBtVWDLk=.f5ae1de3-9ef7-4e43-b27a-8c0d16b74d92@github.com>
Message-ID: <dnYou-4BlINPRFTTUYkcuIQG5SD_DEYRJieOvGlU3GE=.e725c581-54fd-435e-a70f-dc64dc6856b9@github.com>

On Wed, 8 Jun 2022 14:44:33 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.
>> 
>> The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 
>> 
>> This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)
>
> I make heavy use of the `mh = filterArgument(baseMH, 0, arrayOfFilters);` pattern. I assumed it generated fewer LF than making individual calls. Am I wrong?

@JimLaskey no, you're generally right to assume that bunching them up reduces the number of LFs created. There's a flaw in the `makeRepeatedFilterForm` transform that means the theoretical total amount of forms can surpass the baseline if you do _both_ one-by-one and all-at-once transforms from the same root MH. That's a very big if, but it's something I've felt slight unease about since I did that optimization.

-------------

PR: https://git.openjdk.java.net/jdk/pull/9082

From jpai at openjdk.java.net  Wed Jun  8 15:27:32 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 8 Jun 2022 15:27:32 GMT
Subject: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not
 working reliably on Windows
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <2aA1kJkksqDxbNMlKZq3CjNQ10C2Xf1TO4IT8-y3pX0=.27ab6afd-2138-4434-81b4-8954d2f8ff4e@github.com>

On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. 

I had quick look at the CI setup we have access to. It appears that this test passes there successfully on Windows. Could it be something to do with Windows version being used?

test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java line 48:

> 46:     private static void callGetBundle(String baseName, Locale locale,
> 47:                                       Class<? extends Throwable> expectedCause) {
> 48:         if (baseName.equals("UnreadableRB") && System.getProperty("os.name").startsWith("Windows")) {

Hello @magicus, perhaps we could do this check in the `main` of this class (line 37) before calling the `callGetBundle` for the `UnreadableRB` base name? That way this method doesn't have to bother about which `baseName` is being passed.

I had a quick look at how other tests do the OS name checks and they use the `Platform.isWindows()` API which is part of the test library. I suspect you may not be able to use it here though since this `MissingResourceCauseTest` class gets launched manually through the `MissingResourceCauseTestRun`. So using `System.getProperty` I think is fine. Nit - perhaps we could match this check to do whatever `Platform.isWindows()` is doing (which seems to be checking that the os name starts with `win`, ignoring the case).

-------------

PR: https://git.openjdk.java.net/jdk/pull/9061

From naoto at openjdk.java.net  Wed Jun  8 15:53:03 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 8 Jun 2022 15:53:03 GMT
Subject: Integrated: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <0cxpGIiWWnfKQRH3enCmtvwFlb6VMhxi2OMJkBcCmWQ=.2ffae29b-30a7-4170-a6ea-54f5bbe713e6@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

This pull request has now been integrated.

Changeset: 6fb84e2c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6fb84e2c9119bdb9c66dd49422bcab637bbd4008
Stats:     22 lines in 2 files changed: 4 ins; 11 del; 7 mod

8287541: Files.writeString fails to throw IOException for charset "windows-1252"

Reviewed-by: iris, bpb, alanb, jpai, lancea, aturbanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/9019

From psandoz at openjdk.java.net  Wed Jun  8 15:55:02 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 8 Jun 2022 15:55:02 GMT
Subject: RFR: 8287186: JDK modules participating in preview
Message-ID: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>

Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.

It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.

Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.

The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

-------------

Commit messages:
 - Unused import.
 - Generalize the pariticipating in preview APIs.

Changes: https://git.openjdk.java.net/jdk/pull/9087/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287186
  Stats: 98 lines in 7 files changed: 62 ins; 28 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9087.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9087/head:pull/9087

PR: https://git.openjdk.java.net/jdk/pull/9087

From mchung at openjdk.java.net  Wed Jun  8 16:22:35 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 8 Jun 2022 16:22:35 GMT
Subject: RFR: JDK-8281001 Class::forName(String) defaults to system class
 loader if the caller is null [v6]
In-Reply-To: <1dsdhELN4b8_aJiSCG_hA2_M6K0oL8UgMlQizUPYG_8=.f078919a-89ca-4564-8cff-259fd5581c02@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
 <1dsdhELN4b8_aJiSCG_hA2_M6K0oL8UgMlQizUPYG_8=.f078919a-89ca-4564-8cff-259fd5581c02@github.com>
Message-ID: <fMKJT99Yvczv58y1I2zEYrqVIyVLRqZNK9tUvEMKTwY=.6678191a-14d9-4cd1-b2ff-0d3ff16abd4b@github.com>

On Wed, 8 Jun 2022 13:07:20 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   append bug id being fixed rather than sorted insert

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8711

From tprinzing at openjdk.java.net  Wed Jun  8 16:25:40 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Wed, 8 Jun 2022 16:25:40 GMT
Subject: Integrated: JDK-8281001 Class::forName(String) defaults to system
 class loader if the caller is null
In-Reply-To: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
Message-ID: <sGMiBewpRzIDZNA-HbFs43uNp57xFMBtVx4TG5ceBtE=.1c72a5ae-e0e2-497b-811d-9e2e044cf0ac@github.com>

On Sat, 14 May 2022 00:30:00 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

This pull request has now been integrated.

Changeset: b92ce269
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b92ce2699b604cff638db583215863da8e253db8
Stats:     15 lines in 4 files changed: 8 ins; 3 del; 4 mod

8281001: Class::forName(String) defaults to system class loader if the caller is null

Reviewed-by: mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8711

From duke at openjdk.java.net  Wed Jun  8 16:26:05 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 8 Jun 2022 16:26:05 GMT
Subject: Integrated: 8233760: Result of BigDecimal.toString throws overflow
 exception on new BigDecimal(str)
In-Reply-To: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
References: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
Message-ID: <NdP-E6IJ7PCducH2vkrTkdWA5bz09nBV1sk8W5okBWE=.1f733f82-244d-4eeb-a39d-fff3d50621be@github.com>

On Thu, 26 May 2022 18:02:14 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> BigDecimal(String) currently fails to accept some strings produced by BigDecimal.toString(). This PR removes this limitation.

This pull request has now been integrated.

Changeset: c15e10fb
Author:    Raffaello Giulietti <raffaello.giulietti at oracle.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c15e10fb6c35a99e80009f0a7b6a252fcbb549b7
Stats:     70 lines in 2 files changed: 23 ins; 26 del; 21 mod

8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/8905

From duke at openjdk.java.net  Wed Jun  8 16:32:36 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 8 Jun 2022 16:32:36 GMT
Subject: Integrated: 8202449: overflow handling in Random.doubles
In-Reply-To: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>
References: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>
Message-ID: <pgudEqxXQJmTJ7EsftyMzjofklyv-_XBhBCZYkaF35A=.35b53f16-2e72-4f3b-9bc5-c0277d1dac42@github.com>

On Thu, 19 May 2022 15:54:06 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Extend the range of Random.doubles(double, double) and similar methods.

This pull request has now been integrated.

Changeset: c8cff1bd
Author:    Raffaello Giulietti <raffaello.giulietti at oracle.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c8cff1bd6f9807e90a6992ad3e181fe0d94397b8
Stats:     118 lines in 5 files changed: 47 ins; 36 del; 35 mod

8202449: overflow handling in Random.doubles

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/8791

From duke at openjdk.java.net  Wed Jun  8 17:00:27 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Wed, 8 Jun 2022 17:00:27 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v6]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <rLUa0b0Un3Q4Z10SAp1NRIGAy9HJKi4BGrBrBc2JD64=.ac3b642d-9ee1-463e-a5d1-f435ab9df367@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Simplify test names

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/c88bc754..7362da92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=04-05

  Stats: 30 lines in 1 file changed: 10 ins; 3 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.java.net/jdk/pull/9049

From lancea at openjdk.java.net  Wed Jun  8 17:05:32 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 8 Jun 2022 17:05:32 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
References: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
Message-ID: <kaEpxjZenAcOC4sty2w5DkpSxvHaHPYs-J8Au0R1Tqk=.9dd595f0-bde3-4b0c-9e17-4569413ef706@github.com>

On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
> 
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class.
> 
> For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/9036

From alanb at openjdk.java.net  Wed Jun  8 17:24:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 8 Jun 2022 17:24:32 GMT
Subject: RFR: 8287186: JDK modules participating in preview
In-Reply-To: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
Message-ID: <o7B-cdTDeabcvHanobQukiwPRFmQoEkIL11YV8dSGaw=.130f4b1d-3a92-4630-9e63-40a321178bbe@github.com>

On Wed, 8 Jun 2022 15:46:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

Can java.management participate too? It would allow sun.management.Util.isVirtual(Thread) to go away (lots of methods in sun.management.ThreadImpl need to test if a thread is virtual).

-------------

PR: https://git.openjdk.java.net/jdk/pull/9087

From duke at openjdk.java.net  Wed Jun  8 17:40:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:40:40 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v18]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <1xVR4-ZIHnyfeei_7RmrCV8g8aVvzI3aGgUHIP8fZx4=.d4206519-b280-4021-8fbd-a2f46180e8d1@github.com>

> as title.

XenoAmess has updated the pull request incrementally with two additional commits since the last revision:

 - remove null check for Capacitiable in WhiteBoxResizeTest
 - Rename type variable per CSR request; minor spec wording change.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/98bfb0e1..bacc9ca8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=16-17

  Stats: 19 lines in 3 files changed: 0 ins; 13 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Jun  8 17:40:43 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:40:43 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <VKRNghK623T-nMkiS7j_8DfYfdjPBu6tCIhs1x7FaqU=.61db834f-12be-446c-a7d6-8523727ba920@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <VKRNghK623T-nMkiS7j_8DfYfdjPBu6tCIhs1x7FaqU=.61db834f-12be-446c-a7d6-8523727ba920@github.com>
Message-ID: <vl6R4iBqQ81oJiQqySRtRgivszdAVIbjkraflV3FgvA=.c18bd636-d10d-4acc-a273-f1aef8624f53@github.com>

On Wed, 1 Jun 2022 17:34:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 441:
> 
>> 439:         }
>> 440:     }
>> 441: 
> 
> This unifies the test cases between the Set and Map factories, which accomplishes the primary goal. Good.
> 
> The unification is achieved through classic object-oriented polymorphism, which works fine, though which is rather verbose. This could probably be reduced with some tinkering on the model, but it's probably reaching the point where additional tinkering on the model isn't worth it. I'm ok with sticking with this approach for now. Maybe we can clean it up later, or maybe not -- it's at least fairly straightforward.
> 
> One issue that contributes to the verbosity is the repeated null checking. The null checking enables the test code to proceed and end up with -1 as the capacity if there's a null in there somewhere. This will cause the assertion to fail. This is good in that it will call attention to itself (as opposed to silently passing or something). However, if the test cases are set up properly, they should never run into null. If the null checking weren't done, an unexpected null will throw NPE, which will be caught be the framework and reported as an error.
> 
> That seems perfectly fine to me, so I'd suggest simply removing the null checking. That would also reduce the bulkiness of infrastructure.

@stuart-marks done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From naoto at openjdk.java.net  Wed Jun  8 17:47:37 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 8 Jun 2022 17:47:37 GMT
Subject: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not
 working reliably on Windows
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>

On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

Thanks for the investigation, Magnus. I believe it is a bug to include the Windows environment in refactoring the shell script to Java. Why it's been working? No idea. Could be `IOException` has been thrown not by `unreadable` but for some other reason?

-------------

PR: https://git.openjdk.java.net/jdk/pull/9061

From duke at openjdk.java.net  Wed Jun  8 17:49:38 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:49:38 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v19]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>

> as title.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  clean up Calendar

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/bacc9ca8..95d59b97

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=17-18

  Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Jun  8 17:49:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:49:40 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>
Message-ID: <EahYlBb628e0d_B3qOx1YbXqBmU0s5LKut12Z0nM_Qk=.39bbbf60-b42c-40ef-af52-3984487e176c@github.com>

On Wed, 1 Jun 2022 18:26:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> src/java.base/share/classes/java/util/Calendar.java line 2648:
> 
>> 2646:             set.add("gregory");
>> 2647:             set.add("buddhist");
>> 2648:             set.add("japanese");
> 
> This can be replaced with `SET = Set.of("gregory", "buddhist", "japanese");`.

@naotoj Yes it can. I did a further clean up to it, please have a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From kvn at openjdk.java.net  Wed Jun  8 17:55:25 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 8 Jun 2022 17:55:25 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v2]
In-Reply-To: <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>
Message-ID: <ZiP4IVUuN_mMZtnOBclKUg1A6FisHxqJxV8pz7ebPpw=.8e22e84e-bc45-434c-97ca-eb323740ca20@github.com>

On Wed, 8 Jun 2022 09:39:23 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove comments
>  - review comments

Good. I submitted testing.
You need second review.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9068

From psandoz at openjdk.java.net  Wed Jun  8 18:24:35 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 8 Jun 2022 18:24:35 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
Message-ID: <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>

> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  Let java.management participate in preview features.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9087/files
  - new: https://git.openjdk.java.net/jdk/pull/9087/files/5e7ca855..9defdf23

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=00-01

  Stats: 44 lines in 5 files changed: 4 ins; 29 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9087.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9087/head:pull/9087

PR: https://git.openjdk.java.net/jdk/pull/9087

From psandoz at openjdk.java.net  Wed Jun  8 18:24:38 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 8 Jun 2022 18:24:38 GMT
Subject: RFR: 8287186: JDK modules participating in preview
In-Reply-To: <o7B-cdTDeabcvHanobQukiwPRFmQoEkIL11YV8dSGaw=.130f4b1d-3a92-4630-9e63-40a321178bbe@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <o7B-cdTDeabcvHanobQukiwPRFmQoEkIL11YV8dSGaw=.130f4b1d-3a92-4630-9e63-40a321178bbe@github.com>
Message-ID: <K60MqsJDCyyc2JvgDuVerhdbUSbeYZl32dliaxekGiA=.334a0f1c-f6ae-4fc1-a7d8-c85713f4d286@github.com>

On Wed, 8 Jun 2022 17:21:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can java.management participate too? It would allow sun.management.Util.isVirtual(Thread) to go away (lots of methods in sun.management.ThreadImpl need to test if a thread is virtual).

Pushed update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/9087

From alanb at openjdk.java.net  Wed Jun  8 18:30:35 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 8 Jun 2022 18:30:35 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
Message-ID: <R_joxppBdMx0zy4QJnMHA8c_4g1U_SWJMlDiztQ4iGg=.33e28a8b-2926-4fe9-9b9d-dbf78fe4647c@github.com>

On Wed, 8 Jun 2022 18:24:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
>> 
>> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
>> 
>> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
>> 
>> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Let java.management participate in preview features.

The updates to java.base, java.management, and jdk.incubator.* looks fine, it's good to have the reflection code go away.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9087

From rriggs at openjdk.java.net  Wed Jun  8 19:08:59 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 8 Jun 2022 19:08:59 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <ELdnRcxtLDgBaoiXqTXLj5lqSRZvfw_bXrS36oU6U2c=.5d2e2f52-eb23-4ac9-93ac-763517427974@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/1b91dbd2...05cf2d8b

Testing a mask for one AccessFlag looks like:

     if ((modifiers & AccessFlag.STRICTFP.mask()) != 0) { ... }


A method on AccessFlag to test if its mask value is present in a 32-bit value would/could make the code easier to read and write.

    if (AccessFlag.STRICTFP.isPresent(modifiers)) { ...}

The method name should be chosen to make the test clear and readable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From jlahoda at openjdk.java.net  Wed Jun  8 19:29:34 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 8 Jun 2022 19:29:34 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
Message-ID: <WLNko_NnPuWjR7pR-K3-DwHE0AqPQpCXb_2gUyMQQGc=.8e873804-84b3-4b3b-88e5-1ec4cebe1348@github.com>

On Wed, 8 Jun 2022 18:24:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
>> 
>> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
>> 
>> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
>> 
>> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Let java.management participate in preview features.

javac + `jdk.internal.javac` changes look good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9087

From smarks at openjdk.java.net  Wed Jun  8 20:16:33 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 8 Jun 2022 20:16:33 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v19]
In-Reply-To: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
Message-ID: <66QMts98pQNLZzxi4BlX-aj13JkeVQeB8v8MNKVrpDY=.9b8680cc-f54e-4d7f-9b25-806b367d835b@github.com>

On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up Calendar

Running tests and awaiting review from security team. Our internal test system is backlogged and tests might not complete in time to get into JDK 19.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From lancea at openjdk.java.net  Wed Jun  8 20:17:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 8 Jun 2022 20:17:27 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v5]
In-Reply-To: <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <3VxesI8auEv_NO62MsrUnNWeltH1Mc7yfK_5BEhaKJI=.82143bae-08d8-4f58-8e85-4cd0952d85a1@github.com>
Message-ID: <dLzZWF1bWNj28VQFSIx6jx_DXdLCRb3R9OcMSJBJwEw=.4cd3436c-cd45-4b4b-8963-744097f7b691@github.com>

On Wed, 8 Jun 2022 14:51:59 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test message

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/9049

From ascarpino at openjdk.java.net  Wed Jun  8 20:31:43 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 8 Jun 2022 20:31:43 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v19]
In-Reply-To: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
Message-ID: <kqydNmdnzsVvm6ITkeY9avGcwLvwp9C4T8HeILLC12U=.6d177140-6176-44b5-9b4b-bd78570a078d@github.com>

On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up Calendar

I gave a quick look at the security files touched and seems straightforward. I didn't see any problems

-------------

Marked as reviewed by ascarpino (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

From mcimadamore at openjdk.java.net  Wed Jun  8 21:15:15 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 8 Jun 2022 21:15:15 GMT
Subject: RFR: 8288068: Javadoc contains spurious reference to CLinker
Message-ID: <NrNXRiC7_oMGQV35quDe7x4dNB3OAJcC_xIj1Hnfv1I=.9705f7b7-1080-4f5c-8e0a-0fb413810a6d@github.com>

This simple patch fixes a bunch of references to "CLinker" and replaces them with "Linker", following the API name changes.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/9094/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9094&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288068
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9094/head:pull/9094

PR: https://git.openjdk.java.net/jdk/pull/9094

From duke at openjdk.java.net  Wed Jun  8 22:09:48 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 8 Jun 2022 22:09:48 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
Message-ID: <3U2G2s2rU3i848aC3PNZUkBVxZKhVNM3uZPWnA_AObc=.2f5a668f-a0ac-4fa5-9160-e98e7399bb33@github.com>

On Wed, 8 Jun 2022 18:24:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
>> 
>> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
>> 
>> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
>> 
>> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Let java.management participate in preview features.

Just curious, is it still up to incubator modules' discretion to avoid accidental user access to preview content via the modules without enabling preview, like the `PreviewFeatures.ensureEnabled()` in `StructuredTaskScope`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/9087

From iris at openjdk.java.net  Wed Jun  8 23:41:33 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 8 Jun 2022 23:41:33 GMT
Subject: RFR: 8288068: Javadoc contains spurious reference to CLinker
In-Reply-To: <NrNXRiC7_oMGQV35quDe7x4dNB3OAJcC_xIj1Hnfv1I=.9705f7b7-1080-4f5c-8e0a-0fb413810a6d@github.com>
References: <NrNXRiC7_oMGQV35quDe7x4dNB3OAJcC_xIj1Hnfv1I=.9705f7b7-1080-4f5c-8e0a-0fb413810a6d@github.com>
Message-ID: <ZdHuLLdKafKO4bQybvsmw9VRZl862FpfvEsUXAFemGU=.75fd2209-6fc8-4485-85fc-9baebbb6b97e@github.com>

On Wed, 8 Jun 2022 21:07:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This simple patch fixes a bunch of references to "CLinker" and replaces them with "Linker", following the API name changes.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/9094

From kvn at openjdk.java.net  Wed Jun  8 23:57:32 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 8 Jun 2022 23:57:32 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v2]
In-Reply-To: <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>
Message-ID: <ssBVpDU0sJdoTn-ZOEErALrTPwYaKYAO2bZRqgFQOpM=.cd7695b1-a59c-4a5a-83a8-5c34de37dc86@github.com>

On Wed, 8 Jun 2022 09:39:23 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove comments
>  - review comments

Tier1-4 testing passed - no new failures. I suggest to push it into JDK 20 after fork and after you get second review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/9068

From mcimadamore at openjdk.java.net  Thu Jun  9 00:02:35 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 9 Jun 2022 00:02:35 GMT
Subject: Integrated: 8288068: Javadoc contains spurious reference to CLinker
In-Reply-To: <NrNXRiC7_oMGQV35quDe7x4dNB3OAJcC_xIj1Hnfv1I=.9705f7b7-1080-4f5c-8e0a-0fb413810a6d@github.com>
References: <NrNXRiC7_oMGQV35quDe7x4dNB3OAJcC_xIj1Hnfv1I=.9705f7b7-1080-4f5c-8e0a-0fb413810a6d@github.com>
Message-ID: <5J_EuQCkbzwx7ROtG-Lf7qBmr_a39VgsAPGvv2Rh9J0=.540cc376-ce6f-4283-b9dd-e75761c6e08b@github.com>

On Wed, 8 Jun 2022 21:07:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This simple patch fixes a bunch of references to "CLinker" and replaces them with "Linker", following the API name changes.

This pull request has now been integrated.

Changeset: 65f0829d
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/65f0829d645fd988c6a208622b1f34bf9de08e60
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8288068: Javadoc contains spurious reference to CLinker

Reviewed-by: iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/9094

From darcy at openjdk.java.net  Thu Jun  9 01:03:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Jun 2022 01:03:47 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <n1d8Iv4qjk-lznK-UveaBbbb-EAfIGyDOwkoQ935WAQ=.483638ae-69ba-4731-ad21-f47299ca8ca2@github.com>

> Time to start getting ready for JDK 20...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:

 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Update symbols for JDK 19 b25.
 - Merge branch 'master' into JDK-8284858
 - Adjust deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - ... and 34 more: https://git.openjdk.java.net/jdk/compare/530d16c1...1b29a17c

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/e495a579..1b29a17c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=04-05

  Stats: 16423 lines in 539 files changed: 12382 ins; 2143 del; 1898 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From almatvee at openjdk.java.net  Thu Jun  9 01:31:13 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 9 Jun 2022 01:31:13 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
Message-ID: <O6z6codxRYdZJWCsAfqBc8y53f4eXUPGG4T5HtPlOH8=.f9479109-ed89-464a-a702-a2f788f9772a@github.com>

- Warning will be printed if .jpackage.xml has old version number.
 - Error will be thrown if main-class and app-store values are missing from .jpackage.xml.
 - Both main-class and app-store are required values for JDK-8286850 and they might be missing if user uses app images generated by previous jpackage version.

-------------

Commit messages:
 - 8287971: Throw exception for missing values in .jpackage.xml

Changes: https://git.openjdk.java.net/jdk/pull/9098/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287971
  Stats: 73 lines in 6 files changed: 56 ins; 9 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9098.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9098/head:pull/9098

PR: https://git.openjdk.java.net/jdk/pull/9098

From duke at openjdk.java.net  Thu Jun  9 01:54:37 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 9 Jun 2022 01:54:37 GMT
Subject: Integrated: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <uBGmXlQd9TXwXKbiDcrVcLUktKK4rTenr6JRZx7MBjA=.9a961a01-5109-4e38-8594-c3413bdf0c8c@github.com>

On Tue, 19 Apr 2022 18:00:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> as title.

This pull request has now been integrated.

Changeset: e01cd7c3
Author:    XenoAmess <xenoamess at gmail.com>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e01cd7c3ed923cd19509fc972ba6e4aa2991289f
Stats:     154 lines in 29 files changed: 107 ins; 7 del; 40 mod

8284780: Need methods to create pre-sized HashSet and LinkedHashSet

Reviewed-by: naoto, bpb, dfuchs, ascarpino

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From asemenyuk at openjdk.java.net  Thu Jun  9 02:08:30 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 9 Jun 2022 02:08:30 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
In-Reply-To: <O6z6codxRYdZJWCsAfqBc8y53f4eXUPGG4T5HtPlOH8=.f9479109-ed89-464a-a702-a2f788f9772a@github.com>
References: <O6z6codxRYdZJWCsAfqBc8y53f4eXUPGG4T5HtPlOH8=.f9479109-ed89-464a-a702-a2f788f9772a@github.com>
Message-ID: <RlB9t8fF2eGLvAvYEdlHAbeZY8Eb7OXAXxHQUNQbsOA=.5143f15e-ab53-4929-83d3-77fad2b8ad0c@github.com>

On Thu, 9 Jun 2022 01:21:30 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Warning will be printed if .jpackage.xml has old version number.
>  - Error will be thrown if main-class and app-store values are missing from .jpackage.xml.
>  - Both main-class and app-store are required values for JDK-8286850 and they might be missing if user uses app images generated by previous jpackage version.

If some fields of .jpackage.xml are not valid, the entire file must be considered invalid, not only the invalid fields. This is the idea of `AppImageFile.isValid()` method.
We do not support backward compatibility for .jpackage.xml for simplicity.
We do support only the case when an application image supplied in `--app-image` parameter to jpackage was created by the same jpackage, and not by jpackage from another JDK or from the same JDK but on another platform.

I'd discard this fix and create a new one that will:
1. Make `AppImageFile.getVersion()` return the value of `java.version` system property instead of hardcoded "1.0" value.
2. If `AppImageFile.isValid()` returns false, throw exception saying that .jpackage.xml is malformed instead of returning empty AppImageFile instance from `AppImageFile.load()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/9098

From iris at openjdk.java.net  Thu Jun  9 04:23:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 9 Jun 2022 04:23:40 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]
In-Reply-To: <n1d8Iv4qjk-lznK-UveaBbbb-EAfIGyDOwkoQ935WAQ=.483638ae-69ba-4731-ad21-f47299ca8ca2@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <n1d8Iv4qjk-lznK-UveaBbbb-EAfIGyDOwkoQ935WAQ=.483638ae-69ba-4731-ad21-f47299ca8ca2@github.com>
Message-ID: <GM1p-fYjWEfrt5pYM5rZjVuRnY2fr_nKe_hpB_iTk1w=.3c99866a-5384-41be-bbc9-15dd1affffc1@github.com>

On Thu, 9 Jun 2022 01:03:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - ... and 34 more: https://git.openjdk.java.net/jdk/compare/705cfa36...1b29a17c

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From qingfeng.yy at alibaba-inc.com  Thu Jun  9 06:07:32 2022
From: qingfeng.yy at alibaba-inc.com (Yi Yang)
Date: Thu, 09 Jun 2022 14:07:32 +0800
Subject: =?UTF-8?B?QWRkIGphdmEudXRpbC5PYmplY3RzLmR1bXAgdG8gZmFjaWxpdGF0ZSBxdWljayBkZWJ1Z2dp?=
 =?UTF-8?B?bmc=?=
Message-ID: <8705a48d-7e2c-46db-98d4-7b5f3c63f4c7.qingfeng.yy@alibaba-inc.com>

Is it helpful to add a new Objects.dump method for quick debugging? Not in all cases
we can open IDEA and happily use jdb to debug our code, sometimes we may just want
to write a simple script, or work without IDE, for these cases, we can use Objects. dump
to output field details of the object and feed back to the developer, so that they can quickly
modify the code and continue to develop. Another useful scenario is working within jshell,
Objects.dump can visualize object details, which is especially useful for REPL environments.

It looks like var_dump() in PHP[1] :
```
Person p = new Person(...)
Objects.dump(p)
Person = {
  name = "..."
  age = 24
  height = 1.75f
  attr = {
     ...
  }
}
```
In addition, we can also add Config parameters to allow users to control output content and
format they expect, such as
```
config.pretty = true
config.maxDepth = 5
config.dumpParent = true
config.fieldFilter (Field f) -> ...
Objects.dump(obj, config)
```
This is just a very rough idea, it's too early to discuss implementation details at this point,
I'm looking forward to hearing more feedback about the idea of adding Objects.dump itself.

Thanks.

[1] https://www.php.net/manual/en/function.var-dump.php

From mariell.hoversholm at paf.com  Thu Jun  9 08:20:27 2022
From: mariell.hoversholm at paf.com (Mariell Hoversholm)
Date: Thu, 9 Jun 2022 10:20:27 +0200
Subject: Add java.util.Objects.dump to facilitate quick debugging
In-Reply-To: <8705a48d-7e2c-46db-98d4-7b5f3c63f4c7.qingfeng.yy@alibaba-inc.com>
References: <8705a48d-7e2c-46db-98d4-7b5f3c63f4c7.qingfeng.yy@alibaba-inc.com>
Message-ID: <CAKSb5uMfO1OiTMDuFYimo29fSmQSqzCZ-p4tBzzrL-PWcB3gug@mail.gmail.com>

Hey,

Out of curiosity, why not just `System.out.println(person)`?

On Thu, 9 Jun 2022 at 08:08, Yi Yang <qingfeng.yy at alibaba-inc.com> wrote:

> Is it helpful to add a new Objects.dump method for quick debugging? Not in
> all cases
> we can open IDEA and happily use jdb to debug our code, sometimes we may
> just want
> to write a simple script, or work without IDE, for these cases, we can use
> Objects. dump
> to output field details of the object and feed back to the developer, so
> that they can quickly
> modify the code and continue to develop. Another useful scenario is
> working within jshell,
> Objects.dump can visualize object details, which is especially useful for
> REPL environments.
>
> It looks like var_dump() in PHP[1] :
> ```
> Person p = new Person(...)
> Objects.dump(p)
> Person = {
>   name = "..."
>   age = 24
>   height = 1.75f
>   attr = {
>      ...
>   }
> }
> ```
> In addition, we can also add Config parameters to allow users to control
> output content and
> format they expect, such as
> ```
> config.pretty = true
> config.maxDepth = 5
> config.dumpParent = true
> config.fieldFilter (Field f) -> ...
> Objects.dump(obj, config)
> ```
> This is just a very rough idea, it's too early to discuss implementation
> details at this point,
> I'm looking forward to hearing more feedback about the idea of adding
> Objects.dump itself.
>
> Thanks.
>
> [1] https://www.php.net/manual/en/function.var-dump.php

From ihse at openjdk.java.net  Thu Jun  9 08:25:32 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Jun 2022 08:25:32 GMT
Subject: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not
 working reliably on Windows
In-Reply-To: <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
 <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>
Message-ID: <LofjxogQ2FqWanowgpQnSNNuY0gyt_D5JWWqjTtxI6k=.cbd713a9-e6dd-46cc-ad8c-fb8de193a751@github.com>

On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
>> 
>> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
>> 
>> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
>> 
>> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
>> 
>> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).
>
> Thanks for the investigation, Magnus. I believe it is a bug to include the Windows environment in refactoring the shell script to Java. Why it's been working? No idea. Could be `IOException` has been thrown not by `unreadable` but for some other reason?

@naotoj Yes, that could be a likely possibility. Perhaps the file were never created, or not in the expected place?

-------------

PR: https://git.openjdk.java.net/jdk/pull/9061

From mbaesken at openjdk.java.net  Thu Jun  9 11:47:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 9 Jun 2022 11:47:06 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
Message-ID: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>

We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.

Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
VALID_VS_VERSIONS="2019 2017 2022"
Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

-------------

Commit messages:
 - JDK-8288094

Changes: https://git.openjdk.java.net/jdk/pull/9105/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288094
  Stats: 144 lines in 9 files changed: 0 ins; 131 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9105.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9105/head:pull/9105

PR: https://git.openjdk.java.net/jdk/pull/9105

From duke at openjdk.java.net  Thu Jun  9 12:19:35 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 9 Jun 2022 12:19:35 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v7]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <2RGbeMoqCpLOmePC72LlrtxJqqSUQZiLgDQPlStFJmk=.1db7273f-406b-4079-a8da-179b03f4378a@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Update author

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9049/files
  - new: https://git.openjdk.java.net/jdk/pull/9049/files/7362da92..8544abd9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=05-06

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.java.net/jdk/pull/9049

From redestad at openjdk.java.net  Thu Jun  9 13:14:38 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 9 Jun 2022 13:14:38 GMT
Subject: RFR: 8287903: Reduce runtime of java.math microbenchmarks
In-Reply-To: <MJ3QClsZ3coUPGAOuz9nftNN-UPveIQGFquTmnfRGGc=.256c9385-d24d-40c7-8ccd-ec2b8d502fa9@github.com>
References: <MJ3QClsZ3coUPGAOuz9nftNN-UPveIQGFquTmnfRGGc=.256c9385-d24d-40c7-8ccd-ec2b8d502fa9@github.com>
Message-ID: <p_UzOW8AOrVus6Cs4xgI9xM-XTpnBVCXoJX7akGemao=.fa1f051d-6ede-49c9-9e2e-e1d5a04bb90c@github.com>

On Tue, 7 Jun 2022 12:34:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Reduce runtime by running fewer forks, fewer iterations, less warmup. All micros tested in this group appear to stabilize very quickly.
> - Refactor BigIntegers to avoid re-running some (most) micros over and over with parameter values that don't affect them.
> 
> Expected runtime down from 14 hours to 15 minutes.

Thanks for reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/9062

From redestad at openjdk.java.net  Thu Jun  9 13:14:40 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 9 Jun 2022 13:14:40 GMT
Subject: Integrated: 8287903: Reduce runtime of java.math microbenchmarks
In-Reply-To: <MJ3QClsZ3coUPGAOuz9nftNN-UPveIQGFquTmnfRGGc=.256c9385-d24d-40c7-8ccd-ec2b8d502fa9@github.com>
References: <MJ3QClsZ3coUPGAOuz9nftNN-UPveIQGFquTmnfRGGc=.256c9385-d24d-40c7-8ccd-ec2b8d502fa9@github.com>
Message-ID: <eOi03JIViBiGNjr00KJfY4TkRAMlwVKONgrRffwFMHI=.3c3b2cca-0d03-4a9e-ab88-20b658c7d62d@github.com>

On Tue, 7 Jun 2022 12:34:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Reduce runtime by running fewer forks, fewer iterations, less warmup. All micros tested in this group appear to stabilize very quickly.
> - Refactor BigIntegers to avoid re-running some (most) micros over and over with parameter values that don't affect them.
> 
> Expected runtime down from 14 hours to 15 minutes.

This pull request has now been integrated.

Changeset: 7e948f7c
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e948f7ccbb4b9be04f5ecb65cc8dd72e3b495f4
Stats:     104 lines in 4 files changed: 66 ins; 33 del; 5 mod

8287903: Reduce runtime of java.math microbenchmarks

Reviewed-by: ecaspole, aph

-------------

PR: https://git.openjdk.java.net/jdk/pull/9062

From liangchenblue at gmail.com  Thu Jun  9 14:32:16 2022
From: liangchenblue at gmail.com (-)
Date: Thu, 9 Jun 2022 09:32:16 -0500
Subject: Add java.util.Objects.dump to facilitate quick debugging
In-Reply-To: <8705a48d-7e2c-46db-98d4-7b5f3c63f4c7.qingfeng.yy@alibaba-inc.com>
References: <8705a48d-7e2c-46db-98d4-7b5f3c63f4c7.qingfeng.yy@alibaba-inc.com>
Message-ID: <CABe8uE2yodPbxs26F7WVkSt-SPCbGJ=1w2N7DZRgDRLJ9_maGQ@mail.gmail.com>

My main concerns are about security, that many object details, while
useful to viewers, should not be accessible by any code under any
circumstances. Having any code able to print all field content of any
object sounds extremely dangerous.

In my opinion, we can use a MethodHandles.Lookup as a permission
control; the dump may print fields that the lookup context (obtainable
by caller with MethodHandles.lookup()) may access, including ones
accessible through reflection (e.g. open packages).

On Thu, Jun 9, 2022 at 1:07 AM Yi Yang <qingfeng.yy at alibaba-inc.com> wrote:
>
> Is it helpful to add a new Objects.dump method for quick debugging? Not in all cases
> we can open IDEA and happily use jdb to debug our code, sometimes we may just want
> to write a simple script, or work without IDE, for these cases, we can use Objects. dump
> to output field details of the object and feed back to the developer, so that they can quickly
> modify the code and continue to develop. Another useful scenario is working within jshell,
> Objects.dump can visualize object details, which is especially useful for REPL environments.
>
> It looks like var_dump() in PHP[1] :
> ```
> Person p = new Person(...)
> Objects.dump(p)
> Person = {
>   name = "..."
>   age = 24
>   height = 1.75f
>   attr = {
>      ...
>   }
> }
> ```
> In addition, we can also add Config parameters to allow users to control output content and
> format they expect, such as
> ```
> config.pretty = true
> config.maxDepth = 5
> config.dumpParent = true
> config.fieldFilter (Field f) -> ...
> Objects.dump(obj, config)
> ```
> This is just a very rough idea, it's too early to discuss implementation details at this point,
> I'm looking forward to hearing more feedback about the idea of adding Objects.dump itself.
>
> Thanks.
>
> [1] https://www.php.net/manual/en/function.var-dump.php

From naoto at openjdk.java.net  Thu Jun  9 15:45:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 9 Jun 2022 15:45:38 GMT
Subject: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not
 working reliably on Windows
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <Zkua61UFVk-eSqEZmXh_Q8OqaTTTgCKa6mizEHvBMr4=.f0dcb414-7c94-42e3-baed-f645f0a18529@github.com>

On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9061

From naoto at openjdk.java.net  Thu Jun  9 15:45:41 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 9 Jun 2022 15:45:41 GMT
Subject: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not
 working reliably on Windows
In-Reply-To: <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
 <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>
Message-ID: <rewRsxMriFNAhUbo5rVPijDEoX1Cv76vRB3swWysF_U=.257bc9fa-1052-4d8e-a7d4-aeb94bcc92c4@github.com>

On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
>> 
>> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
>> 
>> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
>> 
>> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
>> 
>> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).
>
> Thanks for the investigation, Magnus. I believe it is a bug to include the Windows environment in refactoring the shell script to Java. Why it's been working? No idea. Could be `IOException` has been thrown not by `unreadable` but for some other reason?

> @naotoj Yes, that could be a likely possibility. Perhaps the file were never created, or not in the expected place?

I'd guess something like that too. Anyways, eliminating this unreliability in test is a good clean up. Approving the fix assuming Jai's comment is addressed.

-------------

PR: https://git.openjdk.org/jdk/pull/9061

From naoto at openjdk.java.net  Thu Jun  9 15:48:11 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 9 Jun 2022 15:48:11 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v7]
In-Reply-To: <mhpnjoL_era4xeDDmX7VzNdmFlcVkg6QKVcQWfNgcPo=.c144beee-dc9e-4b08-9b82-eeaca5ff36df@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <mhpnjoL_era4xeDDmX7VzNdmFlcVkg6QKVcQWfNgcPo=.c144beee-dc9e-4b08-9b82-eeaca5ff36df@github.com>
Message-ID: <8w3R129QhA-AkApB-3ngwJSrNcHtWum8ahjeT5BV6Jc=.e67e0c96-a49e-49ee-8a36-875a1e5e35ed@github.com>

On Tue, 7 Jun 2022 14:15:55 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285838: Simplified Daylight period checks for test.

Looks good. Thanks for the contribution.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8661

From redestad at openjdk.java.net  Thu Jun  9 16:04:43 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 9 Jun 2022 16:04:43 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of
 stringifiers [v2]
In-Reply-To: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
Message-ID: <Y2i73g7SEsLA8nkH1Evf0Ye5z1zk1420o-ZCc2kf8KA=.0d5298a4-243b-4c3f-9daf-131c56847355@github.com>

> To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.
> 
> The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 
> 
> This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments based on review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9082/files
  - new: https://git.openjdk.org/jdk/pull/9082/files/51c841e8..4b7c696e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9082&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9082&range=00-01

  Stats: 11 lines in 1 file changed: 7 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9082.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9082/head:pull/9082

PR: https://git.openjdk.org/jdk/pull/9082

From darcy at openjdk.java.net  Thu Jun  9 16:21:25 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Jun 2022 16:21:25 GMT
Subject: Integrated: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <b1Cu-1h4TvuAVVuAlcZi4SoVs0KQOh8UxvL9CUKz3IE=.3792f081-f3fe-444c-981a-af47a3d6f123@github.com>

On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start getting ready for JDK 20...

This pull request has now been integrated.

Changeset: edff51e5
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edff51e5fdb5282830ecfb3792a88c7b28ca6557
Stats:     6453 lines in 69 files changed: 6403 ins; 5 del; 45 mod

8284858: Start of release updates for JDK 20
8286035: Add source 20 and target 20 to javac
8286034: Add SourceVersion.RELEASE_20

Reviewed-by: dholmes, kcr, iris, erikj, jjg, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/8236

From mchung at openjdk.java.net  Thu Jun  9 17:48:07 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 9 Jun 2022 17:48:07 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of
 stringifiers [v2]
In-Reply-To: <Y2i73g7SEsLA8nkH1Evf0Ye5z1zk1420o-ZCc2kf8KA=.0d5298a4-243b-4c3f-9daf-131c56847355@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
 <Y2i73g7SEsLA8nkH1Evf0Ye5z1zk1420o-ZCc2kf8KA=.0d5298a4-243b-4c3f-9daf-131c56847355@github.com>
Message-ID: <p98GaXYgNkrNuWxah6my8PqmMCapG2eFY7eyVyIH48g=.f6bc6fbb-68e4-4e33-9d39-877a9497552f@github.com>

On Thu, 9 Jun 2022 16:04:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.
>> 
>> The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 
>> 
>> This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments based on review feedback

Looks good to me.

Like Jorne's observation, it'd benefit everyone if this could generate just a single new lambda form multiple filters, not just for repeated filters if feasible.   Maybe something to explore more in the future with a tradeoff of complexity.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9082

From bpb at openjdk.java.net  Thu Jun  9 18:38:18 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 9 Jun 2022 18:38:18 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v5]
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <iP7AX78NRh96ngXdhMgAODuDwjuuPUBxdJ6FJ01Rp8U=.2770e2b5-43af-46a1-bd58-7dea630bcdab@github.com>

> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

Brian Burkhalter has updated the pull request 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
 - 6478546: Add break in write loop on ExceptionOccurred
 - Merge
 - 6478546: Clean up io_util.c
 - Merge
 - 6478546: Decrease malloc'ed buffer maximum size to 64 kB
 - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8235/files
  - new: https://git.openjdk.org/jdk/pull/8235/files/10f14bb3..00521485

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8235&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8235&range=03-04

  Stats: 118890 lines in 1877 files changed: 57455 ins; 51098 del; 10337 mod
  Patch: https://git.openjdk.org/jdk/pull/8235.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8235/head:pull/8235

PR: https://git.openjdk.org/jdk/pull/8235

From aturbanov at openjdk.java.net  Thu Jun  9 21:00:36 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 9 Jun 2022 21:00:36 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
Message-ID: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>

https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178

Instead of separate Hashtable.get/remove calls we can just use value returned by `remove`,
It results in cleaner and a bit faster code.

-------------

Commit messages:
 - [PATCH] Avoid redundant Hashtable.get call in Signal.handle
 - [PATCH] Avoid redundant Hashtable.get call in Signal.handle

Changes: https://git.openjdk.org/jdk/pull/9100/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9100&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288140
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9100.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9100/head:pull/9100

PR: https://git.openjdk.org/jdk/pull/9100

From duke at openjdk.java.net  Thu Jun  9 21:15:06 2022
From: duke at openjdk.java.net (David M. Lloyd)
Date: Thu, 9 Jun 2022 21:15:06 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
In-Reply-To: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
Message-ID: <ju4pHE-HHnjlP19TYHzEuHAn7eXKH1jB1eiFL6HZmpw=.08336be5-f8b0-44a6-afea-ae29b7646656@github.com>

On Thu, 9 Jun 2022 07:35:43 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
> 
> Instead of separate Hashtable.get/remove calls we can just use value returned by `remove`,
> It results in cleaner and a bit faster code.

src/java.base/share/classes/jdk/internal/misc/Signal.java line 180:

> 178:             if (newH == 2) {
> 179:                 handlers.put(sig, handler);
> 180:             }

If you made this change instead:

Suggestion:

            Signal.Handler oldHandler;
            if (newH == 2) {
                oldHandler = handlers.replace(sig, handler);
            } else {
                oldHandler = handlers.remove(sig);
            }


Wouldn't you be able to remove the entire `synchronized` block?

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From smarks at openjdk.java.net  Thu Jun  9 23:16:08 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 9 Jun 2022 23:16:08 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
References: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
Message-ID: <sw5JLaBVEWRPtBajBBbR1aII5AcbVZMveO9_WVDejzM=.e45b55a9-ba3c-4204-8467-6eaa541c9ad7@github.com>

On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
> 
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class.
> 
> For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations.

Note that I've integrated [JDK-8284780](https://bugs.openjdk.org/browse/JDK-8284780) (HashSet static factories) so maybe this PR could be updated with tests for those as well.

-------------

PR: https://git.openjdk.org/jdk/pull/9036

From sviswanathan at openjdk.java.net  Fri Jun 10 00:09:00 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 10 Jun 2022 00:09:00 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <yEpPoRr2VaIYoQ69FtoVXgtI2e2psS2LpdQOuGHgTzI=.0f1efe28-f560-48f1-b327-182c888d14fa@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <yEpPoRr2VaIYoQ69FtoVXgtI2e2psS2LpdQOuGHgTzI=.0f1efe28-f560-48f1-b327-182c888d14fa@github.com>
Message-ID: <S4ek0_dLqaSUzE5L4pz_bLmffegMhjPw8N3GHIW2eVc=.23cfbd7d-2c88-42fe-ab2a-a314e278cfb0@github.com>

On Wed, 8 Jun 2022 09:39:04 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> I have added a benchmark for the intrinsic. The result is as follows, thanks a lot:
> 
>                                                     Before          After
>     Benchmark                 (size)  Mode  Cnt  Score   Error  Score   Error  Units
>     Integers.compareUnsigned     500  avgt   15  0.527 ? 0.002  0.498 ? 0.011  us/op
>     Longs.compareUnsigned        500  avgt   15  0.677 ? 0.014  0.561 ? 0.006  us/op

@merykitty Could you please also add the micro benchmark where compareUnsigned result is stored directly in an integer and show the performance of that?

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From ysatowse at openjdk.java.net  Fri Jun 10 02:00:26 2022
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 10 Jun 2022 02:00:26 GMT
Subject: RFR: 8287917: System.loadLibrary does not work on Big Sur if JDK is
 built with macOS SDK 10.15 and earlier
Message-ID: <g3x9IY-mxwALbN_akqYAgFHK9vlsc8KBtQP59VHdGcQ=.cbbd4f55-268f-4f3e-be00-150a26f86ff0@github.com>

Please review this PR.
SDK 10.15 and earlier reports os.version as 10.16 on Big Sur.  This fix will check if dynamic linker support, which is supported from Big Sur, is available or not on the OS even if os.version is reported as 10.16 instead of 11.  The os.version 10.16 doesn't include the update version like y of 10.x.y.  Hence the change only see if it is 10.16 or not.

-------------

Commit messages:
 - Remove trailing whtiespace
 - Move print-debug to the top
 - Print os.version for logging purpose
 - 8287917: System.loadLibrary does not work on Big Sur if JDK is built with macOS SDK 10.15 and earlier

Changes: https://git.openjdk.org/jdk/pull/9077/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9077&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287917
  Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9077.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9077/head:pull/9077

PR: https://git.openjdk.org/jdk/pull/9077

From jpai at openjdk.java.net  Fri Jun 10 03:28:59 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 10 Jun 2022 03:28:59 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al
In-Reply-To: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
References: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
Message-ID: <y80drTVqD8pvkqwTeaPv61zyqG_h9Fu9dpW-In0eU-s=.1fb12997-8832-4d12-938b-97b3344ed48b@github.com>

On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
> 
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class.
> 
> For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations.

Hello Stuart, I'll include tests for those in this PR shortly.

-------------

PR: https://git.openjdk.org/jdk/pull/9036

From jpai at openjdk.java.net  Fri Jun 10 06:47:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 10 Jun 2022 06:47:06 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
In-Reply-To: <ju4pHE-HHnjlP19TYHzEuHAn7eXKH1jB1eiFL6HZmpw=.08336be5-f8b0-44a6-afea-ae29b7646656@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
 <ju4pHE-HHnjlP19TYHzEuHAn7eXKH1jB1eiFL6HZmpw=.08336be5-f8b0-44a6-afea-ae29b7646656@github.com>
Message-ID: <0HUifGODBCcpDT-TweELCoEpB4aWhWsvsRSYSwveXFM=.b9f655c4-f33b-4233-a417-baa57bfaa634@github.com>

On Thu, 9 Jun 2022 21:11:55 GMT, David M. Lloyd <duke at openjdk.java.net> wrote:

>> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
>> 
>> Instead of separate Hashtable.get/remove calls we can just use value returned by `remove`,
>> It results in cleaner and a bit faster code.
>
> src/java.base/share/classes/jdk/internal/misc/Signal.java line 180:
> 
>> 178:             if (newH == 2) {
>> 179:                 handlers.put(sig, handler);
>> 180:             }
> 
> If you made this change instead:
> 
> Suggestion:
> 
>             Signal.Handler oldHandler;
>             if (newH == 2) {
>                 oldHandler = handlers.replace(sig, handler);
>             } else {
>                 oldHandler = handlers.remove(sig);
>             }
> 
> 
> Wouldn't you be able to remove the entire `synchronized` block?

Hello David, I suspect you mean `handlers.put(sig, handler)` and not `handlers.replace(...)`? And yes, I think what you suggest will help remove the synchronized block here.

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From jpai at openjdk.java.net  Fri Jun 10 08:24:10 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 10 Jun 2022 08:24:10 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al [v2]
In-Reply-To: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
References: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
Message-ID: <LjbE0wPsIlCHk8Qi0AhhJSm5IYsSAas0zoxOX57e2wM=.202a955f-6260-4a25-9e56-d0e298294672@github.com>

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
> 
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class.
> 
> For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations.

Jaikiran Pai 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:

 - Add tests for the new HashSet#newHashSet and LinkedHashSet#newLinkedHashSet APIs
 - add a check for negative numElements very early in the new APIs of HashSet and LinkedHashSet
 - Merge latest from master branch
 - 8285405: add test and check for negative argument to HashMap::newHashMap et al

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9036/files
  - new: https://git.openjdk.org/jdk/pull/9036/files/9ccebd79..07bbaa91

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9036&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9036&range=00-01

  Stats: 9862 lines in 210 files changed: 8727 ins; 512 del; 623 mod
  Patch: https://git.openjdk.org/jdk/pull/9036.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9036/head:pull/9036

PR: https://git.openjdk.org/jdk/pull/9036

From jpai at openjdk.java.net  Fri Jun 10 08:26:02 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 10 Jun 2022 08:26:02 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al [v3]
In-Reply-To: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
References: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
Message-ID: <htowLOfO1V1jUwTBmA6SkpCLU2weqCWZ4ey1PSI7viA=.ea0f21e1-a0ab-48c4-a6cf-55dff71b2c61@github.com>

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
> 
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class.
> 
> For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  add newline at the end of the new file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9036/files
  - new: https://git.openjdk.org/jdk/pull/9036/files/07bbaa91..ba159d14

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9036&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9036&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9036.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9036/head:pull/9036

PR: https://git.openjdk.org/jdk/pull/9036

From jpai at openjdk.java.net  Fri Jun 10 08:33:01 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 10 Jun 2022 08:33:01 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al [v3]
In-Reply-To: <htowLOfO1V1jUwTBmA6SkpCLU2weqCWZ4ey1PSI7viA=.ea0f21e1-a0ab-48c4-a6cf-55dff71b2c61@github.com>
References: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
 <htowLOfO1V1jUwTBmA6SkpCLU2weqCWZ4ey1PSI7viA=.ea0f21e1-a0ab-48c4-a6cf-55dff71b2c61@github.com>
Message-ID: <owLDm7gdEhAJ2Ff9d11F8vHe8wXRTDYKQP_cBjEU9Ww=.0fe91c3a-aa25-47bd-bd47-786fccff0742@github.com>

On Fri, 10 Jun 2022 08:26:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
>> 
>> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class.
>> 
>> For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add newline at the end of the new file

I've now update the PR to include tests for `HashSet.newHashSet` and `LinkedHashSet.newLinkedHashSet` APIs. Additionally, their implementation too have has been modified to do the necessary negative param check. The copyright year on the `LinkedHashSet.java` file has also been updated accordingly.

P.S: Please ignore the bot message which talks about rebase/force-push. No rebase or force-push was done (only the recommended merge command was used to merge with latest master branch). I will check with the relevant team to see if there's some bug in the bot which generates that message. I have seen that happen recently on few other PRs as well.

-------------

PR: https://git.openjdk.org/jdk/pull/9036

From duke at openjdk.java.net  Fri Jun 10 08:47:36 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 10 Jun 2022 08:47:36 GMT
Subject: RFR: 8288173: JDK-8202449 fix causes conformance test failure :
 api/java_util/Random/RandomGenerator/NextFloat.html
Message-ID: <nJ53b0pD1oDz77JFPldh9cIRsF3q9YUkeoMleMthzNM=.e9fe9e21-7e74-4955-94ed-7707cc7da31b@github.com>

This fixes a bug introduced with JDK-8202449.

-------------

Commit messages:
 - 8288173: JDK-8202449 fix causes conformance test failure

Changes: https://git.openjdk.org/jdk/pull/9120/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9120&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288173
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9120.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9120/head:pull/9120

PR: https://git.openjdk.org/jdk/pull/9120

From lancea at openjdk.java.net  Fri Jun 10 10:09:05 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 10 Jun 2022 10:09:05 GMT
Subject: RFR: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
In-Reply-To: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
References: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
Message-ID: <TR5_xxZU3neGX93MjEkHC9l9rg9pHA5T0SSh8Km62sQ=.beac14b4-604c-45e7-b446-e73cee8d7fea@github.com>

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

The changes to doneWithMeta() seem reasonable and the other changes remove unused code so look OK to me

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8935

From ihse at openjdk.java.net  Fri Jun 10 10:11:31 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 10:11:31 GMT
Subject: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not
 working reliably on Windows [v2]
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <raqP06TCF3UrNUDMMJC3hnXlmT8hjsUx2paN73feR8A=.baa01e97-4c53-4ab5-b56c-e69f7f00d862@github.com>

> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  From code review:  use more robust OS check and move it to main()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9061/files
  - new: https://git.openjdk.org/jdk/pull/9061/files/7cd2dccf..162e928c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9061&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9061&range=00-01

  Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9061.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9061/head:pull/9061

PR: https://git.openjdk.org/jdk/pull/9061

From ihse at openjdk.java.net  Fri Jun 10 10:11:32 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 10:11:32 GMT
Subject: Integrated: 8287902: UnreadableRB case in MissingResourceCauseTest is
 not working reliably on Windows
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <ZR2plvRXZA99gl1gb_syJkvyLcbzTvCK9Vx7GcRL138=.de1b8af2-e075-4fe0-8bde-b8424bba25ac@github.com>

On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

This pull request has now been integrated.

Changeset: 975316e3
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/975316e3e5f1208e4e15eadc2493d25c15554647
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/9061

From mdoerr at openjdk.java.net  Fri Jun 10 10:53:14 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 10 Jun 2022 10:53:14 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <hhcl2DS9otR1Jql7mhvTBsiP96NUBscYl-i5zXiVIzc=.e1dee9ab-6eff-45b6-b769-8d05bc10871a@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

LGTM and sounds feasible.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9105

From mbaesken at openjdk.java.net  Fri Jun 10 11:30:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 10 Jun 2022 11:30:06 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <hhcl2DS9otR1Jql7mhvTBsiP96NUBscYl-i5zXiVIzc=.e1dee9ab-6eff-45b6-b769-8d05bc10871a@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <hhcl2DS9otR1Jql7mhvTBsiP96NUBscYl-i5zXiVIzc=.e1dee9ab-6eff-45b6-b769-8d05bc10871a@github.com>
Message-ID: <1ekFL0P-_g0l_A4cqFl61JU66x4SyCp97VFeqtkX0gw=.0b43bf9e-0dc1-41b2-bb1f-89e8dcd7d393@github.com>

On Fri, 10 Jun 2022 10:49:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> LGTM and sounds feasible.

Hi Martin, thanks for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/9105

From aturbanov at openjdk.java.net  Fri Jun 10 11:31:06 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 10 Jun 2022 11:31:06 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
 [v2]
In-Reply-To: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
Message-ID: <nx8Z5HZC4KU3ycOKMt4jxsA2JmminkROX1zyWh51qiE=.5d5d98e1-01d0-4973-bb7a-192dc06898a5@github.com>

> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
> 
> Instead of separate Hashtable.get/remove calls we can just use value returned by `remove`,
> It results in cleaner and a bit faster code.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8288140: Avoid redundant Hashtable.get call in Signal.handle
  apply dmlloyd's suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9100/files
  - new: https://git.openjdk.org/jdk/pull/9100/files/220d3b61..829f9e23

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9100&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9100&range=00-01

  Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9100.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9100/head:pull/9100

PR: https://git.openjdk.org/jdk/pull/9100

From duke at openjdk.java.net  Fri Jun 10 11:49:06 2022
From: duke at openjdk.java.net (David M. Lloyd)
Date: Fri, 10 Jun 2022 11:49:06 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
 [v2]
In-Reply-To: <0HUifGODBCcpDT-TweELCoEpB4aWhWsvsRSYSwveXFM=.b9f655c4-f33b-4233-a417-baa57bfaa634@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
 <ju4pHE-HHnjlP19TYHzEuHAn7eXKH1jB1eiFL6HZmpw=.08336be5-f8b0-44a6-afea-ae29b7646656@github.com>
 <0HUifGODBCcpDT-TweELCoEpB4aWhWsvsRSYSwveXFM=.b9f655c4-f33b-4233-a417-baa57bfaa634@github.com>
Message-ID: <adGtEkTAo92PwB1xSJ7E7_jhX-569fbM_IWAQQp-w5Y=.344446fc-e743-403e-b7ce-6f1cedb7afed@github.com>

On Fri, 10 Jun 2022 06:45:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/Signal.java line 180:
>> 
>>> 178:             if (newH == 2) {
>>> 179:                 handlers.put(sig, handler);
>>> 180:             }
>> 
>> If you made this change instead:
>> 
>> Suggestion:
>> 
>>             Signal.Handler oldHandler;
>>             if (newH == 2) {
>>                 oldHandler = handlers.put(sig, handler);
>>             } else {
>>                 oldHandler = handlers.remove(sig);
>>             }
>> 
>> 
>> Wouldn't you be able to remove the entire `synchronized` block?
>
> Hello David, I suspect you mean `handlers.put(sig, handler)` and not `handlers.replace(...)`? And yes, I think what you suggest will help remove the synchronized block here.

Oops, yes you are correct!

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From mbaesken at openjdk.java.net  Fri Jun 10 12:23:35 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 10 Jun 2022 12:23:35 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
Message-ID: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>

When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :

import com.sun.jndi.ldap.LdapURL;
 ....
String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
LdapURL ldapUrl = new LdapURL(url);


java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)

I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
with "special"/problematic host and port values.

-------------

Commit messages:
 - JDK-8288207

Changes: https://git.openjdk.org/jdk/pull/9126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288207
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126

From alanb at openjdk.java.net  Fri Jun 10 13:18:59 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 13:18:59 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <E83n5FJmLDDCR5qw9Pegqoioa9zjN_lqTjP5_ZC3OOI=.3458bd2b-1e10-4353-ad20-81daa7f3146f@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

We have to be cautious about leaking security sensitive configuration in exception messages. Can you look at the security property jdk.includeInException (conf/security/java.security) and usages in the JDK for ideas on how this might be implemented as opt-in?

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From dholmes at openjdk.java.net  Fri Jun 10 13:31:37 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 10 Jun 2022 13:31:37 GMT
Subject: RFR: 8279047: Remove expired flags in JDK 20
Message-ID: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>

Expired Flags in 20:

- FilterSpuriousWakeups
- MinInliningThreshold
- PrefetchFieldsAhead

No remaining usages in code or tests.

- UseHeavyMonitors  (expired in PRODUCT ONLY)

As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM.

- test/jdk/java/lang/Thread/virtual/HoldsLock.java

The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM.

- test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java

Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds.

No documentation in the manpage exists for any of the newly expired flags.

Obsoleted flags in 20:

- ExtendedDTraceProbes

Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913).

- UseContainerCpuShares
- PreferContainerQuotaForCPUCount
- AliasLevel

Undocumented.

Java manpage updates:
- Updates Java version to 20
- Moved ExtendedDTraceProbe info as previously mentioned
- Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated).
- Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly

-------------

Commit messages:
 - Fix typo
 - 8279047: Remove expired flags in JDK 20

Changes: https://git.openjdk.org/jdk/pull/9127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9127&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8279047
  Stats: 69 lines in 5 files changed: 23 ins; 26 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/9127.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9127/head:pull/9127

PR: https://git.openjdk.org/jdk/pull/9127

From mbaesken at openjdk.java.net  Fri Jun 10 13:44:58 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 10 Jun 2022 13:44:58 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <E83n5FJmLDDCR5qw9Pegqoioa9zjN_lqTjP5_ZC3OOI=.3458bd2b-1e10-4353-ad20-81daa7f3146f@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <E83n5FJmLDDCR5qw9Pegqoioa9zjN_lqTjP5_ZC3OOI=.3458bd2b-1e10-4353-ad20-81daa7f3146f@github.com>
Message-ID: <HZqbf5hZnPvSktuITPwsL0fqy_JUQVajPwoCbt587aE=.26378aa5-ac65-4b14-9109-3e0b29df0763@github.com>

On Fri, 10 Jun 2022 13:15:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We have to be cautious about leaking security sensitive configuration in exception messages. Can you look at the security property jdk.includeInException (conf/security/java.security) and usages in the JDK for ideas on how this might be implemented as opt-in?

Hi Alan ,   sure we could use something like the already existing hostInfo of property jdk.includeInException 
      private static final boolean enhancedExceptionText = SecurityProperties.includedInExceptions("hostInfo");
and make the enhancement optional/switchable this way.
On the other hand we already print the url  (_**Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz**_ )  in the existing exception text so I wonder what additional problem the added info would bring? That's why I  did not use the property so far.
But if you think there could be special cases were it would be problematic to have the enhancement, I'll add the usage of the property.

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From alanb at openjdk.java.net  Fri Jun 10 14:03:00 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 14:03:00 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <HZqbf5hZnPvSktuITPwsL0fqy_JUQVajPwoCbt587aE=.26378aa5-ac65-4b14-9109-3e0b29df0763@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <E83n5FJmLDDCR5qw9Pegqoioa9zjN_lqTjP5_ZC3OOI=.3458bd2b-1e10-4353-ad20-81daa7f3146f@github.com>
 <HZqbf5hZnPvSktuITPwsL0fqy_JUQVajPwoCbt587aE=.26378aa5-ac65-4b14-9109-3e0b29df0763@github.com>
Message-ID: <f0SyiH6_o7EpnNJDi4xTEHopgZKhryJumz7Ky9fLScQ=.5243a696-2250-4c29-b2cd-0dcc0e5f96ce@github.com>

On Fri, 10 Jun 2022 13:41:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan , sure we could use something like the already existing hostInfo of property jdk.includeInException private static final boolean enhancedExceptionText = SecurityProperties.includedInExceptions("hostInfo"); and make the enhancement optional/switchable this way. On the other hand we already print the url (_**Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz**_ ) in the existing exception text so I wonder what additional problem the added info would bring? That's why I did not use the property so far. But if you think there could be special cases were it would be problematic to have the enhancement, I'll add the usage of the property.

This is a security sensitive area and not possible to discuss all issues in JBS or in this PR. If this code is changed then it will require someone from security-dev to review.

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From dfuchs at openjdk.java.net  Fri Jun 10 14:22:58 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 10 Jun 2022 14:22:58 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

`URISyntaxException`/`MalformedURLException` usually contains the whole URL - so in this case, because we're parsing a URL, I believe the added information would not leak more sensitive data - especially since I'd expect URI.getHost() to be always `null` and `URI.getPort()` to be always `-1` in this case. 
That is - this exception is thrown when the authority is parsed as a reg_name, as opposed to server-base, because the provided host name (or what looks like a host name) contains a character that is not allowed by java.net.URI in a host name.


jshell> URI.create("ldap://a_b.com:389/foo");
$1 ==> ldap://a_b.com:389/foo

jshell> $1.getAuthority()
$2 ==> "a_b.com:389"

jshell> $1.getHost()
$3 ==> null


As a point of comparison, here is what URISyntaxException looks like if the authority contains a character which is not legal at all in authority:


jshell> new URI("ldap://a_%b.com:389/foo");
|  Exception java.net.URISyntaxException: Malformed escape pair at index 9: ldap://a_%b.com:389/foo
|        at URI$Parser.fail (URI.java:2973)


I agree we should wait for someone from security-dev to chime in though.

I might question whether the added "null:-1" information is really helpful, or just as confusing however.

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From kvn at openjdk.java.net  Fri Jun 10 16:01:02 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 10 Jun 2022 16:01:02 GMT
Subject: RFR: 8279047: Remove expired flags in JDK 20
In-Reply-To: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
References: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
Message-ID: <08vbjWK5DR3Ka73-cLos7Oxvsrte5Xdj_kn5E96LCc8=.7c9af12a-e737-47b6-98ab-e02229456ff2@github.com>

On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Expired Flags in 20:
> 
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
> 
> No remaining usages in code or tests.
> 
> - UseHeavyMonitors  (expired in PRODUCT ONLY)
> 
> As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM.
> 
> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
> 
> The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM.
> 
> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> 
> Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds.
> 
> No documentation in the manpage exists for any of the newly expired flags.
> 
> Obsoleted flags in 20:
> 
> - ExtendedDTraceProbes
> 
> Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913).
> 
> - UseContainerCpuShares
> - PreferContainerQuotaForCPUCount
> - AliasLevel
> 
> Undocumented.
> 
> Java manpage updates:
> - Updates Java version to 20
> - Moved ExtendedDTraceProbe info as previously mentioned
> - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated).
> - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9127

From darcy at openjdk.java.net  Fri Jun 10 16:22:20 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 10 Jun 2022 16:22:20 GMT
Subject: RFR: JDK-8288227: Refactor annotation implementation to use pattern
 matching for instanceof
Message-ID: <tFccfqv6j1-VCm-fCLeMwq9QIdqbrNOAJg-6TCZ3QwE=.076c24f4-feb2-4fff-9a56-be7c8cb89f97@github.com>

There are many instanceof checks in the sun.reflection.annotation code; these would be improved by using pattern matching for instanceof.

-------------

Commit messages:
 - JDK-8288227: Refactor annotation implementation to use pattern matching for instanceo

Changes: https://git.openjdk.org/jdk/pull/9129/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288227
  Stats: 57 lines in 4 files changed: 1 ins; 14 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/9129.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9129/head:pull/9129

PR: https://git.openjdk.org/jdk/pull/9129

From duke at openjdk.java.net  Fri Jun 10 16:30:57 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 10 Jun 2022 16:30:57 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v8]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9049/files
  - new: https://git.openjdk.org/jdk/pull/9049/files/8544abd9..962f0ec1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.org/jdk/pull/9049

From duke at openjdk.java.net  Fri Jun 10 16:44:03 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 10 Jun 2022 16:44:03 GMT
Subject: RFR: JDK-8288227: Refactor annotation implementation to use
 pattern matching for instanceof
In-Reply-To: <tFccfqv6j1-VCm-fCLeMwq9QIdqbrNOAJg-6TCZ3QwE=.076c24f4-feb2-4fff-9a56-be7c8cb89f97@github.com>
References: <tFccfqv6j1-VCm-fCLeMwq9QIdqbrNOAJg-6TCZ3QwE=.076c24f4-feb2-4fff-9a56-be7c8cb89f97@github.com>
Message-ID: <pn2MyCMBGWaNyV9iYyhx3zoZiTZUtVic5vvP12d2CMo=.e96cd1dd-b08a-4472-af67-230d5c08caa7@github.com>

On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> There are many instanceof checks in the sun.reflection.annotation code; these would be improved by using pattern matching for instanceof.

Seems clean

-------------

PR: https://git.openjdk.org/jdk/pull/9129

From alanb at openjdk.java.net  Fri Jun 10 16:50:04 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 16:50:04 GMT
Subject: RFR: JDK-8288227: Refactor annotation implementation to use
 pattern matching for instanceof
In-Reply-To: <tFccfqv6j1-VCm-fCLeMwq9QIdqbrNOAJg-6TCZ3QwE=.076c24f4-feb2-4fff-9a56-be7c8cb89f97@github.com>
References: <tFccfqv6j1-VCm-fCLeMwq9QIdqbrNOAJg-6TCZ3QwE=.076c24f4-feb2-4fff-9a56-be7c8cb89f97@github.com>
Message-ID: <6FJZHaa2AoDO4Khi4Xr-eZWRtPxJGg2GjseyI5lLfpU=.930f1708-fc6e-4980-b491-a48e960181a3@github.com>

On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> There are many instanceof checks in the sun.reflection.annotation code; these would be improved by using pattern matching for instanceof.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9129

From darcy at openjdk.java.net  Fri Jun 10 17:10:05 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 10 Jun 2022 17:10:05 GMT
Subject: Integrated: JDK-8288227: Refactor annotation implementation to use
 pattern matching for instanceof
In-Reply-To: <tFccfqv6j1-VCm-fCLeMwq9QIdqbrNOAJg-6TCZ3QwE=.076c24f4-feb2-4fff-9a56-be7c8cb89f97@github.com>
References: <tFccfqv6j1-VCm-fCLeMwq9QIdqbrNOAJg-6TCZ3QwE=.076c24f4-feb2-4fff-9a56-be7c8cb89f97@github.com>
Message-ID: <r804z-UFpDOM76ERMlMNd9DrFrO8RgvA3ngzFoMHRh8=.6ae9ca76-fa79-4535-aebb-c95db6d466a9@github.com>

On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> There are many instanceof checks in the sun.reflection.annotation code; these would be improved by using pattern matching for instanceof.

This pull request has now been integrated.

Changeset: aaa89714
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aaa897148ab2669e06531521221f0551335b3d1f
Stats:     57 lines in 4 files changed: 1 ins; 14 del; 42 mod

8288227: Refactor annotation implementation to use pattern matching for instanceof

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9129

From mchung at openjdk.java.net  Fri Jun 10 17:58:01 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 10 Jun 2022 17:58:01 GMT
Subject: RFR: 8287917: System.loadLibrary does not work on Big Sur if JDK
 is built with macOS SDK 10.15 and earlier
In-Reply-To: <g3x9IY-mxwALbN_akqYAgFHK9vlsc8KBtQP59VHdGcQ=.cbbd4f55-268f-4f3e-be00-150a26f86ff0@github.com>
References: <g3x9IY-mxwALbN_akqYAgFHK9vlsc8KBtQP59VHdGcQ=.cbbd4f55-268f-4f3e-be00-150a26f86ff0@github.com>
Message-ID: <Kq9ghWWNZ5je-HoAnx2IoOUetu0UYsk1DJAOMA0b_5U=.28569670-597a-4612-8dd3-c73d55751711@github.com>

On Wed, 8 Jun 2022 04:59:07 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.
> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur.  This fix will check if dynamic linker support, which is supported from Big Sur, is available or not on the OS even if os.version is reported as 10.16 instead of 11.  The os.version 10.16 doesn't include the update version like y of 10.x.y.  Hence the change only see if it is 10.16 or not.

Looks good.  Thanks for fixing this.

As a background, Big Sur reports 10.16 as backward compatibility when built with macOS SDK 10.15 and earlier.   Hence this needs to check for os version 10.16 that supports dynamic linker cache.

test/jdk/java/lang/RuntimeTests/loadLibrary/exeLibraryCache/LibraryFromCache.java line 45:

> 43: public class LibraryFromCache {
> 44:     public static void main(String[] args) throws IOException {
> 45:         System.out.println("os.version = " + System.getProperty("os.version"));

The copyright end year needs to be updated.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9077

From alanb at openjdk.java.net  Fri Jun 10 18:05:06 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 18:05:06 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v8]
In-Reply-To: <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>
Message-ID: <Q3jfKrJ_wm3mvDjf-RxOf5Qed20eF3t0tzb0C7nuTvU=.e46c68c6-1f82-47b8-93dd-34c562c333ec@github.com>

On Fri, 10 Jun 2022 16:30:57 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

test/jdk/tools/jar/modularJar/Basic.java line 44:

> 42: 
> 43: import jdk.internal.module.ModuleReferenceImpl;
> 44: import jdk.internal.module.ModuleResolution;

At some point we need to put in test infrastructure to avoid this and a few other tests from depending on JDK internals.

test/jdk/tools/jar/modularJar/Basic.java line 951:

> 949: 
> 950:     @DataProvider(name = "resolutionNames")
> 951:     public Object[][] resolutionNames() {

This is a data provider for resolution warnings, maybe it should be renamed.

-------------

PR: https://git.openjdk.org/jdk/pull/9049

From duke at openjdk.java.net  Fri Jun 10 18:21:10 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 10 Jun 2022 18:21:10 GMT
Subject: RFR: 8288173: JDK-8202449 fix causes conformance test failure :
 api/java_util/Random/RandomGenerator/NextFloat.html
In-Reply-To: <nJ53b0pD1oDz77JFPldh9cIRsF3q9YUkeoMleMthzNM=.e9fe9e21-7e74-4955-94ed-7707cc7da31b@github.com>
References: <nJ53b0pD1oDz77JFPldh9cIRsF3q9YUkeoMleMthzNM=.e9fe9e21-7e74-4955-94ed-7707cc7da31b@github.com>
Message-ID: <Xd5gRlOqVj0Ic0fZ16M_A9ekASi69TMP6YT2uGL795U=.8bc60706-87a4-4476-8ccc-62b240ce8ae2@github.com>

On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> This fixes a bug introduced with JDK-8202449.

The fix reverts an inadvertent "correction" sneaked into JDK-8202449, restoring previous (correct) behavior.

-------------

PR: https://git.openjdk.org/jdk/pull/9120

From bpb at openjdk.java.net  Fri Jun 10 18:26:05 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 10 Jun 2022 18:26:05 GMT
Subject: RFR: 8288173: JDK-8202449 fix causes conformance test failure :
 api/java_util/Random/RandomGenerator/NextFloat.html
In-Reply-To: <nJ53b0pD1oDz77JFPldh9cIRsF3q9YUkeoMleMthzNM=.e9fe9e21-7e74-4955-94ed-7707cc7da31b@github.com>
References: <nJ53b0pD1oDz77JFPldh9cIRsF3q9YUkeoMleMthzNM=.e9fe9e21-7e74-4955-94ed-7707cc7da31b@github.com>
Message-ID: <a9gvppr283G-XRlYj4135o8wgKOYq2jSL38GtiXnopk=.7ed58afe-d389-49c2-ad82-5516a2b27f4c@github.com>

On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> This fixes a bug introduced with JDK-8202449.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9120

From duke at openjdk.java.net  Fri Jun 10 18:28:46 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 10 Jun 2022 18:28:46 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v9]
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Rename dataprovider

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9049/files
  - new: https://git.openjdk.org/jdk/pull/9049/files/962f0ec1..d566ebca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9049&range=07-08

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.org/jdk/pull/9049

From alanb at openjdk.java.net  Fri Jun 10 18:28:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 18:28:47 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v9]
In-Reply-To: <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>
Message-ID: <BdPM3hdNCRYygVZ9n0_H7n7h5_vTPL9pKqnSoIKYoXw=.9c1c6da0-5086-4435-be37-8322b3ba588d@github.com>

On Fri, 10 Jun 2022 18:25:09 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename dataprovider

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9049

From duke at openjdk.java.net  Fri Jun 10 18:28:47 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 10 Jun 2022 18:28:47 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v8]
In-Reply-To: <Q3jfKrJ_wm3mvDjf-RxOf5Qed20eF3t0tzb0C7nuTvU=.e46c68c6-1f82-47b8-93dd-34c562c333ec@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>
 <Q3jfKrJ_wm3mvDjf-RxOf5Qed20eF3t0tzb0C7nuTvU=.e46c68c6-1f82-47b8-93dd-34c562c333ec@github.com>
Message-ID: <Vcih8o167PlfmQ4QVEBCEdta9X2N1JbEI_qy6BiBjL4=.ac88540f-307c-40ba-b560-923f941a397e@github.com>

On Fri, 10 Jun 2022 18:01:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright year
>
> test/jdk/tools/jar/modularJar/Basic.java line 44:
> 
>> 42: 
>> 43: import jdk.internal.module.ModuleReferenceImpl;
>> 44: import jdk.internal.module.ModuleResolution;
> 
> At some point we need to put in test infrastructure to avoid this and a few other tests from depending on JDK internals.

Do you think it is better to parse the output of `javap` instead of using the internals to detect if it worked?

-------------

PR: https://git.openjdk.org/jdk/pull/9049

From alanb at openjdk.java.net  Fri Jun 10 18:28:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Jun 2022 18:28:48 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v8]
In-Reply-To: <Vcih8o167PlfmQ4QVEBCEdta9X2N1JbEI_qy6BiBjL4=.ac88540f-307c-40ba-b560-923f941a397e@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <w_lVnVh4AfmOx9ehBbuytmzb9as_yDyljekYcKFtEPw=.68f8d73b-5d16-4bdb-a50f-cedfeb9d63a7@github.com>
 <Q3jfKrJ_wm3mvDjf-RxOf5Qed20eF3t0tzb0C7nuTvU=.e46c68c6-1f82-47b8-93dd-34c562c333ec@github.com>
 <Vcih8o167PlfmQ4QVEBCEdta9X2N1JbEI_qy6BiBjL4=.ac88540f-307c-40ba-b560-923f941a397e@github.com>
Message-ID: <dtPTNvSCFezqq6hyGDNNgM3hbILXTg5QgYDYcsGf4wU=.9df8e214-b088-440b-b26d-105b7ab684a4@github.com>

On Fri, 10 Jun 2022 18:19:42 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

>> test/jdk/tools/jar/modularJar/Basic.java line 44:
>> 
>>> 42: 
>>> 43: import jdk.internal.module.ModuleReferenceImpl;
>>> 44: import jdk.internal.module.ModuleResolution;
>> 
>> At some point we need to put in test infrastructure to avoid this and a few other tests from depending on JDK internals.
>
> Do you think it is better to parse the output of `javap` instead of using the internals to detect if it worked?

Parsing the output of javap would be fragile. Instead, I think we'll just add some test infrastructure at some point, maybe when this class file attribute is documented somewhere.

-------------

PR: https://git.openjdk.org/jdk/pull/9049

From mullan at openjdk.java.net  Fri Jun 10 18:35:00 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 10 Jun 2022 18:35:00 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <ZLUrevxM3pod59jvPmZcD6EncfEJR6iMlEPpH2U7cWI=.60608b01-8254-42eb-bdb4-81fe0949b023@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

I'll take a look from the security side but may need a few days to review and possibly collaborate with others if I have concerns.

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From rriggs at openjdk.java.net  Fri Jun 10 19:33:08 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 10 Jun 2022 19:33:08 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
 [v2]
In-Reply-To: <nx8Z5HZC4KU3ycOKMt4jxsA2JmminkROX1zyWh51qiE=.5d5d98e1-01d0-4973-bb7a-192dc06898a5@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
 <nx8Z5HZC4KU3ycOKMt4jxsA2JmminkROX1zyWh51qiE=.5d5d98e1-01d0-4973-bb7a-192dc06898a5@github.com>
Message-ID: <4HQBaGMVW5UD8adG1FNDY17ofIeIReatC-rB0RhAmsg=.3c7f0529-87b0-4c3f-8861-3456d1a92afc@github.com>

On Fri, 10 Jun 2022 11:31:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
>> 
>> Instead of separate Hashtable.get/remove calls we can just use value returned by `remove`,
>> It results in cleaner and a bit faster code.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288140: Avoid redundant Hashtable.get call in Signal.handle
>   apply dmlloyd's suggestion

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/jdk/internal/misc/Signal.java line 181:

> 179:         } else {
> 180:             oldHandler = handlers.remove(sig);
> 181:         }

A ternary assignment might be an alternative here:

 Signal.Handler oldHandler = (newH == 2) ? handlers.put(sig, handler) : handlers.remove(sig);

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From clanger at openjdk.java.net  Fri Jun 10 20:16:05 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 10 Jun 2022 20:16:05 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <nvWG4eKOXZIiB9FBNDHzbqmR9jVghlYQAGgDprq1Yl8=.2318a5e3-a50d-4719-b43c-53f0ff1a0138@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

Looks good to me.

-------------

Marked as reviewed by clanger (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9105

From kbarrett at openjdk.java.net  Fri Jun 10 20:18:01 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 10 Jun 2022 20:18:01 GMT
Subject: RFR: 8279047: Remove expired flags in JDK 20
In-Reply-To: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
References: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
Message-ID: <euH6EbulevpQxhhHRHyqjVUS_khwPpTquMBV5778YBc=.7ec41fe5-088a-4c0c-a95a-9c9fbb5eb078@github.com>

On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Expired Flags in 20:
> 
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
> 
> No remaining usages in code or tests.
> 
> - UseHeavyMonitors  (expired in PRODUCT ONLY)
> 
> As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM.
> 
> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
> 
> The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM.
> 
> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> 
> Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds.
> 
> No documentation in the manpage exists for any of the newly expired flags.
> 
> Obsoleted flags in 20:
> 
> - ExtendedDTraceProbes
> 
> Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913).
> 
> - UseContainerCpuShares
> - PreferContainerQuotaForCPUCount
> - AliasLevel
> 
> Undocumented.
> 
> Java manpage updates:
> - Updates Java version to 20
> - Moved ExtendedDTraceProbe info as previously mentioned
> - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated).
> - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9127

From darcy at openjdk.java.net  Fri Jun 10 20:54:08 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 10 Jun 2022 20:54:08 GMT
Subject: RFR: 8288173: JDK-8202449 fix causes conformance test failure :
 api/java_util/Random/RandomGenerator/NextFloat.html
In-Reply-To: <nJ53b0pD1oDz77JFPldh9cIRsF3q9YUkeoMleMthzNM=.e9fe9e21-7e74-4955-94ed-7707cc7da31b@github.com>
References: <nJ53b0pD1oDz77JFPldh9cIRsF3q9YUkeoMleMthzNM=.e9fe9e21-7e74-4955-94ed-7707cc7da31b@github.com>
Message-ID: <C-y1qR-Dvu06YycdR0LR9MyPLTMO184Dtr_t85VPBbI=.1e0edf4a-92e3-4f90-aa84-79fa70b8a464@github.com>

On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> This fixes a bug introduced with JDK-8202449.

Changes look okay, but please do a follow-up fix to add some regression tests for this condition.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9120

From duke at openjdk.java.net  Fri Jun 10 21:05:01 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 10 Jun 2022 21:05:01 GMT
Subject: Integrated: 8288173: JDK-8202449 fix causes conformance test failure :
 api/java_util/Random/RandomGenerator/NextFloat.html
In-Reply-To: <nJ53b0pD1oDz77JFPldh9cIRsF3q9YUkeoMleMthzNM=.e9fe9e21-7e74-4955-94ed-7707cc7da31b@github.com>
References: <nJ53b0pD1oDz77JFPldh9cIRsF3q9YUkeoMleMthzNM=.e9fe9e21-7e74-4955-94ed-7707cc7da31b@github.com>
Message-ID: <RLlTvwqvY6p6L7CPASaikjVB6efHN6JpWTUUsO53ZPo=.c89cddcd-6a9f-4974-8638-131a5095f138@github.com>

On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> This fixes a bug introduced with JDK-8202449.

This pull request has now been integrated.

Changeset: da2339cf
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da2339cf6971532593e4f1b5ebbce8d1ed2e83b2
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

Reviewed-by: bpb, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/9120

From naoto at openjdk.java.net  Fri Jun 10 21:05:42 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 10 Jun 2022 21:05:42 GMT
Subject: RFR: 8287868: Localized names update in COMPAT locale provider
Message-ID: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>

As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.

-------------

Commit messages:
 - 8287868: Localized names update in COMPAT locale provider

Changes: https://git.openjdk.org/jdk/pull/9134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9134&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287868
  Stats: 9930 lines in 65 files changed: 17 ins; 7 del; 9906 mod
  Patch: https://git.openjdk.org/jdk/pull/9134.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9134/head:pull/9134

PR: https://git.openjdk.org/jdk/pull/9134

From prr at openjdk.java.net  Fri Jun 10 21:08:03 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Jun 2022 21:08:03 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <BWDc3GhMpw9OZ71u7HtHOzza-oh0l2oiw0Zp74gDbu0=.ddccdd37-1179-4aac-b2ed-0927138c6f6a@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 38:

> 36: #  define ROUND_TO_INT(num)    ((int) round(num))
> 37: #else
> 38: #  define ROUND_TO_INT(num)    ((int) floor((num) + 0.5))

If you look at when and why this was introduced (*), the "else" was not to support some other compiler - it was to support the older MS compiler. So if you don't want that, then the whole thing reduces to
#define ROUND_TO_INT(num) ((int) round(num))

.. you could even go further and eliminate the macro altogether if it makes sense - you'd have to look at the usages.

Same logic applies to the other files.


(*) https://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010889.html

-------------

PR: https://git.openjdk.org/jdk/pull/9105

From darcy at openjdk.java.net  Sat Jun 11 00:47:22 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 11 Jun 2022 00:47:22 GMT
Subject: Integrated: 8288173: JDK-8202449 fix causes conformance test failure :
 api/java_util/Random/RandomGenerator/NextFloat.html
Message-ID: <WoG0Naat2jV-ieMG5N4vUk_7ICei5yOGemvcIgAa_qo=.3506ab61-2849-4d67-9e5d-f5d2a11fe01c@github.com>

8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

-------------

Commit messages:
 - Backport da2339cf6971532593e4f1b5ebbce8d1ed2e83b2

Changes: https://git.openjdk.org/jdk19/pull/5/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk19&pr=5&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288173
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk19/pull/5.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/5/head:pull/5

PR: https://git.openjdk.org/jdk19/pull/5

From darcy at openjdk.java.net  Sat Jun 11 00:47:23 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 11 Jun 2022 00:47:23 GMT
Subject: Integrated: 8288173: JDK-8202449 fix causes conformance test failure :
 api/java_util/Random/RandomGenerator/NextFloat.html
In-Reply-To: <WoG0Naat2jV-ieMG5N4vUk_7ICei5yOGemvcIgAa_qo=.3506ab61-2849-4d67-9e5d-f5d2a11fe01c@github.com>
References: <WoG0Naat2jV-ieMG5N4vUk_7ICei5yOGemvcIgAa_qo=.3506ab61-2849-4d67-9e5d-f5d2a11fe01c@github.com>
Message-ID: <NMkSbNyE4Ie1mnuk4Qvy2pGiWxKs84cgz33a7orYeak=.2a1d3042-e4bb-4d95-b6e3-4a830a0fc45c@github.com>

On Sat, 11 Jun 2022 00:35:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

This pull request has now been integrated.

Changeset: f4b05a11
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/f4b05a1168e17000ef31173860af77aa722d2280
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

Backport-of: da2339cf6971532593e4f1b5ebbce8d1ed2e83b2

-------------

PR: https://git.openjdk.org/jdk19/pull/5

From dholmes at openjdk.java.net  Sat Jun 11 05:41:49 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 11 Jun 2022 05:41:49 GMT
Subject: RFR: 8279047: Remove expired flags in JDK 20
In-Reply-To: <08vbjWK5DR3Ka73-cLos7Oxvsrte5Xdj_kn5E96LCc8=.7c9af12a-e737-47b6-98ab-e02229456ff2@github.com>
References: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
 <08vbjWK5DR3Ka73-cLos7Oxvsrte5Xdj_kn5E96LCc8=.7c9af12a-e737-47b6-98ab-e02229456ff2@github.com>
Message-ID: <6IscZJPdK1ScWseVs0-DD1Y9JE7sNVLf3Q2779d5MuA=.de292f85-bac4-48ad-8afb-b7e399d87cf4@github.com>

On Fri, 10 Jun 2022 15:57:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Expired Flags in 20:
>> 
>> - FilterSpuriousWakeups
>> - MinInliningThreshold
>> - PrefetchFieldsAhead
>> 
>> No remaining usages in code or tests.
>> 
>> - UseHeavyMonitors  (expired in PRODUCT ONLY)
>> 
>> As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM.
>> 
>> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
>> 
>> The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM.
>> 
>> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
>> 
>> Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds.
>> 
>> No documentation in the manpage exists for any of the newly expired flags.
>> 
>> Obsoleted flags in 20:
>> 
>> - ExtendedDTraceProbes
>> 
>> Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913).
>> 
>> - UseContainerCpuShares
>> - PreferContainerQuotaForCPUCount
>> - AliasLevel
>> 
>> Undocumented.
>> 
>> Java manpage updates:
>> - Updates Java version to 20
>> - Moved ExtendedDTraceProbe info as previously mentioned
>> - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated).
>> - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly
>
> Looks good.

Thanks for the reviews @vnkozlov  and @kimbarrett !

-------------

PR: https://git.openjdk.org/jdk/pull/9127

From alanb at openjdk.java.net  Sat Jun 11 05:50:50 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 11 Jun 2022 05:50:50 GMT
Subject: RFR: 8279047: Remove expired flags in JDK 20
In-Reply-To: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
References: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
Message-ID: <KsBq7KrwhGxa9nrjnqk_nhKi_I9VadgIsFPASH8aqBA=.00c45f74-aa86-4b0a-aeaa-786734f7cad7@github.com>

On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Expired Flags in 20:
> 
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
> 
> No remaining usages in code or tests.
> 
> - UseHeavyMonitors  (expired in PRODUCT ONLY)
> 
> As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM.
> 
> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
> 
> The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM.
> 
> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> 
> Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds.
> 
> No documentation in the manpage exists for any of the newly expired flags.
> 
> Obsoleted flags in 20:
> 
> - ExtendedDTraceProbes
> 
> Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913).
> 
> - UseContainerCpuShares
> - PreferContainerQuotaForCPUCount
> - AliasLevel
> 
> Undocumented.
> 
> Java manpage updates:
> - Updates Java version to 20
> - Moved ExtendedDTraceProbe info as previously mentioned
> - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated).
> - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly

Marked as reviewed by alanb (Reviewer).

test/jdk/java/lang/Thread/virtual/HoldsLock.java line 39:

> 37:  * @modules java.base/java.lang:+open
> 38:  * @compile --enable-preview -source ${jdk.version} HoldsLock.java
> 39:  * @run testng/othervm --enable-preview -XX:+UseHeavyMonitors HoldsLock

The test updates look okay, probably don't need to duplicate the summary tag when it's unchanged but what you have is okay.

-------------

PR: https://git.openjdk.org/jdk/pull/9127

From dholmes at openjdk.java.net  Sat Jun 11 05:55:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 11 Jun 2022 05:55:06 GMT
Subject: RFR: 8279047: Remove expired flags in JDK 20
In-Reply-To: <KsBq7KrwhGxa9nrjnqk_nhKi_I9VadgIsFPASH8aqBA=.00c45f74-aa86-4b0a-aeaa-786734f7cad7@github.com>
References: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
 <KsBq7KrwhGxa9nrjnqk_nhKi_I9VadgIsFPASH8aqBA=.00c45f74-aa86-4b0a-aeaa-786734f7cad7@github.com>
Message-ID: <Ehy1d3XjQZ4VnOgpLu0Pk4paie5aK4PfLH9w-hyIqt8=.3c4d0114-52c8-49c9-9721-7e0d6bb36fa3@github.com>

On Sat, 11 Jun 2022 05:48:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Expired Flags in 20:
>> 
>> - FilterSpuriousWakeups
>> - MinInliningThreshold
>> - PrefetchFieldsAhead
>> 
>> No remaining usages in code or tests.
>> 
>> - UseHeavyMonitors  (expired in PRODUCT ONLY)
>> 
>> As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM.
>> 
>> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
>> 
>> The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM.
>> 
>> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
>> 
>> Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds.
>> 
>> No documentation in the manpage exists for any of the newly expired flags.
>> 
>> Obsoleted flags in 20:
>> 
>> - ExtendedDTraceProbes
>> 
>> Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913).
>> 
>> - UseContainerCpuShares
>> - PreferContainerQuotaForCPUCount
>> - AliasLevel
>> 
>> Undocumented.
>> 
>> Java manpage updates:
>> - Updates Java version to 20
>> - Moved ExtendedDTraceProbe info as previously mentioned
>> - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated).
>> - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review @AlanBateman !

-------------

PR: https://git.openjdk.org/jdk/pull/9127

From dholmes at openjdk.java.net  Sat Jun 11 05:55:08 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 11 Jun 2022 05:55:08 GMT
Subject: Integrated: 8279047: Remove expired flags in JDK 20
In-Reply-To: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
References: <F2_c07gXO47LsIonTHSZn7FGeU7KZXgYEYtm4HvtthI=.763897eb-1746-497b-afd7-a6732cec7ce3@github.com>
Message-ID: <-GiViawovor61GE_0jy750oUVdzGjdVEwu3PZltgFnU=.401a110b-7a93-421d-a839-c928d96a324c@github.com>

On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Expired Flags in 20:
> 
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
> 
> No remaining usages in code or tests.
> 
> - UseHeavyMonitors  (expired in PRODUCT ONLY)
> 
> As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM.
> 
> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
> 
> The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM.
> 
> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> 
> Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds.
> 
> No documentation in the manpage exists for any of the newly expired flags.
> 
> Obsoleted flags in 20:
> 
> - ExtendedDTraceProbes
> 
> Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913).
> 
> - UseContainerCpuShares
> - PreferContainerQuotaForCPUCount
> - AliasLevel
> 
> Undocumented.
> 
> Java manpage updates:
> - Updates Java version to 20
> - Moved ExtendedDTraceProbe info as previously mentioned
> - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated).
> - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly

This pull request has now been integrated.

Changeset: d46f404b
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d46f404b3179c66e8e5775a9e2253c95238153c7
Stats:     69 lines in 5 files changed: 23 ins; 26 del; 20 mod

8279047: Remove expired flags in JDK 20

Reviewed-by: kvn, kbarrett, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9127

From plevart at openjdk.java.net  Sat Jun 11 07:59:01 2022
From: plevart at openjdk.java.net (Peter Levart)
Date: Sat, 11 Jun 2022 07:59:01 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
 [v2]
In-Reply-To: <adGtEkTAo92PwB1xSJ7E7_jhX-569fbM_IWAQQp-w5Y=.344446fc-e743-403e-b7ce-6f1cedb7afed@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
 <ju4pHE-HHnjlP19TYHzEuHAn7eXKH1jB1eiFL6HZmpw=.08336be5-f8b0-44a6-afea-ae29b7646656@github.com>
 <0HUifGODBCcpDT-TweELCoEpB4aWhWsvsRSYSwveXFM=.b9f655c4-f33b-4233-a417-baa57bfaa634@github.com>
 <adGtEkTAo92PwB1xSJ7E7_jhX-569fbM_IWAQQp-w5Y=.344446fc-e743-403e-b7ce-6f1cedb7afed@github.com>
Message-ID: <1tKPiwsuquHxgxYm1gEh0XhCAfpKigGNOSC3oq-rqHM=.d10053bf-1372-49dd-9276-90cb61bad464@github.com>

On Fri, 10 Jun 2022 11:45:28 GMT, David M. Lloyd <duke at openjdk.java.net> wrote:

>> Hello David, I suspect you mean `handlers.put(sig, handler)` and not `handlers.replace(...)`? And yes, I think what you suggest will help remove the synchronized block here.
>
> Oops, yes you are correct!

Hi,
I think the synchronized block was redundant already in original code. Since the entire handle method is `static synchronized` and it is the only method that modifies the `handlers` and `signals` maps.
But even with so much redundant synchronization, the Signal class is not without races. There are multiple possible races in `dispatch(int number)` method which is called from native code to dispatch a signal:
- race no. 1: dispatch method (not synchronized) performs 2 independent lookups into `signals` and `handlers` maps respectively, assuming their inter-referenced state is consistent. But `handle` method may be concurrently modifying them, so `dispatch` may see updated state of `signals` map while seeing old state of `handlers` map or vice versa.
- race  no. 2: besides `signals` and `handlers` there is a 3rd map in native code, updated with `handle0` native method. Native code dispatches signals according to that native map, forwarding them to either native handlers or to `dispatch` Java method. But `handle` method may be modifying that native map concurrently, so dispatch may be called as a consequence of updated native map while seeing old states of `signals` and `handlers` maps.

I'm sure I might have missed some additional races.

How to fix this? Is it even necessary? I think that this internal API is not used frequently so this was hardly an issue. But anyway, it would be a challenge. While the two java maps: `handlers` and `signals` could be replaced with a single map, there is the 3rd map in native code. We would not want to make `dispatch` method synchronized, so with careful ordering of modifications it is perhaps possible to account for races and make them harmless...
WDYT?

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From plevart at openjdk.java.net  Sat Jun 11 08:49:55 2022
From: plevart at openjdk.java.net (Peter Levart)
Date: Sat, 11 Jun 2022 08:49:55 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
 [v2]
In-Reply-To: <1tKPiwsuquHxgxYm1gEh0XhCAfpKigGNOSC3oq-rqHM=.d10053bf-1372-49dd-9276-90cb61bad464@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
 <ju4pHE-HHnjlP19TYHzEuHAn7eXKH1jB1eiFL6HZmpw=.08336be5-f8b0-44a6-afea-ae29b7646656@github.com>
 <0HUifGODBCcpDT-TweELCoEpB4aWhWsvsRSYSwveXFM=.b9f655c4-f33b-4233-a417-baa57bfaa634@github.com>
 <adGtEkTAo92PwB1xSJ7E7_jhX-569fbM_IWAQQp-w5Y=.344446fc-e743-403e-b7ce-6f1cedb7afed@github.com>
 <1tKPiwsuquHxgxYm1gEh0XhCAfpKigGNOSC3oq-rqHM=.d10053bf-1372-49dd-9276-90cb61bad464@github.com>
Message-ID: <UGebiA5wm19dznNB8s3lEQzsXU7WSTXLu2zSXcHsHds=.bac9f67e-adcb-4db1-826c-e24617c5449e@github.com>

On Sat, 11 Jun 2022 07:55:52 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Oops, yes you are correct!
>
> Hi,
> I think the synchronized block was redundant already in original code. Since the entire handle method is `static synchronized` and it is the only method that modifies the `handlers` and `signals` maps.
> But even with so much redundant synchronization, the Signal class is not without races. There are multiple possible races in `dispatch(int number)` method which is called from native code to dispatch a signal:
> - race no. 1: dispatch method (not synchronized) performs 2 independent lookups into `signals` and `handlers` maps respectively, assuming their inter-referenced state is consistent. But `handle` method may be concurrently modifying them, so `dispatch` may see updated state of `signals` map while seeing old state of `handlers` map or vice versa.
> - race  no. 2: besides `signals` and `handlers` there is a 3rd map in native code, updated with `handle0` native method. Native code dispatches signals according to that native map, forwarding them to either native handlers or to `dispatch` Java method. But `handle` method may be modifying that native map concurrently, so dispatch may be called as a consequence of updated native map while seeing old states of `signals` and `handlers` maps.
> 
> I'm sure I might have missed some additional races.
> 
> How to fix this? Is it even necessary? I think that this internal API is not used frequently so this was hardly an issue. But anyway, it would be a challenge. While the two java maps: `handlers` and `signals` could be replaced with a single map, there is the 3rd map in native code. We would not want to make `dispatch` method synchronized, so with careful ordering of modifications it is perhaps possible to account for races and make them harmless...
> WDYT?

Well, studying this further, I think some races are already accounted for and are harmless except one. The `handle` method 1st attempts to register handler in native code via call to `handle0` and then updates the `signals` map.. As soon as native code registers the handler, `dispatch` may be called and the lookup into `signals` map may return null which would cause NPE in the following lookup into `handlers` map. So there are two possibilities to fix this:
- guard for null result from `singnals` lookup, or
- swap the order of modifying the `signals` map and a call to `handle0` native method. You could even update the `signals` map with `.putIfAbsent()` to avoid multiple reassignment with otherwise equal instances. This may unnecessarily establish a mapping for a Signal the can later not be registered, so you can remove it from the `signals` map in that case to clean-up.
The possible case when the lookup into `handlers` map returns null Handler is already taken into account, but there is a possible case where a NativeHandler is replaced with a java Handler implementation and `dispatch` is therefore already called, but `handlers` map lookup still returns a NativeHandler. In that case the NativeHandler::handle method will throw exception. To avoid that, NativeHandler::handle could be an empty method instead.

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From aturbanov at openjdk.java.net  Sat Jun 11 10:57:00 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sat, 11 Jun 2022 10:57:00 GMT
Subject: RFR: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
In-Reply-To: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
References: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
Message-ID: <sGCu_RFjCgZ2wV2jlL2WCQsl6hvgVVCMtz_vf03jmD4=.afe2b601-2eac-42f6-ac42-31b94d1048d3@github.com>

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

Thank you for review!

-------------

PR: https://git.openjdk.org/jdk/pull/8935

From aturbanov at openjdk.java.net  Sat Jun 11 10:57:00 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sat, 11 Jun 2022 10:57:00 GMT
Subject: Integrated: 8287696: Avoid redundant Hashtable.containsKey call in
 JarVerifier.doneWithMeta
In-Reply-To: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
References: <F2nrNCAafSxwi1esInoTtpat7u29C_5q1TfizkKJaNQ=.f15d282b-3ed6-4549-a5d1-f849399e249f@github.com>
Message-ID: <kVuRMEW0BX6QbH5kgH6PVmZWUsvNKSrncJwnAoIUKiE=.9c5e0e92-1e58-458a-b1cb-67deedf27c3f@github.com>

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Hashtable doesn't allow `null` values. So, instead of pair `containsKey`/`remove` calls, we can directly call `remove` and then compare result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

This pull request has now been integrated.

Changeset: f1143b1b
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1143b1b57683665c81d24ff192a9babc30f28ea
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8287696: Avoid redundant Hashtable.containsKey call in JarVerifier.doneWithMeta

Reviewed-by: jpai, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/8935

From liangchenblue at gmail.com  Sat Jun 11 13:53:17 2022
From: liangchenblue at gmail.com (-)
Date: Sat, 11 Jun 2022 08:53:17 -0500
Subject: Very fast List/Deque to java.util?
In-Reply-To: <CADLcvWnYZ5htW7mQXx3gt8Xm8gJ6CPJe6ZNHmEoR3URNQ6H6ig@mail.gmail.com>
References: <CADLcvWnYZ5htW7mQXx3gt8Xm8gJ6CPJe6ZNHmEoR3URNQ6H6ig@mail.gmail.com>
Message-ID: <CABe8uE2gO5RM_nkoc6ur1NZwftB4QGNQiyLGnjC5hZECUK=f0g@mail.gmail.com>

Hello,

> What do you think?

First, for your benchmarks, I recommend you write them with
https://github.com/openjdk/jmh, a library that allows configuration of
warmup time, number of trials, and has utilities that avoid jvm
optimization's impact on your benchmarks.

A few cents: I recall seeing a similar proposal before. This
implementation is definitely superior to the Linked List as an
implementation of both deque and list at the cost of an extra finger
array allocation, but it probably won't excel compared to dedicated
Deque or List implementations in terms of performance and memory
usage.

Modern JDK List/Deque users usually use the array-focused
implementations like ArrayDeque and ArrayList; even though ArrayList
is slow at adding or removing at non-tail, most usages of ArrayList is
iterating and sometimes adding (predominantly at tail). Array
iteration is better optimized by hardware due to arrays. Thus,
LinkedList is already out-of-favor like Vector, and there are relevant
discussions in https://github.com/openjdk/jdk/pull/2744. The
doubly-linked structure of the finger list is at a natural
disadvantage (for iteration) here.

Even though this finger list won't be a replacement for ArrayList or
ArrayDeque, I wonder if it can be modified to become a concurrent
collection, so that modifications to the list can be synchronized by
the intervals between fingers. If it can, it would probably provide an
efficient concurrent list implementation compared to the current
CopyOnWriteArrayList, even though your current implementation seems
not to support concurrency.

> Does it deserve to be included in JDK?

Let's revisit your proposal again: if it's in the JDK, where will it
be used? After all, JDK is a library that is used by millions or
billions of programs. Feel free to come up with a few use cases and we
will see if this finger list is the best for those cases.

On Sat, Jun 11, 2022 at 2:39 AM Rodion Efremov <coderodd3 at gmail.com> wrote:
>
> Hi,
>
> I have this List/Deque implementation that runs (in a rather versatile
> benchmark) much faster than ArrayList and LinkedList:
>
> https://github.com/coderodde/IndexedLinkedList
>
> What do you think? Does it deserve to be included in JDK?
>
> Best regards,
> rodde

From openjdk at icemanx.nl  Sat Jun 11 15:21:40 2022
From: openjdk at icemanx.nl (Rob Spoor)
Date: Sat, 11 Jun 2022 17:21:40 +0200
Subject: Very fast List/Deque to java.util?
In-Reply-To: <CABe8uE2gO5RM_nkoc6ur1NZwftB4QGNQiyLGnjC5hZECUK=f0g@mail.gmail.com>
References: <CADLcvWnYZ5htW7mQXx3gt8Xm8gJ6CPJe6ZNHmEoR3URNQ6H6ig@mail.gmail.com>
 <CABe8uE2gO5RM_nkoc6ur1NZwftB4QGNQiyLGnjC5hZECUK=f0g@mail.gmail.com>
Message-ID: <b38b4181-fd1d-0286-1d8d-8cb502b54726@icemanx.nl>

I'd like to point out that rodde has also asked this project to be 
included in Apache Commons Collections: 
https://lists.apache.org/thread/klwtkbz96rp9zfr1077sc9r8tjtthfl4


On 11/06/2022 15:53, - wrote:
> Hello,
> 
>> What do you think?
> 
> First, for your benchmarks, I recommend you write them with
> https://github.com/openjdk/jmh, a library that allows configuration of
> warmup time, number of trials, and has utilities that avoid jvm
> optimization's impact on your benchmarks.
> 
> A few cents: I recall seeing a similar proposal before. This
> implementation is definitely superior to the Linked List as an
> implementation of both deque and list at the cost of an extra finger
> array allocation, but it probably won't excel compared to dedicated
> Deque or List implementations in terms of performance and memory
> usage.
> 
> Modern JDK List/Deque users usually use the array-focused
> implementations like ArrayDeque and ArrayList; even though ArrayList
> is slow at adding or removing at non-tail, most usages of ArrayList is
> iterating and sometimes adding (predominantly at tail). Array
> iteration is better optimized by hardware due to arrays. Thus,
> LinkedList is already out-of-favor like Vector, and there are relevant
> discussions in https://github.com/openjdk/jdk/pull/2744. The
> doubly-linked structure of the finger list is at a natural
> disadvantage (for iteration) here.
> 
> Even though this finger list won't be a replacement for ArrayList or
> ArrayDeque, I wonder if it can be modified to become a concurrent
> collection, so that modifications to the list can be synchronized by
> the intervals between fingers. If it can, it would probably provide an
> efficient concurrent list implementation compared to the current
> CopyOnWriteArrayList, even though your current implementation seems
> not to support concurrency.
> 
>> Does it deserve to be included in JDK?
> 
> Let's revisit your proposal again: if it's in the JDK, where will it
> be used? After all, JDK is a library that is used by millions or
> billions of programs. Feel free to come up with a few use cases and we
> will see if this finger list is the best for those cases.
> 
> On Sat, Jun 11, 2022 at 2:39 AM Rodion Efremov <coderodd3 at gmail.com> wrote:
>>
>> Hi,
>>
>> I have this List/Deque implementation that runs (in a rather versatile
>> benchmark) much faster than ArrayList and LinkedList:
>>
>> https://github.com/coderodde/IndexedLinkedList
>>
>> What do you think? Does it deserve to be included in JDK?
>>
>> Best regards,
>> rodde


From kevinjeetgill at gmail.com  Sat Jun 11 23:55:06 2022
From: kevinjeetgill at gmail.com (Kevinjeet Gill)
Date: Sat, 11 Jun 2022 16:55:06 -0700
Subject: Addition to MethodHandle: invokeExactUnchecked(()
Message-ID: <CAJouvjLPz1LPF86dKf193T3_L2yZYxmgBXNuka=vBAv36Z1BEQ@mail.gmail.com>

At present, MethodHandle's invokeExact() is declared as the following:

>From [1]:

> @IntrinsicCandidate
>     public final native @PolymorphicSignature Object invokeExact(Object...
> args) throws Throwable;


I think this is a case where this method should probably never have
thrown a checked exception and I'd like to make the case and
test the waters and see if others have the appetite to see this change. I'm
assuming that altering this function signature is a no-go and a new
invokeExactUnchecked() is preferable.

Making the Case

I know, I know there's no PL bikeshed greater than that checked vs
unchecked exceptions -- looking at you, Future.get() -- but I think this
case is fundamentally different. MethodHandles are kindof a low-level niche
unit of JVM magic. That's why it's already an *exceptional* function given
its @PolymorphicSignature. Pun intended.

Most APIs for general use *should* drive good, sane programming habits, but
if you're reaching for MethodHandles you're probably doing something you
want a good deal of control over. There are a ton of ways it's already
expected to be a "just trust me" escape hatch already. MethodHandles are
often used with the expectation that they have to be static finals for them
to be inlined as if they are regular code. It is very awkward
and counter-productive even to have to introduce a *try { } catch(Throwable
e) { } *with all of its syntactic, bytecode, *and* JIT/inlining baggage.
Just throwing the invokeExact() call in a function or a lambda to mask out
the try-catch just pours back the layers you're futzing around with
MethoHandles to peel back.

If there's an interest and an appetite for it I'd love to take a crack at
implementing it. Any pointers are welcome!

[0]: https://bugs.openjdk.java.net/browse/JDK-8254354
[1]:
https://github.com/openjdk/jdk/blame/master/src/java.base/share/classes/java/lang/invoke/MethodHandle.java

From iklam at openjdk.java.net  Mon Jun 13 05:32:06 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 13 Jun 2022 05:32:06 GMT
Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout
 parsing code [v3]
In-Reply-To: <drxPtaMvSc3oDk3ZeKarVsMmGN8GKNmrJMxDhO-KsYo=.f5b25e16-8303-4754-b0c5-477f727429d3@github.com>
References: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
 <drxPtaMvSc3oDk3ZeKarVsMmGN8GKNmrJMxDhO-KsYo=.f5b25e16-8303-4754-b0c5-477f727429d3@github.com>
Message-ID: <Z3rxun9nmaFNlSdqK3OFmO3DP92NqlM2Lb1pQ_XegCU=.e1bb748e-e72c-41e1-9710-d6a10a332fe1@github.com>

On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue
>> of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read.
>> 
>> While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From
>> a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be
>> there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is
>> meant to only use stringStream throughout the cgroups code.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2
>> - [x] Added tests, which I've verified also pass before the stringStream change
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove fix for substring match

Just came back from vacation. LGTM.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8969

From mbaesken at openjdk.java.net  Mon Jun 13 07:24:52 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 07:24:52 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  use round directly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9105/files
  - new: https://git.openjdk.org/jdk/pull/9105/files/ee8dc996..e97c8329

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=00-01

  Stats: 21 lines in 3 files changed: 0 ins; 17 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9105.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9105/head:pull/9105

PR: https://git.openjdk.org/jdk/pull/9105

From mbaesken at openjdk.java.net  Mon Jun 13 07:24:53 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 07:24:53 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <BWDc3GhMpw9OZ71u7HtHOzza-oh0l2oiw0Zp74gDbu0=.ddccdd37-1179-4aac-b2ed-0927138c6f6a@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <BWDc3GhMpw9OZ71u7HtHOzza-oh0l2oiw0Zp74gDbu0=.ddccdd37-1179-4aac-b2ed-0927138c6f6a@github.com>
Message-ID: <dNLh7YlIe945J7TSYatk82tCc3HzmB5YF0ogLmt2dVg=.fad405f8-0895-4e22-a7b8-2b09e1afea2a@github.com>

On Fri, 10 Jun 2022 21:04:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use round directly
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 38:
> 
>> 36: #  define ROUND_TO_INT(num)    ((int) round(num))
>> 37: #else
>> 38: #  define ROUND_TO_INT(num)    ((int) floor((num) + 0.5))
> 
> If you look at when and why this was introduced (*), the "else" was not to support some other compiler - it was to support the older MS compiler. So if you don't want that, then the whole thing reduces to
> #define ROUND_TO_INT(num) ((int) round(num))
> 
> .. you could even go further and eliminate the macro altogether if it makes sense - you'd have to look at the usages.
> 
> Same logic applies to the other files.
> 
> 
> (*) https://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010889.html

Hi Phil, I simplified the code more and now use round directly.

-------------

PR: https://git.openjdk.org/jdk/pull/9105

From mbaesken at openjdk.java.net  Mon Jun 13 07:30:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 07:30:06 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>
Message-ID: <iBPfCNwxK0eC8ni-SlRartfHhYMeTGkHmj1FNDza7xQ=.8014b6be-564d-4cdf-a0d0-9905e91e5196@github.com>

On Fri, 10 Jun 2022 14:19:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I might question whether the added "null:-1" information is really helpful, or just as confusing however.

Hi Daniel, should we maybe better print something like "check for not allowed characters" in the exception ? Do you have an easy and cheap way in mind to the get the unsupported character (in this case "_") to add it to the output ? Would maybe be more helpful than the proposed host:port and better regarding security concerns.

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From coderodd3 at gmail.com  Mon Jun 13 07:56:21 2022
From: coderodd3 at gmail.com (Rodion Efremov)
Date: Mon, 13 Jun 2022 10:56:21 +0300
Subject: [Very fast List/Deque to java.util?]
Message-ID: <CADLcvWmLX6BGneJ1PGDZmkToZwMtc_1NJ0uMTHqXrsQJNQZQhA@mail.gmail.com>

Hello,

I have this List/Deque implementation [1] that (in a versatile benchmark)
runs much faster than ArrayList/LinkedList. Under mild assumptions, it
accesses an element in O(sqrt(N)) time.

Now, if all we want to do is to add at the tail and read via get(int
index), you are better of using java.util.ArrayList. If you wish to iterate
a list removing some elements, the way to go is to use java.util.LinkedList.

 However,, if you deal with larger lists via many different operations
(addFirst/addLast/add(int, E)/get(int)/remove(int)/ettc. my
IndexedLinkedLiist will outperform both of them gracefully.

So, what do you think? Does it deserve to become a class candidate for
java.util?

[1] https://github.com/coderodde/IndexedLinkedList

From aturbanov at openjdk.java.net  Mon Jun 13 09:24:49 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 13 Jun 2022 09:24:49 GMT
Subject: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX
 [v2]
In-Reply-To: <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>
References: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
 <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>
Message-ID: <7Jco1zBSxc2k6TxyqfkiPNACk12zryXZdSIX03kXHmQ=.27c2fda4-7f40-47b2-8698-e5dfbee378e1@github.com>

On Sun, 15 May 2022 10:31:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
>> Compared via JMH benchmark: 150ns -> 125ns/op
>> <details>
>> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>
>> 
>> 
>> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Fork(1)
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class TimeUnitBench {
>> 
>>     static final int SIZE = TimeUnit.values().length * 10;
>> 
>>     @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>>     int bias;
>> 
>>     TimeUnit[] mod;
>> 
>>     @Setup
>>     public void setup() {
>>         mod = new TimeUnit[SIZE];
>> 
>>         TimeUnit[] vals = TimeUnit.values();
>>         for (int c = 0; c < SIZE; c++) {
>>             if (bias == -1) {
>>                 // megamorphic
>>                 mod[c] = vals[c % vals.length];
>>             } else {
>>                 mod[c] = vals[bias];
>>             }
>>         }
>> 
>>         Random r = new Random();
>>         for (int c = 0; c < 10000; c++) {
>>             int i = r.nextInt();
>>             for (int o = 0; o < vals.length; o++) {
>>                 if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
>>                     throw new IllegalStateException("switch " + o);
>>             }
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void const_convert(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_convert(tu));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void value_convert(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_convert(tu, 1L));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void const_toNanos(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_toNanos(tu));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void value_toNanos(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_toNanos(tu, 1L));
>>         }
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_toNanos(TimeUnit tu) {
>>         return tu.toNanos(1L);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_toNanos(TimeUnit tu, long value) {
>>         return tu.toNanos(value);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_convert(TimeUnit tu) {
>>         return TimeUnit.NANOSECONDS.convert(1L, tu);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_convert(TimeUnit tu, long value) {
>>         return TimeUnit.NANOSECONDS.convert(value, tu);
>>     }
>> }
>> 
>> Results:
>> 
>> Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
>> TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
>> TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
>> TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
>> TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
>> TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
>> TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
>> TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
>> TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
>> TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
>> TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
>> TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
>> TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
>> TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
>> TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
>> TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
>> TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
>> TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
>> TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
>> TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
>> TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
>> TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
>> TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
>> TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
>> TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
>> TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
>> TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
>> TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
>> TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
>> TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
>> TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
>> TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
>> TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op
>> 
>> 
>> </details>
>
> Andrey Turbanov 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 remote-tracking branch 'origin/master' into Use_direct_TimeUnit.toSome_instead_of_TimeUnit.convert
>    
>    # Conflicts:
>    #	src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java
>    #	src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java
>  - [PATCH] Simplify TimeUnit.convert calls to TimeUnit.toSomething instead

Still hope to merge it :)

-------------

PR: https://git.openjdk.org/jdk/pull/8376

From sgehwolf at openjdk.java.net  Mon Jun 13 09:45:52 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 13 Jun 2022 09:45:52 GMT
Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout
 parsing code [v3]
In-Reply-To: <drxPtaMvSc3oDk3ZeKarVsMmGN8GKNmrJMxDhO-KsYo=.f5b25e16-8303-4754-b0c5-477f727429d3@github.com>
References: <pA8Kwi-C7h_imM7ycB-yLFer4M4piEXa5cF8dZn8yuE=.c2f520e5-1b05-4ec2-9e32-9e9b1db90aa7@github.com>
 <drxPtaMvSc3oDk3ZeKarVsMmGN8GKNmrJMxDhO-KsYo=.f5b25e16-8303-4754-b0c5-477f727429d3@github.com>
Message-ID: <hI41lLH_dxVTB-1oV8VaIYcgMSXPMes7n3kPQs3hU1w=.a3f04739-68dc-4912-b03a-b5fdb12847f8@github.com>

On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue
>> of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read.
>> 
>> While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From
>> a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be
>> there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is
>> meant to only use stringStream throughout the cgroups code.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2
>> - [x] Added tests, which I've verified also pass before the stringStream change
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove fix for substring match

@erikj79 Do you know why the SKARA bots didn't move this to `ready` by now? Is there an issue with the bots? Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/8969

From mdoerr at openjdk.java.net  Mon Jun 13 10:12:07 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 10:12:07 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
Message-ID: <m5D_rDzd-3NEkUD13SO3ZeXoKJFvWPAR7B-HUshyNlw=.e94d9098-4e20-451a-b58d-df86c87b87c7@github.com>

On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use round directly

Nice!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9105

From aturbanov at openjdk.java.net  Mon Jun 13 10:36:54 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 13 Jun 2022 10:36:54 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
Message-ID: <SUUtDTu4nJk6ynOPqW1O8zG3ESs1fz9D2hFy5qjqTHM=.94191838-3212-4261-ac0b-4e4f26e2dc9d@github.com>

On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use round directly

src/hotspot/share/adlc/main.cpp line 491:

> 489: }
> 490: 
> 491: // VS2005 has its own definition, identical to this one.

Let's adjust comment too. No need to mention VS2005.

-------------

PR: https://git.openjdk.org/jdk/pull/9105

From mbaesken at openjdk.java.net  Mon Jun 13 11:46:53 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 11:46:53 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <SUUtDTu4nJk6ynOPqW1O8zG3ESs1fz9D2hFy5qjqTHM=.94191838-3212-4261-ac0b-4e4f26e2dc9d@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
 <SUUtDTu4nJk6ynOPqW1O8zG3ESs1fz9D2hFy5qjqTHM=.94191838-3212-4261-ac0b-4e4f26e2dc9d@github.com>
Message-ID: <--XzEepPg2J69xcO4_8XjnUr6zUwWrbRFvw3Y87zEV8=.69b1d008-159c-49f3-a685-4115e4d6d53d@github.com>

On Mon, 13 Jun 2022 10:33:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use round directly
>
> src/hotspot/share/adlc/main.cpp line 491:
> 
>> 489: }
>> 490: 
>> 491: // VS2005 has its own definition, identical to this one.
> 
> Let's adjust comment too. No need to mention VS2005.

Thanks for the hint, I removed the VS2005 related comment.

-------------

PR: https://git.openjdk.org/jdk/pull/9105

From mbaesken at openjdk.java.net  Mon Jun 13 11:46:52 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 11:46:52 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove VS2005 comment in adlc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9105/files
  - new: https://git.openjdk.org/jdk/pull/9105/files/e97c8329..97659965

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9105.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9105/head:pull/9105

PR: https://git.openjdk.org/jdk/pull/9105

From john.hendrikx at gmail.com  Mon Jun 13 11:59:51 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 13 Jun 2022 13:59:51 +0200
Subject: [Very fast List/Deque to java.util?]
In-Reply-To: <CADLcvWmLX6BGneJ1PGDZmkToZwMtc_1NJ0uMTHqXrsQJNQZQhA@mail.gmail.com>
References: <CADLcvWmLX6BGneJ1PGDZmkToZwMtc_1NJ0uMTHqXrsQJNQZQhA@mail.gmail.com>
Message-ID: <13e6abdf-32bc-d236-1757-2bb0099040ce@gmail.com>

I took a look.

I found a few results odd:

|com.github.coderodde.util.IndexedLinkedList.addLast in (ms): 8 
java.util.LinkedList.addLast in (ms): 2 java.util.ArrayList.addLast in 
(ms): 157 org.apache.commons.collections4.list.TreeList.addLast in (ms): 38|

Basically, ArrayList's performance (which should be O(1) in this case) 
is surprising. Looking at the benchmark, it is calling 
ArrayList#add(int, E) -- this method is not special cased for adding at 
the end of the list (it will do a range check and call System#arrayCopy 
in all cases).

|com.github.coderodde.util.IndexedLinkedList.stream() in (ms): 1 
java.util.LinkedList.stream() in (ms): 20 java.util.ArrayList.stream() 
in (ms): 16 org.apache.commons.collections4.list.TreeList.stream() in 
(ms): 15|

This test isn't only measuring streaming (iteration?) but also 
re-inserting all elements back into a List 
(collect(Collectors.toList()). What I find odd is that the 
IndexedLinkedList would perform much better here than ArrayList, given 
that the time is probably dominated by the final collect, and not the 
iteration itself.? Is ArrayList#stream poorly optimized or is something 
else going on?

A pure iteration test would be interesting to see.

I also ran the benchmark on my machine. The benchmark on Github doesn't 
mention with what parameters it is run, and so when I run it I get quite 
different results. The committed version of the benchmark seems to use 
collections with a max size of 20 elements. The total time when I run 
the benchmark favors TreeList more than any other:

--- Total time elapsed ---
com.github.coderodde.util.IndexedLinkedList in (ms): 207
java.util.LinkedList in (ms): 4248
java.util.ArrayList in (ms): 1799
org.apache.commons.collections4.list.TreeList in (ms): 159

That said, I think there might be a place for a new list implementation 
in the JDK.? One use case I've had in the past was for a list that is 
always sorted but also allows index based access when displaying a 
window into the list. A TreeMap satisfies the sorting criteria but 
doesn't offer index access, while a plain ArrayList doesn't lend itself 
well for doing sorted inserts/removals (locating the correct location is 
trivial enough, but the actual insert or removal results in a 
potentially large copy).? Apache's TreeList is fairly good at this use case.

--John


On 13/06/2022 09:56, Rodion Efremov wrote:
> Hello,
>
> I have this List/Deque implementation [1] that (in a versatile benchmark)
> runs much faster than ArrayList/LinkedList. Under mild assumptions, it
> accesses an element in O(sqrt(N)) time.
>
> Now, if all we want to do is to add at the tail and read via get(int
> index), you are better of using java.util.ArrayList. If you wish to iterate
> a list removing some elements, the way to go is to use java.util.LinkedList.
>
>   However,, if you deal with larger lists via many different operations
> (addFirst/addLast/add(int, E)/get(int)/remove(int)/ettc. my
> IndexedLinkedLiist will outperform both of them gracefully.
>
> So, what do you think? Does it deserve to become a class candidate for
> java.util?
>
> [1]https://github.com/coderodde/IndexedLinkedList

From alanb at openjdk.java.net  Mon Jun 13 14:32:10 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 13 Jun 2022 14:32:10 GMT
Subject: RFR: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec
Message-ID: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com>

JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change GetVersion to return this version.

test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that JNI_VERSION_19 is returned. The native library in the JMX agent, and several tests, define JNI_OnLoad that return JNI_VERSION_10 as the JNI version needed. These are updated to return JNI_VERSION_19 although these updates aren't strictly needed.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk19/pull/7/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk19&pr=7&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286176
  Stats: 16 lines in 10 files changed: 2 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk19/pull/7.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/7/head:pull/7

PR: https://git.openjdk.org/jdk19/pull/7

From jpai at openjdk.java.net  Mon Jun 13 14:33:07 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 13 Jun 2022 14:33:07 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <iBPfCNwxK0eC8ni-SlRartfHhYMeTGkHmj1FNDza7xQ=.8014b6be-564d-4cdf-a0d0-9905e91e5196@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>
 <iBPfCNwxK0eC8ni-SlRartfHhYMeTGkHmj1FNDza7xQ=.8014b6be-564d-4cdf-a0d0-9905e91e5196@github.com>
Message-ID: <sA6MAh72FfFYsCKjumYqh2lPdKj6AOUsdvcV253_PTw=.a4720d1d-1bfa-4080-8dc4-b8dc36ed49a5@github.com>

On Mon, 13 Jun 2022 07:26:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Daniel, should we maybe better print something like "check for not allowed characters" in the exception ? Do you have an easy and cheap way in mind to the get the unsupported character (in this case "_") to add it to the output ? Would maybe be more helpful than the proposed host:port and better regarding security concerns.

Hello Matthias, the current error message is:

> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389

Are you suggesting that the error message should include some additional wording which states why the authority isn't supported (in this case because of the presence of that `_` character)?

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From mbaesken at openjdk.java.net  Mon Jun 13 14:48:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 14:48:06 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <sA6MAh72FfFYsCKjumYqh2lPdKj6AOUsdvcV253_PTw=.a4720d1d-1bfa-4080-8dc4-b8dc36ed49a5@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <4GJB5l-CGrWS_lmWMOb1vFEOKd_EzWznZsCk88A_SII=.404d4a3e-8953-4d11-b88d-060a4010ff17@github.com>
 <iBPfCNwxK0eC8ni-SlRartfHhYMeTGkHmj1FNDza7xQ=.8014b6be-564d-4cdf-a0d0-9905e91e5196@github.com>
 <sA6MAh72FfFYsCKjumYqh2lPdKj6AOUsdvcV253_PTw=.a4720d1d-1bfa-4080-8dc4-b8dc36ed49a5@github.com>
Message-ID: <tyhwzJh9f6-okGMGwjh2fr1yGeNQY1Li7U1KXtB4fc0=.4775ad73-fa4b-41fc-b511-109c594fe9de@github.com>

On Mon, 13 Jun 2022 14:29:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > Hi Daniel, should we maybe better print something like "check for not allowed characters" in the exception ? Do you have an easy and cheap way in mind to the get the unsupported character (in this case "_") to add it to the output ? Would maybe be more helpful than the proposed host:port and better regarding security concerns.
> 
> Hello Matthias, the current error message is:
> 
> > java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> 
> Are you suggesting that the error message should include some additional wording which states why the authority isn't supported (in this case because of the presence of that `_` character)?

Yes , this is what I meant.  Ideally (and if it is not much overhead/easy to get) we show the 'bad'  character in the message.  Otherwise just some additional wording.

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From psandoz at openjdk.java.net  Mon Jun 13 15:12:11 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 13 Jun 2022 15:12:11 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v3]
In-Reply-To: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
Message-ID: <nquBNDj0inCwi2aDQWXgbPsf_pI4Yt0_B01SHKSPMGo=.4698a394-7479-4651-bd0e-7bf2f3020f34@github.com>

> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

Paul Sandoz has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8287186-preview-participating
 - Let java.management participate in preview features.
 - Unused import.
 - Generalize the pariticipating in preview APIs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9087/files
  - new: https://git.openjdk.org/jdk/pull/9087/files/9defdf23..abd1fbf6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9087&range=01-02

  Stats: 17219 lines in 554 files changed: 13408 ins; 1651 del; 2160 mod
  Patch: https://git.openjdk.org/jdk/pull/9087.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9087/head:pull/9087

PR: https://git.openjdk.org/jdk/pull/9087

From darcy at openjdk.java.net  Mon Jun 13 23:21:00 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 13 Jun 2022 23:21:00 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v4]
In-Reply-To: <FpGq4Pinc2fMFOOW6YQEq1173c-9bReRMk-3a5w8Yfw=.d33cf284-76d0-4cfc-b07a-b2b626ce8d7e@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com>
 <FpGq4Pinc2fMFOOW6YQEq1173c-9bReRMk-3a5w8Yfw=.d33cf284-76d0-4cfc-b07a-b2b626ce8d7e@github.com>
Message-ID: <c3eSJA9W8H0rYyoeUTzotDPAPyzlaCT1jiHfWnP36GY=.af0d82c6-e225-44a1-8faf-9be0120960ab@github.com>

On Tue, 15 Feb 2022 09:06:02 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to more review feedback.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 163:
> 
>> 161:     * @see Class#isEnum()
>> 162:     */
>> 163:     ENUM(0x00004000, false, Set.of(TYPE, FIELD)),
> 
> These?can?use the?**package?private** constant?fields from?`java.lang.reflect.Modifier`: <https://github.com/openjdk/jdk/blob/ab623f8ae05c57b165d4d918d896dbdc5b4177e9/src/java.base/share/classes/java/lang/reflect/Modifier.java#L338-L347>

Good suggestion; will be reflected in the next push.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Mon Jun 13 23:23:03 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 13 Jun 2022 23:23:03 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v22]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <S0CFwY02u2ogLZSs4kSTIV5a1q7nWfzDtQMFtdYB7s4=.1d8a3845-a5d2-4c00-8c6d-63d834dea2fa@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  From review feedback, use package-private contstants in Modifier.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/111c6014..840edf2a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=20-21

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Mon Jun 13 23:36:54 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 13 Jun 2022 23:36:54 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v23]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <8VgCmq0Zsq2zZ1VMERofDyI9lvrTgOiZK61eXM4f1GA=.c5237925-5925-43d0-9269-1048c8eac144@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Correct STATIC vs STATIC_PHASE issue found in code review.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/840edf2a..fd682ac8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=21-22

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Mon Jun 13 23:36:55 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 13 Jun 2022 23:36:55 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v17]
In-Reply-To: <uwKxB1M0800i9rzeM0cn8CuZxRqUzJlRtPu0rWsDZq0=.9df6ee52-6bac-409b-ad77-393c814cd265@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
 <eeadqA6W7ZISwLR883ubuOYGApklylyMqdEMBJuh3zs=.083f410d-e7dc-4110-8d86-e9f98d7b538b@github.com>
 <uwKxB1M0800i9rzeM0cn8CuZxRqUzJlRtPu0rWsDZq0=.9df6ee52-6bac-409b-ad77-393c814cd265@github.com>
Message-ID: <4UsZEdgCIQweiXQPnKBzwV5Ahh5yIu1VdI6CYDeybjQ=.18997efc-5165-4222-a7e4-4f29376b4359@github.com>

On Wed, 13 Apr 2022 21:21:25 GMT, liach <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 167:
>> 
>>> 165:              * but is optional in the dynamic phase, during execution.
>>> 166:              */
>>> 167:             STATIC(AccessFlag.STATIC.mask()),
>> 
>> This?is?actually `AccessFlag.STATIC_PHASE`?(`0x0040`), and?not `AccessFlag.STATIC`?(`0x0008`):
>> Suggestion:
>> 
>>             STATIC(AccessFlag.STATIC_PHASE.mask()),
>
>> In the current hodgepodge AccessFlag, we have STATIC and STATIC_PHASE, and the incorrect ModuleDescriptor.accessFlags().contains(AccessFlag.STATIC) call is much more subtle, especially to new users of this class. Arguably, this misuse would be way worse than that in the distinct enum case.
> 
> Oops, didn't know this already happened. Good spot right there.

Corrected to STATIC_PHASE in subsequent push; thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From dholmes at openjdk.java.net  Tue Jun 14 01:04:59 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Jun 2022 01:04:59 GMT
Subject: RFR: 8288378: [BACKOUT] DST not applying properly with zone id
 offset set with TZ env variable
In-Reply-To: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>
References: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>
Message-ID: <v5ecZPQbBCsJg_8GLCvkEuMVAqx8loQi-Rk_KbcwbLQ=.328c187f-ab04-4603-810d-b30640c7539c@github.com>

On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backing out a fix that is causing a T1 failure.
> 
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

Backout looks accurate - thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9151

From naoto at openjdk.java.net  Tue Jun 14 01:10:48 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 14 Jun 2022 01:10:48 GMT
Subject: Integrated: 8288378: [BACKOUT] DST not applying properly with zone id
 offset set with TZ env variable
In-Reply-To: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>
References: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>
Message-ID: <8Eu9vpMcA3EMoW440c9LHJqjwYTpSPSq7g7qYE9Hbo4=.28f83a78-a70e-48b6-9d72-6081a6958f62@github.com>

On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backing out a fix that is causing a T1 failure.
> 
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

This pull request has now been integrated.

Changeset: fbe92666
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbe926662287283c579fdb4ca8290670500cf5a5
Stats:     95 lines in 2 files changed: 1 ins; 91 del; 3 mod

8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ env variable

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/9151

From naoto at openjdk.java.net  Tue Jun 14 01:03:15 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 14 Jun 2022 01:03:15 GMT
Subject: RFR: 8288378: [BACKOUT] DST not applying properly with zone id offset
 set with TZ env variable
Message-ID: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>

Backing out a fix that is causing a T1 failure.

This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

-------------

Commit messages:
 - 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ env variable

Changes: https://git.openjdk.org/jdk/pull/9151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288378
  Stats: 95 lines in 2 files changed: 1 ins; 91 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9151.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9151/head:pull/9151

PR: https://git.openjdk.org/jdk/pull/9151

From darcy at openjdk.java.net  Tue Jun 14 01:25:24 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 14 Jun 2022 01:25:24 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1CcWL2DOXfuqRNL1vX2E7PH99YUCE3oxBV-S7hCCYao=.ff847c06-17aa-4930-a90b-dac086f25991@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
 <1CcWL2DOXfuqRNL1vX2E7PH99YUCE3oxBV-S7hCCYao=.ff847c06-17aa-4930-a90b-dac086f25991@github.com>
Message-ID: <d8yiX8J903m9jUF-LYsu--7MvZb9HjPk9UMKdegFhfA=.cf86cb7a-137a-41f0-a3db-7827a5b18bf2@github.com>

On Tue, 31 May 2022 17:20:08 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
>> 
>>  - Target JDK 20 rather than 19.
>>  - Merge branch 'master' into JDK-8266670
>>  - Add mask values to constants' javadoc.
>>  - Implement review feedback from mlchung.
>>  - Fix type in @throws tag.
>>  - Merge branch 'master' into JDK-8266670
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - Make workding changes suggested in review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - ... and 22 more: https://git.openjdk.org/jdk/compare/3d668090...05cf2d8b
>
> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 130:
> 
>> 128:         MANDATED(AccessFlag.MANDATED.mask());
>> 129: 
>> 130:         private int mask;
> 
> it should be declared final ?

Sure; will change.

> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 134:
> 
>> 132:             this.mask = mask;
>> 133:         }
>> 134:         private int mask() {return mask;}
> 
> seem useless, `mask` can be accessed directly

Hmm. Stylistically, I prefer methods.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Tue Jun 14 01:25:02 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 14 Jun 2022 01:25:02 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v24]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <GnDnixEO9CusCf8v5e3DjhTBjlJQdiwuDrxmLOcsLKI=.23cdf99b-466b-49f9-b253-58f1c6ede2af@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Make mask fields final in ModuleDescriptor.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/fd682ac8..75ac9c18

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=22-23

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From duke at openjdk.java.net  Tue Jun 14 01:53:09 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 14 Jun 2022 01:53:09 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v24]
In-Reply-To: <GnDnixEO9CusCf8v5e3DjhTBjlJQdiwuDrxmLOcsLKI=.23cdf99b-466b-49f9-b253-58f1c6ede2af@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <GnDnixEO9CusCf8v5e3DjhTBjlJQdiwuDrxmLOcsLKI=.23cdf99b-466b-49f9-b253-58f1c6ede2af@github.com>
Message-ID: <b45s7mXOAR8PKOlJKLywjvcCH7vfXQX5vSdMkV9KOB4=.2a7b167c-bf44-4f99-960a-6e312dca1d61@github.com>

On Tue, 14 Jun 2022 01:25:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make mask fields final in ModuleDescriptor.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 127:

> 125:      * 0x0020}.
> 126:      */
> 127:     SUPER(0x0000_0020, false, Set.of(Location.CLASS)),

Should we document that this flag won't appear in `Class#accessFlags` no matter if it's declared in the class file?

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 300:

> 298:     /**
> 299:      * {@return a set of access flags for the given mask value
> 300:      * appropriate for the location in question}

Should we specify that the returned set is unmodifiable/immutable?

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Tue Jun 14 02:02:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 14 Jun 2022 02:02:47 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v4]
In-Reply-To: <9zRdxb7kB5HwcMkN11Zw6RiSG5KgtxYe-UCUonFyQ34=.b1e6abf7-2c8e-4311-bcb2-6d1fb87f7cac@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com>
 <kLt6tmrBcXJuCkEyc8MJqpCAFIHlwlXqCWesifJujd0=.3ba9ae2f-db6a-498c-9b3d-9502941a7786@github.com>
 <deXxKDbG8iZ116d8G2o7g_XCxkIOGsk6UB1l9Im5Be8=.95e8c3f2-7f53-4d09-8616-a5c9c0172b12@github.com>
 <MEtN7J3iCVfGc0r4wROtdjMCGwUl1ujS6kj73VnGZYI=.e2a38f27-f7e0-41b3-9ee3-5f716087f167@github.com>
 <9zRdxb7kB5HwcMkN11Zw6RiSG5KgtxYe-UCUonFyQ34=.b1e6abf7-2c8e-4311-bcb2-6d1fb87f7cac@github.com>
Message-ID: <3tFpbqiN9mvEoqYibn-43Xgh74zOrg5JsaRuPeZuHo8=.b1534a45-3bd2-4580-9037-e313698fa609@github.com>

On Tue, 31 May 2022 17:23:18 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> For completeness, I think including SUPER is reasonable, even though has been a no-op for some time. (Some time in the future, there could be a class file version aware additions to this enum class.) Well spotted omission.
>
> `ACC_SUPER`may be reconed as `ACC_IDENTITY`by Valhalla, so i'm not sure it's a good idea to add ACC_SUPER.

As discussed elsewhere in the PR, given the historical existence of ACC_SUPER, I think it is reasonable to leave it all. Also, even if removed later in the release, it would be helpful to validate how overlapping flags can be handled in practice in Valhalla.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Tue Jun 14 02:02:48 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 14 Jun 2022 02:02:48 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v24]
In-Reply-To: <b45s7mXOAR8PKOlJKLywjvcCH7vfXQX5vSdMkV9KOB4=.2a7b167c-bf44-4f99-960a-6e312dca1d61@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <GnDnixEO9CusCf8v5e3DjhTBjlJQdiwuDrxmLOcsLKI=.23cdf99b-466b-49f9-b253-58f1c6ede2af@github.com>
 <b45s7mXOAR8PKOlJKLywjvcCH7vfXQX5vSdMkV9KOB4=.2a7b167c-bf44-4f99-960a-6e312dca1d61@github.com>
Message-ID: <jin3u8OC7acTaa9wfQlSOg9XPiDFxOUN9CS4hR_9jQ0=.48b16240-1083-4912-b0f4-f6cd78d6601b@github.com>

On Tue, 14 Jun 2022 01:40:53 GMT, liach <duke at openjdk.java.net> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make mask fields final in ModuleDescriptor.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 300:
> 
>> 298:     /**
>> 299:      * {@return a set of access flags for the given mask value
>> 300:      * appropriate for the location in question}
> 
> Should we specify that the returned set is unmodifiable/immutable?

Sure; that would be consistent with other parts of the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Tue Jun 14 02:25:02 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 14 Jun 2022 02:25:02 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <NlJuFo6hGmq9zM5oPS4vtHNc2gAJfOTIAyCtah6WXYE=.3b0d7a1f-9e67-4d37-bed1-11c86288ceb9@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
 <H4nZJ6RTEc3DpQkv4QhvcJUUPU3jGbwhxHoW_vDYSxs=.c0843e5c-8080-4b31-985a-35ed172cd587@github.com>
 <c680UYmYwn0GfyCChQG2ivAMYpGjyMSJYVpGv2rbszY=.1fed602a-f7ce-4841-9e38-9aa000c2b63b@github.com>
 <NlJuFo6hGmq9zM5oPS4vtHNc2gAJfOTIAyCtah6WXYE=.3b0d7a1f-9e67-4d37-bed1-11c86288ceb9@github.com>
Message-ID: <p4fg3NGyy3bX1_V4h2_XyJb7dwKM7bFFMx6pZgxuhpE=.a2d6ba94-13d8-44f0-9088-6f9dcb250c2a@github.com>

On Wed, 1 Jun 2022 05:09:42 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Or?`AbstractMethodError`, which?is?what `Executable::getParameterCount()`?does:
>> https://github.com/openjdk/jdk/blob/e751b7b1b6f7269a1fe20c07748c726536388f6d/src/java.base/share/classes/java/lang/reflect/Executable.java#L248-L258
>
> Actually, it?should?probably be?`UnsupportedOperationException`?instead.

Hmm. If we had sealed classes and interfaces back in JDK 1.1 when Member was added, it most likely would have been added as sealed interface. But, we didn't have sealed interfaces back then so Member can (potentially) be extended by anyone. IIRC, there are a few classes implementing Member outside of the JDK.

So, when adding a new method would JDK 20, the method should certainly have be default method. I think throwing UnsupportedOperationException in the default is marginally better than the alternatives. I'll update the PR accordingly in a subsequent push. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Tue Jun 14 02:32:54 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 14 Jun 2022 02:32:54 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v25]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/75ac9c18..adcbcb71

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=23-24

  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From ysatowse at openjdk.java.net  Tue Jun 14 05:43:01 2022
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Tue, 14 Jun 2022 05:43:01 GMT
Subject: RFR: 8287917: System.loadLibrary does not work on Big Sur if JDK
 is built with macOS SDK 10.15 and earlier
In-Reply-To: <Kq9ghWWNZ5je-HoAnx2IoOUetu0UYsk1DJAOMA0b_5U=.28569670-597a-4612-8dd3-c73d55751711@github.com>
References: <g3x9IY-mxwALbN_akqYAgFHK9vlsc8KBtQP59VHdGcQ=.cbbd4f55-268f-4f3e-be00-150a26f86ff0@github.com>
 <Kq9ghWWNZ5je-HoAnx2IoOUetu0UYsk1DJAOMA0b_5U=.28569670-597a-4612-8dd3-c73d55751711@github.com>
Message-ID: <yOwbEaHWpQdw6mAdikhT10NH3Mqv8mwpgRGIlC1TVYE=.8dbfbd5f-a5e7-4a41-b64a-abb569c84fbd@github.com>

On Fri, 10 Jun 2022 17:51:37 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Please review this PR.
>> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur.  This fix will check if dynamic linker support, which is supported from Big Sur, is available or not on the OS even if os.version is reported as 10.16 instead of 11.  The os.version 10.16 doesn't include the update version like y of 10.x.y.  Hence the change only see if it is 10.16 or not.
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/exeLibraryCache/LibraryFromCache.java line 45:
> 
>> 43: public class LibraryFromCache {
>> 44:     public static void main(String[] args) throws IOException {
>> 45:         System.out.println("os.version = " + System.getProperty("os.version"));
> 
> The copyright end year needs to be updated.

Thanks for catching.

-------------

PR: https://git.openjdk.org/jdk/pull/9077

From ysatowse at openjdk.java.net  Tue Jun 14 05:46:55 2022
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Tue, 14 Jun 2022 05:46:55 GMT
Subject: RFR: 8287917: System.loadLibrary does not work on Big Sur if JDK
 is built with macOS SDK 10.15 and earlier [v2]
In-Reply-To: <g3x9IY-mxwALbN_akqYAgFHK9vlsc8KBtQP59VHdGcQ=.cbbd4f55-268f-4f3e-be00-150a26f86ff0@github.com>
References: <g3x9IY-mxwALbN_akqYAgFHK9vlsc8KBtQP59VHdGcQ=.cbbd4f55-268f-4f3e-be00-150a26f86ff0@github.com>
Message-ID: <rNasUaKt0mFYzl1pDS1Pq8y5bX6o3GpAWOVXQpKjoKo=.68f0eb60-7b4e-4e88-af49-b4f4b76db75c@github.com>

> Please review this PR.
> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur.  This fix will check if dynamic linker support, which is supported from Big Sur, is available or not on the OS even if os.version is reported as 10.16 instead of 11.  The os.version 10.16 doesn't include the update version like y of 10.x.y.  Hence the change only see if it is 10.16 or not.

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright end year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9077/files
  - new: https://git.openjdk.org/jdk/pull/9077/files/a9b95965..bdd97130

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9077&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9077&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9077.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9077/head:pull/9077

PR: https://git.openjdk.org/jdk/pull/9077

From mbaesken at openjdk.java.net  Tue Jun 14 07:18:08 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 07:18:08 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]
In-Reply-To: <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
Message-ID: <F8p1pl8Xqp0YUWSM2CVv6dOYOmi4JfzNLPDm_kDEgXg=.7fd59069-da46-46f5-b23a-3c0c8776b933@github.com>

On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove VS2005 comment in adlc

Hi Phil and Andrey are you fine with the current version of the PR ?

-------------

PR: https://git.openjdk.org/jdk/pull/9105

From aturbanov at openjdk.java.net  Tue Jun 14 07:37:05 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 14 Jun 2022 07:37:05 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]
In-Reply-To: <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
Message-ID: <PRMkbDt9F0wzGz15GXiw_jJCfpW7NHXz9ntnsRAFwT4=.6627e221-f9a1-48ca-8ee5-a5ea3db846f6@github.com>

On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove VS2005 comment in adlc

Marked as reviewed by aturbanov (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/9105

From duke at openjdk.java.net  Tue Jun 14 08:59:08 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 14 Jun 2022 08:59:08 GMT
Subject: RFR: 8288021: Add hard test cases to
 jdk.internal.math.DoubleToDecimalChecker
In-Reply-To: <09ta5J6B7B3tppzLNexTDnumh-XBIs629Q7saT4o70E=.7354d628-33e3-4602-ab97-6830c306c5c1@github.com>
References: <09ta5J6B7B3tppzLNexTDnumh-XBIs629Q7saT4o70E=.7354d628-33e3-4602-ab97-6830c306c5c1@github.com>
Message-ID: <_Q5hJ6RiK1_BP-0GxyLxzd1Q5d7rZTxKZL0U4owB5VQ=.8de18c82-8163-4418-9ceb-158eeefc1ebb@github.com>

On Wed, 8 Jun 2022 13:12:09 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> These 19'545 doubles were generated on purpose by Paul Zimmermann of INRIA as hard test cases.

Many of the test cases failed before ?[PR3402](https://github.com/openjdk/jdk/pull/3402), so it's worth having them in the codebase to detect regressions.

-------------

PR: https://git.openjdk.org/jdk/pull/9084

From turbanoff at gmail.com  Tue Jun 14 09:44:57 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Tue, 14 Jun 2022 12:44:57 +0300
Subject: Handling of USR2 signal in JVM on Linux
Message-ID: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>

Hello.
During investigation of signal handling in JVM (for
https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)

kill -USR2 1346792

# assert(thread != __null) failed: Missing current thread in SR_handler
# Internal Error
(/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
pid=1346792, tid=1346792

Full hs_err_pid1346792.log:
https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a


Is it known/expected behaviour?
I found some description there
https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?


Andrey Turbanov

From mbaesken at openjdk.java.net  Tue Jun 14 10:43:54 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 10:43:54 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v2]
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <wRLbs_glsg65C2B7dIgDh3XA76e4VlsQef5N_Rx7WsI=.c4db0734-05ca-4506-ba02-e1fbfa8eeab2@github.com>

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust exception text to the suggestion of Daniel Fuchs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/2454d4e5..1050c724

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126

From mbaesken at openjdk.java.net  Tue Jun 14 10:43:54 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 10:43:54 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <Vt1OP6p1e5V3sbSpmrRKW4N-unfQNCtRbZ-UfMGttbU=.01976899-1e9d-4184-b0d8-25a6a9426673@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

Thanks Daniel, I adjusted the exception message to what you suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From mbaesken at openjdk.java.net  Tue Jun 14 10:46:01 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 10:46:01 GMT
Subject: Integrated: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <Wl-mzvch4bCaBlR8_EsYZBVWJJb3r6QJWYOmvWdXMCU=.a1b8b570-16a8-45a0-a2c9-13b29d29ee6f@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

This pull request has now been integrated.

Changeset: 0530f4e5
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0530f4e517be5d5b3ff10be8a0764e564f068c06
Stats:     163 lines in 9 files changed: 0 ins; 149 del; 14 mod

8288094: cleanup old _MSC_VER handling

Reviewed-by: mdoerr, clanger, aturbanov

-------------

PR: https://git.openjdk.org/jdk/pull/9105

From mbaesken at openjdk.java.net  Tue Jun 14 11:36:36 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 11:36:36 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v3]
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  fix copy paste error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/1050c724..bdbe2204

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126

From mbaesken at openjdk.java.net  Tue Jun 14 11:36:36 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 11:36:36 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v2]
In-Reply-To: <wRLbs_glsg65C2B7dIgDh3XA76e4VlsQef5N_Rx7WsI=.c4db0734-05ca-4506-ba02-e1fbfa8eeab2@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <wRLbs_glsg65C2B7dIgDh3XA76e4VlsQef5N_Rx7WsI=.c4db0734-05ca-4506-ba02-e1fbfa8eeab2@github.com>
Message-ID: <MffL-6bzxXsvRJw9_AT1sA_DDUYsHFBjmKCLQROA1uM=.5606bc3a-43e3-47a3-ac16-a9f1c493e36d@github.com>

On Tue, 14 Jun 2022 10:43:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  ....
>> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust exception text to the suggestion of Daniel Fuchs

> I guess there's been some copy paste mistake here :-)

Yes, had to fix that!

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From alanb at openjdk.java.net  Tue Jun 14 11:40:54 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Jun 2022 11:40:54 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v3]
In-Reply-To: <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>
Message-ID: <9_WX5OtZS2cN9mIs4crx5KtyKrAKOVPFtQyT5ZAZoC4=.7cb36ff0-8b61-408e-9558-ab14732b6bb3@github.com>

On Tue, 14 Jun 2022 11:36:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  ....
>> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copy paste error

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 368:

> 366:                         // throw if we have user info or regname
> 367:                         throw new MalformedURLException("Authority component is not server-based, or contains user info. Unsupported authority: " + auth);
> 368:                     }

This looks okay but you may have to split up the line to avoid adding a 150+ char line (most of the file seems to keep the lines under 100 or so).

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From ecki at zusammenkunft.net  Tue Jun 14 11:46:33 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 14 Jun 2022 11:46:33 +0000
Subject: RFR: JDK-8288207: Enhance MalformedURLException in
 Uri.parseCompat [v3]
In-Reply-To: <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <ElfqSbyQzNQbP7uWpOpOTogkSSiocA8Xd5mu04ppot4=.ce5e9074-a96b-4602-876e-4431ea8a64fd@github.com>
Message-ID: <AM9P193MB11429A2B062FA6D723D84901FFAA9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

The change does not seem to be related to your description, and the description does not match the shown exception. In fact the example stacktrace contains the authority value twice and your change adds a diagnostic which is not really helpful for the case of the underscore? I would not be too specific for such general parsing rules.


--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Matthias Baesken <mbaesken at openjdk.java.net>
Gesendet: Tuesday, June 14, 2022 1:36:36 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: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v3]

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
>
>
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  fix copy paste error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/1050c724..bdbe2204

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220614/5c651466/attachment.htm>

From Alan.Bateman at oracle.com  Tue Jun 14 11:46:15 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Jun 2022 12:46:15 +0100
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
Message-ID: <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>

On 14/06/2022 10:44, Andrey Turbanov wrote:
> Hello.
> During investigation of signal handling in JVM (for
> https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
> I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)
>
> kill -USR2 1346792
>
> # assert(thread != __null) failed: Missing current thread in SR_handler
> # Internal Error
> (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
> pid=1346792, tid=1346792
>
> Full hs_err_pid1346792.log:
> https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
>
>
> Is it known/expected behaviour?
> I found some description there
> https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
> that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?

In general you have to be very careful when using signals. Yes, it can 
easily break things and probably notice it quickly with debug builds as 
asserts are compiled in to the builds (like the above). So I think 
you've found the right page to read up on this. In this case, you can 
set _JAVA_SR_SIGNUM to specify a different signal for S/R.

-Alan

From mbaesken at openjdk.java.net  Tue Jun 14 12:18:52 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 12:18:52 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v4]
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  avoid very long line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/bdbe2204..8f528226

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126

From dholmes at openjdk.java.net  Tue Jun 14 12:23:02 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Jun 2022 12:23:02 GMT
Subject: RFR: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec
In-Reply-To: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com>
References: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com>
Message-ID: <3Wz6m66_gkZ4-u268K-AuVrVuInw7FtydqIugurCUbE=.96082836-2ab5-461c-a640-9f22c6a0b136@github.com>

On Sat, 11 Jun 2022 15:42:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change GetVersion to return this version.
> 
> test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that JNI_VERSION_19 is returned. The native library in the JMX agent, and several tests, define JNI_OnLoad that return JNI_VERSION_10 as the JNI version needed. These are updated to return JNI_VERSION_19 although these updates aren't strictly needed.

@AlanBateman  sorry I missed your statement "although these updates aren't strictly needed".

-------------

PR: https://git.openjdk.org/jdk19/pull/7

From dfuchs at openjdk.java.net  Tue Jun 14 12:49:05 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 14 Jun 2022 12:49:05 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v4]
In-Reply-To: <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>
Message-ID: <3dtTh1P6TGT6hX2KjvFtUwMt6NDh0CL0u1LKbTDL7RY=.8b6e29d4-54f8-4410-8855-b073b7dc4535@github.com>

On Tue, 14 Jun 2022 12:18:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  ....
>> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid very long line

The last changes LGTM.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9126

From alanb at openjdk.java.net  Tue Jun 14 12:53:04 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Jun 2022 12:53:04 GMT
Subject: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat
 [v4]
In-Reply-To: <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
 <Oj_CHrSsZeqKChws7ONaWVzJAAKo83zXuJf44fTAKm8=.231e1860-12d2-4dc1-964e-2931c24aa246@github.com>
Message-ID: <WINtNT3RWvvY9EU5w-HNFq_Y4Fo6_4QhjCStP3ETp-M=.abd0d6b5-5665-4d2c-a48f-363ba44ad594@github.com>

On Tue, 14 Jun 2022 12:18:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  ....
>> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid very long line

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From luhenry at openjdk.java.net  Tue Jun 14 13:58:01 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 14 Jun 2022 13:58:01 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v14]
In-Reply-To: <Kzoo-86lD3frnSC7QG4g7Vs-NMn69QemAB6piLkyGQ8=.f2fe2d84-9d71-4ab3-a38c-13583b944f43@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <Kzoo-86lD3frnSC7QG4g7Vs-NMn69QemAB6piLkyGQ8=.f2fe2d84-9d71-4ab3-a38c-13583b944f43@github.com>
Message-ID: <cRHwYd-jhuiSyh4Ng3gqw1tikwOx7aw7wXqRAMnVO9w=.bc7b22d7-a02e-4751-92a4-a9eb10087a1d@github.com>

On Thu, 12 May 2022 12:14:49 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
>> 
>> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
>> 
>> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
>> 
>> 
>> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
>> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
>> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
>> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
>> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
>> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
>> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
>> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
>> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
>> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
>> 
>> 
>> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
>> 
>> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf
>
> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reenable SpecialArraysHashCode by default

Still working on it, other work priorities have popped up. I'm taking the approach of outlining the longer string approach in a dedicated runtime stub. This makes the code easier and it doesn't have a performance impact given the stub is only called on longer strings (the cost of the call is thus amortised by the faster execution).

-------------

PR: https://git.openjdk.org/jdk/pull/7700

From rriggs at openjdk.java.net  Tue Jun 14 14:30:02 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Jun 2022 14:30:02 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v25]
In-Reply-To: <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>
Message-ID: <q3d1HdLKswVaq7lDL1Ya8JguvPsgJN2T-BQCcu9FQcE=.a9668b3d-659c-4adf-bfb9-c2f158e22eee@github.com>

On Tue, 14 Jun 2022 02:32:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 104:

> 102:      */
> 103:     PROTECTED(Modifier.PROTECTED, true,
> 104:               Set.of(Location.FIELD, Location.METHOD, Location.INNER_CLASS)),

In both space and startup time, creating separate sets for the same set of Locations is inefficient.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 213:

> 211:      * <code>{@value "0x%04x" Modifier#STRICT}</code>.
> 212:      */
> 213:     STRICT(Modifier.STRICT, true, Set.of(Location.METHOD)),

ACC_STRICT is defined for class files and appears in the Class.getModifiers() before class file version 46. 
Also it is included in Modifer.classModifiers();  Modifer.CLASS_MODIFIERS.
it might be worth a note saying it is class file version specific.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From rriggs at openjdk.java.net  Tue Jun 14 14:38:03 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Jun 2022 14:38:03 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v25]
In-Reply-To: <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>
Message-ID: <NaF8vamKXSOYBeWpA7fGAwSu8_kE_Wz5j8HC1J1ArBQ=.36123cea-a25e-448c-9c38-64bed95a311d@github.com>

On Tue, 14 Jun 2022 02:32:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 64:

> 62:  * arity (varargs)} method.
> 63:  *
> 64:  * <p>The access flag constants are ordered by non-decreasing mask

This paragraph seems more like an @implNote, describing the ordering of the source.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From redestad at openjdk.java.net  Tue Jun 14 15:24:18 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 14 Jun 2022 15:24:18 GMT
Subject: RFR: 8288425: Footprint regression due MH creation when initializing
 StringConcatFactory
Message-ID: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>

Avoid doing MH creation when initializing `StringConcatFactory` by lazily initializing to a `@Stable` field instead.

-------------

Commit messages:
 - 8288425: Footprint regression due MH creation when initializing StringConcatFactory

Changes: https://git.openjdk.org/jdk/pull/9154/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9154&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288425
  Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9154.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9154/head:pull/9154

PR: https://git.openjdk.org/jdk/pull/9154

From coderodd3 at gmail.com  Tue Jun 14 16:14:43 2022
From: coderodd3 at gmail.com (Rodion Efremov)
Date: Tue, 14 Jun 2022 19:14:43 +0300
Subject: [Very fast List/Deque to java.util?]
In-Reply-To: <CADLcvWncEzQNoPRwPE3qtvRi4T9hAu1e8FZKL2RLe_GR4uROMQ@mail.gmail.com>
References: <CADLcvWmLX6BGneJ1PGDZmkToZwMtc_1NJ0uMTHqXrsQJNQZQhA@mail.gmail.com>
 <13e6abdf-32bc-d236-1757-2bb0099040ce@gmail.com>
 <CADLcvWncEzQNoPRwPE3qtvRi4T9hAu1e8FZKL2RLe_GR4uROMQ@mail.gmail.com>
Message-ID: <CADLcvWkAhwFbARzNZcapfReu=1pprfEwGaszE9S9jji2i4phMw@mail.gmail.com>

ti 14.6.2022 klo 18.49 Rodion Efremov <coderodd3 at gmail.com> kirjoitti:

> Hi community,
>
> > One use case I've had in the past was for a list that is
> always sorted but also allows index based access when displaying a
> window into the list.
>
> I suppose you are talking about an order statistic tree. If that is the
> case, I have one [1].
>
> Best regards,
> rodde
>
> [1] https://github.com/coderodde/OrderStatisticTree
>
>
> ma 13.6.2022 klo 15.00 John Hendrikx <john.hendrikx at gmail.com> kirjoitti:
>
>> I took a look.
>>
>> I found a few results odd:
>>
>> |com.github.coderodde.util.IndexedLinkedList.addLast in (ms): 8
>> java.util.LinkedList.addLast in (ms): 2 java.util.ArrayList.addLast in
>> (ms): 157 org.apache.commons.collections4.list.TreeList.addLast in (ms):
>> 38|
>>
>> Basically, ArrayList's performance (which should be O(1) in this case)
>> is surprising. Looking at the benchmark, it is calling
>> ArrayList#add(int, E) -- this method is not special cased for adding at
>> the end of the list (it will do a range check and call System#arrayCopy
>> in all cases).
>>
>> |com.github.coderodde.util.IndexedLinkedList.stream() in (ms): 1
>> java.util.LinkedList.stream() in (ms): 20 java.util.ArrayList.stream()
>> in (ms): 16 org.apache.commons.collections4.list.TreeList.stream() in
>> (ms): 15|
>>
>> This test isn't only measuring streaming (iteration?) but also
>> re-inserting all elements back into a List
>> (collect(Collectors.toList()). What I find odd is that the
>> IndexedLinkedList would perform much better here than ArrayList, given
>> that the time is probably dominated by the final collect, and not the
>> iteration itself.  Is ArrayList#stream poorly optimized or is something
>> else going on?
>>
>> A pure iteration test would be interesting to see.
>>
>> I also ran the benchmark on my machine. The benchmark on Github doesn't
>> mention with what parameters it is run, and so when I run it I get quite
>> different results. The committed version of the benchmark seems to use
>> collections with a max size of 20 elements. The total time when I run
>> the benchmark favors TreeList more than any other:
>>
>> --- Total time elapsed ---
>> com.github.coderodde.util.IndexedLinkedList in (ms): 207
>> java.util.LinkedList in (ms): 4248
>> java.util.ArrayList in (ms): 1799
>> org.apache.commons.collections4.list.TreeList in (ms): 159
>>
>> That said, I think there might be a place for a new list implementation
>> in the JDK.  One use case I've had in the past was for a list that is
>> always sorted but also allows index based access when displaying a
>> window into the list. A TreeMap satisfies the sorting criteria but
>> doesn't offer index access, while a plain ArrayList doesn't lend itself
>> well for doing sorted inserts/removals (locating the correct location is
>> trivial enough, but the actual insert or removal results in a
>> potentially large copy).  Apache's TreeList is fairly good at this use
>> case.
>>
>> --John
>>
>>
>> On 13/06/2022 09:56, Rodion Efremov wrote:
>> > Hello,
>> >
>> > I have this List/Deque implementation [1] that (in a versatile
>> benchmark)
>> > runs much faster than ArrayList/LinkedList. Under mild assumptions, it
>> > accesses an element in O(sqrt(N)) time.
>> >
>> > Now, if all we want to do is to add at the tail and read via get(int
>> > index), you are better of using java.util.ArrayList. If you wish to
>> iterate
>> > a list removing some elements, the way to go is to use
>> java.util.LinkedList.
>> >
>> >   However,, if you deal with larger lists via many different operations
>> > (addFirst/addLast/add(int, E)/get(int)/remove(int)/ettc. my
>> > IndexedLinkedLiist will outperform both of them gracefully.
>> >
>> > So, what do you think? Does it deserve to become a class candidate for
>> > java.util?
>> >
>> > [1]https://github.com/coderodde/IndexedLinkedList
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220614/a9e50ac3/attachment.htm>

From psandoz at openjdk.java.net  Tue Jun 14 16:26:04 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 14 Jun 2022 16:26:04 GMT
Subject: Integrated: 8287186: JDK modules participating in preview
In-Reply-To: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
Message-ID: <6CzW4Uip3pPr8mDrfl2Edu4ZQm9PWKHvjOjw6kwtv8c=.a388fde1-a6c1-4bce-bedd-09dedc110976@github.com>

On Wed, 8 Jun 2022 15:46:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Allow JDK modules that use preview features (preview language features or preview API features from dependent modules) to participate without the need to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature in which symbols are encountered when processing source as there is no guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An internal annotation `jdk.internal.javac.ParticipatesInPreview` can be declared on the module. Such a declaration cannot be enforced but does by its use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been updated accordingly, both of which participate in preview APIs (APIs in `java.lang.foreign` and `Thread.ofVirtual`, respectively).

This pull request has now been integrated.

Changeset: fb297705
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb297705f6dc668bea0257efb9c46b90b5eab2e9
Stats:     140 lines in 12 files changed: 65 ins; 57 del; 18 mod

8287186: JDK modules participating in preview

Reviewed-by: alanb, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/9087

From jvernee at openjdk.java.net  Tue Jun 14 16:31:12 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 14 Jun 2022 16:31:12 GMT
Subject: RFR: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
References: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
Message-ID: <2B-HlXrcaDLs9b1szU3Lp5GnM6kOQgmXsOcAGQ7Ryyo=.8bf8031d-4ff2-4bc6-8698-505e17c3654e@github.com>

On Tue, 14 Jun 2022 15:16:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Avoid doing MH creation when initializing `StringConcatFactory` by lazily initializing to a `@Stable` field instead.

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9154

From psandoz at openjdk.java.net  Tue Jun 14 16:40:29 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 14 Jun 2022 16:40:29 GMT
Subject: RFR: 8288414: Long::compress/expand samples are not correct
Message-ID: <inryWpZqGS0MQwWq8MkctrVl80HbaqUZQkYNmn-wG5c=.2db4b6b1-0c83-4d82-b661-eab9df9e2c53@github.com>

Update the code examples in the api notes of Long::compress/expand. Some constants need to be explicitly long values.

-------------

Commit messages:
 - Correct Long.compress/expand api notes.

Changes: https://git.openjdk.org/jdk19/pull/14/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk19&pr=14&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288414
  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk19/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/14/head:pull/14

PR: https://git.openjdk.org/jdk19/pull/14

From alanb at openjdk.java.net  Tue Jun 14 16:40:30 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Jun 2022 16:40:30 GMT
Subject: RFR: 8288414: Long::compress/expand samples are not correct
In-Reply-To: <inryWpZqGS0MQwWq8MkctrVl80HbaqUZQkYNmn-wG5c=.2db4b6b1-0c83-4d82-b661-eab9df9e2c53@github.com>
References: <inryWpZqGS0MQwWq8MkctrVl80HbaqUZQkYNmn-wG5c=.2db4b6b1-0c83-4d82-b661-eab9df9e2c53@github.com>
Message-ID: <JoL90jt92neQrgSEp6ZAPZ0e3GBqmawRCsiwA6iYuZI=.d4453bc7-2c02-4d3b-aeb1-4434036ed791@github.com>

On Tue, 14 Jun 2022 16:28:37 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Update the code examples in the api notes of Long::compress/expand. Some constants need to be explicitly long values.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/14

From psandoz at openjdk.java.net  Tue Jun 14 16:45:14 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 14 Jun 2022 16:45:14 GMT
Subject: RFR: 8287186: JDK modules participating in preview [v2]
In-Reply-To: <3U2G2s2rU3i848aC3PNZUkBVxZKhVNM3uZPWnA_AObc=.2f5a668f-a0ac-4fa5-9160-e98e7399bb33@github.com>
References: <zTxPw21c2JYvXC9PBlF39_BGnYF2YPYq6J5rOZibxFI=.4165da71-c112-46f5-a211-b02771ff50ed@github.com>
 <uK2HYdrZq5_CwDIWIXhjpkwGGo1Wu77Ka-MXGtlGe88=.58db8f24-6be6-43b2-98a2-600e55761f9f@github.com>
 <3U2G2s2rU3i848aC3PNZUkBVxZKhVNM3uZPWnA_AObc=.2f5a668f-a0ac-4fa5-9160-e98e7399bb33@github.com>
Message-ID: <OX8A52p2wTWLhHz9ukLgZmO6-p69VOIgDbuUqzNfuxc=.08a4c09e-2436-41a9-ae49-740f9cb71dc9@github.com>

On Wed, 8 Jun 2022 22:07:38 GMT, liach <duke at openjdk.java.net> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Let java.management participate in preview features.
>
> Just curious, is it still up to incubator modules' discretion to avoid accidental user access to preview content via the modules without enabling preview, like the `PreviewFeatures.ensureEnabled()` in `StructuredTaskScope`?

@liach it depends on the API and its scope. A constructor of `StructuredTaskScope` specifies that it implicitly uses a virtual thread factory, so it performs a preview runtime check. 

The same check is also performed by `Thread.ofVirtual`, ensuring developers cannot reflectively work around 
`--enable-preview` when creating virtual threads. This approach is feasible since the API surface is so small.

-------------

PR: https://git.openjdk.org/jdk/pull/9087

From mchung at openjdk.java.net  Tue Jun 14 16:47:15 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 14 Jun 2022 16:47:15 GMT
Subject: RFR: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
References: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
Message-ID: <ju6H6PlTntn9j4tL7lQ82bvVDYjbDp4dC4Mmt_Z57Lg=.084587fa-745d-43a8-b1f1-1294c1542e19@github.com>

On Tue, 14 Jun 2022 15:16:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Avoid doing MH creation when initializing `StringConcatFactory` by lazily initializing to a `@Stable` field instead.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9154

From asemenyuk at openjdk.java.net  Tue Jun 14 18:10:27 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 14 Jun 2022 18:10:27 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
In-Reply-To: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
Message-ID: <x_SkOcJtk7xzie4CLYaafeFlMKPlgPm6IKUkyO2FURM=.07a3b6ce-a6a1-4495-9db4-f084058f7b2d@github.com>

On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 68:

> 66:     private final List<LauncherInfo> addLauncherInfos;
> 67:     private final String signedStr;
> 68:     private final String appStoreStr;

What is the idea of this change?

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From asemenyuk at openjdk.java.net  Tue Jun 14 18:16:03 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 14 Jun 2022 18:16:03 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
In-Reply-To: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
Message-ID: <1bF710fZQ7-8KIpnXcVanMvGS1DeZGz00UlBDMtehnk=.595ef84f-86b0-4444-8e62-40f568ff37d8@github.com>

On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 79:

> 77: warning.no.jdk.modules.found=Warnung: Keine JDK-Module gefunden
> 78: 
> 79: error.foreign-app-image=Error: app-image dir ({0}) not generated by jpackage. Missing .jpackage.xml.

This error message will be misleading in case app image was generated by jpackage and adjusted after.
I'd put it as "Missing .jpackage.xml file in app-image dir ({0})."

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From asemenyuk at openjdk.java.net  Tue Jun 14 18:31:37 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 14 Jun 2022 18:31:37 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
In-Reply-To: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
Message-ID: <X_RKC4jtqQ_-3tyGMBP7LXLC-gqH38qeHj-4THq52-Y=.52ad26dd-9c3c-4856-8783-a7f803f1fa8f@github.com>

On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 272:

> 270:             ));
> 271:     }
> 272: 

1. This is jpackage specific, so it should belong to JPackageCommand class.
2. Please use proper XML API to create XML output.
3. Having `<app-version>1.0</app-version>` in .jpackage.xml file will make `AppImageFile.isValid()` return `false` and `AppImageFile.load()` to throw exception. This seems to be equivalent to not having .jpackage.xml file in app image at all raising a question if this new function is needed at all.

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From asemenyuk at openjdk.java.net  Tue Jun 14 18:36:43 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 14 Jun 2022 18:36:43 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
In-Reply-To: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
Message-ID: <XYGk_GeuolL24xInBJneCDSR42az0mkrJU1JFBWw8_s=.6625aba7-b154-4aaa-ac58-d485e864c134@github.com>

On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098.

-

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 339:

> 337:                 !("true".equals(appStoreStr) || "false".equals(appStoreStr))) {
> 338:             return false;
> 339:         }

It makes sense to unfold this function in the ctor as we don't allow empty AppImageFile instances.

-------------

Changes requested by asemenyuk (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/9

From rriggs at openjdk.java.net  Tue Jun 14 18:58:03 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Jun 2022 18:58:03 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v2]
In-Reply-To: <i7ttqg9j_Ma_hFqj-bg-kSvpnm2xbl6fEVC6DTWLSWM=.cd3ad1fe-5e65-4d85-9c55-8866c8ab199b@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
 <i7ttqg9j_Ma_hFqj-bg-kSvpnm2xbl6fEVC6DTWLSWM=.cd3ad1fe-5e65-4d85-9c55-8866c8ab199b@github.com>
Message-ID: <8gJqFD2EEy97SaUyg0QPZKNJFboCpB9aVIbE5j4bih4=.5117277c-a410-4010-82da-1f0033c041a6@github.com>

On Wed, 8 Jun 2022 10:58:30 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of `Executable.getParameterTypes()` we could use `Executable.getSharedParameterTypes()` in trusted code. Same is applicable for `Executable.getExceptionTypes()`.
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8287908
>  - 8287908: Use non-cloning reflection methods where acceptable

src/java.base/share/classes/java/lang/reflect/Executable.java line 318:

> 316:             final boolean realParamData = hasRealParameterData();
> 317:             final Type[] genericParamTypes = getGenericParameterTypes();
> 318:             final Type[] nonGenericParamTypes = getSharedParameterTypes();

This is not a safe replacement; it may be returned to the caller at line 345.

-------------

PR: https://git.openjdk.org/jdk/pull/9064

From aturbanov at openjdk.java.net  Tue Jun 14 19:25:57 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 14 Jun 2022 19:25:57 GMT
Subject: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX
 [v2]
In-Reply-To: <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>
References: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
 <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>
Message-ID: <DyX_SjE0GlnNOFk7sZJYVn75SF-BZXxUrY5vGJ8EukM=.d0672f32-a1ba-4f69-92bc-088856da0948@github.com>

On Sun, 15 May 2022 10:31:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
>> Compared via JMH benchmark: 150ns -> 125ns/op
>> <details>
>> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>
>> 
>> 
>> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Fork(1)
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class TimeUnitBench {
>> 
>>     static final int SIZE = TimeUnit.values().length * 10;
>> 
>>     @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>>     int bias;
>> 
>>     TimeUnit[] mod;
>> 
>>     @Setup
>>     public void setup() {
>>         mod = new TimeUnit[SIZE];
>> 
>>         TimeUnit[] vals = TimeUnit.values();
>>         for (int c = 0; c < SIZE; c++) {
>>             if (bias == -1) {
>>                 // megamorphic
>>                 mod[c] = vals[c % vals.length];
>>             } else {
>>                 mod[c] = vals[bias];
>>             }
>>         }
>> 
>>         Random r = new Random();
>>         for (int c = 0; c < 10000; c++) {
>>             int i = r.nextInt();
>>             for (int o = 0; o < vals.length; o++) {
>>                 if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
>>                     throw new IllegalStateException("switch " + o);
>>             }
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void const_convert(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_convert(tu));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void value_convert(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_convert(tu, 1L));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void const_toNanos(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_toNanos(tu));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void value_toNanos(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_toNanos(tu, 1L));
>>         }
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_toNanos(TimeUnit tu) {
>>         return tu.toNanos(1L);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_toNanos(TimeUnit tu, long value) {
>>         return tu.toNanos(value);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_convert(TimeUnit tu) {
>>         return TimeUnit.NANOSECONDS.convert(1L, tu);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_convert(TimeUnit tu, long value) {
>>         return TimeUnit.NANOSECONDS.convert(value, tu);
>>     }
>> }
>> 
>> Results:
>> 
>> Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
>> TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
>> TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
>> TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
>> TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
>> TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
>> TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
>> TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
>> TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
>> TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
>> TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
>> TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
>> TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
>> TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
>> TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
>> TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
>> TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
>> TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
>> TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
>> TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
>> TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
>> TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
>> TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
>> TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
>> TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
>> TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
>> TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
>> TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
>> TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
>> TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
>> TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
>> TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
>> TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op
>> 
>> 
>> </details>
>
> Andrey Turbanov 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 remote-tracking branch 'origin/master' into Use_direct_TimeUnit.toSome_instead_of_TimeUnit.convert
>    
>    # Conflicts:
>    #	src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java
>    #	src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java
>  - [PATCH] Simplify TimeUnit.convert calls to TimeUnit.toSomething instead

src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 328:

> 326:         }
> 327:         if (s.endsWith("h")) {
> 328:             return HOURS.toNanos(Long.parseLong(s.substring(0, s.length() - 1).trim()));

May be some JFR experts know, why there was manual multiplication before?

-------------

PR: https://git.openjdk.org/jdk/pull/8376

From aturbanov at openjdk.java.net  Tue Jun 14 19:26:54 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 14 Jun 2022 19:26:54 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
 [v2]
In-Reply-To: <UGebiA5wm19dznNB8s3lEQzsXU7WSTXLu2zSXcHsHds=.bac9f67e-adcb-4db1-826c-e24617c5449e@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
 <ju4pHE-HHnjlP19TYHzEuHAn7eXKH1jB1eiFL6HZmpw=.08336be5-f8b0-44a6-afea-ae29b7646656@github.com>
 <0HUifGODBCcpDT-TweELCoEpB4aWhWsvsRSYSwveXFM=.b9f655c4-f33b-4233-a417-baa57bfaa634@github.com>
 <adGtEkTAo92PwB1xSJ7E7_jhX-569fbM_IWAQQp-w5Y=.344446fc-e743-403e-b7ce-6f1cedb7afed@github.com>
 <1tKPiwsuquHxgxYm1gEh0XhCAfpKigGNOSC3oq-rqHM=.d10053bf-1372-49dd-9276-90cb61bad464@github.com>
 <UGebiA5wm19dznNB8s3lEQzsXU7WSTXLu2zSXcHsHds=.bac9f67e-adcb-4db1-826c-e24617c5449e@github.com>
Message-ID: <mlh0bCwOYGecdkAHxJrsIZ8APlqMy_mfts_J28NDNJY=.d56520b1-4127-4979-9e2d-50f0170077b7@github.com>

On Sat, 11 Jun 2022 08:46:18 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi,
>> I think the synchronized block was redundant already in original code. Since the entire handle method is `static synchronized` and it is the only method that modifies the `handlers` and `signals` maps.
>> But even with so much redundant synchronization, the Signal class is not without races. There are multiple possible races in `dispatch(int number)` method which is called from native code to dispatch a signal:
>> - race no. 1: dispatch method (not synchronized) performs 2 independent lookups into `signals` and `handlers` maps respectively, assuming their inter-referenced state is consistent. But `handle` method may be concurrently modifying them, so `dispatch` may see updated state of `signals` map while seeing old state of `handlers` map or vice versa.
>> - race  no. 2: besides `signals` and `handlers` there is a 3rd map in native code, updated with `handle0` native method. Native code dispatches signals according to that native map, forwarding them to either native handlers or to `dispatch` Java method. But `handle` method may be modifying that native map concurrently, so dispatch may be called as a consequence of updated native map while seeing old states of `signals` and `handlers` maps.
>> 
>> I'm sure I might have missed some additional races.
>> 
>> How to fix this? Is it even necessary? I think that this internal API is not used frequently so this was hardly an issue. But anyway, it would be a challenge. While the two java maps: `handlers` and `signals` could be replaced with a single map, there is the 3rd map in native code. We would not want to make `dispatch` method synchronized, so with careful ordering of modifications it is perhaps possible to account for races and make them harmless...
>> WDYT?
>
> Well, studying this further, I think some races are already accounted for and are harmless except one. The `handle` method 1st attempts to register handler in native code via call to `handle0` and then updates the `signals` map.. As soon as native code registers the handler, `dispatch` may be called and the lookup into `signals` map may return null which would cause NPE in the following lookup into `handlers` map. So there are two possibilities to fix this:
> - guard for null result from `singnals` lookup, or
> - swap the order of modifying the `signals` map and a call to `handle0` native method. You could even update the `signals` map with `.putIfAbsent()` to avoid multiple reassignment with otherwise equal instances. This may unnecessarily establish a mapping for a Signal the can later not be registered, so you can remove it from the `signals` map in that case to clean-up.
> The possible case when the lookup into `handlers` map returns null Handler is already taken into account, but there is a possible case where a NativeHandler is replaced with a java Handler implementation and `dispatch` is therefore already called, but `handlers` map lookup still returns a NativeHandler. In that case the NativeHandler::handle method will throw exception. To avoid that, NativeHandler::handle could be an empty method instead.

I tried to reproduce this possible problem via jcstress, but never caught this race.

package org.openjdk.jcstress.samples.jmm.basic;

import org.openjdk.jcstress.annotations.*;
import org.openjdk.jcstress.infra.results.ZZZZZZZZ_Result;
import sun.misc.Signal;
import sun.misc.SignalHandler;

import java.io.IOException;

import static org.openjdk.jcstress.annotations.Expect.*;

@JCStressTest
@Outcome(id = "false, false, false, false, false, false, false, false", expect = ACCEPTABLE, desc = "All results are ok")
@Outcome(id = ".*", expect = ACCEPTABLE_INTERESTING, desc = "All results are ok")
@State
public class BasicJMM_11_Signal {

    /*
        How to run this test:
            $ /home/turbanoff/.jdks/liberica-18.0.1.1/bin/java -jar jcstress-samples/target/jcstress.jar -t BasicJMM_11_Signal -v
            $ /home/turbanoff/Projects/official_jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -jar jcstress-samples/target/jcstress.jar -t BasicJMM_11_Signal -v
            $ /home/turbanoff/Projects/jdk2/build/linux-x86_64-server-release/jdk/bin/java -jar jcstress-samples/target/jcstress.jar -t BasicJMM_11_Signal -v
     */

    private static final Signal[] signals = new Signal[]{
            new Signal("URG"),
//            new Signal("USR2"),
//            new Signal("ALRM"),
//            new Signal("USR1"),
            new Signal("CHLD"),
            new Signal("XFSZ"),
            new Signal("CONT"),
//            new Signal("POLL"),
            new Signal("WINCH"),
//            new Signal("IO"),
            new Signal("PIPE"),
//            new Signal("HUP"),
//            new Signal("POLL"),
//            new Signal("PROF"),
//            new Signal("INT"),
//            new Signal("STKFLT"),
            new Signal("TSTP"),
//            new Signal("SYS"),
//            new Signal("TERM"),
//            new Signal("TRAP"),
//            new Signal("ABRT"),
            new Signal("TTOU"),
            new Signal("TTIN"),
//            new Signal("BUS"),
//            new Signal("VTALRM"),
//            new Signal("XCPU"),
//            new Signal("PWR")
    };

    private static final String[][] commands = new String[signals.length][];
    private static final long pid = ProcessHandle.current().pid();


    static {
        for (int i = 0; i < commands.length; i++) {
            commands[i] = new String[]{ "kill", "-" + signals[i].getName(), Long.toString(pid) };
        }
    }

    @Actor
    public void thread1() {
        for (String[] command : commands) {
            try {
                new ProcessBuilder(command)
                        .directory(null)
                        .start();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    @Actor
    public void thread2(ZZZZZZZZ_Result r) {
        for (int i = 0; i < signals.length; i++) {
            Signal signal = signals[i];
            Signal.handle(signal, new MySignalHandler(i, r));
        }
    }

    private static class MySignalHandler implements SignalHandler {
        private final int num;
        private final ZZZZZZZZ_Result r;

        public MySignalHandler(int num, ZZZZZZZZ_Result r) {
            this.num = num;
            this.r = r;
        }

        @Override
        public void handle(Signal sig) {
            switch (num) {
                case 0:
                    r.r1 = true;
                    break;
                case 1:
                    r.r2 = true;
                    break;
                case 2:
                    r.r3 = true;
                    break;
                case 3:
                    r.r4 = true;
                case 4:
                    r.r5 = true;
                    break;
                case 5:
                    r.r6 = true;
                    break;
                case 6:
                    r.r7 = true;
                    break;
                case 7:
                    r.r8 = true;
                    break;
            }
        }
    }
}

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From aturbanov at openjdk.java.net  Tue Jun 14 19:26:54 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 14 Jun 2022 19:26:54 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
 [v2]
In-Reply-To: <mlh0bCwOYGecdkAHxJrsIZ8APlqMy_mfts_J28NDNJY=.d56520b1-4127-4979-9e2d-50f0170077b7@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
 <ju4pHE-HHnjlP19TYHzEuHAn7eXKH1jB1eiFL6HZmpw=.08336be5-f8b0-44a6-afea-ae29b7646656@github.com>
 <0HUifGODBCcpDT-TweELCoEpB4aWhWsvsRSYSwveXFM=.b9f655c4-f33b-4233-a417-baa57bfaa634@github.com>
 <adGtEkTAo92PwB1xSJ7E7_jhX-569fbM_IWAQQp-w5Y=.344446fc-e743-403e-b7ce-6f1cedb7afed@github.com>
 <1tKPiwsuquHxgxYm1gEh0XhCAfpKigGNOSC3oq-rqHM=.d10053bf-1372-49dd-9276-90cb61bad464@github.com>
 <UGebiA5wm19dznNB8s3lEQzsXU7WSTXLu2zSXcHsHds=.bac9f67e-adcb-4db1-826c-e24617c5449e@github.com>
 <mlh0bCwOYGecdkAHxJrsIZ8APlqMy_mfts_J28NDNJY=.d56520b1-4127-4979-9e2d-50f0170077b7@github.com>
Message-ID: <CcnhA78Tv--vrSM5VxpUpEPF3elIQSvI5e5SlTXhRuA=.cf5a8c50-836f-4507-a18d-b51d76254aae@github.com>

On Tue, 14 Jun 2022 19:20:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Well, studying this further, I think some races are already accounted for and are harmless except one. The `handle` method 1st attempts to register handler in native code via call to `handle0` and then updates the `signals` map.. As soon as native code registers the handler, `dispatch` may be called and the lookup into `signals` map may return null which would cause NPE in the following lookup into `handlers` map. So there are two possibilities to fix this:
>> - guard for null result from `singnals` lookup, or
>> - swap the order of modifying the `signals` map and a call to `handle0` native method. You could even update the `signals` map with `.putIfAbsent()` to avoid multiple reassignment with otherwise equal instances. This may unnecessarily establish a mapping for a Signal the can later not be registered, so you can remove it from the `signals` map in that case to clean-up.
>> The possible case when the lookup into `handlers` map returns null Handler is already taken into account, but there is a possible case where a NativeHandler is replaced with a java Handler implementation and `dispatch` is therefore already called, but `handlers` map lookup still returns a NativeHandler. In that case the NativeHandler::handle method will throw exception. To avoid that, NativeHandler::handle could be an empty method instead.
>
> I tried to reproduce this possible problem via jcstress, but never caught this race.
> 
> package org.openjdk.jcstress.samples.jmm.basic;
> 
> import org.openjdk.jcstress.annotations.*;
> import org.openjdk.jcstress.infra.results.ZZZZZZZZ_Result;
> import sun.misc.Signal;
> import sun.misc.SignalHandler;
> 
> import java.io.IOException;
> 
> import static org.openjdk.jcstress.annotations.Expect.*;
> 
> @JCStressTest
> @Outcome(id = "false, false, false, false, false, false, false, false", expect = ACCEPTABLE, desc = "All results are ok")
> @Outcome(id = ".*", expect = ACCEPTABLE_INTERESTING, desc = "All results are ok")
> @State
> public class BasicJMM_11_Signal {
> 
>     /*
>         How to run this test:
>             $ /home/turbanoff/.jdks/liberica-18.0.1.1/bin/java -jar jcstress-samples/target/jcstress.jar -t BasicJMM_11_Signal -v
>             $ /home/turbanoff/Projects/official_jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -jar jcstress-samples/target/jcstress.jar -t BasicJMM_11_Signal -v
>             $ /home/turbanoff/Projects/jdk2/build/linux-x86_64-server-release/jdk/bin/java -jar jcstress-samples/target/jcstress.jar -t BasicJMM_11_Signal -v
>      */
> 
>     private static final Signal[] signals = new Signal[]{
>             new Signal("URG"),
> //            new Signal("USR2"),
> //            new Signal("ALRM"),
> //            new Signal("USR1"),
>             new Signal("CHLD"),
>             new Signal("XFSZ"),
>             new Signal("CONT"),
> //            new Signal("POLL"),
>             new Signal("WINCH"),
> //            new Signal("IO"),
>             new Signal("PIPE"),
> //            new Signal("HUP"),
> //            new Signal("POLL"),
> //            new Signal("PROF"),
> //            new Signal("INT"),
> //            new Signal("STKFLT"),
>             new Signal("TSTP"),
> //            new Signal("SYS"),
> //            new Signal("TERM"),
> //            new Signal("TRAP"),
> //            new Signal("ABRT"),
>             new Signal("TTOU"),
>             new Signal("TTIN"),
> //            new Signal("BUS"),
> //            new Signal("VTALRM"),
> //            new Signal("XCPU"),
> //            new Signal("PWR")
>     };
> 
>     private static final String[][] commands = new String[signals.length][];
>     private static final long pid = ProcessHandle.current().pid();
> 
> 
>     static {
>         for (int i = 0; i < commands.length; i++) {
>             commands[i] = new String[]{ "kill", "-" + signals[i].getName(), Long.toString(pid) };
>         }
>     }
> 
>     @Actor
>     public void thread1() {
>         for (String[] command : commands) {
>             try {
>                 new ProcessBuilder(command)
>                         .directory(null)
>                         .start();
>             } catch (IOException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> 
>     @Actor
>     public void thread2(ZZZZZZZZ_Result r) {
>         for (int i = 0; i < signals.length; i++) {
>             Signal signal = signals[i];
>             Signal.handle(signal, new MySignalHandler(i, r));
>         }
>     }
> 
>     private static class MySignalHandler implements SignalHandler {
>         private final int num;
>         private final ZZZZZZZZ_Result r;
> 
>         public MySignalHandler(int num, ZZZZZZZZ_Result r) {
>             this.num = num;
>             this.r = r;
>         }
> 
>         @Override
>         public void handle(Signal sig) {
>             switch (num) {
>                 case 0:
>                     r.r1 = true;
>                     break;
>                 case 1:
>                     r.r2 = true;
>                     break;
>                 case 2:
>                     r.r3 = true;
>                     break;
>                 case 3:
>                     r.r4 = true;
>                 case 4:
>                     r.r5 = true;
>                     break;
>                 case 5:
>                     r.r6 = true;
>                     break;
>                 case 6:
>                     r.r7 = true;
>                     break;
>                 case 7:
>                     r.r8 = true;
>                     break;
>             }
>         }
>     }
> }

I believe fixing this race is out of scope of current PR. Feel free to open a separate issue :)

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From duke at openjdk.java.net  Tue Jun 14 19:27:07 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 14 Jun 2022 19:27:07 GMT
Subject: RFR: 8286849: Use @Stable for generic repositories
In-Reply-To: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
References: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
Message-ID: <qtC3z_bY_N5oMLDcpkNtj4-ko89_hZ6ap6CWdb84FVY=.a9c52627-f170-43f3-837f-f3b2e743d706@github.com>

On Tue, 17 May 2022 04:40:50 GMT, liach <duke at openjdk.java.net> wrote:

> Generic repositories, the implementation detail for generic information in core reflection, can be updated to use the `@Stable` annotation to replace their `volatile` access. Their existing accessor code is already safe, reading the cache fields only once.
> 
> In addition, fixed potentially non-thread-safe `genericInfo` access in `Method`, `Field`, and `RecordComponent`.

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/8742

From duke at openjdk.java.net  Tue Jun 14 19:33:46 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 14 Jun 2022 19:33:46 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v2]
In-Reply-To: <8gJqFD2EEy97SaUyg0QPZKNJFboCpB9aVIbE5j4bih4=.5117277c-a410-4010-82da-1f0033c041a6@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
 <i7ttqg9j_Ma_hFqj-bg-kSvpnm2xbl6fEVC6DTWLSWM=.cd3ad1fe-5e65-4d85-9c55-8866c8ab199b@github.com>
 <8gJqFD2EEy97SaUyg0QPZKNJFboCpB9aVIbE5j4bih4=.5117277c-a410-4010-82da-1f0033c041a6@github.com>
Message-ID: <K6NK1miU8vi0NzizCugrXlC1XewH1zFTtcA6Zm2WC1Q=.22a6794b-e8d6-41d7-96f2-65e34e607821@github.com>

On Tue, 14 Jun 2022 18:46:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8287908
>>  - 8287908: Use non-cloning reflection methods where acceptable
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 318:
> 
>> 316:             final boolean realParamData = hasRealParameterData();
>> 317:             final Type[] genericParamTypes = getGenericParameterTypes();
>> 318:             final Type[] nonGenericParamTypes = getSharedParameterTypes();
> 
> This is not a safe replacement; it may be returned to the caller at line 345.

Right, I was looking into usages of `getAllGenericParameterTypes()` and all of them are read-only. However I agree that later it might become an issue, so I'd use `getParameterTypes()` in line 345.

-------------

PR: https://git.openjdk.org/jdk/pull/9064

From rriggs at openjdk.java.net  Tue Jun 14 19:56:50 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Jun 2022 19:56:50 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v2]
In-Reply-To: <K6NK1miU8vi0NzizCugrXlC1XewH1zFTtcA6Zm2WC1Q=.22a6794b-e8d6-41d7-96f2-65e34e607821@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
 <i7ttqg9j_Ma_hFqj-bg-kSvpnm2xbl6fEVC6DTWLSWM=.cd3ad1fe-5e65-4d85-9c55-8866c8ab199b@github.com>
 <8gJqFD2EEy97SaUyg0QPZKNJFboCpB9aVIbE5j4bih4=.5117277c-a410-4010-82da-1f0033c041a6@github.com>
 <K6NK1miU8vi0NzizCugrXlC1XewH1zFTtcA6Zm2WC1Q=.22a6794b-e8d6-41d7-96f2-65e34e607821@github.com>
Message-ID: <KqMAl8iMM8VXaUe19U46ujtlFD40RxX3dTGwsKZntG4=.c732b887-8a3a-4902-b436-458b6ecdd52a@github.com>

On Tue, 14 Jun 2022 19:31:33 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/reflect/Executable.java line 318:
>> 
>>> 316:             final boolean realParamData = hasRealParameterData();
>>> 317:             final Type[] genericParamTypes = getGenericParameterTypes();
>>> 318:             final Type[] nonGenericParamTypes = getSharedParameterTypes();
>> 
>> This is not a safe replacement; it may be returned to the caller at line 345.
>
> Right, I was looking into usages of `getAllGenericParameterTypes()` and all of them are read-only. However I agree that later it might become an issue, so I'd use `getParameterTypes()` in line 345.

You can probably appreciate how hard it is to keep track of what's a copy (and needs to be copied) and what's not through several levels of APIs. From a security perspective, its better to spend a little extra at runtime, than to run the risk of allowing an internal data structure to be corrupted.

-------------

PR: https://git.openjdk.org/jdk/pull/9064

From duke at openjdk.java.net  Tue Jun 14 19:36:51 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 14 Jun 2022 19:36:51 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v3]
In-Reply-To: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
Message-ID: <cZlvnhWCtA1QALP8IlPlzH9rkITeK8_hDEpSR1DreW0=.9fe3db1d-d4bc-402e-a70c-2bcfc98531e7@github.com>

> Instead of `Executable.getParameterTypes()` we could use `Executable.getSharedParameterTypes()` in trusted code. Same is applicable for `Executable.getExceptionTypes()`.

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8287908: Make Executable.getAllGenericParameterTypes() safe

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9064/files
  - new: https://git.openjdk.org/jdk/pull/9064/files/635854b2..7ef88f83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9064&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9064&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9064.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9064/head:pull/9064

PR: https://git.openjdk.org/jdk/pull/9064

From darcy at openjdk.java.net  Tue Jun 14 20:57:46 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 14 Jun 2022 20:57:46 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v25]
In-Reply-To: <q3d1HdLKswVaq7lDL1Ya8JguvPsgJN2T-BQCcu9FQcE=.a9668b3d-659c-4adf-bfb9-c2f158e22eee@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>
 <q3d1HdLKswVaq7lDL1Ya8JguvPsgJN2T-BQCcu9FQcE=.a9668b3d-659c-4adf-bfb9-c2f158e22eee@github.com>
Message-ID: <-wjBhU88RGkIitizq9mq9HkLwhBsUONLlLYLbLxkdXU=.3291fda1-5485-42a4-a522-9768e29409cd@github.com>

On Tue, 14 Jun 2022 14:17:04 GMT, Roger Riggs <rriggs 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/java/lang/reflect/AccessFlag.java line 213:
> 
>> 211:      * <code>{@value "0x%04x" Modifier#STRICT}</code>.
>> 212:      */
>> 213:     STRICT(Modifier.STRICT, true, Set.of(Location.METHOD)),
> 
> ACC_STRICT is defined for class files and appears in the Class.getModifiers() before class file version 46. 
> Also it is included in Modifer.classModifiers();  Modifer.CLASS_MODIFIERS.
> it might be worth a note saying it is class file version specific.

The ACC_STRICT bit is defined for class file major versions 46 through 60:
https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-4.html
It is the first access flag to be retired in this way.

A number of the access flags (ENUM, ANNOTATION, VARARGS, BRIDGE) are only defined for JDK 5.0 and later, class file major version 49 and above. A similar situations hold for other flags introduced to support modularity only being defined for class file major versions 53 and above.

For JDK 20, the native class file major version is 64.

It would be possible to add some kind of ClassFileVersion enum or other API mechanisms to support a query like "what major versions are this access flag defined?" However, I don't think it is necessary to include such information in the core reflection API at this time and interested parties can lookup the information in the JVMS editions. (I think ClassFileVersion enum would be more appropriate for a byte code manipulation library.)

I'll work on at least adding an explanatory paragraph with a disclaimer that the defined access flags are class file version specific and this class is intended to capture class file versions over time.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Tue Jun 14 22:50:55 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 14 Jun 2022 22:50:55 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v26]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <Syey5tuFoPZN22W1PS-daKxi0tYc4QzxAxr9_NdedOM=.e2adbaf7-9d25-451e-83a2-879fb34f6328@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback from Roger Riggs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/adcbcb71..3e4a1edf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=24-25

  Stats: 23 lines in 1 file changed: 22 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From ysatowse at openjdk.java.net  Wed Jun 15 00:16:40 2022
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 15 Jun 2022 00:16:40 GMT
Subject: Integrated: 8287917: System.loadLibrary does not work on Big Sur if
 JDK is built with macOS SDK 10.15 and earlier
In-Reply-To: <g3x9IY-mxwALbN_akqYAgFHK9vlsc8KBtQP59VHdGcQ=.cbbd4f55-268f-4f3e-be00-150a26f86ff0@github.com>
References: <g3x9IY-mxwALbN_akqYAgFHK9vlsc8KBtQP59VHdGcQ=.cbbd4f55-268f-4f3e-be00-150a26f86ff0@github.com>
Message-ID: <2hIlxDE34kHoMUgzCAl1uayEeCcTO3Af6U2nWxKCUaY=.628aadec-7956-4ec8-96bd-7d1bf7aa4b27@github.com>

On Wed, 8 Jun 2022 04:59:07 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.
> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur.  This fix will check if dynamic linker support, which is supported from Big Sur, is available or not on the OS even if os.version is reported as 10.16 instead of 11.  The os.version 10.16 doesn't include the update version like y of 10.x.y.  Hence the change only see if it is 10.16 or not.

This pull request has now been integrated.

Changeset: fe807217
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe807217a79753f84c00432e7451c17baa6645c5
Stats:     6 lines in 2 files changed: 3 ins; 0 del; 3 mod

8287917: System.loadLibrary does not work on Big Sur if JDK is built with macOS SDK 10.15 and earlier

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/9077

From bpb at openjdk.java.net  Wed Jun 15 00:28:45 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 15 Jun 2022 00:28:45 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v5]
In-Reply-To: <iP7AX78NRh96ngXdhMgAODuDwjuuPUBxdJ6FJ01Rp8U=.2770e2b5-43af-46a1-bd58-7dea630bcdab@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <iP7AX78NRh96ngXdhMgAODuDwjuuPUBxdJ6FJ01Rp8U=.2770e2b5-43af-46a1-bd58-7dea630bcdab@github.com>
Message-ID: <vuwha5HV6VJPlB2vE5DKEB3pjHbjLiON31aoK90hCZ4=.a6cfb45e-1bc4-48c7-a3d8-e64f4f356fef@github.com>

On Thu, 9 Jun 2022 18:38:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.
>
> Brian Burkhalter has updated the pull request 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
>  - 6478546: Add break in write loop on ExceptionOccurred
>  - Merge
>  - 6478546: Clean up io_util.c
>  - Merge
>  - 6478546: Decrease malloc'ed buffer maximum size to 64 kB
>  - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

This change would increase throughput at the expense of the additional complexity of a new loop in the native `readBytes()` function; a loop was already present in the native `writeBytes()` function. Putting the loop in Java was problematic and less improvement in performance was observed. I suggest at this point either refining the current proposal as needed to move it forward, or withdrawing the request and resolving the associated issue as **Will not Fix**.

-------------

PR: https://git.openjdk.org/jdk/pull/8235

From coderodd3 at gmail.com  Wed Jun 15 03:46:19 2022
From: coderodd3 at gmail.com (Rodion Efremov)
Date: Wed, 15 Jun 2022 06:46:19 +0300
Subject: [An order statistic tree to JDK?]
Message-ID: <CADLcvW=HN+x82X5fdAb0W_0gcPFu6ob1KNnOVcS8f7dTXUqn-A@mail.gmail.com>

Hello community,

I have implemented an order statistic tree using the ALV algorithm and,
thus, running all single element methods in worst case logarithmic time
[1]. Basically, it?s a sorted list that allows:
(1) accessing the ith element in O(log n),
(2) getting the index of an input object, runs also in O(log n).

What do you think? Does it have a chance of ending up in JDK?

Best regards,
rodde

[1]
https://github.com/coderodde/OrderStatisticTree/blob/master/src/main/java/net/coderodde/util/OrderStatisticsTree.java
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220615/537360e8/attachment-0001.htm>

From liangchenblue at gmail.com  Wed Jun 15 04:03:32 2022
From: liangchenblue at gmail.com (-)
Date: Tue, 14 Jun 2022 23:03:32 -0500
Subject: [An order statistic tree to JDK?]
In-Reply-To: <CADLcvW=HN+x82X5fdAb0W_0gcPFu6ob1KNnOVcS8f7dTXUqn-A@mail.gmail.com>
References: <CADLcvW=HN+x82X5fdAb0W_0gcPFu6ob1KNnOVcS8f7dTXUqn-A@mail.gmail.com>
Message-ID: <CABe8uE2Vn3F8gSEBHTLjwLSeqp2LfSCkzA_XiYD8nyHzfYi4Cw@mail.gmail.com>

The order statistic for a tree map/set appears easily supported with
an additional size field for each tree node. Don't think we need a new
AVL tree implementation if we desire that functionality. However,
before all, do we really need this functionality of accessing an
object by index? We need a few use cases for this functionality, and
see if this is the best way to cover those cases.

Note: You can already get the index of an input object, in O(log n)
with headMap/headSet. So I only consider the question of accessing an
object by rank/index.

On Tue, Jun 14, 2022 at 10:46 PM Rodion Efremov <coderodd3 at gmail.com> wrote:
>
> Hello community,
>
> I have implemented an order statistic tree using the ALV algorithm and, thus, running all single element methods in worst case logarithmic time [1]. Basically, it?s a sorted list that allows:
> (1) accessing the ith element in O(log n),
> (2) getting the index of an input object, runs also in O(log n).
>
> What do you think? Does it have a chance of ending up in JDK?
>
> Best regards,
> rodde
>
> [1]
> https://github.com/coderodde/OrderStatisticTree/blob/master/src/main/java/net/coderodde/util/OrderStatisticsTree.java
>

From mbaesken at openjdk.java.net  Wed Jun 15 06:55:58 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 15 Jun 2022 06:55:58 GMT
Subject: Integrated: JDK-8288207: Enhance MalformedURLException in
 Uri.parseCompat
In-Reply-To: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
References: <McdnpUJWMlpPvEuqNfSczIJ2MkVBkL78n-WS2cNPQXQ=.5a513bcc-241e-4c25-b2ce-9238587f8702@github.com>
Message-ID: <J7XCcsmtWUkvRjZe3qSuf19ZsSbeC5OwCqwLTOeNIA8=.aaf3796c-164c-45d1-8780-e09445440ecc@github.com>

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to construct an LdapURL object with a bad input string (in this example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  ....
> String url = "ldap://ad_jbs.ttt.net:389/xyz"; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz [Root exception is java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example it is host:port of URI:null:-1] ) so that it is directly visible that the input caused the construction of a URI
> with "special"/problematic host and port values.

This pull request has now been integrated.

Changeset: 33f34d54
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33f34d540e01db7e64da97d518e9dd88d014fb23
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8288207: Enhance MalformedURLException in Uri.parseCompat

Reviewed-by: dfuchs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9126

From turbanoff at gmail.com  Wed Jun 15 10:11:33 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Wed, 15 Jun 2022 13:11:33 +0300
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
Message-ID: <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>

I mean, isn't JVM supposed to be safe? :)
Receiving this signal _could_ happen in a real deployment. And now, as
I can see, we have C++ undefined behaviour in release builds in this
case. Can we consider this as a bug?

Andrey Turbanov

??, 14 ???. 2022 ?. ? 14:46, Alan Bateman <Alan.Bateman at oracle.com>:
>
> On 14/06/2022 10:44, Andrey Turbanov wrote:
> > Hello.
> > During investigation of signal handling in JVM (for
> > https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
> > I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)
> >
> > kill -USR2 1346792
> >
> > # assert(thread != __null) failed: Missing current thread in SR_handler
> > # Internal Error
> > (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
> > pid=1346792, tid=1346792
> >
> > Full hs_err_pid1346792.log:
> > https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
> >
> >
> > Is it known/expected behaviour?
> > I found some description there
> > https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
> > that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?
>
> In general you have to be very careful when using signals. Yes, it can
> easily break things and probably notice it quickly with debug builds as
> asserts are compiled in to the builds (like the above). So I think
> you've found the right page to read up on this. In this case, you can
> set _JAVA_SR_SIGNUM to specify a different signal for S/R.
>
> -Alan

From thomas.stuefe at gmail.com  Wed Jun 15 10:26:32 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 15 Jun 2022 12:26:32 +0200
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
Message-ID: <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>

SIGUSR2 is used by the hotspot, internally, to implement suspend/resume. It
gets sent by hotspot via pthread_kill() to targeted threads to suspend
them. In that case it is known that the receiving thread is a valid java
thread and therefore the assert makes sense.

However, as you describe SIGUSR2 can also be sent from outside via kill(2).
In that case the receiving thread is arbitrarily chosen by the kernel. It
is not necessarily a valid java thread. In that case the VM will crash
(release) or assert (debug).

I tend to think this is an error too. Or at least in grey area. Since this
is very easy to fix in the hotspot, I'd suggest we do this.

If nobody objects, I can file an issue and prepare the patch.

Cheers, Thomas

(P.s. not C++ undefined behavior, nothing to do with C++ :-)

On Wed, Jun 15, 2022 at 12:11 PM Andrey Turbanov <turbanoff at gmail.com>
wrote:

> I mean, isn't JVM supposed to be safe? :)
> Receiving this signal _could_ happen in a real deployment. And now, as
> I can see, we have C++ undefined behaviour in release builds in this
> case. Can we consider this as a bug?
>
> Andrey Turbanov
>
> ??, 14 ???. 2022 ?. ? 14:46, Alan Bateman <Alan.Bateman at oracle.com>:
> >
> > On 14/06/2022 10:44, Andrey Turbanov wrote:
> > > Hello.
> > > During investigation of signal handling in JVM (for
> > > https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
> > > I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)
> > >
> > > kill -USR2 1346792
> > >
> > > # assert(thread != __null) failed: Missing current thread in SR_handler
> > > # Internal Error
> > >
> (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
> > > pid=1346792, tid=1346792
> > >
> > > Full hs_err_pid1346792.log:
> > > https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
> > >
> > >
> > > Is it known/expected behaviour?
> > > I found some description there
> > >
> https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
> > > that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?
> >
> > In general you have to be very careful when using signals. Yes, it can
> > easily break things and probably notice it quickly with debug builds as
> > asserts are compiled in to the builds (like the above). So I think
> > you've found the right page to read up on this. In this case, you can
> > set _JAVA_SR_SIGNUM to specify a different signal for S/R.
> >
> > -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220615/88621b2b/attachment-0001.htm>

From aturbanov at openjdk.java.net  Wed Jun 15 10:37:56 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Jun 2022 10:37:56 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
 [v2]
In-Reply-To: <nx8Z5HZC4KU3ycOKMt4jxsA2JmminkROX1zyWh51qiE=.5d5d98e1-01d0-4973-bb7a-192dc06898a5@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
 <nx8Z5HZC4KU3ycOKMt4jxsA2JmminkROX1zyWh51qiE=.5d5d98e1-01d0-4973-bb7a-192dc06898a5@github.com>
Message-ID: <hVQb6piXnoQdGyaDZLqNyFhyKulL0Ci6xhBOoobqSvM=.a58b0a65-7157-435f-8777-5694cb1b95c3@github.com>

On Fri, 10 Jun 2022 11:31:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
>> 
>> Instead of separate Hashtable.get/remove calls we can just use value returned by `remove`,
>> It results in cleaner and a bit faster code.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288140: Avoid redundant Hashtable.get call in Signal.handle
>   apply dmlloyd's suggestion

Thank you for review!

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From aturbanov at openjdk.java.net  Wed Jun 15 10:37:58 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Jun 2022 10:37:58 GMT
Subject: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle
 [v2]
In-Reply-To: <4HQBaGMVW5UD8adG1FNDY17ofIeIReatC-rB0RhAmsg=.3c7f0529-87b0-4c3f-8861-3456d1a92afc@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
 <nx8Z5HZC4KU3ycOKMt4jxsA2JmminkROX1zyWh51qiE=.5d5d98e1-01d0-4973-bb7a-192dc06898a5@github.com>
 <4HQBaGMVW5UD8adG1FNDY17ofIeIReatC-rB0RhAmsg=.3c7f0529-87b0-4c3f-8861-3456d1a92afc@github.com>
Message-ID: <hGiV8LhOft1OOr4D5CSjwSXI1HiLrMOS8-YP6WOjoJw=.9cc67415-c64f-4fca-adb0-0307b118b040@github.com>

On Fri, 10 Jun 2022 19:30:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288140: Avoid redundant Hashtable.get call in Signal.handle
>>   apply dmlloyd's suggestion
>
> src/java.base/share/classes/jdk/internal/misc/Signal.java line 181:
> 
>> 179:         } else {
>> 180:             oldHandler = handlers.remove(sig);
>> 181:         }
> 
> A ternary assignment might be an alternative here:
> 
>  Signal.Handler oldHandler = (newH == 2) ? handlers.put(sig, handler) : handlers.remove(sig);

Too much logic in the single line. I like `if` approach more.

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From aturbanov at openjdk.java.net  Wed Jun 15 10:38:00 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Jun 2022 10:38:00 GMT
Subject: Integrated: 8288140: Avoid redundant Hashtable.get call in
 Signal.handle
In-Reply-To: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
References: <MI6KYNnRTurMHaopel67w-5lR9VwKeNtAU3tSYj26lw=.25420e9e-4383-447d-af46-d343a6929963@github.com>
Message-ID: <xs_QYWhPsFpVhNbmK86W9PsxsIOoh9TLQTUS4sIs5V4=.3fa620ae-9756-4bea-9c24-0f0b47e5adac@github.com>

On Thu, 9 Jun 2022 07:35:43 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
> 
> Instead of separate Hashtable.get/remove calls we can just use value returned by `remove`,
> It results in cleaner and a bit faster code.

This pull request has now been integrated.

Changeset: dfeeb6f8
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfeeb6f8f3c42d6fe2adf89f243e7011827db122
Stats:     19 lines in 1 file changed: 0 ins; 1 del; 18 mod

8288140: Avoid redundant Hashtable.get call in Signal.handle

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/9100

From thomas.stuefe at gmail.com  Wed Jun 15 10:45:42 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 15 Jun 2022 12:45:42 +0200
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
 <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
Message-ID: <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>

More specifically, I propose to gracefully ignore SIGUSR2 in release builds
if the receiving thread is not a java thread, but to retain the assert in
debug builds.

We could make it more involved by checking the sender pid and accepting
only signals from hotspot threads themselves, but I do not think this
complexity is necessary.

Cheers, Thomas

On Wed, Jun 15, 2022 at 12:26 PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> SIGUSR2 is used by the hotspot, internally, to implement suspend/resume.
> It gets sent by hotspot via pthread_kill() to targeted threads to suspend
> them. In that case it is known that the receiving thread is a valid java
> thread and therefore the assert makes sense.
>
> However, as you describe SIGUSR2 can also be sent from outside via
> kill(2). In that case the receiving thread is arbitrarily chosen by the
> kernel. It is not necessarily a valid java thread. In that case the VM will
> crash (release) or assert (debug).
>
> I tend to think this is an error too. Or at least in grey area. Since this
> is very easy to fix in the hotspot, I'd suggest we do this.
>
> If nobody objects, I can file an issue and prepare the patch.
>
> Cheers, Thomas
>
> (P.s. not C++ undefined behavior, nothing to do with C++ :-)
>
> On Wed, Jun 15, 2022 at 12:11 PM Andrey Turbanov <turbanoff at gmail.com>
> wrote:
>
>> I mean, isn't JVM supposed to be safe? :)
>> Receiving this signal _could_ happen in a real deployment. And now, as
>> I can see, we have C++ undefined behaviour in release builds in this
>> case. Can we consider this as a bug?
>>
>> Andrey Turbanov
>>
>> ??, 14 ???. 2022 ?. ? 14:46, Alan Bateman <Alan.Bateman at oracle.com>:
>> >
>> > On 14/06/2022 10:44, Andrey Turbanov wrote:
>> > > Hello.
>> > > During investigation of signal handling in JVM (for
>> > > https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
>> > > I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)
>> > >
>> > > kill -USR2 1346792
>> > >
>> > > # assert(thread != __null) failed: Missing current thread in
>> SR_handler
>> > > # Internal Error
>> > >
>> (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
>> > > pid=1346792, tid=1346792
>> > >
>> > > Full hs_err_pid1346792.log:
>> > > https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
>> > >
>> > >
>> > > Is it known/expected behaviour?
>> > > I found some description there
>> > >
>> https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
>> > > that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?
>> >
>> > In general you have to be very careful when using signals. Yes, it can
>> > easily break things and probably notice it quickly with debug builds as
>> > asserts are compiled in to the builds (like the above). So I think
>> > you've found the right page to read up on this. In this case, you can
>> > set _JAVA_SR_SIGNUM to specify a different signal for S/R.
>> >
>> > -Alan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220615/cc8c4212/attachment-0001.htm>

From turbanoff at gmail.com  Wed Jun 15 11:16:56 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Wed, 15 Jun 2022 14:16:56 +0300
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
 <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
 <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
Message-ID: <CAF+DQ5fY6z27e1tbVNL8pXFhgB6Zbi2mKcRs7RSggFyupd_9hg@mail.gmail.com>

>not C++ undefined behavior, nothing to do with C++

>From 'signals_posix.cpp':

Thread* thread = Thread::current_or_null_safe();
assert(thread != NULL, "Missing current thread in SR_handler");

if (thread->has_terminated()) {
  return;
}

In release build there will be no assert and 'thread' will be 'NULL'.
This is C++ code and in C++ dereferencing of NULL pointers is
undefined behaviour.
Do I miss something?




Andrey Turbanov

??, 15 ???. 2022 ?. ? 13:45, Thomas St?fe <thomas.stuefe at gmail.com>:
>
> More specifically, I propose to gracefully ignore SIGUSR2 in release builds if the receiving thread is not a java thread, but to retain the assert in debug builds.
>
> We could make it more involved by checking the sender pid and accepting only signals from hotspot threads themselves, but I do not think this complexity is necessary.
>
> Cheers, Thomas
>
> On Wed, Jun 15, 2022 at 12:26 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>>
>> SIGUSR2 is used by the hotspot, internally, to implement suspend/resume. It gets sent by hotspot via pthread_kill() to targeted threads to suspend them. In that case it is known that the receiving thread is a valid java thread and therefore the assert makes sense.
>>
>> However, as you describe SIGUSR2 can also be sent from outside via kill(2). In that case the receiving thread is arbitrarily chosen by the kernel. It is not necessarily a valid java thread. In that case the VM will crash (release) or assert (debug).
>>
>> I tend to think this is an error too. Or at least in grey area. Since this is very easy to fix in the hotspot, I'd suggest we do this.
>>
>> If nobody objects, I can file an issue and prepare the patch.
>>
>> Cheers, Thomas
>>
>> (P.s. not C++ undefined behavior, nothing to do with C++ :-)
>>
>> On Wed, Jun 15, 2022 at 12:11 PM Andrey Turbanov <turbanoff at gmail.com> wrote:
>>>
>>> I mean, isn't JVM supposed to be safe? :)
>>> Receiving this signal _could_ happen in a real deployment. And now, as
>>> I can see, we have C++ undefined behaviour in release builds in this
>>> case. Can we consider this as a bug?
>>>
>>> Andrey Turbanov
>>>
>>> ??, 14 ???. 2022 ?. ? 14:46, Alan Bateman <Alan.Bateman at oracle.com>:
>>> >
>>> > On 14/06/2022 10:44, Andrey Turbanov wrote:
>>> > > Hello.
>>> > > During investigation of signal handling in JVM (for
>>> > > https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
>>> > > I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)
>>> > >
>>> > > kill -USR2 1346792
>>> > >
>>> > > # assert(thread != __null) failed: Missing current thread in SR_handler
>>> > > # Internal Error
>>> > > (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
>>> > > pid=1346792, tid=1346792
>>> > >
>>> > > Full hs_err_pid1346792.log:
>>> > > https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
>>> > >
>>> > >
>>> > > Is it known/expected behaviour?
>>> > > I found some description there
>>> > > https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
>>> > > that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?
>>> >
>>> > In general you have to be very careful when using signals. Yes, it can
>>> > easily break things and probably notice it quickly with debug builds as
>>> > asserts are compiled in to the builds (like the above). So I think
>>> > you've found the right page to read up on this. In this case, you can
>>> > set _JAVA_SR_SIGNUM to specify a different signal for S/R.
>>> >
>>> > -Alan

From thomas.stuefe at gmail.com  Wed Jun 15 11:46:55 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 15 Jun 2022 13:46:55 +0200
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <CAF+DQ5fY6z27e1tbVNL8pXFhgB6Zbi2mKcRs7RSggFyupd_9hg@mail.gmail.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
 <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
 <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
 <CAF+DQ5fY6z27e1tbVNL8pXFhgB6Zbi2mKcRs7RSggFyupd_9hg@mail.gmail.com>
Message-ID: <CAA-vtUwZOkMxFjSxp--paeL00WQQ+ZP31qUS2P0dELyVQxPduw@mail.gmail.com>

Okay, sure. I thought you referred to the way the VM relies in undefined
signal delivery specifics for signals sent to the process.

On Wed 15. Jun 2022 at 13:17, Andrey Turbanov <turbanoff at gmail.com> wrote:

> >not C++ undefined behavior, nothing to do with C++
>
> From 'signals_posix.cpp':
>
> Thread* thread = Thread::current_or_null_safe();
> assert(thread != NULL, "Missing current thread in SR_handler");
>
> if (thread->has_terminated()) {
>   return;
> }
>
> In release build there will be no assert and 'thread' will be 'NULL'.
> This is C++ code and in C++ dereferencing of NULL pointers is
> undefined behaviour.
> Do I miss something?
>
>
>
>
> Andrey Turbanov
>
> ??, 15 ???. 2022 ?. ? 13:45, Thomas St?fe <thomas.stuefe at gmail.com>:
> >
> > More specifically, I propose to gracefully ignore SIGUSR2 in release
> builds if the receiving thread is not a java thread, but to retain the
> assert in debug builds.
> >
> > We could make it more involved by checking the sender pid and accepting
> only signals from hotspot threads themselves, but I do not think this
> complexity is necessary.
> >
> > Cheers, Thomas
> >
> > On Wed, Jun 15, 2022 at 12:26 PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >>
> >> SIGUSR2 is used by the hotspot, internally, to implement
> suspend/resume. It gets sent by hotspot via pthread_kill() to targeted
> threads to suspend them. In that case it is known that the receiving thread
> is a valid java thread and therefore the assert makes sense.
> >>
> >> However, as you describe SIGUSR2 can also be sent from outside via
> kill(2). In that case the receiving thread is arbitrarily chosen by the
> kernel. It is not necessarily a valid java thread. In that case the VM will
> crash (release) or assert (debug).
> >>
> >> I tend to think this is an error too. Or at least in grey area. Since
> this is very easy to fix in the hotspot, I'd suggest we do this.
> >>
> >> If nobody objects, I can file an issue and prepare the patch.
> >>
> >> Cheers, Thomas
> >>
> >> (P.s. not C++ undefined behavior, nothing to do with C++ :-)
> >>
> >> On Wed, Jun 15, 2022 at 12:11 PM Andrey Turbanov <turbanoff at gmail.com>
> wrote:
> >>>
> >>> I mean, isn't JVM supposed to be safe? :)
> >>> Receiving this signal _could_ happen in a real deployment. And now, as
> >>> I can see, we have C++ undefined behaviour in release builds in this
> >>> case. Can we consider this as a bug?
> >>>
> >>> Andrey Turbanov
> >>>
> >>> ??, 14 ???. 2022 ?. ? 14:46, Alan Bateman <Alan.Bateman at oracle.com>:
> >>> >
> >>> > On 14/06/2022 10:44, Andrey Turbanov wrote:
> >>> > > Hello.
> >>> > > During investigation of signal handling in JVM (for
> >>> > > https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
> >>> > > I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)
> >>> > >
> >>> > > kill -USR2 1346792
> >>> > >
> >>> > > # assert(thread != __null) failed: Missing current thread in
> SR_handler
> >>> > > # Internal Error
> >>> > >
> (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
> >>> > > pid=1346792, tid=1346792
> >>> > >
> >>> > > Full hs_err_pid1346792.log:
> >>> > > https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
> >>> > >
> >>> > >
> >>> > > Is it known/expected behaviour?
> >>> > > I found some description there
> >>> > >
> https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
> >>> > > that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?
> >>> >
> >>> > In general you have to be very careful when using signals. Yes, it
> can
> >>> > easily break things and probably notice it quickly with debug builds
> as
> >>> > asserts are compiled in to the builds (like the above). So I think
> >>> > you've found the right page to read up on this. In this case, you can
> >>> > set _JAVA_SR_SIGNUM to specify a different signal for S/R.
> >>> >
> >>> > -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220615/4c55fcb4/attachment.htm>

From david.holmes at oracle.com  Wed Jun 15 13:06:15 2022
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 15 Jun 2022 23:06:15 +1000
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
 <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
 <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
Message-ID: <be5d1b98-3fc9-5383-9513-762160fe43a1@oracle.com>

On 15/06/2022 8:45 pm, Thomas St?fe wrote:
> More specifically, I propose to gracefully ignore SIGUSR2 in release 
> builds if the receiving thread is not a java thread, but to retain the 
> assert in debug builds.
> 
> We could make it more involved by checking the sender pid and accepting 
> only signals from hotspot?threads themselves, but I do not think this 
> complexity is necessary.

Nor do I. SIGUSR2 is reserved for use by the VM and we document that. If 
you start throwing around random signals at processes then they can 
crash - so don't do that. I'm not sure ignoring signals that shouldn't 
be raised actually aids the end-user who obviously has an issue in their 
environment that needs to be addressed.

 >         I mean, isn't JVM supposed to be safe? :)

Not when it comes to native code and signals - there it is more a case 
of caveat emptor.

Cheers,
David
-----

> Cheers, Thomas
> 
> On Wed, Jun 15, 2022 at 12:26 PM Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
> 
>     SIGUSR2 is used by the hotspot, internally, to implement
>     suspend/resume. It gets sent by hotspot via pthread_kill() to
>     targeted threads to suspend them. In that case it is known that the
>     receiving thread is a valid java thread and therefore the assert
>     makes sense.
> 
>     However, as you describe SIGUSR2 can also be sent from outside via
>     kill(2). In that case the receiving thread is arbitrarily chosen by
>     the kernel. It is not necessarily a valid java thread. In that case
>     the VM will crash (release) or assert (debug).
> 
>     I tend to think this is an error too. Or at least in grey area.
>     Since this is very easy to fix in the hotspot, I'd suggest we do this.
> 
>     If nobody objects, I can file an issue and prepare the patch.
> 
>     Cheers, Thomas
> 
>     (P.s. not C++ undefined behavior, nothing to do with C++ :-)
> 
>     On Wed, Jun 15, 2022 at 12:11 PM Andrey Turbanov
>     <turbanoff at gmail.com <mailto:turbanoff at gmail.com>> wrote:
> 
>         I mean, isn't JVM supposed to be safe? :)
>         Receiving this signal _could_ happen in a real deployment. And
>         now, as
>         I can see, we have C++ undefined behaviour in release builds in this
>         case. Can we consider this as a bug?
> 
>         Andrey Turbanov
> 
>         ??, 14 ???. 2022 ?. ? 14:46, Alan Bateman
>         <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>:
>          >
>          > On 14/06/2022 10:44, Andrey Turbanov wrote:
>          > > Hello.
>          > > During investigation of signal handling in JVM (for
>          > >
>         https://github.com/openjdk/jdk/pull/9100#discussion_r894992558
>         <https://github.com/openjdk/jdk/pull/9100#discussion_r894992558> )
>          > > I found out that sending USR2 crashes my JDK. (Linux
>         fastdebug x64)
>          > >
>          > > kill -USR2 1346792
>          > >
>          > > # assert(thread != __null) failed: Missing current thread
>         in SR_handler
>          > > # Internal Error
>          > >
>         (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
>          > > pid=1346792, tid=1346792
>          > >
>          > > Full hs_err_pid1346792.log:
>          > >
>         https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
>         <https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a>
>          > >
>          > >
>          > > Is it known/expected behaviour?
>          > > I found some description there
>          > >
>         https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
>         <https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html>
>          > > that USR2 is used for SUSPEND/RESUME. Is it supported by
>         Hotspot?
>          >
>          > In general you have to be very careful when using signals.
>         Yes, it can
>          > easily break things and probably notice it quickly with debug
>         builds as
>          > asserts are compiled in to the builds (like the above). So I
>         think
>          > you've found the right page to read up on this. In this case,
>         you can
>          > set _JAVA_SR_SIGNUM to specify a different signal for S/R.
>          >
>          > -Alan
> 

From mdoerr at openjdk.java.net  Wed Jun 15 13:35:39 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 15 Jun 2022 13:35:39 GMT
Subject: RFR: 8288485: [PPC64] Usage of iostream breaks NullCallerTest
Message-ID: <QYjhql6t3pgYJMtCmUdJkjw5Q2BNJU3hZ0ABwWloUiI=.8fd1d57a-fa11-4a14-a28f-f94e94b3b700@github.com>

I'd like to revert to "<stdio.h>" functions like it was before [JDK-8281001](https://bugs.openjdk.org/browse/JDK-8281001), except that I'm using stderr in order to preserve the new behavior. Also see JBS issue.

-------------

Commit messages:
 - 8288485: [PPC64] Usage of iostream breaks NullCallerTest

Changes: https://git.openjdk.org/jdk19/pull/19/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=19&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288485
  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk19/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/19/head:pull/19

PR: https://git.openjdk.org/jdk19/pull/19

From thomas.stuefe at gmail.com  Wed Jun 15 14:09:24 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 15 Jun 2022 16:09:24 +0200
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <be5d1b98-3fc9-5383-9513-762160fe43a1@oracle.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
 <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
 <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
 <be5d1b98-3fc9-5383-9513-762160fe43a1@oracle.com>
Message-ID: <CAA-vtUzWCUjFCKhD8tQow8PFm1ugG8hse6U072vRtMEJ9XUpag@mail.gmail.com>

On Wed 15. Jun 2022 at 15:06, David Holmes <david.holmes at oracle.com> wrote:

> On 15/06/2022 8:45 pm, Thomas St?fe wrote:
> > More specifically, I propose to gracefully ignore SIGUSR2 in release
> > builds if the receiving thread is not a java thread, but to retain the
> > assert in debug builds.
> >
> > We could make it more involved by checking the sender pid and accepting
> > only signals from hotspot threads themselves, but I do not think this
> > complexity is necessary.
>
> Nor do I. SIGUSR2 is reserved for use by the VM and we document that. If
> you start throwing around random signals at processes then they can
> crash - so don't do that. I'm not sure ignoring signals that shouldn't
> be raised actually aids the end-user who obviously has an issue in their
> environment that needs to be addressed.


I see your point. I dislike crashes, especially ones they can be reliably
triggered from outside. You never can be sure about the security
implications either.

If you dislike ignoring the signal, and since the default action for
SIGUSR1+2 is process termination, why not exit the VM with an error message
instead? At least we don?t have what looks like a random segfault, and we
could print out the sender pid  too.


>
>  >         I mean, isn't JVM supposed to be safe? :)
>
> Not when it comes to native code and signals - there it is more a case
> of caveat emptor.
>
> Cheers,
> David
> -----
>
> > Cheers, Thomas
> >
> > On Wed, Jun 15, 2022 at 12:26 PM Thomas St?fe <thomas.stuefe at gmail.com
> > <mailto:thomas.stuefe at gmail.com>> wrote:
> >
> >     SIGUSR2 is used by the hotspot, internally, to implement
> >     suspend/resume. It gets sent by hotspot via pthread_kill() to
> >     targeted threads to suspend them. In that case it is known that the
> >     receiving thread is a valid java thread and therefore the assert
> >     makes sense.
> >
> >     However, as you describe SIGUSR2 can also be sent from outside via
> >     kill(2). In that case the receiving thread is arbitrarily chosen by
> >     the kernel. It is not necessarily a valid java thread. In that case
> >     the VM will crash (release) or assert (debug).
> >
> >     I tend to think this is an error too. Or at least in grey area.
> >     Since this is very easy to fix in the hotspot, I'd suggest we do
> this.
> >
> >     If nobody objects, I can file an issue and prepare the patch.
> >
> >     Cheers, Thomas
> >
> >     (P.s. not C++ undefined behavior, nothing to do with C++ :-)
> >
> >     On Wed, Jun 15, 2022 at 12:11 PM Andrey Turbanov
> >     <turbanoff at gmail.com <mailto:turbanoff at gmail.com>> wrote:
> >
> >         I mean, isn't JVM supposed to be safe? :)
> >         Receiving this signal _could_ happen in a real deployment. And
> >         now, as
> >         I can see, we have C++ undefined behaviour in release builds in
> this
> >         case. Can we consider this as a bug?
> >
> >         Andrey Turbanov
> >
> >         ??, 14 ???. 2022 ?. ? 14:46, Alan Bateman
> >         <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>:
> >          >
> >          > On 14/06/2022 10:44, Andrey Turbanov wrote:
> >          > > Hello.
> >          > > During investigation of signal handling in JVM (for
> >          > >
> >         https://github.com/openjdk/jdk/pull/9100#discussion_r894992558
> >         <https://github.com/openjdk/jdk/pull/9100#discussion_r894992558>
> )
> >          > > I found out that sending USR2 crashes my JDK. (Linux
> >         fastdebug x64)
> >          > >
> >          > > kill -USR2 1346792
> >          > >
> >          > > # assert(thread != __null) failed: Missing current thread
> >         in SR_handler
> >          > > # Internal Error
> >          > >
> >
>  (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
> >          > > pid=1346792, tid=1346792
> >          > >
> >          > > Full hs_err_pid1346792.log:
> >          > >
> >
> https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
> >         <
> https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a>
> >          > >
> >          > >
> >          > > Is it known/expected behaviour?
> >          > > I found some description there
> >          > >
> >
> https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
> >         <
> https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
> >
> >          > > that USR2 is used for SUSPEND/RESUME. Is it supported by
> >         Hotspot?
> >          >
> >          > In general you have to be very careful when using signals.
> >         Yes, it can
> >          > easily break things and probably notice it quickly with debug
> >         builds as
> >          > asserts are compiled in to the builds (like the above). So I
> >         think
> >          > you've found the right page to read up on this. In this case,
> >         you can
> >          > set _JAVA_SR_SIGNUM to specify a different signal for S/R.
> >          >
> >          > -Alan
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220615/89a32610/attachment.htm>

From alanb at openjdk.java.net  Wed Jun 15 14:11:51 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 15 Jun 2022 14:11:51 GMT
Subject: RFR: 8288485: [PPC64] Usage of iostream breaks NullCallerTest
In-Reply-To: <QYjhql6t3pgYJMtCmUdJkjw5Q2BNJU3hZ0ABwWloUiI=.8fd1d57a-fa11-4a14-a28f-f94e94b3b700@github.com>
References: <QYjhql6t3pgYJMtCmUdJkjw5Q2BNJU3hZ0ABwWloUiI=.8fd1d57a-fa11-4a14-a28f-f94e94b3b700@github.com>
Message-ID: <HfSd2x5SrquqDcp4gnqLpf7WULCXVDxTxtk1qq1faII=.d41191de-8764-4007-92cb-9291f9df8d22@github.com>

On Wed, 15 Jun 2022 13:25:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to revert to "<stdio.h>" functions like it was before [JDK-8281001](https://bugs.openjdk.org/browse/JDK-8281001), except that I'm using stderr in order to preserve the new behavior. Also see JBS issue.

Switching it to stdio.h is okay but I think the JBS issue or PR should explain if why the test is failing on this platform.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/19

From jvernee at openjdk.java.net  Wed Jun 15 14:58:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 14:58:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
Message-ID: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>

On Tue, 7 Jun 2022 13:00:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
>> 
>> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
>> 
>> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into cleanup_memory_session_impl_state
>  - Add null check on Buffer::checkState
>  - Add docs
>    Simplify liveness check in Buffer
>    Drop redundant import in DirectBuffer
>  - Simplify checkValidState
>  - Add fastpath for implicit session state
>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>  - Fix asNonCloseable to return self
>    Improve direct buffer code with isImplicit predicate
>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>  - Simplify readOnly check
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246

I think this looks good overall, but please try to limit the accessibility of  the methods in `State`.

src/java.base/share/classes/jdk/internal/foreign/ConfinedSessionState.java line 40:

> 38:  * operations triggered by threads other than the owner thread, which we support.
> 39:  */
> 40: public final class ConfinedSessionState extends MemorySessionImpl.State {

Same here. I don't see why this is made public now.

src/java.base/share/classes/jdk/internal/foreign/SharedSessionState.java line 46:

> 44:  * checking the liveness bit upon access can be performed in plain mode, as in the confined case.
> 45:  */
> 46: public class SharedSessionState extends MemorySessionImpl.State {

Unclear to me why this is now public. It still seems to be only accessed from with the `jdk.internal.foreign` package?

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9017

From jvernee at openjdk.java.net  Wed Jun 15 14:58:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 14:58:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
 <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
Message-ID: <NNFbp2rnfsp4-twI5e8a6s9kxqklOnUaInu5fAEUr0o=.a87e3023-0dd0-4b29-86b0-38ed8efd4883@github.com>

On Wed, 15 Jun 2022 14:41:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into cleanup_memory_session_impl_state
>>  - Add null check on Buffer::checkState
>>  - Add docs
>>    Simplify liveness check in Buffer
>>    Drop redundant import in DirectBuffer
>>  - Simplify checkValidState
>>  - Add fastpath for implicit session state
>>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>>  - Fix asNonCloseable to return self
>>    Improve direct buffer code with isImplicit predicate
>>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>>  - Simplify readOnly check
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246
>
> src/java.base/share/classes/jdk/internal/foreign/ConfinedSessionState.java line 40:
> 
>> 38:  * operations triggered by threads other than the owner thread, which we support.
>> 39:  */
>> 40: public final class ConfinedSessionState extends MemorySessionImpl.State {
> 
> Same here. I don't see why this is made public now.

Same for `justClose` and `ConfinedList::add` in this file. They still seem only accessed in the same package.

-------------

PR: https://git.openjdk.org/jdk/pull/9017

From mcimadamore at openjdk.java.net  Wed Jun 15 16:55:06 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 16:55:06 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
 <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
Message-ID: <lTNs91mKp3yK6ux1HoGYYanROrJMGgwBs_ykF-Us-8Q=.d7350e59-cfa0-4cbe-8d33-fd97e24a4a47@github.com>

On Wed, 15 Jun 2022 14:55:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I think this looks good overall, but please try to limit the accessibility of the methods in `State`.

Thanks, I'll take another look

-------------

PR: https://git.openjdk.org/jdk/pull/9017

From xuelei at openjdk.java.net  Wed Jun 15 17:32:41 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 15 Jun 2022 17:32:41 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v8]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <vblABaYcTg_9gjMeJu6bDwj4ZM3V0McmUJfPSq-2o-c=.8ec3c751-d35f-4a9b-ad0c-cc7340f6c073@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  use timeout factor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8979/files
  - new: https://git.openjdk.org/jdk/pull/8979/files/2825686b..bc51397f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=06-07

  Stats: 24 lines in 2 files changed: 3 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.org/jdk/pull/8979

From xuelei at openjdk.java.net  Wed Jun 15 17:32:43 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 15 Jun 2022 17:32:43 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v7]
In-Reply-To: <RT1U-Xkb2cCL-v_GKjEnGxcgfjUSlhmxDr5fnaf7hgQ=.3bf18491-09df-477c-b3e6-37762751b006@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <pqDIz146EyleM3TZeY8WcgjAG9ze7NhE7g7B0bt_K1M=.6fde489c-efb8-4726-861a-38ee6a75fc2d@github.com>
 <THmEMBXe44ieDrUdmDKx-yRYWgijFsdwXM-PLdHv3e8=.bd9bbc0b-de5b-41e0-86cc-c763d179f634@github.com>
 <RT1U-Xkb2cCL-v_GKjEnGxcgfjUSlhmxDr5fnaf7hgQ=.3bf18491-09df-477c-b3e6-37762751b006@github.com>
Message-ID: <IGEI6KTnheskcc8cqA0gVe5aHJWPZA3rNH5r54P9OTA=.7ead3b40-261c-48f6-ae0a-e00b1e79b04a@github.com>

On Mon, 13 Jun 2022 22:21:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 44:
>> 
>>> 42:      */
>>> 43:     public static boolean wait(BooleanSupplier booleanSupplier) {
>>> 44:         return wait(booleanSupplier, 10000L);
>> 
>> For the max waiting time, instead of a fixed value I strongly recommend choosing some base waiting time, say 1 second, and scaling it by the jtreg timeout factor.
>
> I also have similar feedback.  The timeout factor can be found in the `test.timeout.factor` system property, if present.    When running tests with -Xcomp in a fastdebug build, the timeout factor is currently configured to 10.   Setting the base waiting time to 1 second seems reasonable.

Good point!  I changed to use 1 second as the base waiting time.  I was not very sure if 1 second is big enough for the GC cleanup, but the testing result on my laptop and VMs, which are super faster, looks good to me.  Please help to check mach5 result.

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From xuelei at openjdk.java.net  Wed Jun 15 17:39:12 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 15 Jun 2022 17:39:12 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v7]
In-Reply-To: <qtt-SVbqqY8iB_klhuuj6QSjoNd07bxq87ETB6FIh_A=.8b120b05-236e-4db3-855d-bbc78763df2b@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <pqDIz146EyleM3TZeY8WcgjAG9ze7NhE7g7B0bt_K1M=.6fde489c-efb8-4726-861a-38ee6a75fc2d@github.com>
 <qtt-SVbqqY8iB_klhuuj6QSjoNd07bxq87ETB6FIh_A=.8b120b05-236e-4db3-855d-bbc78763df2b@github.com>
Message-ID: <kTcV6sJAXtuUcdBjWEwYFfHYgN5y_8fzH7pdBUkRfLg=.38dd3af7-038f-4a75-8cfd-62f84843c1f6@github.com>

On Mon, 13 Jun 2022 22:37:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Merge
>>  - Merge master
>>  - Merge
>>  - add timeout parameter
>>  - rollback is not in this branch
>>  - rollback JDK-8287384
>>  - back to wait 1 second
>>  - Remove trailing white space
>>  - 8287596: Reorg jdk.test.lib.util.ForceGC
>
> test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java line 224:
> 
>> 222: 
>> 223:         boolean tryUnload() {
>> 224:             return ForceGC.wait(() -> weakRef.get() == null, 1000L);
> 
> This verifies that the reference will never become weakly unreachable, i.e. it remains strongly reachable.
> 
> I suggest to add a method default to 200ms (?) timeout scaled with the timeout factor and expect the specified condition will never met.   Maybe call it `ForceGC.neverTrue(BooleanSupplier)`?   Need to tune the base waiting time; for example if timeout factor is 4, then total wait would be 800 ms.

I see your points.

When I changed the waiting time to 1 second scaled with timeout factor, it looks like safe to use the ForceGC.wait() method for either cleanup and non-cleanup checking.  The default JTREG timeout for a test case is 120 seconds. 1 seconds may be small enough so that we could use it for both cases.

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From mcimadamore at openjdk.java.net  Wed Jun 15 17:52:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:52:31 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v3]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <N43DTnhrT-MpOW5fxbWyn5r2x7Fbn0MEZGYREvuCKAQ=.67761ec2-83ef-46c9-a54e-d0487fc233c5@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9017/files
  - new: https://git.openjdk.org/jdk/pull/9017/files/5b8f7246..67710665

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9017&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9017&range=01-02

  Stats: 17 lines in 3 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9017/head:pull/9017

PR: https://git.openjdk.org/jdk/pull/9017

From mcimadamore at openjdk.java.net  Wed Jun 15 17:52:34 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:52:34 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
Message-ID: <WOeSkpiMEWFdfq24NPuKr1MkRsC-2KyWl7-xBTVhinY=.cedef75d-3936-4ef1-ba65-a24f579ac63e@github.com>

On Tue, 7 Jun 2022 13:00:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
>> 
>> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
>> 
>> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into cleanup_memory_session_impl_state
>  - Add null check on Buffer::checkState
>  - Add docs
>    Simplify liveness check in Buffer
>    Drop redundant import in DirectBuffer
>  - Simplify checkValidState
>  - Add fastpath for implicit session state
>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>  - Fix asNonCloseable to return self
>    Improve direct buffer code with isImplicit predicate
>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>  - Simplify readOnly check
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246

I'm going to close this PR and re-open another against the 19 repo.

-------------

PR: https://git.openjdk.org/jdk/pull/9017

From mcimadamore at openjdk.java.net  Wed Jun 15 17:54:39 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:54:39 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <45yAEXwPWvEqPT03oBHaJgH9HANer_iQ1uDSNGELoiA=.a1e6ee75-275e-407c-a8ce-355f54fab41f@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Address review comments
 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Add null check on Buffer::checkState
 - Add docs
   Simplify liveness check in Buffer
   Drop redundant import in DirectBuffer
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
   Improve direct buffer code with isImplicit predicate
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - ... and 6 more: https://git.openjdk.org/jdk/compare/13d4ddc3...b1a494e4

-------------

Changes: https://git.openjdk.org/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9017&range=03
  Stats: 1751 lines in 39 files changed: 407 ins; 525 del; 819 mod
  Patch: https://git.openjdk.org/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9017/head:pull/9017

PR: https://git.openjdk.org/jdk/pull/9017

From mcimadamore at openjdk.java.net  Wed Jun 15 18:01:08 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 18:01:08 GMT
Subject: Withdrawn: 8287809: Revisit implementation of memory session
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <68QEAhgjPyyQCGZ7bKIm4b_sNlrxfpUWblsB5miSHy8=.22c49980-caba-4fd0-87a9-851ee63dadfd@github.com>

On Fri, 3 Jun 2022 15:47:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9017

From mcimadamore at openjdk.java.net  Wed Jun 15 18:16:21 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 18:16:21 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
Message-ID: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>

This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

-------------

Commit messages:
 - Add missing files
 - Initial push

Changes: https://git.openjdk.org/jdk19/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287809
  Stats: 1751 lines in 39 files changed: 407 ins; 525 del; 819 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From turbanoff at gmail.com  Wed Jun 15 18:58:10 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Wed, 15 Jun 2022 21:58:10 +0300
Subject: ProcessHandleImpl.STARTTIME_PROCESS_UNKNOWN and
 STARTTIME_PROCESS_UNKNOWN
Message-ID: <CAF+DQ5cfC+qHGnRAmHGqcYhY1piTcRqTR7qQj=x891RwpiQHsw@mail.gmail.com>

Hello.
I recently found a couple of unused constants in
java.lang.ProcessHandleImpl class.
They seem to serve only documentation purposes. I'm I right?
If so, I think it's better to remove them or at least make them static.


/* The start time should match any value.
 * Typically, this is because the OS can not supply it.
 * The process is known to exist but not the exact start time.
 */
private final long STARTTIME_ANY = 0L;

/* The start time of a Process that does not exist. */
private final long STARTTIME_PROCESS_UNKNOWN = -1;


Andrey Turbanov

From alanb at openjdk.java.net  Wed Jun 15 19:10:04 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 15 Jun 2022 19:10:04 GMT
Subject: RFR: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec
In-Reply-To: <3Wz6m66_gkZ4-u268K-AuVrVuInw7FtydqIugurCUbE=.96082836-2ab5-461c-a640-9f22c6a0b136@github.com>
References: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com>
 <3Wz6m66_gkZ4-u268K-AuVrVuInw7FtydqIugurCUbE=.96082836-2ab5-461c-a640-9f22c6a0b136@github.com>
Message-ID: <O3Cd_NdBfJVYv_d-NulH4B_8cxu4uYOd8-C9-gUvoVU=.6aee03c4-9895-46fb-aa0b-fc55bec0dee4@github.com>

On Tue, 14 Jun 2022 12:19:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @AlanBateman sorry I missed your statement "although these updates aren't strictly needed".

Right, I decided it would be better to just update them rather than leaving them at _10. For the management agent then JNI_OnLoad returning any supported version will do as we build/test is separating to the rest of the JDK. Same thing for the tests. Someone back porting changes might have to adjust of course but the isn't important here.

-------------

PR: https://git.openjdk.org/jdk19/pull/7

From psandoz at openjdk.java.net  Wed Jun 15 19:25:08 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 15 Jun 2022 19:25:08 GMT
Subject: Integrated: 8288414: Long::compress/expand samples are not correct
In-Reply-To: <inryWpZqGS0MQwWq8MkctrVl80HbaqUZQkYNmn-wG5c=.2db4b6b1-0c83-4d82-b661-eab9df9e2c53@github.com>
References: <inryWpZqGS0MQwWq8MkctrVl80HbaqUZQkYNmn-wG5c=.2db4b6b1-0c83-4d82-b661-eab9df9e2c53@github.com>
Message-ID: <qQu3GNqwgsH_Ih427CM-ATWXoUBaaFwpH3HZ_53Qujs=.cf255c0f-0477-43f8-a665-bad71adb9f59@github.com>

On Tue, 14 Jun 2022 16:28:37 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Update the code examples in the api notes of Long::compress/expand. Some constants need to be explicitly long values.

This pull request has now been integrated.

Changeset: 395aea30
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/395aea307faa96bf78ddc15798ba7d855c2db170
Stats:     10 lines in 1 file changed: 0 ins; 0 del; 10 mod

8288414: Long::compress/expand samples are not correct

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk19/pull/14

From roger.riggs at oracle.com  Wed Jun 15 19:34:14 2022
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 15 Jun 2022 15:34:14 -0400
Subject: ProcessHandleImpl.STARTTIME_PROCESS_UNKNOWN and
 STARTTIME_PROCESS_UNKNOWN
In-Reply-To: <CAF+DQ5cfC+qHGnRAmHGqcYhY1piTcRqTR7qQj=x891RwpiQHsw@mail.gmail.com>
References: <CAF+DQ5cfC+qHGnRAmHGqcYhY1piTcRqTR7qQj=x891RwpiQHsw@mail.gmail.com>
Message-ID: <760d3b65-db8a-0bba-ff0e-db4f7c808679@oracle.com>

Hi,

They are useful as documentation on the interface to native, making them 
static would be constructive.

Thanks, Roger


On 6/15/22 2:58 PM, Andrey Turbanov wrote:
> Hello.
> I recently found a couple of unused constants in
> java.lang.ProcessHandleImpl class.
> They seem to serve only documentation purposes. I'm I right?
> If so, I think it's better to remove them or at least make them static.
>
>
> /* The start time should match any value.
>   * Typically, this is because the OS can not supply it.
>   * The process is known to exist but not the exact start time.
>   */
> private final long STARTTIME_ANY = 0L;
>
> /* The start time of a Process that does not exist. */
> private final long STARTTIME_PROCESS_UNKNOWN = -1;
>
>
> Andrey Turbanov


From redestad at openjdk.java.net  Wed Jun 15 19:51:29 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 15 Jun 2022 19:51:29 GMT
Subject: RFR: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
References: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
Message-ID: <v_uymMXM04aG_X5NQUa3P8j0yDKnP0URkYZc5rCy0-0=.19c0f5ae-f95b-4bf4-b358-66177b160268@github.com>

On Tue, 14 Jun 2022 15:16:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Avoid doing MH creation when initializing `StringConcatFactory` by lazily initializing to a `@Stable` field instead.

Thanks for reviewing!

-------------

PR: https://git.openjdk.org/jdk/pull/9154

From redestad at openjdk.java.net  Wed Jun 15 19:51:30 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 15 Jun 2022 19:51:30 GMT
Subject: Integrated: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
References: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
Message-ID: <XCjvpDuK0DHWYL8oBtme3dQ3VrCT0DJzEfcnSPPiSz0=.20613e3f-c735-4405-815a-3875d578a1da@github.com>

On Tue, 14 Jun 2022 15:16:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Avoid doing MH creation when initializing `StringConcatFactory` by lazily initializing to a `@Stable` field instead.

This pull request has now been integrated.

Changeset: 6d595614
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6d595614a26ebe579268dc8216344dfb099bb3ad
Stats:     11 lines in 1 file changed: 7 ins; 0 del; 4 mod

8288425: Footprint regression due MH creation when initializing StringConcatFactory

Reviewed-by: jvernee, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/9154

From mcimadamore at openjdk.java.net  Wed Jun 15 21:31:45 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 21:31:45 GMT
Subject: RFR: 8288534: Out of bound errors for memory segment access mentions
 wrong values
Message-ID: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>

While playing with the API, I've realized that some of the out of bound error messgaes come out incorrectly.

This is because the bound check is performed as follows (to avoid overflow):


Objects.checkIndex(offset, this.length - length + 1);


So, if out-of-bounds access is detected, the resulting exception mentions the values of the first and second parameter, respectively - but since the second parameter is the result of a subtraction, it doesn't make sense.

The solution is not to use `Objects.checkIndex` directly, but, instead, drop down one level, and pass our own "IOOB formatter":


Preconditions.checkIndex(offset, this.length - length + 1, this);


Note that, in order to recover the correct values, the formatter needs to know the segment size - so I made `AbstractMemorySegment` act as a formatter (so we don't need to allocate in such a hot path).

The fix seems to bring back the desired messages - but I would like some confirmation that doing this won't disrupt intrinsification of the `checkIndex` method.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk19/pull/24/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=24&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288534
  Stats: 24 lines in 2 files changed: 21 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk19/pull/24.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/24/head:pull/24

PR: https://git.openjdk.org/jdk19/pull/24

From mcimadamore at openjdk.java.net  Wed Jun 15 21:34:08 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 21:34:08 GMT
Subject: RFR: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
References: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
Message-ID: <zvAtneuavOHzKdXMK3X0dIcSo-6k30-IVMeO08TUE04=.8fa02664-2cba-4562-9d56-2952fb217abd@github.com>

On Tue, 14 Jun 2022 15:16:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Avoid doing MH creation when initializing `StringConcatFactory` by lazily initializing to a `@Stable` field instead.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 729:

> 727:         MethodHandle base = PREPEND_BASE;
> 728:         if (base == null) {
> 729:             base = PREPEND_BASE = MethodHandles.dropArguments(

I'm curious about this idiom - couldn't this result in the `PREPEND_BASE` field being assigned twice, with objects that are morally identical, but could have different identities? (thus violating `@Stable` contract)

-------------

PR: https://git.openjdk.org/jdk/pull/9154

From psandoz at openjdk.java.net  Wed Jun 15 22:04:02 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 15 Jun 2022 22:04:02 GMT
Subject: RFR: 8288534: Out of bound errors for memory segment access
 mentions wrong values
In-Reply-To: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
References: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
Message-ID: <M4Wcvxnl5eTZ6K55-0aTtgGWHFqOPkgm5gO-8RGrQEc=.bbc686c4-b132-4f63-a977-f259b92561a5@github.com>

On Wed, 15 Jun 2022 21:24:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> While playing with the API, I've realized that some of the out of bound error messgaes come out incorrectly.
> 
> This is because the bound check is performed as follows (to avoid overflow):
> 
> 
> Objects.checkIndex(offset, this.length - length + 1);
> 
> 
> So, if out-of-bounds access is detected, the resulting exception mentions the values of the first and second parameter, respectively - but since the second parameter is the result of a subtraction, it doesn't make sense.
> 
> The solution is not to use `Objects.checkIndex` directly, but, instead, drop down one level, and pass our own "IOOB formatter":
> 
> 
> Preconditions.checkIndex(offset, this.length - length + 1, this);
> 
> 
> Note that, in order to recover the correct values, the formatter needs to know the segment size - so I made `AbstractMemorySegment` act as a formatter (so we don't need to allocate in such a hot path).
> 
> The fix seems to bring back the desired messages - but I would like some confirmation that doing this won't disrupt intrinsification of the `checkIndex` method.

I would expect passing an non-constant exception mapper should work. The C2 intrinsic never accesses the exception mapper argument, and a range check failure results in a deoptimzation back to the interpreter from which the exception mapper is then operated on. However, i think its worth just double checking generated code.

-------------

PR: https://git.openjdk.org/jdk19/pull/24

From jvernee at openjdk.java.net  Wed Jun 15 22:30:09 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 22:30:09 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <U4NNFOHiB-6BybfOYNa3eluBB_n05D2jZlLgjcx9G-4=.f929fc9d-2990-474d-81c4-ebdad836bb5a@github.com>

On Wed, 15 Jun 2022 18:06:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

Already reviewed in the mainline repo.

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/22

From psandoz at openjdk.java.net  Wed Jun 15 22:48:04 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 15 Jun 2022 22:48:04 GMT
Subject: RFR: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <zvAtneuavOHzKdXMK3X0dIcSo-6k30-IVMeO08TUE04=.8fa02664-2cba-4562-9d56-2952fb217abd@github.com>
References: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
 <zvAtneuavOHzKdXMK3X0dIcSo-6k30-IVMeO08TUE04=.8fa02664-2cba-4562-9d56-2952fb217abd@github.com>
Message-ID: <TLutjsajZh3_DZI7C0xX-8yLrAPCUf6dSKlS_Ypi4C0=.fe298014-0f53-4b7f-85cc-4823bbe83603@github.com>

On Wed, 15 Jun 2022 21:30:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Avoid doing MH creation when initializing `StringConcatFactory` by lazily initializing to a `@Stable` field instead.
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 729:
> 
>> 727:         MethodHandle base = PREPEND_BASE;
>> 728:         if (base == null) {
>> 729:             base = PREPEND_BASE = MethodHandles.dropArguments(
> 
> I'm curious about this idiom - couldn't this result in the `PREPEND_BASE` field being assigned twice, with objects that are morally identical, but could have different identities? (thus violating `@Stable` contract)

It's not a violation, it's relying on behavior not discussed by the `@Stable` doc, which refers to such behavior as "undefined".

It's a carefully correlated dance between the code, interpreter, and C2 relying on:
1. safe publication of equivalent immutable structures with no dependence on their identity when operating on them;
2. the field being set in the interpreter; and 
3. by the time C2 inlines `prependBase` the field is no longer be updated, thus C2 can replace the field access with its value.

-------------

PR: https://git.openjdk.org/jdk/pull/9154

From asemenyuk at openjdk.java.net  Thu Jun 16 05:22:24 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 16 Jun 2022 05:22:24 GMT
Subject: RFR: 8287401: jpackage tests failing on Windows due to powershell
 issue
Message-ID: <QVnHMii8QFEZYYElJPluwcNurKRyGoAna_vShzSfnCU=.1b983d80-6b0d-41dd-a76b-f04ca46249b4@github.com>

Run a script extracting icons from executables as PowerShell command line rather than a script

-------------

Commit messages:
 - 8287401: jpackage tests failing on Windows due to powershell issue

Changes: https://git.openjdk.org/jdk19/pull/26/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=26&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287401
  Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk19/pull/26.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/26/head:pull/26

PR: https://git.openjdk.org/jdk19/pull/26

From darcy at openjdk.java.net  Thu Jun 16 06:18:50 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 16 Jun 2022 06:18:50 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v27]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <cxU8VqlgkHli1NeJREwx3K7CZOGyo2EHJs-kruhlIGI=.e95c241c-eebc-41c1-9cf3-94afec84acca@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 41 additional commits since the last revision:

 - Expand regression tests.
 - Merge branch 'master' into JDK-8266670
 - Respond to review feedback from Roger Riggs.
 - Respond to review feedback.
 - Make mask fields final in ModuleDescriptor.
 - Correct STATIC vs STATIC_PHASE issue found in code review.
 - From review feedback, use package-private contstants in Modifier.
 - Update to use @value tag.
 - Merge branch 'master' into JDK-8266670
 - Target JDK 20 rather than 19.
 - ... and 31 more: https://git.openjdk.org/jdk/compare/5cdc1369...9395cfd5

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/3e4a1edf..9395cfd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=25-26

  Stats: 6059 lines in 97 files changed: 3449 ins; 2406 del; 204 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.java.net  Thu Jun 16 06:27:59 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 16 Jun 2022 06:27:59 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v28]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <8UJPLRHzoFyNPDMQdt6EgtG9Ovvbt5Vy7X-IOOz9ss8=.6fb9da4a-ac51-458c-9f13-48fc90c006ee@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Appease jcheck.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/9395cfd5..ebb01e1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=26-27

  Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From jwilhelm at openjdk.java.net  Thu Jun 16 07:09:00 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 16 Jun 2022 07:09:00 GMT
Subject: RFR: Merge jdk19
Message-ID: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8288533: Missing @param tags in com.sun.source classes
 - 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64
 - 8288414: Long::compress/expand samples are not correct
 - 8288289: Preview APIs in jdk.jdi, jdk.management, and jdk.jfr should be reflective preview APIs
 - 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
 - 8288360: CI: ciInstanceKlass::implementor() is not consistent for well-known classes
 - 8287889: (fs) Files.copy description of REPLACE_EXISTING is hard to read
 - 8288303: C1: Miscompilation due to broken Class.getModifiers intrinsic
 - 8288214: serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java test failed
 - ... and 1 more: https://git.openjdk.org/jdk/compare/39526e28...8b43a607

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9179&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9179&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9179/files
  Stats: 254 lines in 17 files changed: 193 ins; 13 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/9179.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9179/head:pull/9179

PR: https://git.openjdk.org/jdk/pull/9179

From jkuhn at openjdk.java.net  Thu Jun 16 07:31:35 2022
From: jkuhn at openjdk.java.net (Johannes Kuhn)
Date: Thu, 16 Jun 2022 07:31:35 GMT
Subject: RFR: JDK-8288475: Initializing RandomGeneratorFactory.FactoryMapHolder
 fails if a SecurityManager is installed
Message-ID: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>

* This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
* The annotations of the provider classes are now parsed early.  
  This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
* If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
  This avoids parsing annotations of user classes from a privileged context.

-------------

Commit messages:
 - Fix line endings
 - Initial fix

Changes: https://git.openjdk.org/jdk/pull/9180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9180&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288475
  Stats: 70 lines in 4 files changed: 65 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9180.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9180/head:pull/9180

PR: https://git.openjdk.org/jdk/pull/9180

From shade at openjdk.java.net  Thu Jun 16 08:16:42 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 16 Jun 2022 08:16:42 GMT
Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java
 fails with various GCs
Message-ID: <zNNFS3Kz9VfMsbouO2UM6q-yaVA20ZyPQrXvGuuqTjw=.633cd832-b2aa-4be3-ad76-0954998b9bd0@github.com>

Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails:


$ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC"

test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success
test ObjectStreamClassCaching.testCachingEffectiveness(): failure
java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertFalse(Assert.java:67)


I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while.

Additional testing:
 - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions
 - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions
 - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions
 - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions
 - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk19/pull/27/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=27&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283276
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk19/pull/27.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/27/head:pull/27

PR: https://git.openjdk.org/jdk19/pull/27

From duke at openjdk.java.net  Thu Jun 16 08:24:20 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Thu, 16 Jun 2022 08:24:20 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v25]
In-Reply-To: <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>
Message-ID: <bpXITJ93BrFU9tKLzc7oZeuoIGffAR42nhnzL0DkW3A=.c076b4d4-03bf-438a-9b02-43790aeef6f8@github.com>

On Tue, 14 Jun 2022 02:32:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

src/java.base/share/classes/java/lang/reflect/Member.java line 92:

> 90:      * @implSpec
> 91:      * The default implementation returns throws {@link
> 92:      * UnsupportedOperationException}.

Typo:
Suggestion:

     * The default implementation throws {@link UnsupportedOperationException}.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From mcimadamore at openjdk.org  Thu Jun 16 09:55:19 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Jun 2022 09:55:19 GMT
Subject: RFR: 8288534: Out of bound errors for memory segment access
 mentions wrong values
In-Reply-To: <M4Wcvxnl5eTZ6K55-0aTtgGWHFqOPkgm5gO-8RGrQEc=.bbc686c4-b132-4f63-a977-f259b92561a5@github.com>
References: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
 <M4Wcvxnl5eTZ6K55-0aTtgGWHFqOPkgm5gO-8RGrQEc=.bbc686c4-b132-4f63-a977-f259b92561a5@github.com>
Message-ID: <s44u8uVXlI0frwZSBH6ObJlPfxGSikot6l0nf_QqxRQ=.48406303-bd1f-43a0-91f1-dcd69e7bfd59@github.com>

On Wed, 15 Jun 2022 22:00:22 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I would expect passing an non-constant exception mapper should work. The C2 intrinsic never accesses the exception mapper argument, and a range check failure results in a deoptimzation back to the interpreter from which the exception mapper is then operated on. However, i think its worth just double checking generated code.

Both @iwanowww and @rwestrel have confirmed that that should be indeed the case. I did some test with PrintInlining with seemed to show the method as correctly inlined. For extra safety I will run all memory access benchmarks, and compare before/after.

-------------

PR: https://git.openjdk.org/jdk19/pull/24

From mcimadamore at openjdk.org  Thu Jun 16 10:35:14 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Jun 2022 10:35:14 GMT
Subject: RFR: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <TLutjsajZh3_DZI7C0xX-8yLrAPCUf6dSKlS_Ypi4C0=.fe298014-0f53-4b7f-85cc-4823bbe83603@github.com>
References: <zSYITyHoMeMLQPT1rvr6MwJIHuCiS_xs_7cIJOKJrGw=.dda965b1-423c-45e4-800b-8a35bb51645c@github.com>
 <zvAtneuavOHzKdXMK3X0dIcSo-6k30-IVMeO08TUE04=.8fa02664-2cba-4562-9d56-2952fb217abd@github.com>
 <TLutjsajZh3_DZI7C0xX-8yLrAPCUf6dSKlS_Ypi4C0=.fe298014-0f53-4b7f-85cc-4823bbe83603@github.com>
Message-ID: <uCTfVpf-ndP1etEnTsSek0IwYCnj1_iwp0I_KhQIar0=.d371a9db-28a9-45df-a352-1beb91348cda@github.com>

On Wed, 15 Jun 2022 22:43:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 729:
>> 
>>> 727:         MethodHandle base = PREPEND_BASE;
>>> 728:         if (base == null) {
>>> 729:             base = PREPEND_BASE = MethodHandles.dropArguments(
>> 
>> I'm curious about this idiom - couldn't this result in the `PREPEND_BASE` field being assigned twice, with objects that are morally identical, but could have different identities? (thus violating `@Stable` contract)
>
> It's not a violation, it's relying on behavior not discussed by the `@Stable` doc, which refers to such behavior as "undefined".
> 
> It's a carefully correlated dance between the code, interpreter, and C2 relying on:
> 1. safe publication of equivalent immutable structures with no dependence on their identity when operating on them;
> 2. the field being set in the interpreter; and 
> 3. by the time C2 inlines `prependBase` the field is no longer be updated, thus C2 can replace the field access with its value.

Thanks, I think I was missing (2)

-------------

PR: https://git.openjdk.org/jdk/pull/9154

From jwilhelm at openjdk.org  Thu Jun 16 12:05:20 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 16 Jun 2022 12:05:20 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>
References: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>
Message-ID: <jE5ZH0NidXVkm_bPpXtl0UPI_FXUl9NK5fQyfDq6Cvg=.57654ad5-3d0b-4019-a178-2777c19d9611@github.com>

On Thu, 16 Jun 2022 07:00:53 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 3d12c022
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d12c0225b31bb359bec70aac6befd879cd0c934
Stats:     254 lines in 17 files changed: 193 ins; 13 del; 48 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9179

From mcimadamore at openjdk.org  Thu Jun 16 12:16:19 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Jun 2022 12:16:19 GMT
Subject: RFR: 8288534: Out of bound errors for memory segment access
 mentions wrong values [v2]
In-Reply-To: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
References: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
Message-ID: <9zR5CCYdsCsR6MdKMjeHuSbHgnj6lU7g46gVBlU98ek=.53f88f7a-4fa1-4144-bb4c-a1aa54255f30@github.com>

> While playing with the API, I've realized that some of the out of bound error messgaes come out incorrectly.
> 
> This is because the bound check is performed as follows (to avoid overflow):
> 
> 
> Objects.checkIndex(offset, this.length - length + 1);
> 
> 
> So, if out-of-bounds access is detected, the resulting exception mentions the values of the first and second parameter, respectively - but since the second parameter is the result of a subtraction, it doesn't make sense.
> 
> The solution is not to use `Objects.checkIndex` directly, but, instead, drop down one level, and pass our own "IOOB formatter":
> 
> 
> Preconditions.checkIndex(offset, this.length - length + 1, this);
> 
> 
> Note that, in order to recover the correct values, the formatter needs to know the segment size - so I made `AbstractMemorySegment` act as a formatter (so we don't need to allocate in such a hot path).
> 
> The fix seems to bring back the desired messages - but I would like some confirmation that doing this won't disrupt intrinsification of the `checkIndex` method.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add @ForceInline on AbstractLayout::byteSize

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/24/files
  - new: https://git.openjdk.org/jdk19/pull/24/files/ebbc356c..8b15d0fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=24&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=24&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk19/pull/24.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/24/head:pull/24

PR: https://git.openjdk.org/jdk19/pull/24

From mcimadamore at openjdk.org  Thu Jun 16 12:16:20 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Jun 2022 12:16:20 GMT
Subject: RFR: 8288534: Out of bound errors for memory segment access
 mentions wrong values
In-Reply-To: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
References: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
Message-ID: <TprhS-VB_uRzBWgFfW-6G4G1DelC0u3YGAkr17m4ODQ=.79f6f7b7-adef-44c7-8878-e53e66aa3ffc@github.com>

On Wed, 15 Jun 2022 21:24:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> While playing with the API, I've realized that some of the out of bound error messgaes come out incorrectly.
> 
> This is because the bound check is performed as follows (to avoid overflow):
> 
> 
> Objects.checkIndex(offset, this.length - length + 1);
> 
> 
> So, if out-of-bounds access is detected, the resulting exception mentions the values of the first and second parameter, respectively - but since the second parameter is the result of a subtraction, it doesn't make sense.
> 
> The solution is not to use `Objects.checkIndex` directly, but, instead, drop down one level, and pass our own "IOOB formatter":
> 
> 
> Preconditions.checkIndex(offset, this.length - length + 1, this);
> 
> 
> Note that, in order to recover the correct values, the formatter needs to know the segment size - so I made `AbstractMemorySegment` act as a formatter (so we don't need to allocate in such a hot path).
> 
> The fix seems to bring back the desired messages - but I would like some confirmation that doing this won't disrupt intrinsification of the `checkIndex` method.

Benchmarks looks all good except UnrolledAccess::handle_loop_instance. A quick PrintInlining revealed a missed inlining for `MemoryLayout.byteSize` which is called by `MemorySegment::getAtIndex`. This is an issue I spotted in the past, so we might just fix it now.

-------------

PR: https://git.openjdk.org/jdk19/pull/24

From david.holmes at oracle.com  Thu Jun 16 13:16:43 2022
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Jun 2022 23:16:43 +1000
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <CAA-vtUzWCUjFCKhD8tQow8PFm1ugG8hse6U072vRtMEJ9XUpag@mail.gmail.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
 <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
 <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
 <be5d1b98-3fc9-5383-9513-762160fe43a1@oracle.com>
 <CAA-vtUzWCUjFCKhD8tQow8PFm1ugG8hse6U072vRtMEJ9XUpag@mail.gmail.com>
Message-ID: <2014aec0-945b-a311-6fd7-46dad4899b00@oracle.com>

On 16/06/2022 12:09 am, Thomas St?fe wrote:
> On Wed 15. Jun 2022 at 15:06, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 15/06/2022 8:45 pm, Thomas St?fe wrote:
>      > More specifically, I propose to gracefully ignore SIGUSR2 in release
>      > builds if the receiving thread is not a java thread, but to
>     retain the
>      > assert in debug builds.
>      >
>      > We could make it more involved by checking the sender pid and
>     accepting
>      > only signals from hotspot?threads themselves, but I do not think
>     this
>      > complexity is necessary.
> 
>     Nor do I. SIGUSR2 is reserved for use by the VM and we document
>     that. If
>     you start throwing around random signals at processes then they can
>     crash - so don't do that. I'm not sure ignoring signals that shouldn't
>     be raised actually aids the end-user who obviously has an issue in
>     their
>     environment that needs to be addressed.
> 
> 
> I see your point. I dislike crashes, especially ones they can be 
> reliably triggered from outside. You never can be sure about the 
> security implications either.
> 
> If you dislike ignoring the signal, and since the default action for 
> SIGUSR1+2 is process termination, why not exit the VM with an error 
> message instead? At least we don?t have what looks like a random 
> segfault, and we could print out the sender pid ?too.

We could ... but then do we do that for every other signal that can be 
thrown at the JVM from externally and which will leads to crashes? Where 
do you stop?

David
-----

> 
> 
>      ?>? ? ? ? ?I mean, isn't JVM supposed to be safe? :)
> 
>     Not when it comes to native code and signals - there it is more a case
>     of caveat emptor.
> 
>     Cheers,
>     David
>     -----
> 
>      > Cheers, Thomas
>      >
>      > On Wed, Jun 15, 2022 at 12:26 PM Thomas St?fe
>     <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>
>      > <mailto:thomas.stuefe at gmail.com
>     <mailto:thomas.stuefe at gmail.com>>> wrote:
>      >
>      >? ? ?SIGUSR2 is used by the hotspot, internally, to implement
>      >? ? ?suspend/resume. It gets sent by hotspot via pthread_kill() to
>      >? ? ?targeted threads to suspend them. In that case it is known
>     that the
>      >? ? ?receiving thread is a valid java thread and therefore the assert
>      >? ? ?makes sense.
>      >
>      >? ? ?However, as you describe SIGUSR2 can also be sent from
>     outside via
>      >? ? ?kill(2). In that case the receiving thread is arbitrarily
>     chosen by
>      >? ? ?the kernel. It is not necessarily a valid java thread. In
>     that case
>      >? ? ?the VM will crash (release) or assert (debug).
>      >
>      >? ? ?I tend to think this is an error too. Or at least in grey area.
>      >? ? ?Since this is very easy to fix in the hotspot, I'd suggest we
>     do this.
>      >
>      >? ? ?If nobody objects, I can file an issue and prepare the patch.
>      >
>      >? ? ?Cheers, Thomas
>      >
>      >? ? ?(P.s. not C++ undefined behavior, nothing to do with C++ :-)
>      >
>      >? ? ?On Wed, Jun 15, 2022 at 12:11 PM Andrey Turbanov
>      >? ? ?<turbanoff at gmail.com <mailto:turbanoff at gmail.com>
>     <mailto:turbanoff at gmail.com <mailto:turbanoff at gmail.com>>> wrote:
>      >
>      >? ? ? ? ?I mean, isn't JVM supposed to be safe? :)
>      >? ? ? ? ?Receiving this signal _could_ happen in a real
>     deployment. And
>      >? ? ? ? ?now, as
>      >? ? ? ? ?I can see, we have C++ undefined behaviour in release
>     builds in this
>      >? ? ? ? ?case. Can we consider this as a bug?
>      >
>      >? ? ? ? ?Andrey Turbanov
>      >
>      >? ? ? ? ???, 14 ???. 2022 ?. ? 14:46, Alan Bateman
>      >? ? ? ? ?<Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>
>     <mailto:Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>>:
>      >? ? ? ? ? >
>      >? ? ? ? ? > On 14/06/2022 10:44, Andrey Turbanov wrote:
>      >? ? ? ? ? > > Hello.
>      >? ? ? ? ? > > During investigation of signal handling in JVM (for
>      >? ? ? ? ? > >
>      > https://github.com/openjdk/jdk/pull/9100#discussion_r894992558
>     <https://github.com/openjdk/jdk/pull/9100#discussion_r894992558>
>      >       
>      ?<https://github.com/openjdk/jdk/pull/9100#discussion_r894992558
>     <https://github.com/openjdk/jdk/pull/9100#discussion_r894992558>> )
>      >? ? ? ? ? > > I found out that sending USR2 crashes my JDK. (Linux
>      >? ? ? ? ?fastdebug x64)
>      >? ? ? ? ? > >
>      >? ? ? ? ? > > kill -USR2 1346792
>      >? ? ? ? ? > >
>      >? ? ? ? ? > > # assert(thread != __null) failed: Missing current
>     thread
>      >? ? ? ? ?in SR_handler
>      >? ? ? ? ? > > # Internal Error
>      >? ? ? ? ? > >
>      >       
>      ?(/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
>      >? ? ? ? ? > > pid=1346792, tid=1346792
>      >? ? ? ? ? > >
>      >? ? ? ? ? > > Full hs_err_pid1346792.log:
>      >? ? ? ? ? > >
>      >
>     https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
>     <https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a>
>      >       
>      ?<https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a <https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a>>
>      >? ? ? ? ? > >
>      >? ? ? ? ? > >
>      >? ? ? ? ? > > Is it known/expected behaviour?
>      >? ? ? ? ? > > I found some description there
>      >? ? ? ? ? > >
>      >
>     https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
>     <https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html>
>      >       
>      ?<https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html <https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html>>
>      >? ? ? ? ? > > that USR2 is used for SUSPEND/RESUME. Is it supported by
>      >? ? ? ? ?Hotspot?
>      >? ? ? ? ? >
>      >? ? ? ? ? > In general you have to be very careful when using signals.
>      >? ? ? ? ?Yes, it can
>      >? ? ? ? ? > easily break things and probably notice it quickly
>     with debug
>      >? ? ? ? ?builds as
>      >? ? ? ? ? > asserts are compiled in to the builds (like the
>     above). So I
>      >? ? ? ? ?think
>      >? ? ? ? ? > you've found the right page to read up on this. In
>     this case,
>      >? ? ? ? ?you can
>      >? ? ? ? ? > set _JAVA_SR_SIGNUM to specify a different signal for S/R.
>      >? ? ? ? ? >
>      >? ? ? ? ? > -Alan
>      >
> 

From david.lloyd at redhat.com  Thu Jun 16 13:53:42 2022
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 16 Jun 2022 08:53:42 -0500
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <2014aec0-945b-a311-6fd7-46dad4899b00@oracle.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
 <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
 <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
 <be5d1b98-3fc9-5383-9513-762160fe43a1@oracle.com>
 <CAA-vtUzWCUjFCKhD8tQow8PFm1ugG8hse6U072vRtMEJ9XUpag@mail.gmail.com>
 <2014aec0-945b-a311-6fd7-46dad4899b00@oracle.com>
Message-ID: <CANghgrSNrBAkbg_z3=-_pqSXQ4--QR_PAYxha9xT0D5G+3AxVg@mail.gmail.com>

On Thu, Jun 16, 2022 at 8:17 AM David Holmes <david.holmes at oracle.com> wrote:
> On 16/06/2022 12:09 am, Thomas St?fe wrote:
> > On Wed 15. Jun 2022 at 15:06, David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>> wrote:
> >     Nor do I. SIGUSR2 is reserved for use by the VM and we document
> >     that. If
> >     you start throwing around random signals at processes then they can
> >     crash - so don't do that. I'm not sure ignoring signals that shouldn't
> >     be raised actually aids the end-user who obviously has an issue in
> >     their
> >     environment that needs to be addressed.
> >
> >
> > I see your point. I dislike crashes, especially ones they can be
> > reliably triggered from outside. You never can be sure about the
> > security implications either.
> >
> > If you dislike ignoring the signal, and since the default action for
> > SIGUSR1+2 is process termination, why not exit the VM with an error
> > message instead? At least we don?t have what looks like a random
> > segfault, and we could print out the sender pid  too.
>
> We could ... but then do we do that for every other signal that can be
> thrown at the JVM from externally and which will leads to crashes? Where
> do you stop?

Well, playing devil's advocate, why not? Would it be more complex than adding a

    if (si.si_pid != my_cached_pid) {
        // it came from Outside, let's exit with 128+signum
        // ...
    }

to the top of the signal handler(s)?

-- 
- DML ? he/him


From asotona at openjdk.org  Thu Jun 16 13:59:07 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 13:59:07 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v11]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <E4j45zg2e_METAHDCb8VB7vBVN3OBZMV9r7kuSY_Ud0=.80634e26-7c57-40c3-b424-104af94c2591@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 5 more: https://git.openjdk.org/jdk/compare/cf4a4966...3314423d

-------------

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=10
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599

From rriggs at openjdk.org  Thu Jun 16 14:37:27 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Jun 2022 14:37:27 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v28]
In-Reply-To: <8UJPLRHzoFyNPDMQdt6EgtG9Ovvbt5Vy7X-IOOz9ss8=.6fb9da4a-ac51-458c-9f13-48fc90c006ee@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <8UJPLRHzoFyNPDMQdt6EgtG9Ovvbt5Vy7X-IOOz9ss8=.6fb9da4a-ac51-458c-9f13-48fc90c006ee@github.com>
Message-ID: <1felaUnNIWIw9vFf0u3OlddDgtFuw-mwneJ5uMoh8Tg=.757b7ab8-62d2-4144-82e1-3aab1dd4c195@github.com>

On Thu, 16 Jun 2022 06:27:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/7445

From psandoz at openjdk.org  Thu Jun 16 15:28:50 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 16 Jun 2022 15:28:50 GMT
Subject: RFR: 8288534: Out of bound errors for memory segment access
 mentions wrong values [v2]
In-Reply-To: <9zR5CCYdsCsR6MdKMjeHuSbHgnj6lU7g46gVBlU98ek=.53f88f7a-4fa1-4144-bb4c-a1aa54255f30@github.com>
References: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
 <9zR5CCYdsCsR6MdKMjeHuSbHgnj6lU7g46gVBlU98ek=.53f88f7a-4fa1-4144-bb4c-a1aa54255f30@github.com>
Message-ID: <OQvxTW91NjTV7dTsUTY9HsnRYkMUP8ZMqcvyyhsiZ9Y=.04f977ce-a377-4484-a225-7c0d09c1880f@github.com>

On Thu, 16 Jun 2022 12:16:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> While playing with the API, I've realized that some of the out of bound error messgaes come out incorrectly.
>> 
>> This is because the bound check is performed as follows (to avoid overflow):
>> 
>> 
>> Objects.checkIndex(offset, this.length - length + 1);
>> 
>> 
>> So, if out-of-bounds access is detected, the resulting exception mentions the values of the first and second parameter, respectively - but since the second parameter is the result of a subtraction, it doesn't make sense.
>> 
>> The solution is not to use `Objects.checkIndex` directly, but, instead, drop down one level, and pass our own "IOOB formatter":
>> 
>> 
>> Preconditions.checkIndex(offset, this.length - length + 1, this);
>> 
>> 
>> Note that, in order to recover the correct values, the formatter needs to know the segment size - so I made `AbstractMemorySegment` act as a formatter (so we don't need to allocate in such a hot path).
>> 
>> The fix seems to bring back the desired messages - but I would like some confirmation that doing this won't disrupt intrinsification of the `checkIndex` method.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ForceInline on AbstractLayout::byteSize

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/24

From asotona at openjdk.org  Thu Jun 16 15:36:45 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 15:36:45 GMT
Subject: RFR: 8288594: Address possibly lossy conversions in java.base
 FloatToDecimal
Message-ID: <pzpkK0ViROXq3MD96mQmFtr1EpwukG2gR9qyij-0zCc=.b927eeea-3f92-430b-81c4-582221425234@github.com>

One new case of possibly lossy conversions recently appeared in jdk.internal.math.FloatToDecimal.
This patch avoids the warning by explicit cast from long to int.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8288594: Address possibly lossy conversions in java.base FloatToDecimal

Changes: https://git.openjdk.org/jdk/pull/9188/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9188&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288594
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9188.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9188/head:pull/9188

PR: https://git.openjdk.org/jdk/pull/9188

From xuelei at openjdk.org  Thu Jun 16 15:55:00 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 16 Jun 2022 15:55:00 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v9]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <Z0OeNFDtTr2kYfv-HpQm0gRj8v2rxWETRUqWrgEWR7M=.f7e01958-6284-493f-9da7-9ecdb12d9e84@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8907__;!!ACWV5N9M2RV99hQ!O6EQBBr1eLb8OEbyuEwKMh9RY8w0cTN82qBpXMXBQJmWU4FI_-rzbvII5bv3Ipb-i52QkFD41RzdjGKH-huJd-w$ ).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  remove trailing whitespaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8979/files
  - new: https://git.openjdk.org/jdk/pull/8979/files/bc51397f..6073acb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.org/jdk/pull/8979

From mcimadamore at openjdk.org  Thu Jun 16 16:04:54 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Jun 2022 16:04:54 GMT
Subject: Integrated: 8288534: Out of bound errors for memory segment access
 mentions wrong values
In-Reply-To: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
References: <3mM1V78ZwmNYxSB51LPWjcM7N9AkGL5eQiQ04m0Y6CQ=.7e00bd1a-5d8a-4999-a484-04dbc053322e@github.com>
Message-ID: <9M4XE1_ZZ-J29OtzCGyvZVpa6vldA14LUqLXJryJbEw=.0059f3ff-5918-4087-9f08-5e073fc51f5d@github.com>

On Wed, 15 Jun 2022 21:24:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> While playing with the API, I've realized that some of the out of bound error messgaes come out incorrectly.
> 
> This is because the bound check is performed as follows (to avoid overflow):
> 
> 
> Objects.checkIndex(offset, this.length - length + 1);
> 
> 
> So, if out-of-bounds access is detected, the resulting exception mentions the values of the first and second parameter, respectively - but since the second parameter is the result of a subtraction, it doesn't make sense.
> 
> The solution is not to use `Objects.checkIndex` directly, but, instead, drop down one level, and pass our own "IOOB formatter":
> 
> 
> Preconditions.checkIndex(offset, this.length - length + 1, this);
> 
> 
> Note that, in order to recover the correct values, the formatter needs to know the segment size - so I made `AbstractMemorySegment` act as a formatter (so we don't need to allocate in such a hot path).
> 
> The fix seems to bring back the desired messages - but I would like some confirmation that doing this won't disrupt intrinsification of the `checkIndex` method.

This pull request has now been integrated.

Changeset: ff3db520
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/ff3db52044f69754b1ccf54961f453d4afbfba3a
Stats:     26 lines in 3 files changed: 23 ins; 0 del; 3 mod

8288534: Out of bound errors for memory segment access mentions wrong values

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk19/pull/24

From rriggs at openjdk.org  Thu Jun 16 16:11:56 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Jun 2022 16:11:56 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v9]
In-Reply-To: <Z0OeNFDtTr2kYfv-HpQm0gRj8v2rxWETRUqWrgEWR7M=.f7e01958-6284-493f-9da7-9ecdb12d9e84@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <Z0OeNFDtTr2kYfv-HpQm0gRj8v2rxWETRUqWrgEWR7M=.f7e01958-6284-493f-9da7-9ecdb12d9e84@github.com>
Message-ID: <STM_EdzJAndHF8f7AXy1Kx3RMOT0IN4rvpjbsDqECb0=.e4a78277-d1ca-494e-855b-5c4b5541a76c@github.com>

On Thu, 16 Jun 2022 15:55:00 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8907__;!!ACWV5N9M2RV99hQ!Je_bf2xNMQS8uv-Y4eVoH4-gQWybzceT5Pe4a5e2fcDHN_WXR-mzH7Mk6ojON_7YmuaXBCbKpPS38vT5nJTiIlU$ ).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing whitespaces

test/jdk/java/io/ObjectStreamClass/TestOSCClassLoaderLeak.java line 64:

> 62:         assertNotNull(myOwnClassLoaderWeakReference.get());
> 63: 
> 64:         assertTrue(ForceGC.wait(() -> myOwnClassLoaderWeakReference.get() == null));

The call to ref.get() can create a strong reference to the object; depending on the timing it might interfere with the GC in process.
`ref.refersTo(null)` is preferred over `ref.get() == null` 

Here and all subsequent changes.

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From rriggs at openjdk.org  Thu Jun 16 16:12:46 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Jun 2022 16:12:46 GMT
Subject: RFR: 8288594: Address possibly lossy conversions in java.base
 FloatToDecimal
In-Reply-To: <pzpkK0ViROXq3MD96mQmFtr1EpwukG2gR9qyij-0zCc=.b927eeea-3f92-430b-81c4-582221425234@github.com>
References: <pzpkK0ViROXq3MD96mQmFtr1EpwukG2gR9qyij-0zCc=.b927eeea-3f92-430b-81c4-582221425234@github.com>
Message-ID: <GBrD6_bUftskm4PZ_dMM8WXGpsvkatFx6q5nNSC_9Vs=.f4ee90f9-327f-4712-8259-f298c34c60af@github.com>

On Thu, 16 Jun 2022 15:26:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> One new case of possibly lossy conversions recently appeared in jdk.internal.math.FloatToDecimal.
> This patch avoids the warning by explicit cast from long to int.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9188

From asotona at openjdk.org  Thu Jun 16 17:01:53 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 17:01:53 GMT
Subject: Integrated: 8288594: Address possibly lossy conversions in java.base
 FloatToDecimal
In-Reply-To: <pzpkK0ViROXq3MD96mQmFtr1EpwukG2gR9qyij-0zCc=.b927eeea-3f92-430b-81c4-582221425234@github.com>
References: <pzpkK0ViROXq3MD96mQmFtr1EpwukG2gR9qyij-0zCc=.b927eeea-3f92-430b-81c4-582221425234@github.com>
Message-ID: <oxFIOG61jZ7VahGZ0YKuMdeXj_2cig_g-4rOa1sb98s=.370d77c9-2e75-40e7-82f5-698b4acb3496@github.com>

On Thu, 16 Jun 2022 15:26:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> One new case of possibly lossy conversions recently appeared in jdk.internal.math.FloatToDecimal.
> This patch avoids the warning by explicit cast from long to int.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: e7d52e25
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7d52e25a273a534c3195ea58745fd4a34963454
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288594: Address possibly lossy conversions in java.base FloatToDecimal

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/9188

From asotona at openjdk.org  Thu Jun 16 17:05:17 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 17:05:17 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v12]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <3FVbsCyO8Uhv_P47AQJRdjzXy-Vrd3bD1-ReNIZ7jBI=.f4b29583-4211-4027-90b1-f7e133ff56ea@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - ... and 6 more: https://git.openjdk.org/jdk/compare/e7d52e25...1b2d663d

-------------

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=11
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599

From aturbanov at openjdk.org  Thu Jun 16 17:33:48 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 16 Jun 2022 17:33:48 GMT
Subject: Integrated: 8285519: Change usages of TimeUnit.convert to
 TimeUnit.toXXX
In-Reply-To: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
References: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
Message-ID: <G4kUylmuwgF-aleWY5MnVvtcras8GXGv2RVAVyZYKzU=.712f527f-a7d2-4fab-a9a9-11ee32ef539b@github.com>

On Sat, 23 Apr 2022 21:02:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
> Compared via JMH benchmark: 150ns -> 125ns/op
> <details>
> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>
> 
> 
> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class TimeUnitBench {
> 
>     static final int SIZE = TimeUnit.values().length * 10;
> 
>     @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>     int bias;
> 
>     TimeUnit[] mod;
> 
>     @Setup
>     public void setup() {
>         mod = new TimeUnit[SIZE];
> 
>         TimeUnit[] vals = TimeUnit.values();
>         for (int c = 0; c < SIZE; c++) {
>             if (bias == -1) {
>                 // megamorphic
>                 mod[c] = vals[c % vals.length];
>             } else {
>                 mod[c] = vals[bias];
>             }
>         }
> 
>         Random r = new Random();
>         for (int c = 0; c < 10000; c++) {
>             int i = r.nextInt();
>             for (int o = 0; o < vals.length; o++) {
>                 if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
>                     throw new IllegalStateException("switch " + o);
>             }
>         }
>     }
> 
>     @Benchmark
>     public void const_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu, 1L));
>         }
>     }
> 
>     @Benchmark
>     public void const_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu, 1L));
>         }
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu) {
>         return tu.toNanos(1L);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu, long value) {
>         return tu.toNanos(value);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu) {
>         return TimeUnit.NANOSECONDS.convert(1L, tu);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu, long value) {
>         return TimeUnit.NANOSECONDS.convert(value, tu);
>     }
> }
> 
> Results:
> 
> Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
> TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
> TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
> TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
> TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
> TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
> TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
> TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
> TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
> TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
> TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
> TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
> TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
> TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
> TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
> TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
> TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
> TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
> TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
> TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
> TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
> TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
> TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
> TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
> TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
> TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
> TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
> TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
> TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
> TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
> TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
> TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
> TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op
> 
> 
> </details>

This pull request has now been integrated.

Changeset: e833c1d1
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e833c1d179f926edabb2d40c6c357ab20bba726e
Stats:     24 lines in 4 files changed: 2 ins; 0 del; 22 mod

8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/8376

From mullan at openjdk.org  Thu Jun 16 17:54:58 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 Jun 2022 17:54:58 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
Message-ID: <RO6qKMSxUOOkB6uLw61XkLIBuvfBjC1gagSCc5WSU-A=.10b2ed0b-ce90-4a4c-93fa-c658f935d827@github.com>

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.  
>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>   This avoids parsing annotations of user classes from a privileged context.

test/jdk/java/util/Random/SecurityManagerFactory.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

Update year to 2022.

test/jdk/java/util/Random/SecurityManagerFactory.java line 29:

> 27:  * @summary Checks if the random factory providers can be loaded when a SecurityManager is active
> 28:  * @bug 8288475
> 29:  * @run main/othervm/policy=java.policy -Djava.security.manager SecurityManagerFactory

You should not need to specify the `java.security.manager` system property as the jtreg `policy` tag will automatically run it under a SecurityManager.

test/jdk/java/util/Random/SecurityManagerFactory.java line 34:

> 32: public class SecurityManagerFactory {
> 33:     public static void main(String[] args) {
> 34:         RandomGeneratorFactory.all().toList();

Should you also check what `RandomGenerator`s are returned when an SM is enabled to make sure it is ok?

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From almatvee at openjdk.org  Thu Jun 16 18:21:02 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 16 Jun 2022 18:21:02 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v2]
In-Reply-To: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
Message-ID: <Yp2_rJW1NGNZDnf9ryk9veYI7hJaz49cWImZaalj25Q=.d87c0a78-b4e3-45bf-94b0-9cefccbc61a7@github.com>

> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!NgVdVIfGfiCL40KAsDby-Ir9nDaz-bobTPkIIqXNrWDeLTm0q-Z69dZ98EP_SNaNq4XEfm_LtGBAUzlzYWY5RAtroQ$ .

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8287971: Throw exception for missing values in .jpackage.xml [v2]

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/9/files
  - new: https://git.openjdk.org/jdk19/pull/9/files/daee617b..c06af061

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=00-01

  Stats: 250 lines in 9 files changed: 159 ins; 54 del; 37 mod
  Patch: https://git.openjdk.org/jdk19/pull/9.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/9/head:pull/9

PR: https://git.openjdk.org/jdk19/pull/9

From almatvee at openjdk.org  Thu Jun 16 18:21:07 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 16 Jun 2022 18:21:07 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v2]
In-Reply-To: <x_SkOcJtk7xzie4CLYaafeFlMKPlgPm6IKUkyO2FURM=.07a3b6ce-a6a1-4495-9db4-f084058f7b2d@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
 <x_SkOcJtk7xzie4CLYaafeFlMKPlgPm6IKUkyO2FURM=.07a3b6ce-a6a1-4495-9db4-f084058f7b2d@github.com>
Message-ID: <j8kPit9hiS4VxV8NROqClPWYDKAtR_pgo2DiK4Zw_YY=.274bf54a-7957-4ec8-a1ba-ef07b4cb05a8@github.com>

On Tue, 14 Jun 2022 18:07:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8287971: Throw exception for missing values in .jpackage.xml [v2]
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 68:
> 
>> 66:     private final List<LauncherInfo> addLauncherInfos;
>> 67:     private final String signedStr;
>> 68:     private final String appStoreStr;
> 
> What is the idea of this change?

To store string values, so it can be validated to make sure it is true or false only. I changed it back, since I moved validation to ctor.

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 339:
> 
>> 337:                 !("true".equals(appStoreStr) || "false".equals(appStoreStr))) {
>> 338:             return false;
>> 339:         }
> 
> It makes sense to unfold this function in the ctor as we don't allow empty AppImageFile instances.

Done.

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 79:
> 
>> 77: warning.no.jdk.modules.found=Warnung: Keine JDK-Module gefunden
>> 78: 
>> 79: error.foreign-app-image=Error: app-image dir ({0}) not generated by jpackage. Missing .jpackage.xml.
> 
> This error message will be misleading in case app image was generated by jpackage and adjusted after.
> I'd put it as "Missing .jpackage.xml file in app-image dir ({0})."

Done.

> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 272:
> 
>> 270:             ));
>> 271:     }
>> 272: 
> 
> 1. This is jpackage specific, so it should belong to JPackageCommand class.
> 2. Please use proper XML API to create XML output.
> 3. Having `<app-version>1.0</app-version>` in .jpackage.xml file will make `AppImageFile.isValid()` return `false` and `AppImageFile.load()` to throw exception. This seems to be equivalent to not having .jpackage.xml file in app image at all raising a question if this new function is needed at all.

1 and 2 done. I think you mistaken `<app-version>1.0</app-version>` with `<jpackage-state version="%s"`. We never read <app-version> and I do put correct value for `<jpackage-state version="%s"`. It is required for several tests which uses empty/dummy app images and since we started required .jpackage.xml file we need it for empty app images as well.

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From darcy at openjdk.org  Thu Jun 16 19:57:55 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 16 Jun 2022 19:57:55 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v28]
In-Reply-To: <8UJPLRHzoFyNPDMQdt6EgtG9Ovvbt5Vy7X-IOOz9ss8=.6fb9da4a-ac51-458c-9f13-48fc90c006ee@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <8UJPLRHzoFyNPDMQdt6EgtG9Ovvbt5Vy7X-IOOz9ss8=.6fb9da4a-ac51-458c-9f13-48fc90c006ee@github.com>
Message-ID: <7G3Sp-ryGvv7l-p1oqGxdlzEh-pXnR2eIIOFOSEWRfk=.2dc95142-f321-4f78-a37e-699f18decc6e@github.com>

On Thu, 16 Jun 2022 06:27:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

A note on the regression tests, I'm expanding the set of tests for the different access flags in different locations. I've partitioned these separately for class, field, method flags, etc. Those sorts of locations could potentially be combined into a single test, but I think it is clearer to have them separate (and in a bulk regression test run, they shouldn't take much longer to run as separate tests). To test ACC_STRICT, earlier source and target settings need to be used so that test is separate.

In the course of writing tests for ACC_SUPER, it looks like Class.getModifiers() strips out the ACC_SUPER bit in the VM implementation ([JDK-4109635](https://bugs.openjdk.org/browse/JDK-4109635)). I'm sure those who have knives sharpened to remove SUPER will be encouraged by this, but I'd still prefer to leave SUPER as an AccessFlag for now.

As a follow-up to this work, it may be necessary or helpful to have a different library access point or an additional library access point to query information from the JVM. Alternatively, the VM could take responsibility for constructing the AccessFlag sets. For example, if (and when) there is reuse of a bit position for a single construct, say on a class file, the interpretation of the bit is dependent on class file version. While the VM knows that the class file version is, the libraries don't currently have access to that information and knowing that versioning information in some capacity would be needed to properly construct the access flags.

I'm going to take a pass at writing tests for ModuleDescriptor before considering pushes these changes.

Thanks for all the review feedback so far.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From aturbanov at openjdk.org  Thu Jun 16 20:44:20 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 16 Jun 2022 20:44:20 GMT
Subject: RFR: 8288628: Unnecessary Hashtable usage in ConditionalSpecialCasing
Message-ID: <kf1_S_6HBNMCNOvz2IdeQ8QKgtDr-SY2IG1umSb48nI=.c8e4203c-c9b9-422c-b3cf-d68d54ed66dc@github.com>

If a thread-safe implementation is not needed, it is recommended to use HashMap in place of Hashtable.
`ConditionalSpecialCasing.entryTable` is read-only Map which is modified only in `static` block. It means we can safely replace it with HashMap.

-------------

Commit messages:
 - [PATCH] Unnecessary Hashtable usage in ConditionalSpecialCasing

Changes: https://git.openjdk.org/jdk/pull/9172/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288628
  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9172.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9172/head:pull/9172

PR: https://git.openjdk.org/jdk/pull/9172

From almatvee at openjdk.org  Thu Jun 16 21:24:46 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 16 Jun 2022 21:24:46 GMT
Subject: RFR: 8287401: jpackage tests failing on Windows due to powershell
 issue
In-Reply-To: <QVnHMii8QFEZYYElJPluwcNurKRyGoAna_vShzSfnCU=.1b983d80-6b0d-41dd-a76b-f04ca46249b4@github.com>
References: <QVnHMii8QFEZYYElJPluwcNurKRyGoAna_vShzSfnCU=.1b983d80-6b0d-41dd-a76b-f04ca46249b4@github.com>
Message-ID: <wIHOuhu9QUG4cEYECat0B3-fdzpc2PRGoZ54Rb2G5kc=.e8537206-df14-420a-8841-a29d4d90ffb8@github.com>

On Thu, 16 Jun 2022 05:15:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Run a script extracting icons from executables as PowerShell command line rather than a script

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/26

From darcy at openjdk.org  Thu Jun 16 21:30:12 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 16 Jun 2022 21:30:12 GMT
Subject: RFR: JDK-8288573: Make
 `java.lang.reflect.Executable::getParameterCount()' actually abstract
Message-ID: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>

Whatever the motivation for how this method was coded when added in JDK 8, since Executable is now a sealed class with Constructor and Method the only allowed subclasses, getParameterCount can be coded as an normal abstract method. (The implementation of getParameterCount in Method and Constructor use fields private to each of those classes so the code cannot easily be shared in Executable).

Please also review the small accompanying CSR: https://bugs.openjdk.org/browse/JDK-8288630

-------------

Commit messages:
 - JDK-8288573: Make `java.lang.reflect.Executable::getParameterCount()` actually abstract

Changes: https://git.openjdk.org/jdk/pull/9192/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9192&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288573
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9192.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9192/head:pull/9192

PR: https://git.openjdk.org/jdk/pull/9192

From darcy at openjdk.org  Thu Jun 16 21:44:57 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 16 Jun 2022 21:44:57 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v25]
In-Reply-To: <bpXITJ93BrFU9tKLzc7oZeuoIGffAR42nhnzL0DkW3A=.c076b4d4-03bf-438a-9b02-43790aeef6f8@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>
 <bpXITJ93BrFU9tKLzc7oZeuoIGffAR42nhnzL0DkW3A=.c076b4d4-03bf-438a-9b02-43790aeef6f8@github.com>
Message-ID: <u_cgQMgR0RCLTfDSRWQye1hN9DutvB4f3hQ48Q8QiXo=.642fb130-3aa0-4658-b513-ec49858fd638@github.com>

On Thu, 16 Jun 2022 08:21:49 GMT, ExE Boss <duke 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/java/lang/reflect/Member.java line 92:
> 
>> 90:      * @implSpec
>> 91:      * The default implementation returns throws {@link
>> 92:      * UnsupportedOperationException}.
> 
> Typo:
> Suggestion:
> 
>      * The default implementation throws {@link UnsupportedOperationException}.

Thanks @ExE-Boss; will fix.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From raffaello.giulietti at oracle.com  Thu Jun 16 21:57:15 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Thu, 16 Jun 2022 23:57:15 +0200
Subject: Integrated: 8288594: Address possibly lossy conversions in
 java.base FloatToDecimal
In-Reply-To: <oxFIOG61jZ7VahGZ0YKuMdeXj_2cig_g-4rOa1sb98s=.370d77c9-2e75-40e7-82f5-698b4acb3496@github.com>
References: <pzpkK0ViROXq3MD96mQmFtr1EpwukG2gR9qyij-0zCc=.b927eeea-3f92-430b-81c4-582221425234@github.com>
 <oxFIOG61jZ7VahGZ0YKuMdeXj_2cig_g-4rOa1sb98s=.370d77c9-2e75-40e7-82f5-698b4acb3496@github.com>
Message-ID: <a27ada50-5f99-1211-a669-a55c2b15d4c0@oracle.com>

Although the conversion is mathematically sound and never lossy, this 
change should probably be backported to 19 as well.


Greetings
Raffaello


On 2022-06-16 19:01, Adam Sotona wrote:
> On Thu, 16 Jun 2022 15:26:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:
> 
>> One new case of possibly lossy conversions recently appeared in jdk.internal.math.FloatToDecimal.
>> This patch avoids the warning by explicit cast from long to int.
>>
>> Please review.
>>
>> Thanks,
>> Adam
> 
> This pull request has now been integrated.
> 
> Changeset: e7d52e25
> Author:    Adam Sotona <asotona at openjdk.org>
> URL:       https://git.openjdk.org/jdk/commit/e7d52e25a273a534c3195ea58745fd4a34963454
> Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod
> 
> 8288594: Address possibly lossy conversions in java.base FloatToDecimal
> 
> Reviewed-by: rriggs
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/9188

From asemenyuk at openjdk.org  Thu Jun 16 22:07:17 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 16 Jun 2022 22:07:17 GMT
Subject: Integrated: 8287401: jpackage tests failing on Windows due to
 powershell issue
In-Reply-To: <QVnHMii8QFEZYYElJPluwcNurKRyGoAna_vShzSfnCU=.1b983d80-6b0d-41dd-a76b-f04ca46249b4@github.com>
References: <QVnHMii8QFEZYYElJPluwcNurKRyGoAna_vShzSfnCU=.1b983d80-6b0d-41dd-a76b-f04ca46249b4@github.com>
Message-ID: <feLWQj7-QFeoEdvBkChlEFxCsjOiku1B0hYpTMYjboI=.19ee284f-e394-408f-a51c-3b4cce96d7b4@github.com>

On Thu, 16 Jun 2022 05:15:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Run a script extracting icons from executables as PowerShell command line rather than a script

This pull request has now been integrated.

Changeset: c254c9d0
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/c254c9d095d0473282ad74e66239a790912a3d76
Stats:     8 lines in 1 file changed: 0 ins; 3 del; 5 mod

8287401: jpackage tests failing on Windows due to powershell issue

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk19/pull/26

From raffaello.giulietti at oracle.com  Thu Jun 16 22:15:47 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 17 Jun 2022 00:15:47 +0200
Subject: Integrated: 8288594: Address possibly lossy conversions in
 java.base FloatToDecimal
In-Reply-To: <a27ada50-5f99-1211-a669-a55c2b15d4c0@oracle.com>
References: <pzpkK0ViROXq3MD96mQmFtr1EpwukG2gR9qyij-0zCc=.b927eeea-3f92-430b-81c4-582221425234@github.com>
 <oxFIOG61jZ7VahGZ0YKuMdeXj_2cig_g-4rOa1sb98s=.370d77c9-2e75-40e7-82f5-698b4acb3496@github.com>
 <a27ada50-5f99-1211-a669-a55c2b15d4c0@oracle.com>
Message-ID: <47f26a88-97d3-6aa2-e440-6f5d4dbd0ee0@oracle.com>

Ah, no, it's a P4 bug.
Sorry for the noise


On 2022-06-16 23:57, Raffaello Giulietti wrote:
> Although the conversion is mathematically sound and never lossy, this 
> change should probably be backported to 19 as well.
> 
> 
> Greetings
> Raffaello
> 
> 
> On 2022-06-16 19:01, Adam Sotona wrote:
>> On Thu, 16 Jun 2022 15:26:37 GMT, Adam Sotona <asotona at openjdk.org> 
>> wrote:
>>
>>> One new case of possibly lossy conversions recently appeared in 
>>> jdk.internal.math.FloatToDecimal.
>>> This patch avoids the warning by explicit cast from long to int.
>>>
>>> Please review.
>>>
>>> Thanks,
>>> Adam
>>
>> This pull request has now been integrated.
>>
>> Changeset: e7d52e25
>> Author:??? Adam Sotona <asotona at openjdk.org>
>> URL:       
>> https://git.openjdk.org/jdk/commit/e7d52e25a273a534c3195ea58745fd4a34963454 
>>
>> Stats:???? 1 line in 1 file changed: 0 ins; 0 del; 1 mod
>>
>> 8288594: Address possibly lossy conversions in java.base FloatToDecimal
>>
>> Reviewed-by: rriggs
>>
>> -------------
>>
>> PR: https://git.openjdk.org/jdk/pull/9188

From asemenyuk at openjdk.org  Thu Jun 16 22:22:53 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 16 Jun 2022 22:22:53 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v2]
In-Reply-To: <Yp2_rJW1NGNZDnf9ryk9veYI7hJaz49cWImZaalj25Q=.d87c0a78-b4e3-45bf-94b0-9cefccbc61a7@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
 <Yp2_rJW1NGNZDnf9ryk9veYI7hJaz49cWImZaalj25Q=.d87c0a78-b4e3-45bf-94b0-9cefccbc61a7@github.com>
Message-ID: <LjW8s9WelSPvHM6oLOd_eK_hiX-ZVXjb47FYVKeh1ec=.ba7c6cec-28ad-4158-a784-1e0c99885dd1@github.com>

On Thu, 16 Jun 2022 18:21:02 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>>  - Re-fixed as Alexey suggested in https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!PsH8lvwzF-7qlBJnkrq2yx-aMl9Jf2BJYRPBFzkkyajXchbNnyMFTo8ocZadqzWUvIX4CBbhkaUfap-KlfE929wC1Mk$ .
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287971: Throw exception for missing values in .jpackage.xml [v2]

No need to copy/paste xml authoring code from IOUtils. This API is accessible outside of jpackage. Check out https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/jdk/tools/jpackage/windows/WinScriptTest.java*L151__;Iw!!ACWV5N9M2RV99hQ!PsH8lvwzF-7qlBJnkrq2yx-aMl9Jf2BJYRPBFzkkyajXchbNnyMFTo8ocZadqzWUvIX4CBbhkaUfap-KlfE9P1yKXnI$ 

-------------

Changes requested by asemenyuk (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/9

From asemenyuk at openjdk.org  Thu Jun 16 22:22:55 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 16 Jun 2022 22:22:55 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v2]
In-Reply-To: <j8kPit9hiS4VxV8NROqClPWYDKAtR_pgo2DiK4Zw_YY=.274bf54a-7957-4ec8-a1ba-ef07b4cb05a8@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
 <x_SkOcJtk7xzie4CLYaafeFlMKPlgPm6IKUkyO2FURM=.07a3b6ce-a6a1-4495-9db4-f084058f7b2d@github.com>
 <j8kPit9hiS4VxV8NROqClPWYDKAtR_pgo2DiK4Zw_YY=.274bf54a-7957-4ec8-a1ba-ef07b4cb05a8@github.com>
Message-ID: <YQNWIPVZK8e7Rh15RgdjPUUG-xu1BRbl_qtH2wDDiIo=.6d41671e-8c01-4932-a323-d250fed04eda@github.com>

On Thu, 16 Jun 2022 18:14:45 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 272:
>> 
>>> 270:             ));
>>> 271:     }
>>> 272: 
>> 
>> 1. This is jpackage specific, so it should belong to JPackageCommand class.
>> 2. Please use proper XML API to create XML output.
>> 3. Having `<app-version>1.0</app-version>` in .jpackage.xml file will make `AppImageFile.isValid()` return `false` and `AppImageFile.load()` to throw exception. This seems to be equivalent to not having .jpackage.xml file in app image at all raising a question if this new function is needed at all.
>
> 1 and 2 done. I think you mistaken `<app-version>1.0</app-version>` with `<jpackage-state version="%s"`. We never read <app-version> and I do put correct value for `<jpackage-state version="%s"`. It is required for several tests which uses empty/dummy app images and since we started required .jpackage.xml file we need it for empty app images as well.

Right! My bad, sorry for the confusion.

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From naoto at openjdk.org  Thu Jun 16 22:29:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 16 Jun 2022 22:29:09 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
Message-ID: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>

This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.

-------------

Commit messages:
 - 8288589: Files.readString ignores encoding errors for UTF-16

Changes: https://git.openjdk.org/jdk/pull/9193/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288589
  Stats: 51 lines in 2 files changed: 26 ins; 14 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9193/head:pull/9193

PR: https://git.openjdk.org/jdk/pull/9193

From rriggs at openjdk.org  Thu Jun 16 22:48:49 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Jun 2022 22:48:49 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
In-Reply-To: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
Message-ID: <WS7wWPcvFP9wuk6dqJiHbPZ6G_wlM3nPm4cFUZ9Fk0g=.4b7e12d6-91cf-4d7a-8a1b-67cb1260eae8@github.com>

On Thu, 16 Jun 2022 22:21:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9193

From iris at openjdk.org  Fri Jun 17 00:33:46 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 17 Jun 2022 00:33:46 GMT
Subject: RFR: JDK-8288573: Make
 `java.lang.reflect.Executable::getParameterCount()' actually abstract
In-Reply-To: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
References: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
Message-ID: <xAyT6mVDVK_oTyFVoQr0rE91nD-9Dr2hwkH8w1xvGBw=.b87a21dd-8bed-4554-846a-b2a00ee8905a@github.com>

On Thu, 16 Jun 2022 21:21:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Whatever the motivation for how this method was coded when added in JDK 8, since Executable is now a sealed class with Constructor and Method the only allowed subclasses, getParameterCount can be coded as an normal abstract method. (The implementation of getParameterCount in Method and Constructor use fields private to each of those classes so the code cannot easily be shared in Executable).
> 
> Please also review the small accompanying CSR: https://bugs.openjdk.org/browse/JDK-8288630

Associated CSR also Reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9192

From iris at openjdk.org  Fri Jun 17 00:52:46 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 17 Jun 2022 00:52:46 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
In-Reply-To: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
Message-ID: <jEhHGQaDQ6pifgGIPoXtfHXjjKH7ZP9eFDYFyiCJUqs=.bff45919-a8a0-436b-ac59-3e2c9b370c56@github.com>

On Thu, 16 Jun 2022 22:21:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From darcy at openjdk.org  Fri Jun 17 01:42:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Jun 2022 01:42:30 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v29]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <WYceI91OJVqivv3oYHwDIn1J5NV0R_xeRMuLfYNCYjA=.7e2f188f-a46f-4251-adb8-8da7f2ab2a37@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:

 - Fix typo Exe-Boss spotted in review feedback.
 - Merge branch 'master' into JDK-8266670
 - Appease jcheck.
 - Expand regression tests.
 - Merge branch 'master' into JDK-8266670
 - Respond to review feedback from Roger Riggs.
 - Respond to review feedback.
 - Make mask fields final in ModuleDescriptor.
 - Correct STATIC vs STATIC_PHASE issue found in code review.
 - From review feedback, use package-private contstants in Modifier.
 - ... and 34 more: https://git.openjdk.org/jdk/compare/d64a6d2b...81e6ef07

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/ebb01e1d..81e6ef07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=27-28

  Stats: 2200 lines in 70 files changed: 1652 ins; 213 del; 335 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.org  Fri Jun 17 03:10:47 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Jun 2022 03:10:47 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v30]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <apVaORMp3B0YXqIO628KYIxLPVVDjlBdilqxTFQ3GbI=.7d1365d6-67e7-4cd1-8c44-b6f80a6350b3@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add module-related tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/81e6ef07..81bfc6d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=28-29

  Stats: 88 lines in 1 file changed: 88 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From jkuhn at openjdk.org  Fri Jun 17 03:47:49 2022
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Fri, 17 Jun 2022 03:47:49 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <RO6qKMSxUOOkB6uLw61XkLIBuvfBjC1gagSCc5WSU-A=.10b2ed0b-ce90-4a4c-93fa-c658f935d827@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <RO6qKMSxUOOkB6uLw61XkLIBuvfBjC1gagSCc5WSU-A=.10b2ed0b-ce90-4a4c-93fa-c658f935d827@github.com>
Message-ID: <YFWAU6UC5b74XTFHzQPRmyNeOsweoXRyYTm13PGKRkY=.04c42afd-0b7d-4655-9083-c1944806780a@github.com>

On Thu, 16 Jun 2022 17:43:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
>> * The annotations of the provider classes are now parsed early.  
>>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
>> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>>   This avoids parsing annotations of user classes from a privileged context.
>
> test/jdk/java/util/Random/SecurityManagerFactory.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Update year to 2022.

Will fix.

> test/jdk/java/util/Random/SecurityManagerFactory.java line 29:
> 
>> 27:  * @summary Checks if the random factory providers can be loaded when a SecurityManager is active
>> 28:  * @bug 8288475
>> 29:  * @run main/othervm/policy=java.policy -Djava.security.manager SecurityManagerFactory
> 
> You should not need to specify the `java.security.manager` system property as the jtreg `policy` tag will automatically run it under a SecurityManager.

Thanks, was not aware of that

> test/jdk/java/util/Random/SecurityManagerFactory.java line 34:
> 
>> 32: public class SecurityManagerFactory {
>> 33:     public static void main(String[] args) {
>> 34:         RandomGeneratorFactory.all().toList();
> 
> Should you also check what `RandomGenerator`s are returned when an SM is enabled to make sure it is ok?

As long as it doesn't throw it's ok.

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From duke at openjdk.org  Fri Jun 17 04:02:57 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 17 Jun 2022 04:02:57 GMT
Subject: RFR: 8286849: Use @Stable for generic repositories
In-Reply-To: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
References: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
Message-ID: <riZGSBVvn_B5BtXrdkG-PAlG7_SvYAw8PA9L-dl6X7c=.c9afbe1f-65b3-4509-bae6-3a650905217b@github.com>

On Tue, 17 May 2022 04:40:50 GMT, liach <duke at openjdk.org> wrote:

> Generic repositories, the implementation detail for generic information in core reflection, can be updated to use the `@Stable` annotation to replace their `volatile` access. Their existing accessor code is already safe, reading the cache fields only once.
> 
> In addition, fixed potentially non-thread-safe `genericInfo` access in `Method`, `Field`, and `RecordComponent`.

Most?JDK?code places the?`@Stable`?annotation between?field?modifiers and?the?field?type.

--------------------------------------------------------------------------------

Also?note?that `@Stable` on?array?fields also?makes the?array read?only after?initialisation:
https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java*L51-L56__;Iw!!ACWV5N9M2RV99hQ!MNPwqM3U_iWsPhWZbo8JzBfg-QiS8vF6UVPJcEANMX2L-1EtqdMntILJ1Ys8hvKEjNUFp7r4MVbwAYP5xu15$ 

src/java.base/share/classes/java/lang/Class.java line 3297:

> 3295:     // Generic info repository; lazily initialized
> 3296:     @Stable
> 3297:     private transient ClassRepository genericInfo;

Suggestion:

    private transient @Stable ClassRepository genericInfo;

src/java.base/share/classes/java/lang/reflect/Constructor.java line 77:

> 75:     // generic info repository; lazily initialized
> 76:     @Stable
> 77:     private transient ConstructorRepository genericInfo;

Suggestion:

    private transient @Stable ConstructorRepository genericInfo;

src/java.base/share/classes/java/lang/reflect/Field.java line 80:

> 78:     // generic info repository; lazily initialized
> 79:     @Stable
> 80:     private transient FieldRepository genericInfo;

Suggestion:

    private transient @Stable FieldRepository genericInfo;

src/java.base/share/classes/java/lang/reflect/Method.java line 86:

> 84:     // generic info repository; lazily initialized
> 85:     @Stable
> 86:     private transient MethodRepository genericInfo;

Suggestion:

    private transient @Stable MethodRepository genericInfo;

src/java.base/share/classes/java/lang/reflect/RecordComponent.java line 59:

> 57:     // generic info repository; lazily initialized
> 58:     @Stable
> 59:     private transient FieldRepository genericInfo;

Suggestion:

    private transient @Stable FieldRepository genericInfo;

src/java.base/share/classes/sun/reflect/generics/repository/ClassRepository.java line 48:

> 46:     /** The generic superclass info.  Lazily initialized. */
> 47:     @Stable
> 48:     private Type superclass;

Suggestion:

    private @Stable Type superclass;

src/java.base/share/classes/sun/reflect/generics/repository/ClassRepository.java line 52:

> 50:     /** The generic superinterface info.  Lazily initialized. */
> 51:     @Stable
> 52:     private Type[] superInterfaces;

Suggestion:

    private @Stable Type[] superInterfaces;

src/java.base/share/classes/sun/reflect/generics/repository/ConstructorRepository.java line 49:

> 47:     /** The generic parameter types.  Lazily initialized. */
> 48:     @Stable
> 49:     private Type[] parameterTypes;

Suggestion:

    private @Stable Type[] parameterTypes;

src/java.base/share/classes/sun/reflect/generics/repository/ConstructorRepository.java line 53:

> 51:     /** The generic exception types.  Lazily initialized. */
> 52:     @Stable
> 53:     private Type[] exceptionTypes;

Suggestion:

    private @Stable Type[] exceptionTypes;

src/java.base/share/classes/sun/reflect/generics/repository/FieldRepository.java line 47:

> 45:     /** The generic type info.  Lazily initialized. */
> 46:     @Stable
> 47:     private Type genericType;

Suggestion:

    private @Stable Type genericType;

src/java.base/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java line 50:

> 48:     /** The formal type parameters.  Lazily initialized. */
> 49:     @Stable
> 50:     private TypeVariable<?>[] typeParameters;

Suggestion:

    private @Stable TypeVariable<?>[] typeParameters;

src/java.base/share/classes/sun/reflect/generics/repository/MethodRepository.java line 45:

> 43:     /** The generic return type info.  Lazily initialized. */
> 44:     @Stable
> 45:     private Type returnType;

Suggestion:

    private @Stable Type returnType;

src/java.base/share/classes/sun/reflect/generics/scope/AbstractScope.java line 48:

> 46:     /** The enclosing scope of this scope.  Lazily initialized. */
> 47:     @Stable
> 48:     private Scope enclosingScope;

Suggestion:

    private @Stable Scope enclosingScope;

-------------

PR: https://git.openjdk.org/jdk/pull/8742

From almatvee at openjdk.org  Fri Jun 17 04:07:47 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 17 Jun 2022 04:07:47 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v3]
In-Reply-To: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
Message-ID: <OUqYeLjWGZt7ULMS5J5YHEunhUY8RYjsUFg0ssGCo6E=.192a1fae-4d9e-4a49-b723-6df61f5bf008@github.com>

> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!O9EYpCECe4owBSx5Afed1_edIOYL5-MqdziwEb_3iNi3T8oFSoldnyr3Gbz_8xPC-of21OjvRc3oLJ-J5w6V0Lpkng$ .

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8287971: Throw exception for missing values in .jpackage.xml [v3]

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/9/files
  - new: https://git.openjdk.org/jdk19/pull/9/files/c06af061..2199f4e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=01-02

  Stats: 99 lines in 2 files changed: 1 ins; 97 del; 1 mod
  Patch: https://git.openjdk.org/jdk19/pull/9.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/9/head:pull/9

PR: https://git.openjdk.org/jdk19/pull/9

From almatvee at openjdk.org  Fri Jun 17 04:07:49 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 17 Jun 2022 04:07:49 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v2]
In-Reply-To: <Yp2_rJW1NGNZDnf9ryk9veYI7hJaz49cWImZaalj25Q=.d87c0a78-b4e3-45bf-94b0-9cefccbc61a7@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
 <Yp2_rJW1NGNZDnf9ryk9veYI7hJaz49cWImZaalj25Q=.d87c0a78-b4e3-45bf-94b0-9cefccbc61a7@github.com>
Message-ID: <b63v4MHQkVbIadLMNlQO5xwMAcV9yq6RJGoKtBFkmeU=.49a90010-d17b-468a-a2b5-3513ed6004f9@github.com>

On Thu, 16 Jun 2022 18:21:02 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>>  - Re-fixed as Alexey suggested in https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!MiXPcE28nIXl_Hg-ji0E1JDSYIL3xYaIfIUBzeIpboB3rr5cYRxY-XwVKLB0tbQTs6ifthtrkSwAWeh6ssIYexxC1g$ .
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287971: Throw exception for missing values in .jpackage.xml [v2]

8287971: Throw exception for missing values in .jpackage.xml [v3]
 - Removed copy/paste code from TKit.java.

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From duke at openjdk.org  Fri Jun 17 05:36:52 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 17 Jun 2022 05:36:52 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v2]
In-Reply-To: <953PEa-1Og5iTtp-1P0JWVTUmEuysrFavJb4dYliq-4=.94144fa8-8c5d-4543-970c-4303bdb94c2d@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <953PEa-1Og5iTtp-1P0JWVTUmEuysrFavJb4dYliq-4=.94144fa8-8c5d-4543-970c-4303bdb94c2d@github.com>
Message-ID: <uHhSpsjLaHewE3V6bdoZEs7rKSGVmKtyZzMRDioNopI=.4e7d852e-3b0a-4981-a202-1b30a58a0693@github.com>

On Mon, 13 Jun 2022 19:55:47 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
>> 
>> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288327: Add clarifying comments

src/java.base/share/classes/java/lang/reflect/Executable.java line 453:

> 451: 
> 452:     private transient boolean hasRealParameterData;
> 453:     private transient volatile Parameter[] parameters;

These?can?probably be?annotated with?`@Stable` (see?also?[GH?8742]):
Suggestion:

    private transient @Stable boolean hasRealParameterData;
    private transient @Stable volatile Parameter[] parameters;


[GH?8742]: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8742__;!!ACWV5N9M2RV99hQ!Pu7IhhN7O8BZ8UFonTLx3XeO8PLqruZTKko5qqtlFfXoeqkvrnO5pNA5lvtjZOVqSVk2yzbMa5S8nkxjwuO1$ 

-------------

PR: https://git.openjdk.org/jdk/pull/9143

From alanb at openjdk.org  Fri Jun 17 06:00:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Jun 2022 06:00:06 GMT
Subject: Integrated: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec
In-Reply-To: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com>
References: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com>
Message-ID: <iRmB641YhbfeUseZBsMQlfPUhdA2VjHFHzBGhMbxJsU=.da478b3a-08d5-48dc-a539-417f554ab21b@github.com>

On Sat, 11 Jun 2022 15:42:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change GetVersion to return this version.
> 
> test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that JNI_VERSION_19 is returned. The native library in the JMX agent, and several tests, define JNI_OnLoad that return JNI_VERSION_10 as the JNI version needed. These are updated to return JNI_VERSION_19 although these updates aren't strictly needed.

This pull request has now been integrated.

Changeset: 53bf1bfd
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/53bf1bfdabb79b37afedd09051d057f9eea620f2
Stats:     16 lines in 10 files changed: 2 ins; 0 del; 14 mod

8286176: Add JNI_VERSION_19 to jni.h and JNI spec

Reviewed-by: dcubed, iris, mchung, dholmes

-------------

PR: https://git.openjdk.org/jdk19/pull/7

From thomas.stuefe at gmail.com  Fri Jun 17 06:04:57 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 17 Jun 2022 08:04:57 +0200
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <CANghgrSNrBAkbg_z3=-_pqSXQ4--QR_PAYxha9xT0D5G+3AxVg@mail.gmail.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
 <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
 <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
 <be5d1b98-3fc9-5383-9513-762160fe43a1@oracle.com>
 <CAA-vtUzWCUjFCKhD8tQow8PFm1ugG8hse6U072vRtMEJ9XUpag@mail.gmail.com>
 <2014aec0-945b-a311-6fd7-46dad4899b00@oracle.com>
 <CANghgrSNrBAkbg_z3=-_pqSXQ4--QR_PAYxha9xT0D5G+3AxVg@mail.gmail.com>
Message-ID: <CAA-vtUx3apKjiCmVtJ9HW+g2rVqADTAAn30Gt+xSji2-UuNQjQ@mail.gmail.com>

>
>
> > >
> > > I see your point. I dislike crashes, especially ones they can be
> > > reliably triggered from outside. You never can be sure about the
> > > security implications either.
> > >
> > > If you dislike ignoring the signal, and since the default action for
> > > SIGUSR1+2 is process termination, why not exit the VM with an error
> > > message instead? At least we don?t have what looks like a random
> > > segfault, and we could print out the sender pid  too.
> >
> > We could ... but then do we do that for every other signal that can be
> > thrown at the JVM from externally and which will leads to crashes? Where
> > do you stop?
>
>
It's a very limited set. I'd say we limit this to

1) signal for which we registered handlers: the handlers should at least
not crash or vanish the VM without a trace
2) signals which may conceivably be sent to the VM in the normal course of
events: if the default action is to terminate the VM, we should handle them

Note that for (2), we already do this for some signals. We explicitly
handle SIGPIPE (https://bugs.openjdk.org/browse/JDK-4229104) and SIGXFSZ (
https://bugs.openjdk.org/browse/JDK-6499219) because they kill the VM.


> Well, playing devil's advocate, why not? Would it be more complex than
> adding a
>
>     if (si.si_pid != my_cached_pid) {
>         // it came from Outside, let's exit with 128+signum
>         // ...
>     }
>
> to the top of the signal handler(s)?
>
> --
> - DML ? he/him
>
>
I filed a JBS issue and a PR:
https://github.com/openjdk/jdk/pull/9181#issuecomment-1157353776.

I went with a different approach, just using Thread::current=NULL as an
indicator. I was worried that Unix implementations may leave the si_pid
field empty, or that it gets filled with the sender's kernel thread id, not
the process pid. Just verified that on Linux, its really actually the
process id (so the main threads id).

Cheers, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220617/9b9be065/attachment-0001.htm>

From duke at openjdk.org  Fri Jun 17 06:17:46 2022
From: duke at openjdk.org (liach)
Date: Fri, 17 Jun 2022 06:17:46 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v2]
In-Reply-To: <uHhSpsjLaHewE3V6bdoZEs7rKSGVmKtyZzMRDioNopI=.4e7d852e-3b0a-4981-a202-1b30a58a0693@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <953PEa-1Og5iTtp-1P0JWVTUmEuysrFavJb4dYliq-4=.94144fa8-8c5d-4543-970c-4303bdb94c2d@github.com>
 <uHhSpsjLaHewE3V6bdoZEs7rKSGVmKtyZzMRDioNopI=.4e7d852e-3b0a-4981-a202-1b30a58a0693@github.com>
Message-ID: <ocN4vUGhkUDS7FqplmBUFqRdi7sRPUytL1LV5yMrR10=.11bffdf1-548c-4fc0-9a50-522ea33d2635@github.com>

On Fri, 17 Jun 2022 05:34:25 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288327: Add clarifying comments
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 453:
> 
>> 451: 
>> 452:     private transient boolean hasRealParameterData;
>> 453:     private transient volatile Parameter[] parameters;
> 
> These?can?probably be?annotated with?`@Stable` (see?also?[GH?8742]):
> Suggestion:
> 
>     private transient @Stable boolean hasRealParameterData;
>     private transient @Stable volatile Parameter[] parameters;
> 
> 
> [GH?8742]: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8742__;!!ACWV5N9M2RV99hQ!LCGH0C1JTymKJBYhuf9QGi40oZ5nPH-YmfYHk30effXmBBfOpYlC9ixsITWo_Uhfgyu4l0w3837mmshCk-bM$ 

Another approach would be to keep the parameter array and the boolean in a record, and mark the record field as stable, possibly like what's done in #6889. Keeping them in a record like:

record ParameterData(Parameter[] parameters, boolean real) {}

private transient @Stable ParameterData parameterData;

private ParameterData parameterData() {
    ParameterData data = parameterData;
    if (data != null)
        return data;
    // Create parameter data, cache and return
}

boolean hasRealParameterData() { return parameterData().real(); }
private Parameter[] privateGetParameters() { return parameterData().parameters(); }


This code should be more maintainable in the long run as well, with more straightforward concurrency and caching model.

-------------

PR: https://git.openjdk.org/jdk/pull/9143

From duke at openjdk.org  Fri Jun 17 06:30:49 2022
From: duke at openjdk.org (liach)
Date: Fri, 17 Jun 2022 06:30:49 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v2]
In-Reply-To: <ocN4vUGhkUDS7FqplmBUFqRdi7sRPUytL1LV5yMrR10=.11bffdf1-548c-4fc0-9a50-522ea33d2635@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <953PEa-1Og5iTtp-1P0JWVTUmEuysrFavJb4dYliq-4=.94144fa8-8c5d-4543-970c-4303bdb94c2d@github.com>
 <uHhSpsjLaHewE3V6bdoZEs7rKSGVmKtyZzMRDioNopI=.4e7d852e-3b0a-4981-a202-1b30a58a0693@github.com>
 <ocN4vUGhkUDS7FqplmBUFqRdi7sRPUytL1LV5yMrR10=.11bffdf1-548c-4fc0-9a50-522ea33d2635@github.com>
Message-ID: <xE7SityyyKKwi3EixhPlfbPnQqIab3SOO3EbDqG1Exk=.da79dd4f-b369-4c8d-b246-bd16f7c5d9ee@github.com>

On Fri, 17 Jun 2022 06:14:32 GMT, liach <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Executable.java line 453:
>> 
>>> 451: 
>>> 452:     private transient boolean hasRealParameterData;
>>> 453:     private transient volatile Parameter[] parameters;
>> 
>> These?can?probably be?annotated with?`@Stable` (see?also?[GH?8742]):
>> Suggestion:
>> 
>>     private transient @Stable boolean hasRealParameterData;
>>     private transient @Stable volatile Parameter[] parameters;
>> 
>> 
>> [GH?8742]: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8742__;!!ACWV5N9M2RV99hQ!N5tsYl_TBRKmfUUQW8y4mWPDosNfRCnScec50IJaZ9-dE66PRrTOjlPZLtH9cYdAW6OVve-XK-uOXps9cx5N$ 
>
> Another approach would be to keep the parameter array and the boolean in a record, and mark the record field as stable, possibly like what's done in #6889. Keeping them in a record like:
> 
> record ParameterData(Parameter[] parameters, boolean real) {}
> 
> private transient @Stable ParameterData parameterData;
> 
> private ParameterData parameterData() {
>     ParameterData data = parameterData;
>     if (data != null)
>         return data;
>     // Create parameter data, cache and return
> }
> 
> boolean hasRealParameterData() { return parameterData().real(); }
> private Parameter[] privateGetParameters() { return parameterData().parameters(); }
> 
> 
> This code should be more maintainable in the long run as well, with more straightforward concurrency and caching model.

If my record approach is used, `hasRealParameterData()` and `privateGetParameters()` should be manually inlined instead, for code clarity. Alternatively, you can rename the components to like `sharedArray`/`sharedParameters`, `isReal` to make the call sites like `parameterData().sharedParameters().clone()` or `parameterData().isReal()` more descriptive.

Currently, `hasRealParameterData` is only used in `Executable::getAllGenericParameterTypes`, and `privateGetParameters` only in `Executable::getParameters` (except the unintuitive usage to initialize the parameter data), so the impact of such a refactor and inline would be small.

-------------

PR: https://git.openjdk.org/jdk/pull/9143

From alanb at openjdk.org  Fri Jun 17 06:37:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Jun 2022 06:37:49 GMT
Subject: RFR: JDK-8288573: Make
 `java.lang.reflect.Executable::getParameterCount()' actually abstract
In-Reply-To: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
References: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
Message-ID: <wwbxJs5JQEv0ezO-CZbouX3CQtSUel_LlDL8oLwmncI=.aa67057e-60ab-45df-bb91-4e2f0e36c4e7@github.com>

On Thu, 16 Jun 2022 21:21:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Whatever the motivation for how this method was coded when added in JDK 8, since Executable is now a sealed class with Constructor and Method the only allowed subclasses, getParameterCount can be coded as an normal abstract method. (The implementation of getParameterCount in Method and Constructor use fields private to each of those classes so the code cannot easily be shared in Executable).
> 
> Please also review the small accompanying CSR: https://bugs.openjdk.org/browse/JDK-8288630

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9192

From jpai at openjdk.org  Fri Jun 17 06:47:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 06:47:51 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
Message-ID: <xhjVkWfOEVfunuhQ2Rak9ovsjR_SYqfvic8Mq1GdW4A=.892fcb4d-443d-4401-830c-119f0bce2927@github.com>

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.  
>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>   This avoids parsing annotations of user classes from a privileged context.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 170:

> 168:                     .filter(p -> !p.type().isAnnotationPresent(Deprecated.class) &&
> 169:                             p.type().isAnnotationPresent(RandomGeneratorProperties.class))
> 170:                     .toList();

Hello Johannes, I haven't yet fully grasped this change, so a few questions:

1. Does this change now mean that in the presence of a SecurityManager, the `RandomGeneratorFactory.all()` method will no longer return instances of `RandomGeneratorFactory` which belong to the application's classloader (those added as Service provider implementations of that interface within the application's jar for example)? Would that then contradict the expectations of the `RandomGeneratorFactory.all()` API and is there any other way to obtain those application specific implementations?
2. I see that this patch now calls `VM.isSystemDomainLoader` in the presence of the SecurityManager. That method implementation internally calls `ClassLoader.getPlatformClassLoader()` which has SecurityManager checks for the `RuntimePermission` for `getClassLoader` permission. Does this call then have to be in a privileged block?
3. Is this entire issue specific only to the `RandomGeneratorFactory.all()` method? For example, I see that there are some other methods which also use the ServiceProvider API to find the relevant provider implementation and there's also an `isDeprecated` method which checks for the presence of an annotation on the provider's implementation. Are those methods affected too?
4.

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From jpai at openjdk.org  Fri Jun 17 06:54:48 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 06:54:48 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
Message-ID: <u2qkACD7g9XGT4yz6Q3GWGM9UWD1r2n3qTZgBbkE1nY=.59127fb1-828a-4cd4-ac43-f2fc5bc272f7@github.com>

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.  
>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>   This avoids parsing annotations of user classes from a privileged context.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 165:

> 163:                 onlyBuiltIn = p -> VM.isSystemDomainLoader(p.type().getClassLoader());
> 164:             } else {
> 165:                 onlyBuiltIn = p -> true;

Should this variable be renamed to something else? Because right now it does the opposite of it's name. i.e. When `onlyBuiltIn` is set to `true`, like here, the code a few lines below which filters the stream accepts all `RandomGeneratorFactory` implementations that have been found.

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From jkuhn at openjdk.org  Fri Jun 17 06:54:49 2022
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Fri, 17 Jun 2022 06:54:49 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <u2qkACD7g9XGT4yz6Q3GWGM9UWD1r2n3qTZgBbkE1nY=.59127fb1-828a-4cd4-ac43-f2fc5bc272f7@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <u2qkACD7g9XGT4yz6Q3GWGM9UWD1r2n3qTZgBbkE1nY=.59127fb1-828a-4cd4-ac43-f2fc5bc272f7@github.com>
Message-ID: <JaomL_3JtoDSghEyk0HAEYPQBISLtGHEM8iIYlH90e0=.6a553cd3-e95b-44c6-808b-6e144e1af9e0@github.com>

On Fri, 17 Jun 2022 06:47:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
>> * The annotations of the provider classes are now parsed early.  
>>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
>> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>>   This avoids parsing annotations of user classes from a privileged context.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 165:
> 
>> 163:                 onlyBuiltIn = p -> VM.isSystemDomainLoader(p.type().getClassLoader());
>> 164:             } else {
>> 165:                 onlyBuiltIn = p -> true;
> 
> Should this variable be renamed to something else? Because right now it does the opposite of it's name. i.e. When `onlyBuiltIn` is set to `true`, like here, the code a few lines below which filters the stream accepts all `RandomGeneratorFactory` implementations that have been found.

Good idea. Naming is hard - and I don't have a good name. Maybe `allowType`?

On second thought, I could change it to `Stream<...> s = ...; if (...) {s = s.filter(...)}`.

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From jpai at openjdk.org  Fri Jun 17 07:06:53 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 07:06:53 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
Message-ID: <Y3nlpAJzAb-NXYyAbG1vw8iYQrgKwyDIqpBOpfHDjkw=.3039493f-f205-4954-be8f-d3e6500e30e1@github.com>

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.  
>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>   This avoids parsing annotations of user classes from a privileged context.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 141:

> 139: 
> 140:     private static class FactoryMapHolder {
> 141:         static final Map<String, Provider<? extends RandomGenerator>> FACTORY_MAP = createFactoryMap();

Unrelated to this PR, but a more general question. It appears that this `FACTORY_MAP` gets cached on first use/call. A few questions about the `createFactoryMap` method:
1. The javadoc of that private method says:

/**
         * Returns the factory map, lazily constructing map on first use.
         *
         * @return Map of RandomGeneratorFactory classes.
         */

But the implementation and the signature of this method actually return a Map of `RandomGenerator` classes and not the `RandomGeneratorFactory` classes.
2. The implementation of this method internally uses the `ServiceLoader` to load the `RandomGenerator` service provider implementations. The internal implementation of the `ServiceLoader` will use a Thread context classloader that is set on the calling thread. The result of the call to this `createFactoryMap` is then cached once and for all in the `FACTORY_MAP`. Would this then lead to a non-deterministic behaviour where whoever ends up initializing this `FactoryMapHolder` first, will end up storing those RandomGenerators for every one else? Is this intentional? Do you think this caching should be reviewed?

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From jkuhn at openjdk.org  Fri Jun 17 07:14:55 2022
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Fri, 17 Jun 2022 07:14:55 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <Y3nlpAJzAb-NXYyAbG1vw8iYQrgKwyDIqpBOpfHDjkw=.3039493f-f205-4954-be8f-d3e6500e30e1@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <Y3nlpAJzAb-NXYyAbG1vw8iYQrgKwyDIqpBOpfHDjkw=.3039493f-f205-4954-be8f-d3e6500e30e1@github.com>
Message-ID: <KD-Tcm4BGWQeERzwzdeAuhhUQrDEJKUQc2ynmBnVFfw=.782c8efc-e4cb-4cfa-a4e3-2fd41b25b358@github.com>

On Fri, 17 Jun 2022 07:04:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
>> * The annotations of the provider classes are now parsed early.  
>>   This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block.
>> * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader.  
>>   This avoids parsing annotations of user classes from a privileged context.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 141:
> 
>> 139: 
>> 140:     private static class FactoryMapHolder {
>> 141:         static final Map<String, Provider<? extends RandomGenerator>> FACTORY_MAP = createFactoryMap();
> 
> Unrelated to this PR, but a more general question. It appears that this `FACTORY_MAP` gets cached on first use/call. A few questions about the `createFactoryMap` method:
> 1. The javadoc of that private method says:
> 
> /**
>          * Returns the factory map, lazily constructing map on first use.
>          *
>          * @return Map of RandomGeneratorFactory classes.
>          */
> 
> But the implementation and the signature of this method actually return a Map of `RandomGenerator` classes and not the `RandomGeneratorFactory` classes.
> 2. The implementation of this method internally uses the `ServiceLoader` to load the `RandomGenerator` service provider implementations. The internal implementation of the `ServiceLoader` will use a Thread context classloader that is set on the calling thread. The result of the call to this `createFactoryMap` is then cached once and for all in the `FACTORY_MAP`. Would this then lead to a non-deterministic behaviour where whoever ends up initializing this `FactoryMapHolder` first, will end up storing those RandomGenerators for every one else? Is this intentional? Do you think this caching should be reviewed?

Good point. It might be useful to explicitly pass the boot layer to the service loader.

But that is outside the scope of this bug - my goal here is just to make it not throw an exception when running with a SecurityManager while not introducing security vulnerabilities.

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From jpai at openjdk.org  Fri Jun 17 07:14:57 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 07:14:57 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <KD-Tcm4BGWQeERzwzdeAuhhUQrDEJKUQc2ynmBnVFfw=.782c8efc-e4cb-4cfa-a4e3-2fd41b25b358@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <Y3nlpAJzAb-NXYyAbG1vw8iYQrgKwyDIqpBOpfHDjkw=.3039493f-f205-4954-be8f-d3e6500e30e1@github.com>
 <KD-Tcm4BGWQeERzwzdeAuhhUQrDEJKUQc2ynmBnVFfw=.782c8efc-e4cb-4cfa-a4e3-2fd41b25b358@github.com>
Message-ID: <WfOVnFQTfIj0v07hjyH90JQm_aey0kPcugxRCp4S5dE=.0dbd2664-a516-459d-a3ae-a518e848bf44@github.com>

On Fri, 17 Jun 2022 07:10:02 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> But that is outside the scope of this bug

Agreed. I'm not expecting that to be changed in this PR :)  It was more a general question about the implementation.

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From jpai at openjdk.org  Fri Jun 17 07:20:43 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 07:20:43 GMT
Subject: RFR: JDK-8288573: Make
 `java.lang.reflect.Executable::getParameterCount()' actually abstract
In-Reply-To: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
References: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
Message-ID: <fTSos6NnFJzsKIc5Q-wuDDpvkHiWDoYbW2Uzc3-6mlM=.93f34e37-f740-4ec6-8334-4dc36ebf680f@github.com>

On Thu, 16 Jun 2022 21:21:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Whatever the motivation for how this method was coded when added in JDK 8, since Executable is now a sealed class with Constructor and Method the only allowed subclasses, getParameterCount can be coded as an normal abstract method. (The implementation of getParameterCount in Method and Constructor use fields private to each of those classes so the code cannot easily be shared in Executable).
> 
> Please also review the small accompanying CSR: https://bugs.openjdk.org/browse/JDK-8288630

Change looks fine to me. The copyright year on this file will need an update, which I guess you would be doing before integrating this.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9192

From hiran.chaudhuri at gmx.net  Fri Jun 17 07:39:37 2022
From: hiran.chaudhuri at gmx.net (Hiran Chaudhuri)
Date: Fri, 17 Jun 2022 09:39:37 +0200
Subject: Java Logging Documentation
Message-ID: <43ce1a5377cdae76c1fe46ef45ec3a3a25e10c3d.camel@gmx.net>

Hello there.

Switching from log4j2 towards Java Logging (one dependency less), I
notice that the documentation at
https://docs.oracle.com/en/java/javase/18/core/java-logging-overview.html#GUID-B83B652C-17EA-48D9-93D2-563AE1FF8EDA
is not very useful to me.

While I know very well how to configure log4j through properties or XML
files, for Java Logging a configuration file/properties is mentioned,
but I do not see
- the structure of the file (what properties should or have to be set?)
- where should the file go (or where will the logging framework be
searching for it?)
- examples of logging configuration via configuration file (currently
there are just API examples)

I'd be glad if that documentation could be extended in this respect.

Hiran


From duke at openjdk.org  Fri Jun 17 09:29:22 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 17 Jun 2022 09:29:22 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v3]
In-Reply-To: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
Message-ID: <q_TSyDqhnwdAr9A33Kf1c56zLLgfJSqX_sjPXU3vWKo=.72b644b6-1a56-4920-ac77-ea0e49c9bf0d@github.com>

> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
> 
> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into 8288327
 - 8288327: Use record store
 - 8288327: Add clarifying comments
 - 8288327: Executable.hasRealParameterData should not be volatile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9143/files
  - new: https://git.openjdk.org/jdk/pull/9143/files/5c52be9f..076cde01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=01-02

  Stats: 9459 lines in 287 files changed: 5494 ins; 2884 del; 1081 mod
  Patch: https://git.openjdk.org/jdk/pull/9143.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9143/head:pull/9143

PR: https://git.openjdk.org/jdk/pull/9143

From duke at openjdk.org  Fri Jun 17 09:29:31 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 17 Jun 2022 09:29:31 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v2]
In-Reply-To: <xE7SityyyKKwi3EixhPlfbPnQqIab3SOO3EbDqG1Exk=.da79dd4f-b369-4c8d-b246-bd16f7c5d9ee@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <953PEa-1Og5iTtp-1P0JWVTUmEuysrFavJb4dYliq-4=.94144fa8-8c5d-4543-970c-4303bdb94c2d@github.com>
 <uHhSpsjLaHewE3V6bdoZEs7rKSGVmKtyZzMRDioNopI=.4e7d852e-3b0a-4981-a202-1b30a58a0693@github.com>
 <ocN4vUGhkUDS7FqplmBUFqRdi7sRPUytL1LV5yMrR10=.11bffdf1-548c-4fc0-9a50-522ea33d2635@github.com>
 <xE7SityyyKKwi3EixhPlfbPnQqIab3SOO3EbDqG1Exk=.da79dd4f-b369-4c8d-b246-bd16f7c5d9ee@github.com>
Message-ID: <pBjj-9MoF6ha8_p5pVIQO8nEijzSNAzPls1tjU1i4X0=.33bde80c-9890-4523-ab36-fd76878fc5b3@github.com>

On Fri, 17 Jun 2022 06:27:12 GMT, liach <duke at openjdk.org> wrote:

>> Another approach would be to keep the parameter array and the boolean in a record, and mark the record field as stable, possibly like what's done in #6889. Keeping them in a record like:
>> 
>> record ParameterData(Parameter[] parameters, boolean real) {}
>> 
>> private transient @Stable ParameterData parameterData;
>> 
>> private ParameterData parameterData() {
>>     ParameterData data = parameterData;
>>     if (data != null)
>>         return data;
>>     // Create parameter data, cache and return
>> }
>> 
>> boolean hasRealParameterData() { return parameterData().real(); }
>> private Parameter[] privateGetParameters() { return parameterData().parameters(); }
>> 
>> 
>> This code should be more maintainable in the long run as well, with more straightforward concurrency and caching model.
>
> If my record approach is used, `hasRealParameterData()` and `privateGetParameters()` should be manually inlined instead, for code clarity. Alternatively, you can rename the components to like `sharedArray`/`sharedParameters`, `isReal` to make the call sites like `parameterData().sharedParameters().clone()` or `parameterData().isReal()` more descriptive.
> 
> Currently, `hasRealParameterData` is only used in `Executable::getAllGenericParameterTypes`, and `privateGetParameters` only in `Executable::getParameters` (except the unintuitive usage to initialize the parameter data), so the impact of such a refactor and inline would be small.

@liach Good point, done!

-------------

PR: https://git.openjdk.org/jdk/pull/9143

From jpai at openjdk.org  Fri Jun 17 10:12:56 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Jun 2022 10:12:56 GMT
Subject: RFR: JDK-8288475: Initializing
 RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is
 installed
In-Reply-To: <JaomL_3JtoDSghEyk0HAEYPQBISLtGHEM8iIYlH90e0=.6a553cd3-e95b-44c6-808b-6e144e1af9e0@github.com>
References: <Lnu_H3oeKWSO7YTJqVonsUdYmton4aQ9LzD8N0sdeWo=.e8b03476-9c7c-49a5-b41e-ec602d1513fa@github.com>
 <u2qkACD7g9XGT4yz6Q3GWGM9UWD1r2n3qTZgBbkE1nY=.59127fb1-828a-4cd4-ac43-f2fc5bc272f7@github.com>
 <JaomL_3JtoDSghEyk0HAEYPQBISLtGHEM8iIYlH90e0=.6a553cd3-e95b-44c6-808b-6e144e1af9e0@github.com>
Message-ID: <xE7Km52cLgQ9brBM-e70h8F6EJ2wDh7Pc9APZpdxwNg=.9cdce373-f6cf-4d9a-9968-62739c9b4846@github.com>

On Fri, 17 Jun 2022 06:50:24 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 165:
>> 
>>> 163:                 onlyBuiltIn = p -> VM.isSystemDomainLoader(p.type().getClassLoader());
>>> 164:             } else {
>>> 165:                 onlyBuiltIn = p -> true;
>> 
>> Should this variable be renamed to something else? Because right now it does the opposite of it's name. i.e. When `onlyBuiltIn` is set to `true`, like here, the code a few lines below which filters the stream accepts all `RandomGeneratorFactory` implementations that have been found.
>
> Good idea. Naming is hard - and I don't have a good name. Maybe `allowType`?
> 
> On second thought, I could change it to `Stream<...> s = ...; if (...) {s = s.filter(...)}`.

I think what you have with the filter call is fine. I think just renaming the `onlyBuiltIn` variable should be enough. Perhaps rename it to `acceptedProviders`?

-------------

PR: https://git.openjdk.org/jdk/pull/9180

From duke at openjdk.org  Fri Jun 17 10:43:01 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 17 Jun 2022 10:43:01 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v3]
In-Reply-To: <q_TSyDqhnwdAr9A33Kf1c56zLLgfJSqX_sjPXU3vWKo=.72b644b6-1a56-4920-ac77-ea0e49c9bf0d@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <q_TSyDqhnwdAr9A33Kf1c56zLLgfJSqX_sjPXU3vWKo=.72b644b6-1a56-4920-ac77-ea0e49c9bf0d@github.com>
Message-ID: <Svk5gdZp8Uwsk4KJANz4qFSND-heS6hVoiG6Vb5sV-s=.5e3839f4-21b0-4786-81db-5b60780b142c@github.com>

On Fri, 17 Jun 2022 09:29:22 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
>> 
>> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8288327
>  - 8288327: Use record store
>  - 8288327: Add clarifying comments
>  - 8288327: Executable.hasRealParameterData should not be volatile

src/java.base/share/classes/java/lang/reflect/Executable.java line 777:

> 775:     }
> 776: 
> 777:     record ParameterData(Parameter[] parameters, boolean real) {}

The?`ParameterData.parameters`?field can?probably be?marked as?[`@Stable`] (since?the?`parameters`?array is?never?modified):
Suggestion:

    record ParameterData(@Stable Parameter[] parameters, boolean real) {}


Also?the?`real`?record?component should?probably be?renamed to?`isReal` as?@liach?suggested in?[GH?9143?(comment)].

[GH?9143?(comment)]: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9143*discussion_r899802093__;Iw!!ACWV5N9M2RV99hQ!OeL5Zo46nS8lb1vkbw1RNZVCCXGuOaxOVhP-yBBYLYoIlq4QhUjuO5GL-gf8bJNP2adueR7So62POAr5EyKP$ 
[`@Stable`]: https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java__;!!ACWV5N9M2RV99hQ!OeL5Zo46nS8lb1vkbw1RNZVCCXGuOaxOVhP-yBBYLYoIlq4QhUjuO5GL-gf8bJNP2adueR7So62POFGSimfz$ 

-------------

PR: https://git.openjdk.org/jdk/pull/9143

From duke at openjdk.org  Fri Jun 17 10:54:09 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 17 Jun 2022 10:54:09 GMT
Subject: RFR: JDK-8288573: Make
 `java.lang.reflect.Executable::getParameterCount()' actually abstract
In-Reply-To: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
References: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
Message-ID: <6uoDXEidHaCuAtLFLq1SBCGDwcZEMiS-v6iChpQqigo=.142d47cd-2d75-45e7-b22b-548c0fcf189f@github.com>

On Thu, 16 Jun 2022 21:21:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Whatever the motivation for how this method was coded when added in JDK 8, since Executable is now a sealed class with Constructor and Method the only allowed subclasses, getParameterCount can be coded as an normal abstract method. (The implementation of getParameterCount in Method and Constructor use fields private to each of those classes so the code cannot easily be shared in Executable).
> 
> Please also review the small accompanying CSR: https://bugs.openjdk.org/browse/JDK-8288630

Note?that the?PR?title actually?needs?to?be ``Make<NBSP>`java.lang.reflect.Executable::getParameterCount()` actually<NBSP>abstract`` with?`<NBSP>` being?replaced by?the?`NO?BREAK?SPACE (U+00A0)` code?point (<kbd>alt</kbd>+<kbd>0</kbd><kbd>1</kbd><kbd>6</kbd><kbd>0</kbd>).

--------------------------------------------------------------------------------

This?is?because I?use non?breaking?spaces a?lot.

-------------

PR: https://git.openjdk.org/jdk/pull/9192

From duke at openjdk.org  Fri Jun 17 11:21:49 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 17 Jun 2022 11:21:49 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v4]
In-Reply-To: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
Message-ID: <CYXUywvj-GH7yGtI6zT2CgCV79sk_Uaes9_288H1BQI=.f00fbd19-5aa1-4f20-86fa-336a92d413ac@github.com>

> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
> 
> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8288327: Mark ParameterData.parameters as @Stable and rename real -> isReal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9143/files
  - new: https://git.openjdk.org/jdk/pull/9143/files/076cde01..8ead0357

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9143.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9143/head:pull/9143

PR: https://git.openjdk.org/jdk/pull/9143

From duke at openjdk.org  Fri Jun 17 11:21:53 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 17 Jun 2022 11:21:53 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v4]
In-Reply-To: <Svk5gdZp8Uwsk4KJANz4qFSND-heS6hVoiG6Vb5sV-s=.5e3839f4-21b0-4786-81db-5b60780b142c@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <q_TSyDqhnwdAr9A33Kf1c56zLLgfJSqX_sjPXU3vWKo=.72b644b6-1a56-4920-ac77-ea0e49c9bf0d@github.com>
 <Svk5gdZp8Uwsk4KJANz4qFSND-heS6hVoiG6Vb5sV-s=.5e3839f4-21b0-4786-81db-5b60780b142c@github.com>
Message-ID: <4zqcTqZHs7lS5h6prrewgKk2LltsDXymLil3jwG8gJw=.5bd7f466-4825-432a-a08a-4be9caa5e30f@github.com>

On Fri, 17 Jun 2022 10:31:39 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288327: Mark ParameterData.parameters as @Stable and rename real -> isReal
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 777:
> 
>> 775:     }
>> 776: 
>> 777:     record ParameterData(Parameter[] parameters, boolean real) {}
> 
> The?`ParameterData.parameters`?field can?probably be?marked as?[`@Stable`] (since?the?`parameters`?array is?never?modified):
> Suggestion:
> 
>     record ParameterData(@Stable Parameter[] parameters, boolean real) {}
> 
> 
> Also?the?`real`?record?component should?probably be?renamed to?`isReal` as?@liach?suggested in?[GH?9143?(comment)].
> 
> [GH?9143?(comment)]: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9143*discussion_r899802093__;Iw!!ACWV5N9M2RV99hQ!PPLP0cqTBjkLFwhsIrte6kC_0rHTBaDkXEkEhu1D1VgRyiTiYjNKzT8X7812VcB4h64d6A33thLyzviiW7es$ 
> [`@Stable`]: https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java__;!!ACWV5N9M2RV99hQ!PPLP0cqTBjkLFwhsIrte6kC_0rHTBaDkXEkEhu1D1VgRyiTiYjNKzT8X7812VcB4h64d6A33thLyzunOu8jW$ 

Done!

-------------

PR: https://git.openjdk.org/jdk/pull/9143

From jwilhelm at openjdk.org  Fri Jun 17 12:24:19 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 17 Jun 2022 12:24:19 GMT
Subject: RFR: Merge jdk19
Message-ID: <iAAt-vOyoM8VX3hFOWbmy1AVrFxNuBLzw1dRbe6E4IY=.96c7e0d9-668c-459f-be99-570db613cfa9@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8286176: Add JNI_VERSION_19 to jni.h and JNI spec
 - 8287401: jpackage tests failing on Windows due to powershell issue
 - 8288534: Out of bound errors for memory segment access mentions wrong values

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/9197/files
  Stats: 50 lines in 14 files changed: 25 ins; 3 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/9197.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9197/head:pull/9197

PR: https://git.openjdk.org/jdk/pull/9197

From redestad at openjdk.org  Fri Jun 17 13:44:27 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 17 Jun 2022 13:44:27 GMT
Subject: RFR: 8288667: Reduce runtime of java.text microbenchmarks
Message-ID: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>

- Refactor micro using a range of parameters to a simpler benchmark that tests different values in one pass
- Reduce iterations and their runtimes, but add forks (important to be able to detect run-to-run variation anomalies)

Just one micro modified in this package, but reduces total runtime from 16 minutes to ~1 minute

-------------

Commit messages:
 - Reduce runtime of java.text micros

Changes: https://git.openjdk.org/jdk/pull/9198/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9198&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288667
  Stats: 21 lines in 1 file changed: 10 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9198.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9198/head:pull/9198

PR: https://git.openjdk.org/jdk/pull/9198

From jwilhelm at openjdk.org  Fri Jun 17 13:50:58 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 17 Jun 2022 13:50:58 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <iAAt-vOyoM8VX3hFOWbmy1AVrFxNuBLzw1dRbe6E4IY=.96c7e0d9-668c-459f-be99-570db613cfa9@github.com>
References: <iAAt-vOyoM8VX3hFOWbmy1AVrFxNuBLzw1dRbe6E4IY=.96c7e0d9-668c-459f-be99-570db613cfa9@github.com>
Message-ID: <x6UTZXwCO29ezzLkLFigvnD4BaqyXY-69f8ivIwKPcc=.e384ca8e-0fe4-431e-a0c5-8384907fff3a@github.com>

On Fri, 17 Jun 2022 12:16:32 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: af64d316
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af64d316c0f687c4ceab7591e050449c64e3babc
Stats:     50 lines in 14 files changed: 25 ins; 3 del; 22 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9197

From cstein at openjdk.org  Fri Jun 17 13:54:01 2022
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 17 Jun 2022 13:54:01 GMT
Subject: RFR: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used [v9]
In-Reply-To: <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
 <lJgMI92gEFWgzBv1-21MjAKn2bXFjMKh1Bf0w1GMpEw=.492a0eeb-46ec-4c29-a637-b375488e380b@github.com>
Message-ID: <Y666DncZv5-PSis_udJwwCKKKsxPJ1o8SnwdTJWBQng=.957a5f1e-6df1-42b6-8e4e-cb25f537ddf4@github.com>

On Fri, 10 Jun 2022 18:28:46 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename dataprovider

LGTM

-------------

Marked as reviewed by cstein (Author).

PR: https://git.openjdk.org/jdk/pull/9049

From duke at openjdk.org  Fri Jun 17 13:58:59 2022
From: duke at openjdk.org (liach)
Date: Fri, 17 Jun 2022 13:58:59 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v4]
In-Reply-To: <4zqcTqZHs7lS5h6prrewgKk2LltsDXymLil3jwG8gJw=.5bd7f466-4825-432a-a08a-4be9caa5e30f@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <q_TSyDqhnwdAr9A33Kf1c56zLLgfJSqX_sjPXU3vWKo=.72b644b6-1a56-4920-ac77-ea0e49c9bf0d@github.com>
 <Svk5gdZp8Uwsk4KJANz4qFSND-heS6hVoiG6Vb5sV-s=.5e3839f4-21b0-4786-81db-5b60780b142c@github.com>
 <4zqcTqZHs7lS5h6prrewgKk2LltsDXymLil3jwG8gJw=.5bd7f466-4825-432a-a08a-4be9caa5e30f@github.com>
Message-ID: <1ohi4VTGdzi0UuU79tUya4_23TyfsizhUOdOys8A46o=.03194dda-6f62-4791-87f8-3e755ead6f4e@github.com>

On Fri, 17 Jun 2022 11:17:18 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Executable.java line 777:
>> 
>>> 775:     }
>>> 776: 
>>> 777:     record ParameterData(Parameter[] parameters, boolean real) {}
>> 
>> The?`ParameterData.parameters`?field can?probably be?marked as?[`@Stable`] (since?the?`parameters`?array is?never?modified):
>> Suggestion:
>> 
>>     record ParameterData(@Stable Parameter[] parameters, boolean real) {}
>> 
>> 
>> Also?the?`real`?record?component should?probably be?renamed to?`isReal` as?@liach?suggested in?[GH?9143?(comment)].
>> 
>> [GH?9143?(comment)]: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9143*discussion_r899802093__;Iw!!ACWV5N9M2RV99hQ!J63u7Go-g9GhEjZFWdnrewEwa84zjq6BtIGWjYCaadPNKrGsj8BMqbuBJYk0Bp-sEM4dNuRmK0TwyzeT3lIc$ 
>> [`@Stable`]: https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java__;!!ACWV5N9M2RV99hQ!J63u7Go-g9GhEjZFWdnrewEwa84zjq6BtIGWjYCaadPNKrGsj8BMqbuBJYk0Bp-sEM4dNuRmK0Twy8KsGcQf$ 
>
> Done!

I don't think this stable is critical here, as we don't use the parameters array entries separately, but doesn't seem wrong to have it too.

-------------

PR: https://git.openjdk.org/jdk/pull/9143

From sean.mullan at oracle.com  Fri Jun 17 14:15:52 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 17 Jun 2022 10:15:52 -0400
Subject: Fwd: Bug JDK-8176553
In-Reply-To: <04eec9b7-4995-3f88-c2db-ec8ba628dffa@redhat.com>
References: <04eec9b7-4995-3f88-c2db-ec8ba628dffa@redhat.com>
Message-ID: <06a79df6-24fc-bfbd-476e-208ac4ec9fa7@oracle.com>

[reposting to core-libs-dev as this is in the JNDI/LDAP component]


-------- Forwarded Message --------
Subject: Bug JDK-8176553
Date: Fri, 17 Jun 2022 14:23:11 +0200
From: Ricardo Martin Camarero <rmartinc at redhat.com>
To: security-dev at openjdk.org

Hi!

I decided to send an email to the security-dev email list as ldap is
involved. Please redirect me to other list if it is not the proper audience.

The last last days I have faced the same issue that is commented in
JDK-8176553 [1]. Although it is cataloged as fixed in 12, the issue is
not solved in the openjdk master branch yet. You can test with this
simple project [2]. The project is using apache-ds and creating 12
branches with redirects from one to the other. The search should be
limited to 5 hops but you will see that all of them are followed (12).
Therefore, If there are loops, the search hangs indefinitely. So
JDK-8176553 is not fixed completely. You just need `mvn clean test` to
reproduce the problem in that project.

I have investigated and I think the attached little patch fixes the
issue. Mainly the `LdapReferralException` is not stopping the referral
loop in some situations. I have added a test in the jndi jtreg
test-suite to check everything works OK; `make test
TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java`

WDYT? Is the PR worthy?

Thanks in advance!


[1] https://bugs.openjdk.org/browse/JDK-8176553
[2] 
https://urldefense.com/v3/__https://github.com/rmartinc/apache-ds-referrals__;!!ACWV5N9M2RV99hQ!IZkp5q_gOAeIP8Y9Gvr8aniLloG51lZJwlG1yN6BRDyHHLpyr0W64TDMUPAzoPu7dOBOyJrNcKYmwaOF9REM3oA$ 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8176553.patch
Type: text/x-patch
Size: 9531 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220617/c6c84ebc/8176553-0001.patch>

From asotona at openjdk.org  Fri Jun 17 14:27:41 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Jun 2022 14:27:41 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName
Message-ID: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>

The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 

There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 

This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
Class internal name validation and extended ClassDescTest are also parts of this patch.

CSR is linked with the issue.

Please review.

Thank you,
Adam

-------------

Commit messages:
 - 8278863: Add method ClassDesc::ofInternalName

Changes: https://git.openjdk.org/jdk/pull/9201/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9201&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8278863
  Stats: 52 lines in 3 files changed: 52 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9201.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9201/head:pull/9201

PR: https://git.openjdk.org/jdk/pull/9201

From rriggs at openjdk.org  Fri Jun 17 14:45:59 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Jun 2022 14:45:59 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v30]
In-Reply-To: <apVaORMp3B0YXqIO628KYIxLPVVDjlBdilqxTFQ3GbI=.7d1365d6-67e7-4cd1-8c44-b6f80a6350b3@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <apVaORMp3B0YXqIO628KYIxLPVVDjlBdilqxTFQ3GbI=.7d1365d6-67e7-4cd1-8c44-b6f80a6350b3@github.com>
Message-ID: <7SQ3kLpME0w8LSxcnrZL72WG-W-7xf_rYFr_nssWlAc=.23badd37-b074-4c7c-a5c0-46dca2e3fe2e@github.com>

On Fri, 17 Jun 2022 03:10:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add module-related tests.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 428:

> 426:                                        ABSTRACT, STRICT, SYNTHETIC)),
> 427:                           entry(Location.INNER_CLASS,
> 428:                                 Set.of(PUBLIC, PRIVATE, PROTECTED,

Should SUPER be included for INNER_CLASS?

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From forax at openjdk.org  Fri Jun 17 14:53:00 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 17 Jun 2022 14:53:00 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v30]
In-Reply-To: <7SQ3kLpME0w8LSxcnrZL72WG-W-7xf_rYFr_nssWlAc=.23badd37-b074-4c7c-a5c0-46dca2e3fe2e@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <apVaORMp3B0YXqIO628KYIxLPVVDjlBdilqxTFQ3GbI=.7d1365d6-67e7-4cd1-8c44-b6f80a6350b3@github.com>
 <7SQ3kLpME0w8LSxcnrZL72WG-W-7xf_rYFr_nssWlAc=.23badd37-b074-4c7c-a5c0-46dca2e3fe2e@github.com>
Message-ID: <f0pui8j9iT8zPb1K421SkJ2bQqR08pXp_8y5X_GvR4E=.c815e4ac-0380-42bf-94f0-1286c6f1efc6@github.com>

On Fri, 17 Jun 2022 14:42:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add module-related tests.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 428:
> 
>> 426:                                        ABSTRACT, STRICT, SYNTHETIC)),
>> 427:                           entry(Location.INNER_CLASS,
>> 428:                                 Set.of(PUBLIC, PRIVATE, PROTECTED,
> 
> Should SUPER be included for INNER_CLASS?

The JVMS does not allow it
https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-4.html#jvms-4.7.6

The inner class flags are not the flags on the inner class itself (the class with a '$' in its name) but the flags on the attribute InnerClass inside the outerclass. Those flags are used by javac but not by the VM.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From jvernee at openjdk.org  Fri Jun 17 15:10:52 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Jun 2022 15:10:52 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName
In-Reply-To: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
Message-ID: <26mC6dLmsbCkl1g-MFWKwvU1_JCa5J4KsTi3hUPvEz8=.974ba3b5-86fe-4909-9462-e6713ba17e8a@github.com>

On Fri, 17 Jun 2022 14:19:11 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 
> 
> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 
> 
> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
> Class internal name validation and extended ClassDescTest are also parts of this patch.
> 
> CSR is linked with the issue.
> 
> Please review.
> 
> Thank you,
> Adam

I've worked with ClassDesc quite a bit as well, and often found myself wanting to do the opposite. i.e. if I have a `ClassDesc`, convert it to an internal name string (to give to ASM).

There are also methods to get the descriptor, as well as display name & package name from a `ClassDesc`. So, I'd like to suggest adding a method to get the internal name from a `ClassDesc` as well.

test/jdk/java/lang/constant/ClassDescTest.java line 136:

> 134: 
> 135:         List<ClassDesc> stringClassDescs = Arrays.asList(ClassDesc.ofDescriptor("Ljava/lang/String;"),
> 136:                                                         ClassDesc.ofInternalName("java/lang/String"),                                                        ClassDesc.of("java.lang", "String"),

Looks like an accidental duplicate of `ClassDesc.of("java.lang", "String")`?
Suggestion:

                                                        ClassDesc.ofInternalName("java/lang/String"),

-------------

PR: https://git.openjdk.org/jdk/pull/9201

From jvernee at openjdk.org  Fri Jun 17 15:31:53 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Jun 2022 15:31:53 GMT
Subject: RFR: 8288667: Reduce runtime of java.text microbenchmarks
In-Reply-To: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>
References: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>
Message-ID: <zMP0d8rb-9NRheigRIsQ5-G9RULKsx6kK-Y8tof4gQc=.8694fdfc-e92b-40d1-94fc-b9095475083b@github.com>

On Fri, 17 Jun 2022 12:59:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Refactor micro using a range of parameters to a simpler benchmark that tests different values in one pass
> - Reduce iterations and their runtimes, but add forks (important to be able to detect run-to-run variation anomalies)
> 
> Just one micro modified in this package, but reduces total runtime from 16 minutes to ~1 minute

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9198

From naoto at openjdk.org  Fri Jun 17 15:45:59 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Jun 2022 15:45:59 GMT
Subject: RFR: 8288628: Unnecessary Hashtable usage in
 ConditionalSpecialCasing
In-Reply-To: <kf1_S_6HBNMCNOvz2IdeQ8QKgtDr-SY2IG1umSb48nI=.c8e4203c-c9b9-422c-b3cf-d68d54ed66dc@github.com>
References: <kf1_S_6HBNMCNOvz2IdeQ8QKgtDr-SY2IG1umSb48nI=.c8e4203c-c9b9-422c-b3cf-d68d54ed66dc@github.com>
Message-ID: <vtT-K8lmJmnOHP9i3nZju5Z2zkrK-ysqjzuGwGOdRkM=.b95e7a65-1ded-45a1-a39a-14ad56e72e47@github.com>

On Wed, 15 Jun 2022 19:49:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> If a thread-safe implementation is not needed, it is recommended to use HashMap in place of Hashtable.
> `ConditionalSpecialCasing.entryTable` is read-only Map which is modified only in `static` block. It means we can safely replace it with HashMap.

Looks good.
I would have refactored the initialization of the static map itself, but it would be for another day.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9172

From naoto at openjdk.org  Fri Jun 17 16:34:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Jun 2022 16:34:52 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
In-Reply-To: <Zy_wOy-3HLx4wVCWoIRjl-ub4W7gBBxTaCriQ-fct4U=.1ead2148-5dcd-4d1b-945d-9df19a58688f@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <Zy_wOy-3HLx4wVCWoIRjl-ub4W7gBBxTaCriQ-fct4U=.1ead2148-5dcd-4d1b-945d-9df19a58688f@github.com>
Message-ID: <MQyNkcRmYXp7Rf3MGMg0hEfdsEPH3tBN31-U_EWJLRw=.60c92c7c-1f9f-4fd2-b6f4-5db8d417714b@github.com>

On Fri, 17 Jun 2022 10:43:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Files.readString has been broken several times by the changes in to String in this area. Would it be possible to survey the tests that we have for this method, esp. the error cases, to see if we need more tests.

I looked for similar test cases but ended up finding nothing. Thus I created a new test case here. Problem is that they are issued through `SharedSecrets`, which are effectively *APIs* but treated as private methods which leads to insufficient testing. I now think that I would add not only b2c test, but also c2b test (for getBytesNoRepl() method) is needed. I will modify the test case to include it.

BTW, I found a spec bug in `Files.writeString()` w/o `Charset` argument, where the `@throws` clause reads: "[IOException](https://urldefense.com/v3/__https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/io/IOException.html__;!!ACWV5N9M2RV99hQ!KboVU1MBg56sylrGOkI7-hqJs9RQOLKUEejCyalJMNSXnmMUGsWmw_UdcI3MAQoK6xhmE-5MlPGfAoMi3zyK5Q$ ) - if an I/O error occurs writing to or creating the file, or the text cannot be encoded using the specified charset", but there is no specified charset there.

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From darcy at openjdk.org  Fri Jun 17 16:36:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Jun 2022 16:36:10 GMT
Subject: RFR: JDK-8288573: Make Executable.getParameterCount() actually
 abstract [v2]
In-Reply-To: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
References: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
Message-ID: <axNbOeNyBap4Mqtj8HvX4fRl8TiC3nl558E7vc8sN30=.7519b6bc-3d37-4796-a24e-66f109027613@github.com>

> Whatever the motivation for how this method was coded when added in JDK 8, since Executable is now a sealed class with Constructor and Method the only allowed subclasses, getParameterCount can be coded as an normal abstract method. (The implementation of getParameterCount in Method and Constructor use fields private to each of those classes so the code cannot easily be shared in Executable).
> 
> Please also review the small accompanying CSR: https://bugs.openjdk.org/browse/JDK-8288630

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9192/files
  - new: https://git.openjdk.org/jdk/pull/9192/files/f1a3116c..131c8c1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9192&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9192&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9192.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9192/head:pull/9192

PR: https://git.openjdk.org/jdk/pull/9192

From lancea at openjdk.org  Fri Jun 17 16:40:15 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 17 Jun 2022 16:40:15 GMT
Subject: RFR: 8288527: broken link in
 java.base/java/util/zip/package-summary.html
Message-ID: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>

Hi all,

Please review this patch for JDK 19 to address a broken link due to PKWare moving the location for APPNOTE.txt

Best,
Lance

-------------

Commit messages:
 - Address broken linke for APPNOTE.txt

Changes: https://git.openjdk.org/jdk19/pull/35/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=35&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288527
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk19/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk19/pull/35

From bpb at openjdk.org  Fri Jun 17 16:50:59 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Jun 2022 16:50:59 GMT
Subject: RFR: 8288527: broken link in
 java.base/java/util/zip/package-summary.html
In-Reply-To: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
References: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
Message-ID: <fTdRp_lVmG9TvQ3mRb6yVQOpR19DDGLgWCPOJmtQ3dQ=.36989ffb-251a-4bbf-808e-5e1f9f427627@github.com>

On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch for JDK 19 to address a broken link due to PKWare moving the location for APPNOTE.txt
> 
> Best,
> Lance

Link verified.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/35

From duke at openjdk.org  Fri Jun 17 16:52:22 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Fri, 17 Jun 2022 16:52:22 GMT
Subject: RFR: 8288596: Random:from() adapter does not delegate to supplied
 generator in all cases
Message-ID: <5VcKHDxn2sRglNaWKpiccebi2CohEde0Mb8JOSQh8m4=.892e04a0-3659-48a3-8776-aebb46d63757@github.com>

Extend delegation by instance returned by Random.from() to all methods exposed by RandomGenerator.

-------------

Commit messages:
 - 8288596: Random:from() adapter does not delegate to supplied generator in all cases

Changes: https://git.openjdk.org/jdk19/pull/36/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=36&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288596
  Stats: 100 lines in 2 files changed: 97 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk19/pull/36.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/36/head:pull/36

PR: https://git.openjdk.org/jdk19/pull/36

From martin at openjdk.org  Fri Jun 17 16:57:56 2022
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 17 Jun 2022 16:57:56 GMT
Subject: RFR: 8288527: broken link in
 java.base/java/util/zip/package-summary.html
In-Reply-To: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
References: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
Message-ID: <vzKxvBaNs2eYRCaaqXqiE_-yQTRl_IAlHHPmEDM54H4=.107e21d1-8504-4a0f-9de0-8146b2dfa3c9@github.com>

On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch for JDK 19 to address a broken link due to PKWare moving the location for APPNOTE.txt
> 
> Best,
> Lance

I would change to the imperfect
https://urldefense.com/v3/__https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT__;!!ACWV5N9M2RV99hQ!NjBbYRAA-LG2RzBsVd-YDZugKK5R3qTS4N_F9ao5zu2tJfNazIBC5hfdhCwUxjMNk_UKKb-bZFvS5sabwxMq1A4$ 
which at least leads to a real document, not a 404

-------------

PR: https://git.openjdk.org/jdk19/pull/35

From naoto at openjdk.org  Fri Jun 17 17:02:00 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Jun 2022 17:02:00 GMT
Subject: RFR: 8288527: broken link in
 java.base/java/util/zip/package-summary.html
In-Reply-To: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
References: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
Message-ID: <x8RpDlPnZFNV0m2iqbnVXr7E9gBR1qcDuTiA5S-7uiI=.117ee3cd-70e9-426c-b327-19ac71a47302@github.com>

On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch for JDK 19 to address a broken link due to PKWare moving the location for APPNOTE.txt
> 
> Best,
> Lance

Would the link https://urldefense.com/v3/__https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT__;!!ACWV5N9M2RV99hQ!O6OoFcGXKhevgs7-fDR7_GwvSzGBYvCx3FT_PI-pTnLfENNjMv5LmqEOBclH08Cs6pUCRJkbwtwMaiiCeLstZQ$  be more appropriate as the "file format specification"?

-------------

PR: https://git.openjdk.org/jdk19/pull/35

From darcy at openjdk.org  Fri Jun 17 17:02:01 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Jun 2022 17:02:01 GMT
Subject: Integrated: JDK-8288573: Make Executable.getParameterCount() actually
 abstract
In-Reply-To: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
References: <HJAXCT1h-0kpAN3MiU1P5P_DirhLkVuFHdOo7v9Oz0w=.2a5dfe49-0d7b-4b90-8355-584939435b13@github.com>
Message-ID: <c04arugFdjvPQFIU6AUmxkexybPu2QI8TzXDKFIljTU=.f7c795b5-e6eb-40ab-90da-6ee0c3a8c851@github.com>

On Thu, 16 Jun 2022 21:21:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Whatever the motivation for how this method was coded when added in JDK 8, since Executable is now a sealed class with Constructor and Method the only allowed subclasses, getParameterCount can be coded as an normal abstract method. (The implementation of getParameterCount in Method and Constructor use fields private to each of those classes so the code cannot easily be shared in Executable).
> 
> Please also review the small accompanying CSR: https://bugs.openjdk.org/browse/JDK-8288630

This pull request has now been integrated.

Changeset: 47b86690
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/47b86690b6672301aa46d4a7b9ced58d17047cc7
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8288573: Make Executable.getParameterCount() actually abstract

Reviewed-by: iris, alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/9192

From asemenyuk at openjdk.org  Fri Jun 17 17:06:06 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Jun 2022 17:06:06 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v3]
In-Reply-To: <OUqYeLjWGZt7ULMS5J5YHEunhUY8RYjsUFg0ssGCo6E=.192a1fae-4d9e-4a49-b723-6df61f5bf008@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
 <OUqYeLjWGZt7ULMS5J5YHEunhUY8RYjsUFg0ssGCo6E=.192a1fae-4d9e-4a49-b723-6df61f5bf008@github.com>
Message-ID: <xoFcMOEgPwOMtj33FXEgM2NoaEOjOqIif_WfOFtYEh0=.c7b1ff3a-9615-46e4-bcab-6506a4e6512b@github.com>

On Fri, 17 Jun 2022 04:07:47 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>>  - Re-fixed as Alexey suggested in https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!If66npa4KIXhh8J0EMMtHPhW-ElCNHLu8weh3DrMRm9S7IeBSkWI4Plcggx6hrN4-M0mANwjXSt1fa4yrIcbKyRziQg$ .
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287971: Throw exception for missing values in .jpackage.xml [v3]

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 307:

> 305:         if (appImage == null) {
> 306:             throw new RuntimeException("Error: --app-image expected");
> 307:         }

Can be simplified to:

Path jpackageXMLFile = AppImageFile.getPathInAppImage(
                Optional.ofNullable(getArgumentValue("--app-image")).map(
                        Path::of).orElseThrow(() -> {
                            return new RuntimeException(
                                    "Error: --app-image expected");
                        }));


And you don't need copy/paste code from `AppImageFile.getPathInAppImage()` below.

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From asotona at openjdk.org  Fri Jun 17 17:03:52 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Jun 2022 17:03:52 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v2]
In-Reply-To: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
Message-ID: <4P4EvpeXJutiMscfB_kohgICuFx0ogBzKHaen0ZjkLE=.269c2ace-23d6-48ed-96c1-e87630598191@github.com>

> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 
> 
> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 
> 
> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
> Class internal name validation and extended ClassDescTest are also parts of this patch.
> 
> CSR is linked with the issue.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/lang/constant/ClassDescTest.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9201/files
  - new: https://git.openjdk.org/jdk/pull/9201/files/3f19648f..51e811f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9201&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9201&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9201.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9201/head:pull/9201

PR: https://git.openjdk.org/jdk/pull/9201

From lancea at openjdk.org  Fri Jun 17 17:10:52 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 17 Jun 2022 17:10:52 GMT
Subject: RFR: 8288527: broken link in
 java.base/java/util/zip/package-summary.html
In-Reply-To: <vzKxvBaNs2eYRCaaqXqiE_-yQTRl_IAlHHPmEDM54H4=.107e21d1-8504-4a0f-9de0-8146b2dfa3c9@github.com>
References: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
 <vzKxvBaNs2eYRCaaqXqiE_-yQTRl_IAlHHPmEDM54H4=.107e21d1-8504-4a0f-9de0-8146b2dfa3c9@github.com>
Message-ID: <KQZqJTywBRIPXvia4OjTI295y-xI1tRz24qUskZKNks=.f4267a9e-7344-4d28-bec7-c4703f864bb5@github.com>

On Fri, 17 Jun 2022 16:55:50 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> I would change to the imperfect
> https://urldefense.com/v3/__https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT__;!!ACWV5N9M2RV99hQ!L1f8haAwUq1MetDxmR_stKKymXfm_VGE_xJ2TysCslYfBFNeeOKsTJNxGKCLYvCx5cH9SCYL47Qgd7XTqMZkrT8$ 
> which at least leads to a real document, not a 404

I thought about that as well.  But given the proposed URL seems to be the main entry point for the APPNOTE, I felt it was safer incase PKWare moves the link again.   With the change by PKWare, it has broken many sites that were pointing to it previously, including the [Library of Congress](https://urldefense.com/v3/__https://www.loc.gov/preservation/digital/formats/fdd/fdd000354.shtml__;!!ACWV5N9M2RV99hQ!L1f8haAwUq1MetDxmR_stKKymXfm_VGE_xJ2TysCslYfBFNeeOKsTJNxGKCLYvCx5cH9SCYL47Qgd7XTB7RV5Xs$ ) which why I chose this direction.

-------------

PR: https://git.openjdk.org/jdk19/pull/35

From asotona at openjdk.org  Fri Jun 17 17:03:54 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Jun 2022 17:03:54 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v2]
In-Reply-To: <26mC6dLmsbCkl1g-MFWKwvU1_JCa5J4KsTi3hUPvEz8=.974ba3b5-86fe-4909-9462-e6713ba17e8a@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
 <26mC6dLmsbCkl1g-MFWKwvU1_JCa5J4KsTi3hUPvEz8=.974ba3b5-86fe-4909-9462-e6713ba17e8a@github.com>
Message-ID: <su1b6qKidDFHC7zMJkroKAVKb0s32lVzeXAXst2ly20=.64596529-102e-4f18-9fd4-83053cb544be@github.com>

On Fri, 17 Jun 2022 15:01:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/lang/constant/ClassDescTest.java
>>   
>>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>
> test/jdk/java/lang/constant/ClassDescTest.java line 136:
> 
>> 134: 
>> 135:         List<ClassDesc> stringClassDescs = Arrays.asList(ClassDesc.ofDescriptor("Ljava/lang/String;"),
>> 136:                                                         ClassDesc.ofInternalName("java/lang/String"),                                                        ClassDesc.of("java.lang", "String"),
> 
> Looks like an accidental duplicate of `ClassDesc.of("java.lang", "String")`?
> Suggestion:
> 
>                                                         ClassDesc.ofInternalName("java/lang/String"),

Thanks for pointing it out, I had to watch my screen quite a long time to see it is hidden behind the corner :)

-------------

PR: https://git.openjdk.org/jdk/pull/9201

From asotona at openjdk.org  Fri Jun 17 17:23:59 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Jun 2022 17:23:59 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v2]
In-Reply-To: <4P4EvpeXJutiMscfB_kohgICuFx0ogBzKHaen0ZjkLE=.269c2ace-23d6-48ed-96c1-e87630598191@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
 <4P4EvpeXJutiMscfB_kohgICuFx0ogBzKHaen0ZjkLE=.269c2ace-23d6-48ed-96c1-e87630598191@github.com>
Message-ID: <iWholz6_IGXuQ3-X0YTFdse-sMOjJdYyG7jV0fAQN9o=.2cba62fe-85c3-44ac-92eb-1c7e1cd92d9e@github.com>

On Fri, 17 Jun 2022 17:03:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 
>> 
>> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 
>> 
>> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
>> Class internal name validation and extended ClassDescTest are also parts of this patch.
>> 
>> CSR is linked with the issue.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/lang/constant/ClassDescTest.java
>   
>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

My initial thoughts were the same. Passing internal class name through the ClassDesc in and out is very frequent when using ASM library or similar.
However the problem here is that not all ClassDesc have internal class name, it can be applied only to non-primitive and non-array descriptors.
Proposed approach to work with class names in various forms (which can be even more tricky with upcoming Valhalla) is to use ClassDesc as the primary class-describing entity (instead of any form of String).
 
While constructing ClassDesc from various other forms (internal names, binary names, derivation from other ClassDesc, getting it from Class, etc...) is mostly user responsibility. 
Different ways of ClassDesc serialization in various contexts (method descriptor, class reference, annotation, etc...) should be always responsibility of the processing library.

For ASM case I would rather recommend a util class directly converting ClassDesc to ASM Type, while passing ClassDesc through String internal name is risky and not covering all cases.

-------------

PR: https://git.openjdk.org/jdk/pull/9201

From jvernee at openjdk.org  Fri Jun 17 17:27:57 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Jun 2022 17:27:57 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v2]
In-Reply-To: <4P4EvpeXJutiMscfB_kohgICuFx0ogBzKHaen0ZjkLE=.269c2ace-23d6-48ed-96c1-e87630598191@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
 <4P4EvpeXJutiMscfB_kohgICuFx0ogBzKHaen0ZjkLE=.269c2ace-23d6-48ed-96c1-e87630598191@github.com>
Message-ID: <VbrAlvuH6_oN9L4FFZ94Jl0FXPoQ6NBALZAZfzmNEso=.baa01feb-79db-451e-95a4-8e3f502f39ee@github.com>

On Fri, 17 Jun 2022 17:03:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 
>> 
>> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 
>> 
>> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
>> Class internal name validation and extended ClassDescTest are also parts of this patch.
>> 
>> CSR is linked with the issue.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/lang/constant/ClassDescTest.java
>   
>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

Thanks for explaining.

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9201

From martin at openjdk.org  Fri Jun 17 17:56:01 2022
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 17 Jun 2022 17:56:01 GMT
Subject: RFR: 8288527: broken link in
 java.base/java/util/zip/package-summary.html
In-Reply-To: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
References: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
Message-ID: <32KYIExcXzadsdYLeDLduIwUB1-HC3EM_sl2XP-EQEo=.5dd90422-1208-4551-8424-c4ac5c23490d@github.com>

On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch for JDK 19 to address a broken link due to PKWare moving the location for APPNOTE.txt
> 
> Best,
> Lance

I've never communicated with pkware, but this might be a good first time to email zipformat at pkware.com, referencing this problem.  There's a good chance PKWARE will simply fix their 404s.

-------------

PR: https://git.openjdk.org/jdk19/pull/35

From lancea at openjdk.org  Fri Jun 17 18:03:53 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 17 Jun 2022 18:03:53 GMT
Subject: RFR: 8288527: broken link in
 java.base/java/util/zip/package-summary.html
In-Reply-To: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
References: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
Message-ID: <W8-xUz_015MWywNLprR_GErWKH1lEYSqlHUl0oiQ6PQ=.6b4fbd0b-5b22-468a-a381-5641b093ceb7@github.com>

On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch for JDK 19 to address a broken link due to PKWare moving the location for APPNOTE.txt
> 
> Best,
> Lance

> I've never communicated with pkware, but this might be a good first time to email [zipformat at pkware.com](mailto:zipformat at pkware.com), referencing this problem. There's a good chance PKWARE will simply fix their 404s.

I think that is a reasonable suggestion and I will do that.  Given we are in the end game for JDK 19, I would like to move forward with this change.  We can adjust later or for JDK 20, but we are trying to close down issues which are must fix, in which this is one.

-------------

PR: https://git.openjdk.org/jdk19/pull/35

From mcimadamore at openjdk.org  Fri Jun 17 18:19:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:19:22 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!PURf47Tx3IHsn4r3Q6t3YUMp-kirS2J1rdJ0hx_W3gPaJy1oHsJ_LsQEmyMD_isGigYq82vk18K6ERWiCmNns5bTKx4HWA$ 

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into memory_session_cleanup
 - Fix issue in Direct-X-Buffer template
 - Simplify and drop the state class
 - Add missing files
 - Initial push

-------------

Changes: https://git.openjdk.org/jdk19/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=01
  Stats: 543 lines in 28 files changed: 48 ins; 110 del; 385 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:25:24 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:25:24 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v3]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <5qDmnUurtGSqPny2rf0qUp3wafWfpRRvpMJyI_r0VkM=.20cd2a71-bed0-4ef7-80ca-fd6e9efc2528@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!Iad5ZYIBKo6G8OmmBEpmRZekLOyVUfHNgi9JARpVmrUedI3fLRC3VvMwy4h-WDdnsbZ71KGxv99JP5gzdsD4RP7upCEDuQ$ 

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Unify heap vs. implicit scopes

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/22/files
  - new: https://git.openjdk.org/jdk19/pull/22/files/be81918f..b605aeab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=01-02

  Stats: 12 lines in 3 files changed: 3 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:25:25 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:25:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>
Message-ID: <cCTCVBbOOKw_cFTiqNt4rYCnWYWAGKo5S3kiapdTGxI=.663dbdb4-b47c-4b00-909d-156ea8b42ecf@github.com>

On Fri, 17 Jun 2022 18:19:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!P7sU9UDKU8tT1iAO9LVvEHY405JOZwI2z8rLL3-ARQTa7ikW-1bYQJvtSC2KTMkZZ2-OCKKdpbjG5qunW-7bt6qpT3197Q$ 
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into memory_session_cleanup
>  - Fix issue in Direct-X-Buffer template
>  - Simplify and drop the state class
>  - Add missing files
>  - Initial push

I ended up simplifying this PR, by selecting some of the improvement from the previous patch:
* simplify handling of "readOnly" for memory segments
* Remove duplication between `sessionImpl` and `session` accessors, by making non-closeable views also be subclasses of `MemorySessionImpl`
* use better naming for the `checkValidState` methods - now the plain method is the method that should be used by all clients, while `checkValidStateRaw` is the method that should only be used in ScopedMemoryAccess
* unify exception handling, and fix issues around WrongThreadException not being handled correctly in ScopedMemoryAccess

-------------

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:39:03 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:39:03 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!JbqlSnOAQCnoGfGjSR9ODas1vyjzkF4ONduTcHSVCWdjG3CB4-ZhX8llEZg_0mu3-AqmRhVAWY5lZS-IDBMIEaKzWm2ckQ$ 

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Revert implicit vs. heap session changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/22/files
  - new: https://git.openjdk.org/jdk19/pull/22/files/b605aeab..a6841b24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=02-03

  Stats: 14 lines in 5 files changed: 4 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From martin at openjdk.org  Fri Jun 17 19:17:00 2022
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 17 Jun 2022 19:17:00 GMT
Subject: RFR: 8288527: broken link in
 java.base/java/util/zip/package-summary.html
In-Reply-To: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
References: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
Message-ID: <EFW8zYhiN2EC2UQ5FCcBbscOMToh2K9Z01jpKvg7JbI=.0f42db21-be2a-4f7d-bfd0-69eb61a512ae@github.com>

On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch for JDK 19 to address a broken link due to PKWare moving the location for APPNOTE.txt
> 
> Best,
> Lance

Marked as reviewed by martin (Reviewer).

I'm pleasantly surprised broken doc links are a release blocker - if only pkware had the same policy!

-------------

PR: https://git.openjdk.org/jdk19/pull/35

From mcimadamore at openjdk.org  Fri Jun 17 20:42:59 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 20:42:59 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
Message-ID: <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>

On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!PTgf-96nF99J6u5zXvgIK8gDa_y-GwCjRZ0uALQAk5zZJ7sIb8lIrdasF6oRY-U2YqR3JXkv4CFtxlWidLpOuYm5qPP4KA$ 
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert implicit vs. heap session changes

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 530:

> 528:             bufferSession = bufferSegment.session;
> 529:         } else {
> 530:             bufferSession = MemorySessionImpl.heapSession(bb);

I think this should be tweaked (as part of another patch). Buffer segments should have same lifecycle of array segments - and array segments have the global session. This is because an array segment always keeps the underlying array alive. I think we should enhance memory segment implementation (esp. that of native segments), so that it can be used to keep other objects alive. This would be useful also in the `loaderLookup` where we create another of those odd sessions - in that case we should just say that the segments returned by loader lookup have global scope, and keep the loader alive.

-------------

PR: https://git.openjdk.org/jdk19/pull/22

From almatvee at openjdk.org  Fri Jun 17 21:49:55 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 17 Jun 2022 21:49:55 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v4]
In-Reply-To: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
Message-ID: <w074RY_VQrNX4OCAXdl2FKrd46ygqyDz25aUP4-AWbQ=.7a5ccbbe-d80e-4750-9cbc-fce1cbb60459@github.com>

> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!LN6NRTeW0ncedaBw8wNkDvWsY7haMeJTzuSC4dsP1nBOzWYLKB3-vd2Kai_PP_xq482TZ8ZfXiUEmg2xwSLTYQF3Bw$ .

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8287971: Throw exception for missing values in .jpackage.xml [v4]

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/9/files
  - new: https://git.openjdk.org/jdk19/pull/9/files/2199f4e2..d489ee60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=9&range=02-03

  Stats: 25 lines in 2 files changed: 0 ins; 15 del; 10 mod
  Patch: https://git.openjdk.org/jdk19/pull/9.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/9/head:pull/9

PR: https://git.openjdk.org/jdk19/pull/9

From almatvee at openjdk.org  Fri Jun 17 21:49:58 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 17 Jun 2022 21:49:58 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v3]
In-Reply-To: <xoFcMOEgPwOMtj33FXEgM2NoaEOjOqIif_WfOFtYEh0=.c7b1ff3a-9615-46e4-bcab-6506a4e6512b@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
 <OUqYeLjWGZt7ULMS5J5YHEunhUY8RYjsUFg0ssGCo6E=.192a1fae-4d9e-4a49-b723-6df61f5bf008@github.com>
 <xoFcMOEgPwOMtj33FXEgM2NoaEOjOqIif_WfOFtYEh0=.c7b1ff3a-9615-46e4-bcab-6506a4e6512b@github.com>
Message-ID: <e-TyDsIkq4MbsFbCvm48Fo26MOaW_vqSZhpcGd5ynos=.f5531312-c503-4b2e-b713-c6fcc7eb998b@github.com>

On Fri, 17 Jun 2022 17:01:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8287971: Throw exception for missing values in .jpackage.xml [v3]
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 307:
> 
>> 305:         if (appImage == null) {
>> 306:             throw new RuntimeException("Error: --app-image expected");
>> 307:         }
> 
> Can be simplified to:
> 
> Path jpackageXMLFile = AppImageFile.getPathInAppImage(
>                 Optional.ofNullable(getArgumentValue("--app-image")).map(
>                         Path::of).orElseThrow(() -> {
>                             return new RuntimeException(
>                                     "Error: --app-image expected");
>                         }));
> 
> 
> And you don't need copy/paste code from `AppImageFile.getPathInAppImage()` below.

Done. I also switched to use AppImageFile.getVersion() and AppImageFile.getPlatform().

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From mcimadamore at openjdk.org  Fri Jun 17 21:50:05 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 21:50:05 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
 <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>
Message-ID: <cw0qgrS7-SFUAkNN-b0fUDZRZJaqTUO8YTAeqohDimk=.1e6ee1ad-4499-4578-b2c8-4087b68fdaae@github.com>

On Fri, 17 Jun 2022 20:39:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert implicit vs. heap session changes
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 530:
> 
>> 528:             bufferSession = bufferSegment.session;
>> 529:         } else {
>> 530:             bufferSession = MemorySessionImpl.heapSession(bb);
> 
> I think this should be tweaked (as part of another patch). Buffer segments should have same lifecycle of array segments - and array segments have the global session. This is because an array segment always keeps the underlying array alive. I think we should enhance memory segment implementation (esp. that of native segments), so that it can be used to keep other objects alive. This would be useful also in the `loaderLookup` where we create another of those odd sessions - in that case we should just say that the segments returned by loader lookup have global scope, and keep the loader alive.

I've filed a dependent PR for this: https://urldefense.com/v3/__https://github.com/openjdk/jdk19/pull/39__;!!ACWV5N9M2RV99hQ!LQxkLIaI9ySs-LLe36ur5jBGBzDzPz3HI6H08K6ip4I6R8lrvK5XPEanQPSunGcdyVgWqnWwrlTg4c0Z5XD7vAYTBDZvZw$ 

-------------

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 21:53:29 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 21:53:29 GMT
Subject: RFR: 8288697: Clarify lifecycle of buffer segments and loader lookup
Message-ID: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>

This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases:

* when a buffer segment is created, to keep the original buffer instance reachable
* when a loader symbol lookup is created, to keep the classloader instance reachable

Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model.

This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments.

This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case.

-------------

Depends on: https://git.openjdk.org/jdk19/pull/22

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk19/pull/39/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=39&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288697
  Stats: 47 lines in 8 files changed: 5 ins; 15 del; 27 mod
  Patch: https://git.openjdk.org/jdk19/pull/39.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/39/head:pull/39

PR: https://git.openjdk.org/jdk19/pull/39

From mcimadamore at openjdk.org  Fri Jun 17 22:12:54 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 22:12:54 GMT
Subject: RFR: 8288697: Clarify lifecycle of buffer segments and loader
 lookup
In-Reply-To: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
References: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
Message-ID: <9BbVhkYmwTPt9m69BEx-CVPGARA2Iv6t2pvRVljif5Q=.15c9ab45-7f2b-46ce-8fa3-a66984f17fab@github.com>

On Fri, 17 Jun 2022 21:39:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases:
> 
> * when a buffer segment is created, to keep the original buffer instance reachable
> * when a loader symbol lookup is created, to keep the classloader instance reachable
> 
> Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model.
> 
> This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments.
> 
> This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case.

After thinking some more, I realized that going down this path might cause reachability issues when said segments are dereferenced (from ScopedMemoryAccess) or when they are passed to native function (using linker). Both system keep the session reachable, not the segment. Moving back to draft for now.

-------------

PR: https://git.openjdk.org/jdk19/pull/39

From serb at openjdk.org  Fri Jun 17 23:14:53 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Jun 2022 23:14:53 GMT
Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <eg6oa0mM1gHJ1Z8On__L6JoO5xe6Rd_6zXtV-POrgGU=.16037f2f-8574-4e44-b63a-caa1bffb49d0@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
 <eg6oa0mM1gHJ1Z8On__L6JoO5xe6Rd_6zXtV-POrgGU=.16037f2f-8574-4e44-b63a-caa1bffb49d0@github.com>
Message-ID: <nQ7yJdmcRUB23SBr9X9xSzQacsMsgtaN18iC99B02uo=.4767fb7e-46dc-441b-a6c1-50aef550e868@github.com>

On Fri, 13 May 2022 01:54:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
>> 
>> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
>> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.
>
> Thank you everyone for the reviews.

@jaikiran Do you have a plan to backport this fix to the 17 and below?

-------------

PR: https://git.openjdk.org/jdk/pull/8675

From asemenyuk at openjdk.org  Sat Jun 18 00:03:54 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Jun 2022 00:03:54 GMT
Subject: RFR: 8287971: Throw exception for missing values in .jpackage.xml
 [v4]
In-Reply-To: <w074RY_VQrNX4OCAXdl2FKrd46ygqyDz25aUP4-AWbQ=.7a5ccbbe-d80e-4750-9cbc-fce1cbb60459@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
 <w074RY_VQrNX4OCAXdl2FKrd46ygqyDz25aUP4-AWbQ=.7a5ccbbe-d80e-4750-9cbc-fce1cbb60459@github.com>
Message-ID: <gpfnO28RUaRefVvtxIfK3yl1pNjqtI-rSAfOgXLhaAg=.80976c1b-2787-4c4c-aac2-86e04e548095@github.com>

On Fri, 17 Jun 2022 21:49:55 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>>  - Re-fixed as Alexey suggested in https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!L9Wx4XLqNXqBW6JfLUB-UtOMKv2w4XEjkELvJNW45-VaMix5WZFxGhh4tKwKBcy1FZ7C3UVb9p2HqEBa2sIhZItOEc0$ .
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287971: Throw exception for missing values in .jpackage.xml [v4]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From naoto at openjdk.org  Sat Jun 18 00:31:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 18 Jun 2022 00:31:06 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v2]
In-Reply-To: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
Message-ID: <_g36T1LwpXJmJ91PiJ4WQMjhk08mMMjPNzh5hdhV418=.08bb181d-60a8-4e86-a9e9-59203b2eabf1@github.com>

> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added c2b test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9193/files
  - new: https://git.openjdk.org/jdk/pull/9193/files/ea8618fa..e1afd207

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=00-01

  Stats: 140 lines in 2 files changed: 85 ins; 55 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9193/head:pull/9193

PR: https://git.openjdk.org/jdk/pull/9193

From duke at openjdk.org  Sat Jun 18 02:33:58 2022
From: duke at openjdk.org (kristylee88)
Date: Sat, 18 Jun 2022 02:33:58 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v2]
In-Reply-To: <_g36T1LwpXJmJ91PiJ4WQMjhk08mMMjPNzh5hdhV418=.08bb181d-60a8-4e86-a9e9-59203b2eabf1@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <_g36T1LwpXJmJ91PiJ4WQMjhk08mMMjPNzh5hdhV418=.08bb181d-60a8-4e86-a9e9-59203b2eabf1@github.com>
Message-ID: <Kumw0hFMIjk5fxGB4VF3YWQISjrNOM-5cZZbd5CHww0=.93a77b82-a791-4886-8ad5-71a57a7c2d8f@github.com>

On Sat, 18 Jun 2022 00:31:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
>> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added c2b test

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From xuelei at openjdk.org  Sat Jun 18 05:55:32 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 18 Jun 2022 05:55:32 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8907__;!!ACWV5N9M2RV99hQ!NIUTecPFCnKlByf3ypfW7DMsH2RaETuGUtn0v0H-l5eETSbdGe8GVUqQaFZCdzIeuDEiRNMvVjCcoGqo-V7amUc$ ).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Master
 - use Reference.refersTo
 - remove trailing whitespaces
 - use timeout factor
 - Merge
 - Merge master
 - Merge
 - add timeout parameter
 - rollback is not in this branch
 - rollback JDK-8287384
 - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282

-------------

Changes: https://git.openjdk.org/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=09
  Stats: 93 lines in 10 files changed: 14 ins; 38 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.org/jdk/pull/8979

From xuelei at openjdk.org  Sat Jun 18 06:03:54 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 18 Jun 2022 06:03:54 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v9]
In-Reply-To: <STM_EdzJAndHF8f7AXy1Kx3RMOT0IN4rvpjbsDqECb0=.e4a78277-d1ca-494e-855b-5c4b5541a76c@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <Z0OeNFDtTr2kYfv-HpQm0gRj8v2rxWETRUqWrgEWR7M=.f7e01958-6284-493f-9da7-9ecdb12d9e84@github.com>
 <STM_EdzJAndHF8f7AXy1Kx3RMOT0IN4rvpjbsDqECb0=.e4a78277-d1ca-494e-855b-5c4b5541a76c@github.com>
Message-ID: <tHroVfSb3ZE1TjOAPHeaqPRSwjjEp-l6wH-enontRDY=.86887e2d-8aa7-4902-ab54-1520ca4239c6@github.com>

On Thu, 16 Jun 2022 16:08:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove trailing whitespaces
>
> test/jdk/java/io/ObjectStreamClass/TestOSCClassLoaderLeak.java line 64:
> 
>> 62:         assertNotNull(myOwnClassLoaderWeakReference.get());
>> 63: 
>> 64:         assertTrue(ForceGC.wait(() -> myOwnClassLoaderWeakReference.get() == null));
> 
> The call to ref.get() can create a strong reference to the object; depending on the timing it might interfere with the GC in process.
> `ref.refersTo(null)` is preferred over `ref.get() == null` 
> 
> Here and all subsequent changes.

Good point.  I learned a lot these days from PRs comments!  Thank you!

The patch is changed to use refersTo().

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From jpai at openjdk.org  Sat Jun 18 07:28:53 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 Jun 2022 07:28:53 GMT
Subject: RFR: 8288628: Unnecessary Hashtable usage in
 ConditionalSpecialCasing
In-Reply-To: <kf1_S_6HBNMCNOvz2IdeQ8QKgtDr-SY2IG1umSb48nI=.c8e4203c-c9b9-422c-b3cf-d68d54ed66dc@github.com>
References: <kf1_S_6HBNMCNOvz2IdeQ8QKgtDr-SY2IG1umSb48nI=.c8e4203c-c9b9-422c-b3cf-d68d54ed66dc@github.com>
Message-ID: <RZVEMq3rtVGOIV--b8sfivmLr1rCVn-x98RtMU-E9Yw=.762be3d5-b44b-4292-987f-df7a6cb4aad8@github.com>

On Wed, 15 Jun 2022 19:49:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> If a thread-safe implementation is not needed, it is recommended to use HashMap in place of Hashtable.
> `ConditionalSpecialCasing.entryTable` is read-only Map which is modified only in `static` block. It means we can safely replace it with HashMap.

Changing this to `HashMap` now means that usages of this might have to check for `null` values returned by the `Map` APIs. Looking at the usage of `entryTable`, it appears that there are relevant `null` checks already in place, plus I don't see any code in this class which directly returns the values from the `entryTable` to callers of this class.

So the change looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9172

From turbanoff at gmail.com  Sat Jun 18 19:35:42 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Sat, 18 Jun 2022 22:35:42 +0300
Subject: Always true condition in ClassSpecializer constructor
Message-ID: <CAF+DQ5dO0LUg8VXhBBtzxkSv_jVOEqC-PvOmpKJm+E6fx72q8Q@mail.gmail.com>

Hello.
I found suspicious null check in java.lang.invoke.ClassSpecializer constructor:

S topSpecies = null;
if (tsk != null && topSpecies == null) {
    // if there is a key, build the top species if needed:
    topSpecies = findSpecies(tsk);
}

'null' is assigned to the 'topSpecies' variable and then, in the next
statement, it's compared with 'null'. Second part of the condition
will always be true.


Andrey Turbanov

From duke at openjdk.org  Sun Jun 19 00:02:49 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 00:02:49 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v5]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <YKOKUuY7IeoCf20kEISy0ZTnhDx_sH6AYQVY_k5pl74=.0886105a-2d89-4694-b15d-f5fed90fc5fb@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:

  Add JMH

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/1daaadac..2c873856

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=03-04

  Stats: 83 lines in 1 file changed: 83 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Sun Jun 19 00:16:33 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 00:16:33 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v6]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <NL-04RpHv9FYIuJoo09lBHhtAkH9dq43d7dHbLWrBoU=.a62c43f1-17c0-4666-b40e-2c6f54fa0eab@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:

  Split out PRNG benchmarks into org.openjdk.bench.java.util.random

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/2c873856..13c6d22c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=04-05

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Sun Jun 19 00:30:59 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Sun, 19 Jun 2022 00:30:59 GMT
Subject: RFR: 8288667: Reduce runtime of java.text microbenchmarks
In-Reply-To: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>
References: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>
Message-ID: <UhJEa1owgurj1mxQHl4GQAwohezPRxRWarzueW6GJRg=.af2ae26e-9e6f-4d56-9b88-d71629da7917@github.com>

On Fri, 17 Jun 2022 12:59:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Refactor micro using a range of parameters to a simpler benchmark that tests different values in one pass
> - Reduce iterations and their runtimes, but add forks (important to be able to detect run-to-run variation anomalies)
> 
> Just one micro modified in this package, but reduces total runtime from 16 minutes to ~1 minute

test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 65:

> 63:     @Benchmark
> 64:     public void testDefNumberFormatter(final Blackhole blackhole) {
> 65:         for (double value : values) {

Should this now include `@OperationsPerInvocation(13)` since the loop is performing multiple operations per invocation?

-------------

PR: https://git.openjdk.org/jdk/pull/9198

From duke at openjdk.org  Sun Jun 19 00:33:30 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 00:33:30 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v7]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <PlDgsy1IuJtL_bg5g9IKgMm9uFskrv8jg1kX2092ZSg=.2a9042a8-c7c5-49b8-b229-dc20f69c2bce@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick 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:

  Split out PRNG benchmarks into org.openjdk.bench.java.util.random

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/13c6d22c..f84e0e03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Sun Jun 19 00:43:31 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 00:43:31 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v8]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <XNkaFHuZmjRVmBjFkTOR3IvKADGCVJ8S1d7flRatLVs=.62326121-dc89-434f-8f05-84a0455c0334@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:

  Bugfix: need a thread-local instance for throughput test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/f84e0e03..d903efe5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=06-07

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Sun Jun 19 00:49:31 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 00:49:31 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v9]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <MXxmuJSEKbAPJvJA6Y-2Hc-iCdmItMWzBmzivOZtfDo=.3b91583a-ff13-464c-b3ce-6324d2cc032c@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:

  More sensible benchmark-mode settings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/d903efe5..f74b6872

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=07-08

  Stats: 5 lines in 1 file changed: 4 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Sun Jun 19 00:56:36 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 00:56:36 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v10]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <-4GkK7xXZK6kNIAV0zeaBFEbOdv_tEX0VxuEpX8e4Es=.4a71f6b1-0368-4476-b74c-38cc7db6a43c@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick 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:

  More sensible benchmark-mode settings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/f74b6872..db9ff01d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Sun Jun 19 01:16:39 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 01:16:39 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v11]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <iPxD2oPUbqcXx0iCSnWnKT1L6D0ol_A8kjF4TkWdDtQ=.2f203397-94eb-4963-9d81-fe8486e81552@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Bugfix: need a thread-local instance for throughput test"
  
  This reverts commit d903efe57225e916a5450ac31437123050e3377c.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/db9ff01d..cab6b5bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=09-10

  Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Sun Jun 19 22:33:35 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 22:33:35 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v12]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <U5tTppWium-CtimnlZiO6HZpgQwh1CE1dwcG8GkIqyo=.e385ff5b-465a-4eae-9020-b5607d1feac1@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:

  Weaken contract of computeWinsorizedNextExponential to save max/min calls

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/cab6b5bb..5919faeb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=10-11

  Stats: 17 lines in 1 file changed: 0 ins; 5 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Sun Jun 19 23:30:32 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 23:30:32 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v13]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <KFV7vbutWjsI-LUBT4_3dNK_-rDI4TgdEiSRFDFxKW8=.0d224a25-9ead-49c7-a975-f2b8b0713dde@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:

  Simplify Javadoc description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/5919faeb..e3f55542

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=11-12

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Sun Jun 19 23:38:36 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 19 Jun 2022 23:38:36 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v14]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <bLPYyKu-bV3Blq9kH9-YW_uc6ltGFiogng4u-_Qeq68=.8d90a88e-0b6c-434a-b290-bc6441887781@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:

  Rewrite Javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/e3f55542..d1c9bafd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=12-13

  Stats: 29 lines in 1 file changed: 18 ins; 11 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From pvssasikala at gmail.com  Mon Jun 20 03:29:08 2022
From: pvssasikala at gmail.com (Sasi Peri)
Date: Sun, 19 Jun 2022 23:29:08 -0400
Subject: Inconsistencies in the return value (type) of string functions
 toLower() and toUpper().
Message-ID: <CALR+58k+EYsAsLtTA9SNhYRGFq4pxkS8RoemFGVAnxR7zF=dvQ@mail.gmail.com>

Hello,

*Issue details*

toLower() and toUpper() return a new String object sometimes and sometimes
a string literal, based on the input string type (and also sometimes based
on the VM/jdk type)



For example

-       HotSpot VM, If the input is a string literal, which *already* has
all ?lower case letters?, toLower would return the same string literal, if
not it will convert all letters to lower and returns a new String() object.

-       However, openJ9 (e.g. IBM jdk8 ditsro, ) always returns a new
String object not a literal.



This behavior is non deterministic, inconsistent, you cannot always predict
if the outcome is a new string object OR an interned string from pool
(particularly from unit testing stand point).



*Sample code to show case above behavior*

*package* com.bugs;

*import* java.util.Locale;



*public* *class* TestStringFunction

{



*  public* *static* *void* main(String args[])

  {

    String s1 = "abc";

    String s2 = "ABC";



    System.*out*.println("----- case: when string already lower ----------"
);

*    testIfEqualsLower*(s1);



    System.*out*.println("----- case: when string with upper case
----------");

*    testIfEqualsLower*(s2);





  }



*  private* *static* *void* testIfEqualsLower(String s)

  {



*     if*(s.toLowerCase() == "abc")

     {

        System.*out*.println("YES - literal");

     }



*     if*(s.toLowerCase().equals("abc"))

     {

        System.*out*.println("YES ? equals func");

     }



   }

}





*Out put*



----- case: when string already lower ----------

YES - literal

YES ? equals func



----- case: when string with upper case ----------

YES - equals func





*Why this could be an issue or bug prone?*

-       Suppose an unit test is written, for a method doAThing(), that has
toLower/Upper conversions in the middle of the code somewhere, and apply
logic based on that.
-       Though general guidance to compare unknown string (types) is always
using equals, sometimes developers can make a mistake (i.e. suppose they
used == in a unit test)
-       If the code review did not catch it, this behavior can cause all
unit tests passed, as long unit test is written with ?small case string? as
input.
-       It could potentially make it to prod, and can be realized only when
it hits a case when input string has all uppercase OR mixed case letters,
which could be after multiple sprints, at the point not easily detectable.



*Suggestion*

It would be great if we always can make a new String() and return always a
String object not an interned string sometimes, as openJ9/ibm does (with
some jdk versions).

It may not be good idea, to always return ?.interned? value and fill up the
intern pool, for these short-lived objects (as they are most times).



If this is agreed/approved, I can make a change and commit.


Regards

- SP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220619/4810e963/attachment-0001.htm>

From pvssasikala at gmail.com  Mon Jun 20 03:45:08 2022
From: pvssasikala at gmail.com (Sasi Peri)
Date: Sun, 19 Jun 2022 23:45:08 -0400
Subject: Inconsistencies in the return value (type) of string functions
 toLower() and toUpper().
In-Reply-To: <CALR+58k+EYsAsLtTA9SNhYRGFq4pxkS8RoemFGVAnxR7zF=dvQ@mail.gmail.com>
References: <CALR+58k+EYsAsLtTA9SNhYRGFq4pxkS8RoemFGVAnxR7zF=dvQ@mail.gmail.com>
Message-ID: <CALR+58ma2=miUWHu3207Ds7KgyDiUwmJ6VWtm1on49DN1GcjPg@mail.gmail.com>

   - Attaching the sample code file (same code copied inline in the above
   issue)
   - Tested with hotspot vm JDK 17 temu and adopt JDK 8, for the above
   non-deterministic behavior.
   - Also tested with opnJ9 (IBM, jdk8), which returned always a new
   String, so == comparison will always fail and only .equals will work.


On Sun, Jun 19, 2022 at 11:29 PM Sasi Peri <pvssasikala at gmail.com> wrote:

> Hello,
>
> *Issue details*
>
> toLower() and toUpper() return a new String object sometimes and sometimes
> a string literal, based on the input string type (and also sometimes based
> on the VM/jdk type)
>
>
>
> For example
>
> -       HotSpot VM, If the input is a string literal, which *already* has
> all ?lower case letters?, toLower would return the same string literal, if
> not it will convert all letters to lower and returns a new String() object.
>
> -       However, openJ9 (e.g. IBM jdk8 ditsro, ) always returns a new
> String object not a literal.
>
>
>
> This behavior is non deterministic, inconsistent, you cannot always
> predict if the outcome is a new string object OR an interned string from
> pool (particularly from unit testing stand point).
>
>
>
> *Sample code to show case above behavior*
>
> *package* com.bugs;
>
> *import* java.util.Locale;
>
>
>
> *public* *class* TestStringFunction
>
> {
>
>
>
> *  public* *static* *void* main(String args[])
>
>   {
>
>     String s1 = "abc";
>
>     String s2 = "ABC";
>
>
>
>     System.*out*.println("----- case: when string already lower
> ----------");
>
> *    testIfEqualsLower*(s1);
>
>
>
>     System.*out*.println("----- case: when string with upper case
> ----------");
>
> *    testIfEqualsLower*(s2);
>
>
>
>
>
>   }
>
>
>
> *  private* *static* *void* testIfEqualsLower(String s)
>
>   {
>
>
>
> *     if*(s.toLowerCase() == "abc")
>
>      {
>
>         System.*out*.println("YES - literal");
>
>      }
>
>
>
> *     if*(s.toLowerCase().equals("abc"))
>
>      {
>
>         System.*out*.println("YES ? equals func");
>
>      }
>
>
>
>    }
>
> }
>
>
>
>
>
> *Out put*
>
>
>
> ----- case: when string already lower ----------
>
> YES - literal
>
> YES ? equals func
>
>
>
> ----- case: when string with upper case ----------
>
> YES - equals func
>
>
>
>
>
> *Why this could be an issue or bug prone?*
>
> -       Suppose an unit test is written, for a method doAThing(), that
> has toLower/Upper conversions in the middle of the code somewhere, and
> apply logic based on that.
> -       Though general guidance to compare unknown string (types) is
> always using equals, sometimes developers can make a mistake (i.e. suppose
> they used == in a unit test)
> -       If the code review did not catch it, this behavior can cause all
> unit tests passed, as long unit test is written with ?small case string? as
> input.
> -       It could potentially make it to prod, and can be realized only
> when it hits a case when input string has all uppercase OR mixed case
> letters, which could be after multiple sprints, at the point not easily
> detectable.
>
>
>
> *Suggestion*
>
> It would be great if we always can make a new String() and return always a
> String object not an interned string sometimes, as openJ9/ibm does (with
> some jdk versions).
>
> It may not be good idea, to always return ?.interned? value and fill up
> the intern pool, for these short-lived objects (as they are most times).
>
>
>
> If this is agreed/approved, I can make a change and commit.
>
>
> Regards
>
> - SP
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220619/6a81171e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestStringToLowerCase.java
Type: application/octet-stream
Size: 603 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220619/6a81171e/TestStringToLowerCase-0001.java>

From ecki at zusammenkunft.net  Mon Jun 20 03:57:13 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 20 Jun 2022 03:57:13 +0000
Subject: Inconsistencies in the return value (type) of string functions
 toLower() and toUpper().
In-Reply-To: <CALR+58ma2=miUWHu3207Ds7KgyDiUwmJ6VWtm1on49DN1GcjPg@mail.gmail.com>
References: <CALR+58k+EYsAsLtTA9SNhYRGFq4pxkS8RoemFGVAnxR7zF=dvQ@mail.gmail.com>
 <CALR+58ma2=miUWHu3207Ds7KgyDiUwmJ6VWtm1on49DN1GcjPg@mail.gmail.com>
Message-ID: <DBAP193MB11463169857AB5CF981C4766FFB09@DBAP193MB1146.EURP193.PROD.OUTLOOK.COM>

Since Sting instances are immutable Idendity should not matter and It is wrong in most cases to rely on string Idendity (==) and the APIs are intentionally not making any assertions about Idendity and/or interning of strings (also the most efficient implementation would not return a new instance if not needed, this also applies to replace or escape or similar functions - just don?t rely on it).

Gruss
Bernd
--
https://urldefense.com/v3/__http://bernd.eckenfels.net__;!!ACWV5N9M2RV99hQ!OCDLUrMtQ8iDuN5ZBlmPgMeJIq1GGLAOuq8CauKNxaqHh-RiIaLCGL-ScrHHeUpLQyeWzm4wj0SMmsGK9Lhbcm5T1Q$ 
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.org> im Auftrag von Sasi Peri <pvssasikala at gmail.com>
Gesendet: Monday, June 20, 2022 5:45:08 AM
An: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Betreff: Re: Inconsistencies in the return value (type) of string functions toLower() and toUpper().


  *   Attaching the sample code file (same code copied inline in the above issue)
  *   Tested with hotspot vm JDK 17 temu and adopt JDK 8, for the above non-deterministic behavior.
  *   Also tested with opnJ9 (IBM, jdk8), which returned always a new String, so == comparison will always fail and only .equals will work.

On Sun, Jun 19, 2022 at 11:29 PM Sasi Peri <pvssasikala at gmail.com<mailto:pvssasikala at gmail.com>> wrote:
Hello,


Issue details

toLower() and toUpper() return a new String object sometimes and sometimes a string literal, based on the input string type (and also sometimes based on the VM/jdk type)



For example

-       HotSpot VM, If the input is a string literal, which *already* has all ?lower case letters?, toLower would return the same string literal, if not it will convert all letters to lower and returns a new String() object.

-       However, openJ9 (e.g. IBM jdk8 ditsro, ) always returns a new String object not a literal.



This behavior is non deterministic, inconsistent, you cannot always predict if the outcome is a new string object OR an interned string from pool (particularly from unit testing stand point).



Sample code to show case above behavior

package com.bugs;

import java.util.Locale;



public class TestStringFunction

{



  public static void main(String args[])

  {

    String s1 = "abc";

    String s2 = "ABC";



    System.out.println("----- case: when string already lower ----------");

    testIfEqualsLower(s1);



    System.out.println("----- case: when string with upper case ----------");

    testIfEqualsLower(s2);





  }



  private static void testIfEqualsLower(String s)

  {



     if(s.toLowerCase() == "abc")

     {

        System.out.println("YES - literal");

     }



     if(s.toLowerCase().equals("abc"))

     {

        System.out.println("YES ? equals func");

     }



   }

}





Out put



----- case: when string already lower ----------

YES - literal

YES ? equals func



----- case: when string with upper case ----------

YES - equals func





Why this could be an issue or bug prone?

-       Suppose an unit test is written, for a method doAThing(), that has toLower/Upper conversions in the middle of the code somewhere, and apply logic based on that.
-       Though general guidance to compare unknown string (types) is always using equals, sometimes developers can make a mistake (i.e. suppose they used == in a unit test)
-       If the code review did not catch it, this behavior can cause all unit tests passed, as long unit test is written with ?small case string? as input.
-       It could potentially make it to prod, and can be realized only when it hits a case when input string has all uppercase OR mixed case letters, which could be after multiple sprints, at the point not easily detectable.



Suggestion

It would be great if we always can make a new String() and return always a String object not an interned string sometimes, as openJ9/ibm does (with some jdk versions).

It may not be good idea, to always return ?.interned? value and fill up the intern pool, for these short-lived objects (as they are most times).



If this is agreed/approved, I can make a change and commit.


Regards

- SP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220620/adeb5d5f/attachment-0001.htm>

From liangchenblue at gmail.com  Mon Jun 20 05:22:37 2022
From: liangchenblue at gmail.com (-)
Date: Mon, 20 Jun 2022 00:22:37 -0500
Subject: Inconsistencies in the return value (type) of string functions
 toLower() and toUpper().
In-Reply-To: <CALR+58k+EYsAsLtTA9SNhYRGFq4pxkS8RoemFGVAnxR7zF=dvQ@mail.gmail.com>
References: <CALR+58k+EYsAsLtTA9SNhYRGFq4pxkS8RoemFGVAnxR7zF=dvQ@mail.gmail.com>
Message-ID: <CABe8uE0ewBWENvdY3oEeG6nhZ4fbush5vLJgMK-nyGS6r6acYg@mail.gmail.com>

As an observer, I do not think this is a good idea, and there's just so
many problems in your whole story...

1. The issues or bugs you described arise from bad programming behaviors.
Every time you see ==, always remember that == only compares by identity,
and do not try to use it to check equality of objects! Always use
Objects.equals, or Arrays.equals if you are checking arrays. Java's core
library has tons of objects that have equality distinct from having the
same identity, yet they reuse the same identity when viable, such as in
java.time packages. If you can miss ==, you probably can miss ! in reviews,
and are you going to patch every boolean method to prevent those?
2. The specification of these methods do not require returning new String
instances, so both implementations are proper. If one implementation
accidentally has an unspecified "feature" that helps you, you can't rule
out that that implementation may remove it at any time without prior
notice. Will you ask IBM to restore it if OpenJ9 removes this "feature" you
depend on?
3. If you really, really, really want new strings, just wrap every call to
toLowerCase() or toUpperCase() in a new String(), or use a bytecode
transformation library to patch every call to such factory methods in your
test code. That is easily done in your code reviews, and the lack of such
wraps is more easily spotted than the == misuse, right?


On Sun, Jun 19, 2022 at 10:30 PM Sasi Peri <pvssasikala at gmail.com> wrote:

> Hello,
>
> *Issue details*
>
> toLower() and toUpper() return a new String object sometimes and sometimes
> a string literal, based on the input string type (and also sometimes based
> on the VM/jdk type)
>
>
>
> For example
>
> -       HotSpot VM, If the input is a string literal, which *already* has
> all ?lower case letters?, toLower would return the same string literal, if
> not it will convert all letters to lower and returns a new String() object.
>
> -       However, openJ9 (e.g. IBM jdk8 ditsro, ) always returns a new
> String object not a literal.
>
>
>
> This behavior is non deterministic, inconsistent, you cannot always
> predict if the outcome is a new string object OR an interned string from
> pool (particularly from unit testing stand point).
>
>
>
> *Sample code to show case above behavior*
>
> *package* com.bugs;
>
> *import* java.util.Locale;
>
>
>
> *public* *class* TestStringFunction
>
> {
>
>
>
> *  public* *static* *void* main(String args[])
>
>   {
>
>     String s1 = "abc";
>
>     String s2 = "ABC";
>
>
>
>     System.*out*.println("----- case: when string already lower
> ----------");
>
> *    testIfEqualsLower*(s1);
>
>
>
>     System.*out*.println("----- case: when string with upper case
> ----------");
>
> *    testIfEqualsLower*(s2);
>
>
>
>
>
>   }
>
>
>
> *  private* *static* *void* testIfEqualsLower(String s)
>
>   {
>
>
>
> *     if*(s.toLowerCase() == "abc")
>
>      {
>
>         System.*out*.println("YES - literal");
>
>      }
>
>
>
> *     if*(s.toLowerCase().equals("abc"))
>
>      {
>
>         System.*out*.println("YES ? equals func");
>
>      }
>
>
>
>    }
>
> }
>
>
>
>
>
> *Out put*
>
>
>
> ----- case: when string already lower ----------
>
> YES - literal
>
> YES ? equals func
>
>
>
> ----- case: when string with upper case ----------
>
> YES - equals func
>
>
>
>
>
> *Why this could be an issue or bug prone?*
>
> -       Suppose an unit test is written, for a method doAThing(), that
> has toLower/Upper conversions in the middle of the code somewhere, and
> apply logic based on that.
> -       Though general guidance to compare unknown string (types) is
> always using equals, sometimes developers can make a mistake (i.e. suppose
> they used == in a unit test)
> -       If the code review did not catch it, this behavior can cause all
> unit tests passed, as long unit test is written with ?small case string? as
> input.
> -       It could potentially make it to prod, and can be realized only
> when it hits a case when input string has all uppercase OR mixed case
> letters, which could be after multiple sprints, at the point not easily
> detectable.
>
>
>
> *Suggestion*
>
> It would be great if we always can make a new String() and return always a
> String object not an interned string sometimes, as openJ9/ibm does (with
> some jdk versions).
>
> It may not be good idea, to always return ?.interned? value and fill up
> the intern pool, for these short-lived objects (as they are most times).
>
>
>
> If this is agreed/approved, I can make a change and commit.
>
>
> Regards
>
> - SP
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220620/ef26da6a/attachment-0001.htm>

From asotona at openjdk.org  Mon Jun 20 07:45:46 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 20 Jun 2022 07:45:46 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v3]
In-Reply-To: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
Message-ID: <D4wAQ1eHUnHYZsRzjjYwCIsdKpHeOugdKrNwxYh4Ufs=.fe14d73a-fde9-4e91-a8d1-214edde05a63@github.com>

> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 
> 
> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 
> 
> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
> Class internal name validation and extended ClassDescTest are also parts of this patch.
> 
> CSR is linked with the issue.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  updated ClassDesc::ofInternal javadoc with JVMS link and fixed indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9201/files
  - new: https://git.openjdk.org/jdk/pull/9201/files/51e811f8..9cb30fbf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9201&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9201&range=01-02

  Stats: 19 lines in 1 file changed: 1 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9201.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9201/head:pull/9201

PR: https://git.openjdk.org/jdk/pull/9201

From aturbanov at openjdk.org  Mon Jun 20 07:59:08 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 20 Jun 2022 07:59:08 GMT
Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time
Message-ID: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>

Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.

-------------

Commit messages:
 - [PATCH] Avoid redundant ConcurrentHashMap.get call in java.time

Changes: https://git.openjdk.org/jdk/pull/9208/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288723
  Stats: 20 lines in 4 files changed: 8 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9208.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9208/head:pull/9208

PR: https://git.openjdk.org/jdk/pull/9208

From duke at openjdk.org  Mon Jun 20 08:29:58 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Mon, 20 Jun 2022 08:29:58 GMT
Subject: RFR: 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)
In-Reply-To: <QYjhql6t3pgYJMtCmUdJkjw5Q2BNJU3hZ0ABwWloUiI=.8fd1d57a-fa11-4a14-a28f-f94e94b3b700@github.com>
References: <QYjhql6t3pgYJMtCmUdJkjw5Q2BNJU3hZ0ABwWloUiI=.8fd1d57a-fa11-4a14-a28f-f94e94b3b700@github.com>
Message-ID: <dbxBHI1jR1N9wSycPiYnoAKdjuwY2az1NXNrI4zafsg=.86309b1b-f1ef-4636-aef1-a737556ab862@github.com>

On Wed, 15 Jun 2022 13:25:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to revert to "<stdio.h>" functions like it was before [JDK-8281001](https://bugs.openjdk.org/browse/JDK-8281001), except that I'm using stderr in order to preserve the new behavior. Also see JBS issue.

Marked as reviewed by parttimenerd at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk19/pull/19

From mdoerr at openjdk.org  Mon Jun 20 08:38:17 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 20 Jun 2022 08:38:17 GMT
Subject: RFR: 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)
In-Reply-To: <QYjhql6t3pgYJMtCmUdJkjw5Q2BNJU3hZ0ABwWloUiI=.8fd1d57a-fa11-4a14-a28f-f94e94b3b700@github.com>
References: <QYjhql6t3pgYJMtCmUdJkjw5Q2BNJU3hZ0ABwWloUiI=.8fd1d57a-fa11-4a14-a28f-f94e94b3b700@github.com>
Message-ID: <SWZJQIuvR-77TJAXvP_gah39j0pTFvLXvI4QDD8-Jl0=.7b645fc7-8c4e-481d-a501-d43a2d90af68@github.com>

On Wed, 15 Jun 2022 13:25:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to revert to "<stdio.h>" functions like it was before [JDK-8281001](https://bugs.openjdk.org/browse/JDK-8281001), except that I'm using stderr in order to preserve the new behavior. Also see JBS issue.

Thanks for the reviews! I've added a bit more info to the issue.

-------------

PR: https://git.openjdk.org/jdk19/pull/19

From mdoerr at openjdk.org  Mon Jun 20 08:38:19 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 20 Jun 2022 08:38:19 GMT
Subject: Integrated: 8288485: jni/nullCaller/NullCallerTest.java failing
 (ppc64)
In-Reply-To: <QYjhql6t3pgYJMtCmUdJkjw5Q2BNJU3hZ0ABwWloUiI=.8fd1d57a-fa11-4a14-a28f-f94e94b3b700@github.com>
References: <QYjhql6t3pgYJMtCmUdJkjw5Q2BNJU3hZ0ABwWloUiI=.8fd1d57a-fa11-4a14-a28f-f94e94b3b700@github.com>
Message-ID: <JpnhWd16TS_3SLyeUZeJVpfsfbntrL9TJAP-gXjDl_s=.3e2a6ce1-46e9-4f9a-ae71-c7dc2ce8cee0@github.com>

On Wed, 15 Jun 2022 13:25:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to revert to "<stdio.h>" functions like it was before [JDK-8281001](https://bugs.openjdk.org/browse/JDK-8281001), except that I'm using stderr in order to preserve the new behavior. Also see JBS issue.

This pull request has now been integrated.

Changeset: 09da87cf
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/09da87cf5c2ed6de059425437e46517da9883e7e
Stats:     4 lines in 1 file changed: 1 ins; 1 del; 2 mod

8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk19/pull/19

From redestad at openjdk.org  Mon Jun 20 09:13:58 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Jun 2022 09:13:58 GMT
Subject: RFR: 8288667: Reduce runtime of java.text microbenchmarks [v2]
In-Reply-To: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>
References: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>
Message-ID: <kePp1RVGp7JeIuXdmCBhvACFWER4p0M0vGPh-8k2hFk=.5ba9b53a-388f-4919-91c0-9f2ace1fe8b6@github.com>

> - Refactor micro using a range of parameters to a simpler benchmark that tests different values in one pass
> - Reduce iterations and their runtimes, but add forks (important to be able to detect run-to-run variation anomalies)
> 
> Just one micro modified in this package, but reduces total runtime from 16 minutes to ~1 minute

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add OperationsPerInvocation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9198/files
  - new: https://git.openjdk.org/jdk/pull/9198/files/28016417..a1284b68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9198&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9198&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9198.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9198/head:pull/9198

PR: https://git.openjdk.org/jdk/pull/9198

From redestad at openjdk.org  Mon Jun 20 09:14:00 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Jun 2022 09:14:00 GMT
Subject: RFR: 8288667: Reduce runtime of java.text microbenchmarks [v2]
In-Reply-To: <UhJEa1owgurj1mxQHl4GQAwohezPRxRWarzueW6GJRg=.af2ae26e-9e6f-4d56-9b88-d71629da7917@github.com>
References: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>
 <UhJEa1owgurj1mxQHl4GQAwohezPRxRWarzueW6GJRg=.af2ae26e-9e6f-4d56-9b88-d71629da7917@github.com>
Message-ID: <0LIAqw4ybeeh5MxALFKK4kqpX61_cHsqh7ADlqYF3jo=.4d7c0b0b-f6c6-4055-98e4-1f8dc54726ce@github.com>

On Sun, 19 Jun 2022 00:27:27 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add OperationsPerInvocation
>
> test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 65:
> 
>> 63:     @Benchmark
>> 64:     public void testDefNumberFormatter(final Blackhole blackhole) {
>> 65:         for (double value : values) {
> 
> Should this now include `@OperationsPerInvocation(13)` since the loop is performing multiple operations per invocation?

Makes sense since it keeps the timing per operation in the same ballpark.

-------------

PR: https://git.openjdk.org/jdk/pull/9198

From sergei.tsypanov at yandex.ru  Mon Jun 20 09:43:50 2022
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Mon, 20 Jun 2022 11:43:50 +0200
Subject: DirectBufferAllocTest fails after replacement of Thread.sleep() with
 Thread.onSpinWait()
Message-ID: <2298281655718230@iva5-64778ce1ba26.qloud-c.yandex.net>

Hello,

while playing with Thread.onSpinWait() in busy-wait loops I've replaced Thread.sleep() with
preferable (at least as it appears from the JavaDoc) Thread.onSpinWait() in java.nio.Bits.

Immediately after that DirectBufferAllocTest started to fail with OOME. This is surprising, as the change
does not seem to change any program logic:

diff --git a/src/java.base/share/classes/java/nio/Bits.java b/src/java.base/share/classes/java/nio/Bits.java
--- a/src/java.base/share/classes/java/nio/Bits.java	(revision 7d4df6a83f6333e0e73686b807ee5d4b0ac10cd2)
+++ b/src/java.base/share/classes/java/nio/Bits.java	(date 1655709575452)
@@ -162,8 +162,7 @@
                 }
                 try {
                     if (!jlra.waitForReferenceProcessing()) {
-                        Thread.sleep(sleepTime);
-                        sleepTime <<= 1;
+                        Thread.onSpinWait();
                         sleeps++;
                     }
                 } catch (InterruptedException e) {

Another surprise here is that when I copy the test as simple Java application
it fails when I run it with the same JVM options (-XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent),
but doesn't if I put a breakpoint in IntelliJ at sleeps++ and stop there for 6-7 times while
the test is running. No failure observed if I drop JVM options either.

Is it a bug somewhere in GC/runtime or am I doing something wrong?

Regards,
Sergey Tsypanov

From attila at openjdk.org  Mon Jun 20 09:51:56 2022
From: attila at openjdk.org (Attila Szegedi)
Date: Mon, 20 Jun 2022 09:51:56 GMT
Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in
 java.time
In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
Message-ID: <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>

On Sat, 18 Jun 2022 10:43:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.

src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 319:

> 317:                 store = prev;
> 318:             }
> 319:         }

You could do better here and use `computeIfAbsent` with `createStore` as its lambda. You could even change the signature of `createStore` to take `Entry<TemporalField, Locale>` as its parameter and then you could have this method be:

    private Object findStore(TemporalField field, Locale locale) {
        return CACHE.computeIfAbsent(createEntry(field, locale), this::createStore);
    }

    ...

    private Object createStore(Entry<TemporalField, Locale> entry) {
        ...
    }

This applies to most other changes you made, the one in `ZoneOffset` is the only one that's slightly different because there you have adjustment of `ID_CACHE` too.

-------------

PR: https://git.openjdk.org/jdk/pull/9208

From redestad at openjdk.org  Mon Jun 20 10:24:55 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Jun 2022 10:24:55 GMT
Subject: Integrated: 8288667: Reduce runtime of java.text microbenchmarks
In-Reply-To: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>
References: <FXDB3dVrnPuRnBe3I9Ih5nEEQAuUHC3h0tIpbKLhxbw=.1bef0d2e-c143-411f-8dca-f258b492b640@github.com>
Message-ID: <ni_a8hyqoVf7XvyASkjUF-WqZBHmhuZGiEhl28aG2WI=.4a3f89af-f6e9-4dfe-be87-35df1a594e59@github.com>

On Fri, 17 Jun 2022 12:59:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Refactor micro using a range of parameters to a simpler benchmark that tests different values in one pass
> - Reduce iterations and their runtimes, but add forks (important to be able to detect run-to-run variation anomalies)
> 
> Just one micro modified in this package, but reduces total runtime from 16 minutes to ~1 minute

This pull request has now been integrated.

Changeset: d917e187
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d917e1874e46ccc26a8fa4ac82d21f4b22484452
Stats:     23 lines in 1 file changed: 12 ins; 2 del; 9 mod

8288667: Reduce runtime of java.text microbenchmarks

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/9198

From redestad at openjdk.org  Mon Jun 20 10:54:26 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Jun 2022 10:54:26 GMT
Subject: RFR: 8288732: Reduce runtime of java.util.concurrent microbenchmarks
Message-ID: <mYymzOgt__HGcR6_bQzrxGIn6Tko1idFcukgBT3rc40=.fd7868c2-2993-44b1-8131-ca7ac5f17b79@github.com>

- Refactor so that various baseline micros are not run repeatedly with different parameter values that does not affect the baseline
- Tune iteration times, counts, forks..

Reduces runtime of java.util.concurrent micros from an estimated 14h43m to 1h21m

-------------

Commit messages:
 - Copyrights
 - Merge branch 'master' into micro_runtime_juc
 - Reduce runtime of j.u.concurrent micros

Changes: https://git.openjdk.org/jdk/pull/9214/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9214&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288732
  Stats: 219 lines in 12 files changed: 117 ins; 21 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/9214.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9214/head:pull/9214

PR: https://git.openjdk.org/jdk/pull/9214

From jpai at openjdk.org  Mon Jun 20 11:51:54 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 20 Jun 2022 11:51:54 GMT
Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
Message-ID: <rQQuysKlPnrqvAw_2ctpuvhtQI2Tq7A0xehLa2N4fGw=.52ff545e-9c81-4a54-ad6f-644165159fa9@github.com>

On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
> 
> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.

Hello Sergey, there's currently no plan to backport this. We are hoping to hear back from Apple for the root cause issue that we have filed.

-------------

PR: https://git.openjdk.org/jdk/pull/8675

From redestad at openjdk.org  Mon Jun 20 11:59:16 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Jun 2022 11:59:16 GMT
Subject: RFR: 8288011: StringConcatFactory: Split application of
 stringifiers [v2]
In-Reply-To: <Y2i73g7SEsLA8nkH1Evf0Ye5z1zk1420o-ZCc2kf8KA=.0d5298a4-243b-4c3f-9daf-131c56847355@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
 <Y2i73g7SEsLA8nkH1Evf0Ye5z1zk1420o-ZCc2kf8KA=.0d5298a4-243b-4c3f-9daf-131c56847355@github.com>
Message-ID: <UNOeyHhvYFvaidLtdHyx1do1ErdG3phh52k_wEQvjvg=.3372c27e-f36c-4048-84bc-0332e710ac6c@github.com>

On Thu, 9 Jun 2022 16:04:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.
>> 
>> The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 
>> 
>> This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://urldefense.com/v3/__https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248__;!!ACWV5N9M2RV99hQ!M-YXLABYjfVMR7dBszho0HABOJ5jyVMSig_m31rczmDi7Tv9eBksPRG4m9-qzQFEw4LLqVdJJi8b1j052rDHdfoCWw$ ) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments based on review feedback

Thanks for reviews. I've filed [JDK-8288738](https://bugs.openjdk.org/browse/JDK-8288738) to explore adding a generalized `LambdaForm` class which would minimize the number of bound arguments and generated classes. I think the changes here are easy enough to back out as part of exploring that route, so I'll go ahead and integrate this enhancement for now.

-------------

PR: https://git.openjdk.org/jdk/pull/9082

From redestad at openjdk.org  Mon Jun 20 11:59:17 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Jun 2022 11:59:17 GMT
Subject: Integrated: 8288011: StringConcatFactory: Split application of
 stringifiers
In-Reply-To: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
References: <fGfETwll6S44G4U-uR71XL_38go_lcLi8rHEjc3bHtY=.84252885-539b-4c1e-8d2c-b8fe1fd194dd@github.com>
Message-ID: <Pd6UB3naoH2F1_bzrTLbr3em7im9bPvgZ0T6M_ch9Rg=.f2e000b6-ff82-4ef7-864c-752b490baa33@github.com>

On Wed, 8 Jun 2022 10:20:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> To take optimal advantage of the pre-existing optimization for repeated filters we could split the application of different types of stringifiers.
> 
> The resulting difference in order of evaluation is not observable by conventional means since all reference type share the same object stringifier, and the others are filtering primitives (floats and doubles) which have been passed by value already. 
> 
> This change neutral on many concatenation expression shapes, but for any complex expressions with interleaving float/double and reference parameters it brings a straightforward reduction in rebinds and underlying LFs generated. For example on the [MixedStringCombinations.java](https://urldefense.com/v3/__https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248__;!!ACWV5N9M2RV99hQ!N8f88zl1gqIUZjyrdSYuxItI-Tx-H8jXe5t5lUWldrNkmotWJ-mSsapozJWvv7yUDLomQy451gUTYnBRpKQ-TA9WAg$ ) test there's a modest 2% reduction in total classes loaded with this change (from 16209 to 15872)

This pull request has now been integrated.

Changeset: 5cdb4b19
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cdb4b196047d4f2d69df0fc73102c102bf042f7
Stats:     38 lines in 1 file changed: 23 ins; 5 del; 10 mod

8288011: StringConcatFactory: Split application of stringifiers

Reviewed-by: jvernee, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/9082

From david.holmes at oracle.com  Mon Jun 20 12:58:32 2022
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 20 Jun 2022 22:58:32 +1000
Subject: DirectBufferAllocTest fails after replacement of Thread.sleep()
 with Thread.onSpinWait()
In-Reply-To: <2298281655718230@iva5-64778ce1ba26.qloud-c.yandex.net>
References: <2298281655718230@iva5-64778ce1ba26.qloud-c.yandex.net>
Message-ID: <fd8fb3a1-4d3a-1a9b-70ff-2704492c0abc@oracle.com>

On 20/06/2022 7:43 pm, ?????? ??????? wrote:
> Hello,
> 
> while playing with Thread.onSpinWait() in busy-wait loops I've replaced Thread.sleep() with
> preferable (at least as it appears from the JavaDoc) Thread.onSpinWait() in java.nio.Bits.
> 
> Immediately after that DirectBufferAllocTest started to fail with OOME. This is surprising, as the change
> does not seem to change any program logic:

Do you get the OOME using Thread.yield() or just a busy-wait? The sleep 
limits the computation and ensures other threads can make progress; 
whereas a busy loop may not allow that and so you exhaust memory.

David

> diff --git a/src/java.base/share/classes/java/nio/Bits.java b/src/java.base/share/classes/java/nio/Bits.java
> --- a/src/java.base/share/classes/java/nio/Bits.java	(revision 7d4df6a83f6333e0e73686b807ee5d4b0ac10cd2)
> +++ b/src/java.base/share/classes/java/nio/Bits.java	(date 1655709575452)
> @@ -162,8 +162,7 @@
>                   }
>                   try {
>                       if (!jlra.waitForReferenceProcessing()) {
> -                        Thread.sleep(sleepTime);
> -                        sleepTime <<= 1;
> +                        Thread.onSpinWait();
>                           sleeps++;
>                       }
>                   } catch (InterruptedException e) {
> 
> Another surprise here is that when I copy the test as simple Java application
> it fails when I run it with the same JVM options (-XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent),
> but doesn't if I put a breakpoint in IntelliJ at sleeps++ and stop there for 6-7 times while
> the test is running. No failure observed if I drop JVM options either.
> 
> Is it a bug somewhere in GC/runtime or am I doing something wrong?
> 
> Regards,
> Sergey Tsypanov

From dfuchs at openjdk.org  Mon Jun 20 14:17:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 20 Jun 2022 14:17:20 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more eagerly
Message-ID: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>

Hi,

Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.

The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.

-------------

Commit messages:
 - JDK-8288746: HttpClient resources could be reclaimed more eagerly

Changes: https://git.openjdk.org/jdk/pull/9217/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9217&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288746
  Stats: 178 lines in 8 files changed: 99 ins; 13 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/9217.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9217/head:pull/9217

PR: https://git.openjdk.org/jdk/pull/9217

From sergei.tsypanov at yandex.ru  Mon Jun 20 14:46:45 2022
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Mon, 20 Jun 2022 16:46:45 +0200
Subject: DirectBufferAllocTest fails after replacement of Thread.sleep()
 with Thread.onSpinWait()
In-Reply-To: <fd8fb3a1-4d3a-1a9b-70ff-2704492c0abc@oracle.com>
References: <2298281655718230@iva5-64778ce1ba26.qloud-c.yandex.net>
 <fd8fb3a1-4d3a-1a9b-70ff-2704492c0abc@oracle.com>
Message-ID: <5235181655736405@vla3-6a5326aeb4ee.qloud-c.yandex.net>

> Do you get the OOME using Thread.yield() or just a busy-wait?

I reproduce it with busy-wait involving Thread.onSpinWait() and only when the test is run with -XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent

If I either drop mentioned VM options or use Thread.sleep() OOME will never happen (at least on my machine).

P.S. If I use Thread.yield() the problem is not reproduced any more.

P.P.S. How should I interpret this? Thread.onSpinWait() is discouraged for busy-waiting?

> On 20/06/2022 7:43 pm, ?????? ??????? wrote:
> 
>> Hello,
>>
>> while playing with Thread.onSpinWait() in busy-wait loops I've replaced Thread.sleep() with
>> preferable (at least as it appears from the JavaDoc) Thread.onSpinWait() in java.nio.Bits.
>>
>> Immediately after that DirectBufferAllocTest started to fail with OOME. This is surprising, as the change
>> does not seem to change any program logic:
> 
> Do you get the OOME using Thread.yield() or just a busy-wait? The sleep
> limits the computation and ensures other threads can make progress;
> whereas a busy loop may not allow that and so you exhaust memory.
> 
> David
> 
>> diff --git a/src/java.base/share/classes/java/nio/Bits.java b/src/java.base/share/classes/java/nio/Bits.java
>> --- a/src/java.base/share/classes/java/nio/Bits.java (revision 7d4df6a83f6333e0e73686b807ee5d4b0ac10cd2)
>> +++ b/src/java.base/share/classes/java/nio/Bits.java (date 1655709575452)
>> @@ -162,8 +162,7 @@
>> }
>> try {
>> if (!jlra.waitForReferenceProcessing()) {
>> - Thread.sleep(sleepTime);
>> - sleepTime <<= 1;
>> + Thread.onSpinWait();
>> sleeps++;
>> }
>> } catch (InterruptedException e) {
>>
>> Another surprise here is that when I copy the test as simple Java application
>> it fails when I run it with the same JVM options (-XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent),
>> but doesn't if I put a breakpoint in IntelliJ at sleeps++ and stop there for 6-7 times while
>> the test is running. No failure observed if I drop JVM options either.
>>
>> Is it a bug somewhere in GC/runtime or am I doing something wrong?
>>
>> Regards,
>> Sergey Tsypanov

From sergei.tsypanov at yandex.ru  Mon Jun 20 14:49:33 2022
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Mon, 20 Jun 2022 16:49:33 +0200
Subject: DirectBufferAllocTest fails after replacement of Thread.sleep()
 with Thread.onSpinWait()
In-Reply-To: <fd8fb3a1-4d3a-1a9b-70ff-2704492c0abc@oracle.com>
References: <2298281655718230@iva5-64778ce1ba26.qloud-c.yandex.net>
 <fd8fb3a1-4d3a-1a9b-70ff-2704492c0abc@oracle.com>
Message-ID: <5296351655736573@vla5-8300199a0c8b.qloud-c.yandex.net>


> Do you get the OOME using Thread.yield() or just a busy-wait?

I reproduce it with busy-wait involving Thread.onSpinWait() and only when the test is run with -XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent

If I either drop mentioned VM options or use Thread.sleep() OOME will never happen (at least on my machine).

P.S. If I use Thread.yield() the problem is not reproduced any more.

P.P.S. How should I interpret this? Thread.onSpinWait() is discouraged for busy-waiting?

> On 20/06/2022 7:43 pm, ?????? ??????? wrote:
> 
>> Hello,
>>
>> while playing with Thread.onSpinWait() in busy-wait loops I've replaced Thread.sleep() with
>> preferable (at least as it appears from the JavaDoc) Thread.onSpinWait() in java.nio.Bits.
>>
>> Immediately after that DirectBufferAllocTest started to fail with OOME. This is surprising, as the change
>> does not seem to change any program logic:
> 
> Do you get the OOME using Thread.yield() or just a busy-wait? The sleep
> limits the computation and ensures other threads can make progress;
> whereas a busy loop may not allow that and so you exhaust memory.
> 
> David
> 
>> diff --git a/src/java.base/share/classes/java/nio/Bits.java b/src/java.base/share/classes/java/nio/Bits.java
>> --- a/src/java.base/share/classes/java/nio/Bits.java (revision 7d4df6a83f6333e0e73686b807ee5d4b0ac10cd2)
>> +++ b/src/java.base/share/classes/java/nio/Bits.java (date 1655709575452)
>> @@ -162,8 +162,7 @@
>> }
>> try {
>> if (!jlra.waitForReferenceProcessing()) {
>> - Thread.sleep(sleepTime);
>> - sleepTime <<= 1;
>> + Thread.onSpinWait();
>> sleeps++;
>> }
>> } catch (InterruptedException e) {
>>
>> Another surprise here is that when I copy the test as simple Java application
>> it fails when I run it with the same JVM options (-XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent),
>> but doesn't if I put a breakpoint in IntelliJ at sleeps++ and stop there for 6-7 times while
>> the test is running. No failure observed if I drop JVM options either.
>>
>> Is it a bug somewhere in GC/runtime or am I doing something wrong?
>>
>> Regards,
>> Sergey Tsypanov

From duke at openjdk.org  Mon Jun 20 15:05:58 2022
From: duke at openjdk.org (liach)
Date: Mon, 20 Jun 2022 15:05:58 GMT
Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in
 java.time
In-Reply-To: <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>
Message-ID: <T1aGUhg2oja-wwEfNWodY5NDQu-0b_u7RrWD-Pll1Oc=.01a4d5f4-9985-43da-a45e-d5fb8bc6e966@github.com>

On Mon, 20 Jun 2022 09:11:31 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.
>
> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 319:
> 
>> 317:                 store = prev;
>> 318:             }
>> 319:         }
> 
> You could do better here and use `computeIfAbsent` with `createStore` as its lambda. You could even change the signature of `createStore` to take `Entry<TemporalField, Locale>` as its parameter and then you could have this method be:
> 
>     private Object findStore(TemporalField field, Locale locale) {
>         return CACHE.computeIfAbsent(createEntry(field, locale), this::createStore);
>     }
> 
>     ...
> 
>     private Object createStore(Entry<TemporalField, Locale> entry) {
>         ...
>     }
> 
> This applies to most other changes you made, the one in `ZoneOffset` is the only one that's slightly different because there you have adjustment of `ID_CACHE` too.

This behaves slightly different from the old initialization; the concurrent hash map blocks when the mapping function is run, just in case if non-blocking instantiation is what we want. If that's not a problem, I would prefer szegedi's suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/9208

From pvssasikala at gmail.com  Mon Jun 20 17:19:07 2022
From: pvssasikala at gmail.com (Sasi Peri)
Date: Mon, 20 Jun 2022 13:19:07 -0400
Subject: Inconsistencies in the return value (type) of string functions
 toLower() and toUpper().
In-Reply-To: <CABe8uE0ewBWENvdY3oEeG6nhZ4fbush5vLJgMK-nyGS6r6acYg@mail.gmail.com>
References: <CALR+58k+EYsAsLtTA9SNhYRGFq4pxkS8RoemFGVAnxR7zF=dvQ@mail.gmail.com>
 <CABe8uE0ewBWENvdY3oEeG6nhZ4fbush5vLJgMK-nyGS6r6acYg@mail.gmail.com>
Message-ID: <CALR+58kr2+DzPibQa6giuHd4r1QhqH5f0puhrd5m6qGYjD9OVw@mail.gmail.com>

   1. Like I already said ?==? should be avoided in the first place, and
   the issue(s) described, 100 % are the bad programming behaviors. No debate
   there.
   2. And, my point is not to return a new object or literal (I a am not
   trying to drive this one specific behavior one way or another), there could
   be many more implementation ideas as well (to make sense of semantic use of
   operators) may be via ?operator overloading? like other programming langs.
      -  And, yes, we could write wrappers of our own or make ?linters? of
      our own and scan, auto-detect and/or auto-fix. We can get very creative.
   3. But the bigger point again is not about specific implementation or
   justifying bad programming behavior or ways to deal with it
   (lint/auto-detect/fix),

o   But to make it *?less error-prone*? (around semantics), improve it, so
there are fewer opportunities to make a mistake, in general.

o   That?s the inconsistencies, the non-deterministic nature of the output
(based on a VM-type/input-type/jdk-provider-type) would cause less
experienced developers (or coming from other langs to code in java), easily
make mistakes, that is not easily detectable (as it works in some
cases/unit-tests).

On Mon, Jun 20, 2022 at 1:22 AM - <liangchenblue at gmail.com> wrote:

> As an observer, I do not think this is a good idea, and there's just so
> many problems in your whole story...
>
> 1. The issues or bugs you described arise from bad programming behaviors.
> Every time you see ==, always remember that == only compares by identity,
> and do not try to use it to check equality of objects! Always use
> Objects.equals, or Arrays.equals if you are checking arrays. Java's core
> library has tons of objects that have equality distinct from having the
> same identity, yet they reuse the same identity when viable, such as in
> java.time packages. If you can miss ==, you probably can miss ! in reviews,
> and are you going to patch every boolean method to prevent those?
> 2. The specification of these methods do not require returning new String
> instances, so both implementations are proper. If one implementation
> accidentally has an unspecified "feature" that helps you, you can't rule
> out that that implementation may remove it at any time without prior
> notice. Will you ask IBM to restore it if OpenJ9 removes this "feature" you
> depend on?
> 3. If you really, really, really want new strings, just wrap every call to
> toLowerCase() or toUpperCase() in a new String(), or use a bytecode
> transformation library to patch every call to such factory methods in your
> test code. That is easily done in your code reviews, and the lack of such
> wraps is more easily spotted than the == misuse, right?
>
>
> On Sun, Jun 19, 2022 at 10:30 PM Sasi Peri <pvssasikala at gmail.com> wrote:
>
>> Hello,
>>
>> *Issue details*
>>
>> toLower() and toUpper() return a new String object sometimes and
>> sometimes a string literal, based on the input string type (and also
>> sometimes based on the VM/jdk type)
>>
>>
>>
>> For example
>>
>> -       HotSpot VM, If the input is a string literal, which *already*
>> has all ?lower case letters?, toLower would return the same string literal,
>> if not it will convert all letters to lower and returns a new String()
>> object.
>>
>> -       However, openJ9 (e.g. IBM jdk8 ditsro, ) always returns a new
>> String object not a literal.
>>
>>
>>
>> This behavior is non deterministic, inconsistent, you cannot always
>> predict if the outcome is a new string object OR an interned string from
>> pool (particularly from unit testing stand point).
>>
>>
>>
>> *Sample code to show case above behavior*
>>
>> *package* com.bugs;
>>
>> *import* java.util.Locale;
>>
>>
>>
>> *public* *class* TestStringFunction
>>
>> {
>>
>>
>>
>> *  public* *static* *void* main(String args[])
>>
>>   {
>>
>>     String s1 = "abc";
>>
>>     String s2 = "ABC";
>>
>>
>>
>>     System.*out*.println("----- case: when string already lower
>> ----------");
>>
>> *    testIfEqualsLower*(s1);
>>
>>
>>
>>     System.*out*.println("----- case: when string with upper case
>> ----------");
>>
>> *    testIfEqualsLower*(s2);
>>
>>
>>
>>
>>
>>   }
>>
>>
>>
>> *  private* *static* *void* testIfEqualsLower(String s)
>>
>>   {
>>
>>
>>
>> *     if*(s.toLowerCase() == "abc")
>>
>>      {
>>
>>         System.*out*.println("YES - literal");
>>
>>      }
>>
>>
>>
>> *     if*(s.toLowerCase().equals("abc"))
>>
>>      {
>>
>>         System.*out*.println("YES ? equals func");
>>
>>      }
>>
>>
>>
>>    }
>>
>> }
>>
>>
>>
>>
>>
>> *Out put*
>>
>>
>>
>> ----- case: when string already lower ----------
>>
>> YES - literal
>>
>> YES ? equals func
>>
>>
>>
>> ----- case: when string with upper case ----------
>>
>> YES - equals func
>>
>>
>>
>>
>>
>> *Why this could be an issue or bug prone?*
>>
>> -       Suppose an unit test is written, for a method doAThing(), that
>> has toLower/Upper conversions in the middle of the code somewhere, and
>> apply logic based on that.
>> -       Though general guidance to compare unknown string (types) is
>> always using equals, sometimes developers can make a mistake (i.e. suppose
>> they used == in a unit test)
>> -       If the code review did not catch it, this behavior can cause all
>> unit tests passed, as long unit test is written with ?small case string? as
>> input.
>> -       It could potentially make it to prod, and can be realized only
>> when it hits a case when input string has all uppercase OR mixed case
>> letters, which could be after multiple sprints, at the point not easily
>> detectable.
>>
>>
>>
>> *Suggestion*
>>
>> It would be great if we always can make a new String() and return always
>> a String object not an interned string sometimes, as openJ9/ibm does (with
>> some jdk versions).
>>
>> It may not be good idea, to always return ?.interned? value and fill up
>> the intern pool, for these short-lived objects (as they are most times).
>>
>>
>>
>> If this is agreed/approved, I can make a change and commit.
>>
>>
>> Regards
>>
>> - SP
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220620/10ca49be/attachment-0001.htm>

From lancea at openjdk.org  Mon Jun 20 17:35:55 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 20 Jun 2022 17:35:55 GMT
Subject: Integrated: 8288527: broken link in
 java.base/java/util/zip/package-summary.html
In-Reply-To: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
References: <9QuGp0558L-yhjt3BQwqItDZ7t-WwTiNANQigYR4SP4=.6a01baca-87e3-44ce-9bc2-07ce4b16e876@github.com>
Message-ID: <CSiV8tQupx-SFjrrZuzkPy3CaNjbeIOBIazLnTOsko0=.cc5f2439-5b8d-4e4e-b9e6-5604a15132f5@github.com>

On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch for JDK 19 to address a broken link due to PKWare moving the location for APPNOTE.txt
> 
> Best,
> Lance

This pull request has now been integrated.

Changeset: 453e8beb
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/453e8beb43d56656d358c56f9d505ceaeba53f72
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8288527: broken link in java.base/java/util/zip/package-summary.html

Reviewed-by: bpb, martin

-------------

PR: https://git.openjdk.org/jdk19/pull/35

From brian.goetz at oracle.com  Mon Jun 20 18:24:39 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 20 Jun 2022 14:24:39 -0400
Subject: Inconsistencies in the return value (type) of string functions
 toLower() and toUpper().
In-Reply-To: <CALR+58k+EYsAsLtTA9SNhYRGFq4pxkS8RoemFGVAnxR7zF=dvQ@mail.gmail.com>
References: <CALR+58k+EYsAsLtTA9SNhYRGFq4pxkS8RoemFGVAnxR7zF=dvQ@mail.gmail.com>
Message-ID: <3c8a462d-1a60-3aa9-721d-aaa0c40490b5@oracle.com>

What you are suggesting is what we call "specifying the implementation", 
which is generally not a very good idea.

The specification for these methods says "returns a String <with the 
following properties>".? That's a good specification!? It says what you 
can expect from the result.? It says nothing about the identity of the 
returned object, whether it is interned, whether it is aliased, etc.? 
This is by design. Specifying the implementation not only robs future 
implementers of the ability to improve the implementation (which in turn 
improves all the code that uses it, without having to even recompile), 
and encourages people to do questionable things like make assumptions 
about the identity of the returned String.

To describe this as "non-deterministic" is an abuse of the term.? What 
is going on here is that the specification makes certain promises, and 
multiple implementations choose different ways to get there (and any 
given implementation could choose different ways in different points in 
time.)? Similarly, describing it as "inconsistent" is also an abuse; no 
one promised a non-aliased object.

If your code wants to make assumptions about interning or lack of 
aliasing, you should call "new String(s)".

On 6/19/2022 11:29 PM, Sasi Peri wrote:
> Hello,
>
> *Issue details*
>
> toLower() and toUpper() return a new String object sometimes and 
> sometimes a string literal, based on the input string type (and also 
> sometimes based on the VM/jdk type)
>
> For example
>
> -HotSpot VM, If the input is a string literal, which *already* has all 
> ?lower case letters?, toLower would return the same string literal, if 
> not it will convert all letters to lower and returns a new String() 
> object.
>
> -However, openJ9 (e.g. IBM jdk8 ditsro, ) always returns a new String 
> object not a literal.
>
> This behavior is non deterministic, inconsistent, you cannot always 
> predict if the outcome is a new string object OR an interned string 
> from pool (particularly from unit testing stand point).
>
> *Sample code to show case above behavior*
>
> *package*com.bugs;
>
> *import*java.util.Locale;
>
> *public**class*TestStringFunction
>
> {
>
> *? public**static**void*main(String args[])
>
> ? {
>
> ??? String s1= "abc";
>
> ??? String s2= "ABC";
>
> ??? System.*/out/*.println("----- case: when string already lower 
> ----------");
>
> /testIfEqualsLower/(s1);
>
> ??? System.*/out/*.println("----- case: when string with upper case 
> ----------");
>
> /testIfEqualsLower/(s2);
>
> ? }
>
> *? private**static**void*testIfEqualsLower(String s)
>
> ? {
>
> *??? ?if*(s.toLowerCase() == "abc")
>
> ??? ?{
>
> ?????? ?System.*/out/*.println("YES - literal");
>
> ??? ?}
>
> *??? ?if*(s.toLowerCase().equals("abc"))
>
> ??? ?{
>
> ?????? ?System.*/out/*.println("YES ? equals func");
>
> ??? ?}
>
> ?? }
>
> }
>
> *_Out put_*
>
> *__*
>
> ----- case: when string already lower ----------
>
> YES - literal
>
> YES ? equals func
>
> ----- case: when string with upper case ----------
>
> YES - equals func**
>
> **
>
> *Why this could be an issue or bug prone?*
>
> -Suppose an unit test is written, for a method doAThing(), that has 
> toLower/Upper conversions in the middle of the code somewhere, and 
> apply logic based on that.
> -Though general guidance to compare unknown string (types) is always 
> using equals, sometimes developers can make a mistake (i.e. suppose 
> they used == in a unit test)
> -If the code review did not catch it, this behavior can cause all unit 
> tests passed, as long unit test is written with ?small case string? as 
> input.
> -It could potentially make it to prod, and can be realized only when 
> it hits a case when inputstring has all uppercase OR mixed case 
> letters, which could be after multiple sprints, at the point not 
> easily detectable.
>
> *Suggestion*
>
> It would be great if we always can make a new String() and return 
> always a String object not an interned string sometimes, as openJ9/ibm 
> does (with some jdk versions).
>
> It may not be good idea, to always return ?.interned? value and fill 
> up the intern pool, for these short-lived objects (as they are most 
> times).
>
> If this is agreed/approved, I can make a change and commit.
>
>
> Regards
>
> - SP
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220620/60daec0d/attachment-0001.htm>

From jwilhelm at openjdk.org  Mon Jun 20 18:28:50 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 20 Jun 2022 18:28:50 GMT
Subject: RFR: Merge jdk19
Message-ID: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8288527: broken link in java.base/java/util/zip/package-summary.html
 - 8288741: JFR: Change package name of snippet files
 - 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
 - 8287800: JFR: Incorrect error message when starting recording with missing .jfc file
 - 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)
 - 8288564: C2: LShiftLNode::Ideal produces wrong result after JDK-8278114
 - 8288397: AArch64: Fix register issues in SVE backend match rules
 - 8288692: jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java fails after JDK-8288545
 - 8268398: 15% increase in JFR footprint in Noop-Base
 - ... and 1 more: https://git.openjdk.org/jdk/compare/302a6c06...6efc7e9e

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9220/files
  Stats: 752 lines in 36 files changed: 538 ins; 58 del; 156 mod
  Patch: https://git.openjdk.org/jdk/pull/9220.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9220/head:pull/9220

PR: https://git.openjdk.org/jdk/pull/9220

From duke at openjdk.org  Mon Jun 20 18:31:54 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 20 Jun 2022 18:31:54 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
Message-ID: <YecuwWKp3-Ap4sBzBO1ZwHhRZCI3uW4OIJCc3rjAwjo=.3469f256-12a4-4104-9ac3-ed5906238646@github.com>

On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
> 
> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.

Shouldn't we use `Reference.refersTo()` instead of `Reference.get() == smth` in lines 428 and 501?

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From jwilhelm at openjdk.org  Mon Jun 20 19:44:19 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 20 Jun 2022 19:44:19 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
References: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
Message-ID: <wOC-cOnunQe0dlkf1uVHOn0PrafZajxmhFD_Rg6cwuI=.072a626a-5ae7-4ed5-a0a6-d3eeacd89c8b@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 96 additional commits since the last revision:

 - Merge
 - 8287801: Fix test-bugs related to stress flags
   
   Reviewed-by: chagedorn, thartmann
 - 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
   
   Reviewed-by: jbachorik, egahlin
 - 8287771: Remove useless G1 After GC summary refinement and sampling thread times
   
   Reviewed-by: tschatzl, kbarrett
 - 8288011: StringConcatFactory: Split application of stringifiers
   
   Reviewed-by: jvernee, mchung
 - 8288685: JFR: Use static methods for Active Recording and Active Setting events
   
   Reviewed-by: mgronlun
 - 8288673: Reduce runtime of java.time microbenchmarks
   
   Reviewed-by: jvernee
 - 8288667: Reduce runtime of java.text microbenchmarks
   
   Reviewed-by: jvernee
 - 8284672: Collapse identical catch branches in java.desktop
   
   Reviewed-by: prr, aivanov, serb
 - 8288329: Avoid redundant TreeMap.containsKey call in PolicyParser.read
   
   Reviewed-by: mullan
 - ... and 86 more: https://git.openjdk.org/jdk/compare/cb2201b4...6efc7e9e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9220/files
  - new: https://git.openjdk.org/jdk/pull/9220/files/6efc7e9e..6efc7e9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9220.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9220/head:pull/9220

PR: https://git.openjdk.org/jdk/pull/9220

From jwilhelm at openjdk.org  Mon Jun 20 19:44:19 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 20 Jun 2022 19:44:19 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
References: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
Message-ID: <99J0-7NZyn_B1qAUt-E3RDXhVlOBpw5q0y_7OfkWqNU=.c9779d47-1137-44ca-8b97-bd31716fbc11@github.com>

On Mon, 20 Jun 2022 18:20:21 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 7039c661
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7039c6616ad1b67320f08e7ea4763e8ff4977430
Stats:     752 lines in 36 files changed: 538 ins; 58 del; 156 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9220

From mcimadamore at openjdk.org  Mon Jun 20 21:29:57 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 20 Jun 2022 21:29:57 GMT
Subject: RFR: 8288761: SegmentAllocator:allocate(long bytesSize) not throwing
 IAEx when bytesSize < 0
Message-ID: <-2C9IA0kqJYX66c2BDITjapzom0cljNzid877uCRy9A=.a695bf67-1df3-4e6c-bcda-18a129e848de@github.com>

The various SegmentAllocator subclasses do not check for the constraints mentioned in the javadoc.
This patch pulls the checks into a common routine in the Utils class, and then call that check routine from all the `allocate` implementations.

-------------

Commit messages:
 - Add comments in allocation check
 - Initial push

Changes: https://git.openjdk.org/jdk19/pull/50/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=50&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288761
  Stats: 59 lines in 5 files changed: 43 ins; 13 del; 3 mod
  Patch: https://git.openjdk.org/jdk19/pull/50.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/50/head:pull/50

PR: https://git.openjdk.org/jdk19/pull/50

From david.holmes at oracle.com  Mon Jun 20 21:58:47 2022
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Jun 2022 07:58:47 +1000
Subject: DirectBufferAllocTest fails after replacement of Thread.sleep()
 with Thread.onSpinWait()
In-Reply-To: <5296351655736573@vla5-8300199a0c8b.qloud-c.yandex.net>
References: <2298281655718230@iva5-64778ce1ba26.qloud-c.yandex.net>
 <fd8fb3a1-4d3a-1a9b-70ff-2704492c0abc@oracle.com>
 <5296351655736573@vla5-8300199a0c8b.qloud-c.yandex.net>
Message-ID: <e6232617-b4bb-f714-cb5d-4321b8c67773@oracle.com>

On 21/06/2022 12:49 am, ?????? ??????? wrote:
> 
>> Do you get the OOME using Thread.yield() or just a busy-wait?
> 
> I reproduce it with busy-wait involving Thread.onSpinWait() and only when the test is run with -XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent
> 
> If I either drop mentioned VM options or use Thread.sleep() OOME will never happen (at least on my machine).

That indicates that without those flags, or with the sleep, memory use 
does not outpace memory return.

> P.S. If I use Thread.yield() the problem is not reproduced any more.

Which indicates yielding is having a similar effect to sleeping - though 
I would expect it to be less pronounced.

> P.P.S. How should I interpret this? Thread.onSpinWait() is discouraged for busy-waiting?

Thread.onSpinWait _is_ busy-waiting, but it may (depending on 
architecture) actually execute a more (power) efficient form of busy-wait.

The takeaway from this exercise is that loops with sleeps can't always 
be replaced by loops that busy-wait. Functionally the logic is the same, 
but you can't just ignore the concurrency aspects.

Cheers,
David
-----

>> On 20/06/2022 7:43 pm, ?????? ??????? wrote:
>>
>>> Hello,
>>>
>>> while playing with Thread.onSpinWait() in busy-wait loops I've replaced Thread.sleep() with
>>> preferable (at least as it appears from the JavaDoc) Thread.onSpinWait() in java.nio.Bits.
>>>
>>> Immediately after that DirectBufferAllocTest started to fail with OOME. This is surprising, as the change
>>> does not seem to change any program logic:
>>
>> Do you get the OOME using Thread.yield() or just a busy-wait? The sleep
>> limits the computation and ensures other threads can make progress;
>> whereas a busy loop may not allow that and so you exhaust memory.
>>
>> David
>>
>>> diff --git a/src/java.base/share/classes/java/nio/Bits.java b/src/java.base/share/classes/java/nio/Bits.java
>>> --- a/src/java.base/share/classes/java/nio/Bits.java (revision 7d4df6a83f6333e0e73686b807ee5d4b0ac10cd2)
>>> +++ b/src/java.base/share/classes/java/nio/Bits.java (date 1655709575452)
>>> @@ -162,8 +162,7 @@
>>> }
>>> try {
>>> if (!jlra.waitForReferenceProcessing()) {
>>> - Thread.sleep(sleepTime);
>>> - sleepTime <<= 1;
>>> + Thread.onSpinWait();
>>> sleeps++;
>>> }
>>> } catch (InterruptedException e) {
>>>
>>> Another surprise here is that when I copy the test as simple Java application
>>> it fails when I run it with the same JVM options (-XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent),
>>> but doesn't if I put a breakpoint in IntelliJ at sleeps++ and stop there for 6-7 times while
>>> the test is running. No failure observed if I drop JVM options either.
>>>
>>> Is it a bug somewhere in GC/runtime or am I doing something wrong?
>>>
>>> Regards,
>>> Sergey Tsypanov

From robm at openjdk.org  Tue Jun 21 00:14:47 2022
From: robm at openjdk.org (Rob McKenna)
Date: Tue, 21 Jun 2022 00:14:47 GMT
Subject: RFR: 8287672: jtreg test
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
 [v2]
In-Reply-To: <Y3LKKXeWPYrjOsp6ndLH5bGfpnecF1SJq203Rd4iqjI=.a052a8d5-7870-4e48-9f38-3ebe19823251@github.com>
References: <Y3LKKXeWPYrjOsp6ndLH5bGfpnecF1SJq203Rd4iqjI=.a052a8d5-7870-4e48-9f38-3ebe19823251@github.com>
Message-ID: <xImA7VCFd_-LPnEnQzt5UWKEOzmz-_tM2hNExgsCgW4=.818f170f-f765-4c71-ab8d-ff97ace5722d@github.com>

> Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work.

Rob McKenna 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:

 - Use assertNotNull
 - Merge branch 'master' into JDK-8287672
 - 8281695: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8974/files
  - new: https://git.openjdk.org/jdk/pull/8974/files/49cdbb9b..f6d3143e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8974&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8974&range=00-01

  Stats: 44137 lines in 1286 files changed: 33036 ins; 6642 del; 4459 mod
  Patch: https://git.openjdk.org/jdk/pull/8974.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8974/head:pull/8974

PR: https://git.openjdk.org/jdk/pull/8974

From robm at openjdk.org  Tue Jun 21 00:26:37 2022
From: robm at openjdk.org (Rob McKenna)
Date: Tue, 21 Jun 2022 00:26:37 GMT
Subject: Integrated: 8287672: jtreg test
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
In-Reply-To: <Y3LKKXeWPYrjOsp6ndLH5bGfpnecF1SJq203Rd4iqjI=.a052a8d5-7870-4e48-9f38-3ebe19823251@github.com>
References: <Y3LKKXeWPYrjOsp6ndLH5bGfpnecF1SJq203Rd4iqjI=.a052a8d5-7870-4e48-9f38-3ebe19823251@github.com>
Message-ID: <508C-SHGX0zeDTzlCLwsMWE0GO6ZKEvaBLX8bn6hRQs=.89dae86d-ffb1-489c-87b6-91e180020adc@github.com>

On Wed, 1 Jun 2022 15:41:57 GMT, Rob McKenna <robm at openjdk.org> wrote:

> Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work.

This pull request has now been integrated.

Changeset: 7e211d7d
Author:    Rob McKenna <robm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run

Reviewed-by: dfuchs, aefimov

-------------

PR: https://git.openjdk.org/jdk/pull/8974

From yangang at ec.com.cn  Tue Jun 21 12:35:19 2022
From: yangang at ec.com.cn (=?gbk?B?WWFuIEdhbmc=?=)
Date: Tue, 21 Jun 2022 12:35:19 +0800(CST)
Subject: =?gbk?B?anZtICBjcmFzaCBvbiBtZW1tb3ZlX3Nzc2UzX2JhY2s=?=
Message-ID: <4LRtwm2VPsz5vNQ@mx3.ec.com.cn>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220621/baed35b9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs_err_pid6443.log
Type: application/octet-stream
Size: 226833 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220621/baed35b9/hs_err_pid6443-0001.log>

From david.holmes at oracle.com  Tue Jun 21 05:11:43 2022
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Jun 2022 15:11:43 +1000
Subject: jvm crash on memmove_ssse3_back
In-Reply-To: <4LRtwm2VPsz5vNQ@mx3.ec.com.cn>
References: <4LRtwm2VPsz5vNQ@mx3.ec.com.cn>
Message-ID: <04bcf1c1-c332-b333-cd8e-cf01641ac98c@oracle.com>

Hi,

On 21/06/2022 2:35 pm, Yan Gang wrote:
> hi all:
>  ?I have jvm crash issue. not get core,only?hs_err_pid6443.log.

These mailing lists are not for general bug reports but to discuss 
development of OpenJDK.

Your hs_err file states:

# The crash happened outside the Java Virtual Machine in native code.

and your stack shows:

> stack info:
> Stack: [0x00007fd5dca04000,0x00007fd5dcb05000],? sp=0x00007fd5dcb03008,  
> free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
> C=native code)
> C? [libc.so.6+0x15ca75]? __memmove_ssse3_back+0x2865
> 
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> J 4835  
> org.fusesource.leveldbjni.internal.NativeDB$DBJNI.Put(JLorg/fusesource/leveldbjni/internal/NativeWriteOptions;Lorg/fusesource/leveldbjni/internal/NativeSlice;Lorg/fusesource/leveldbjni/internal/NativeSlice;)J 

So this is a bug in the fusesource code.

Cheers,
David Holmes
------------

> (0 bytes) @ 0x00007fd609f881fd [0x00007fd609f88180+0x7d]
> J 4832 C1 
> org.fusesource.leveldbjni.internal.NativeDB.put(Lorg/fusesource/leveldbjni/internal/NativeWriteOptions;[B[B)V 
> (76 bytes) @ 0x00007fd609f9f70c [0x00007fd609f9ed20+0x9ec]
> J 4831 C1 
> org.fusesource.leveldbjni.internal.JniDB.put([B[BLorg/iq80/leveldb/WriteOptions;)Lorg/iq80/leveldb/Snapshot; 
> (50 bytes) @ 0x00007fd609f94024 [0x00007fd609f93f20+0x104]
> J 4830 C1 org.fusesource.leveldbjni.internal.JniDB.put([B[B)V (15 bytes) 
> @ 0x00007fd609f847cc [0x00007fd609f84660+0x16c]
> j  
> org.apache.hadoop.yarn.server.nodemanager.recovery.NMLeveldbStateStoreService.storeMasterKey(Ljava/lang/String;Lorg/apache/hadoop/yarn/server/api/records/MasterKey;)V+20
> j  
> org.apache.hadoop.yarn.server.nodemanager.recovery.NMLeveldbStateStoreService.storeContainerTokenPreviousMasterKey(Lorg/apache/hadoop/yarn/server/api/records/MasterKey;)V+4
> j  
> org.apache.hadoop.yarn.server.nodemanager.security.NMContainerTokenSecretManager.updatePreviousMasterKey(Lorg/apache/hadoop/yarn/server/security/MasterKeyData;)V+13
> j  
> org.apache.hadoop.yarn.server.nodemanager.security.NMContainerTokenSecretManager.setMasterKey(Lorg/apache/hadoop/yarn/server/api/records/MasterKey;)V+72
> j  
> org.apache.hadoop.yarn.server.nodemanager.NodeStatusUpdaterImpl$1.updateMasterKeys(Lorg/apache/hadoop/yarn/server/api/protocolrecords/NodeHeartbeatResponse;)V+24
> J 7243% C1 
> org.apache.hadoop.yarn.server.nodemanager.NodeStatusUpdaterImpl$1.run()V 
> (1172 bytes) @ 0x00007fd60a4bce7c [0x00007fd60a4bc400+0xa7c]
> j? java.lang.Thread.run()V+11
> v? ~StubRoutines::call_stub
> 
> detail info upload crash log.
> Thanks!

From yangang at ec.com.cn  Tue Jun 21 13:18:31 2022
From: yangang at ec.com.cn (=?gbk?B?WWFuIEdhbmc=?=)
Date: Tue, 21 Jun 2022 13:18:31 +0800(CST)
Subject: =?gbk?B?UmU6UmU6IGp2bSBjcmFzaCBvbiBtZW1tb3ZlX3Nzc2UzX2JhY2s=?=
Message-ID: <4LRvtb4bSBz5vNK@mx3.ec.com.cn>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220621/8b50a591/attachment.htm>

From alanb at openjdk.org  Tue Jun 21 06:39:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Jun 2022 06:39:18 GMT
Subject: RFR: 8287982: Concurrent implicit attach from native threads crashes
 VM
Message-ID: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com>

If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread without a thread name, or native threads that attach implicitly by using a function pointer to do an up call.

The issue that raises its head periodically is that native threads that JNI attach do the initializaiton of the Thread object in the context of the attaching thread. Great care must be taken because Java code is executing in the context of a Thread that is not fully initialized. The right thing is probably to create the Thread object in another thread, using the service thread has been mentioned. The issue at this time arises when two or more native threads attempt to attach without thread names at around the same time. The first thread that needs an automatically generated name triggers the loading and initialization of a helper class.  If there are other threads attaching at the same time then they may have to wait on the monitor which can trigger the crash because the field holder with the thread status is not created at this time. Crashes in monitor enter and notify have been observed. Coleen has changed this code so that linking and initialization uses a mutex (JDK-8288064) so t
 his specific crash doesn't duplicate in the main line. The short term fix for openjdk/jdk19 is to reorder the initialization so that field holder with the thread status is created before setting the name.

Creating a jtreg test with the conditions to duplicate this issue is complicated. The jtreg main wrapper creates the main thread with an automatically generated thread name before it runs the test main method. This is the reason that the test needs to launch a new VM with the right setup to exercise both explicit and implicit attach.

-------------

Commit messages:
 - Move -ljvm to LIBS
 - Swap link options
 - Update test
 - Cleanup
 - Merge
 - Initial version

Changes: https://git.openjdk.org/jdk19/pull/28/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=28&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287982
  Stats: 402 lines in 7 files changed: 364 ins; 21 del; 17 mod
  Patch: https://git.openjdk.org/jdk19/pull/28.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/28/head:pull/28

PR: https://git.openjdk.org/jdk19/pull/28

From alanb at openjdk.org  Tue Jun 21 06:51:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Jun 2022 06:51:09 GMT
Subject: RFR: 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java
 from problemlist
In-Reply-To: <LT1zYZzXCl-dLrl9CSbojrPN95_aSbgAkg5A6tpecME=.f014c351-b7c5-414a-920b-dc3cde9a5db8@github.com>
References: <LT1zYZzXCl-dLrl9CSbojrPN95_aSbgAkg5A6tpecME=.f014c351-b7c5-414a-920b-dc3cde9a5db8@github.com>
Message-ID: <Rqu82pDMtwCNqbMYSJdeUSLwWsS53WQrCLVSm0lfjPE=.6221e217-6143-4d96-ac66-d67690b1a34f@github.com>

On Tue, 21 Jun 2022 06:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to remove the `CompressorPluginTest` from the problemlist?
> 
> This test was problem listed since it had intermittently failed with odd exception in the past (https://bugs.openjdk.org/browse/JDK-8247407). Over the past several months I have attempted multiple runs of this test (with very high test repeats) both locally as well as a CI setup to see if this is still reproducible. So far, I haven't been able to reproduce it. Given the odd exception it was throwing originally, it's hard to say what the issue could have been (and whether it got fixed in recent times), but since it isn't reproducible now, I would like to remove this from the problemlist. If it does fail again, I'll go ahead and collect some additional details to help narrow this down.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9221

From jpai at openjdk.org  Tue Jun 21 06:51:08 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Jun 2022 06:51:08 GMT
Subject: RFR: 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java
 from problemlist
Message-ID: <LT1zYZzXCl-dLrl9CSbojrPN95_aSbgAkg5A6tpecME=.f014c351-b7c5-414a-920b-dc3cde9a5db8@github.com>

Can I please get a review for this change which proposes to remove the `CompressorPluginTest` from the problemlist?

This test was problem listed since it had intermittently failed with odd exception in the past (https://bugs.openjdk.org/browse/JDK-8247407). Over the past several months I have attempted multiple runs of this test (with very high test repeats) both locally as well as a CI setup to see if this is still reproducible. So far, I haven't been able to reproduce it. Given the odd exception it was throwing originally, it's hard to say what the issue could have been (and whether it got fixed in recent times), but since it isn't reproducible now, I would like to remove this from the problemlist. If it does fail again, I'll go ahead and collect some additional details to help narrow this down.

-------------

Commit messages:
 - 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist

Changes: https://git.openjdk.org/jdk/pull/9221/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9221&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288744
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9221.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9221/head:pull/9221

PR: https://git.openjdk.org/jdk/pull/9221

From Alan.Bateman at oracle.com  Tue Jun 21 07:00:51 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Jun 2022 08:00:51 +0100
Subject: DirectBufferAllocTest fails after replacement of Thread.sleep()
 with Thread.onSpinWait()
In-Reply-To: <e6232617-b4bb-f714-cb5d-4321b8c67773@oracle.com>
References: <2298281655718230@iva5-64778ce1ba26.qloud-c.yandex.net>
 <fd8fb3a1-4d3a-1a9b-70ff-2704492c0abc@oracle.com>
 <5296351655736573@vla5-8300199a0c8b.qloud-c.yandex.net>
 <e6232617-b4bb-f714-cb5d-4321b8c67773@oracle.com>
Message-ID: <43f60341-9d2c-be8d-ad66-b5ed744a00ea@oracle.com>

On 20/06/2022 22:58, David Holmes wrote:
>
> Thread.onSpinWait _is_ busy-waiting, but it may (depending on 
> architecture) actually execute a more (power) efficient form of 
> busy-wait.
>
> The takeaway from this exercise is that loops with sleeps can't always 
> be replaced by loops that busy-wait. Functionally the logic is the 
> same, but you can't just ignore the concurrency aspects.
Right, and in this case I don't think a busy wait would be very 
efficient as it would require a very high max spin count. To date 
Peter's exponential back-off has worked well and it's rare to hear about 
OOME cases caused by code that that is allocating direct buffers for 
single use. In time, I assume we will see more code using the new FFM 
API which can support deterministic memory release.

-Alan

From dholmes at openjdk.org  Tue Jun 21 07:13:41 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Jun 2022 07:13:41 GMT
Subject: RFR: 8287982: Concurrent implicit attach from native threads
 crashes VM
In-Reply-To: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com>
References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com>
Message-ID: <IPcWzrm_4jSQEQ5E_elMU13g1SShbt62OLiFK17mFfc=.506eab72-2e02-42bc-a486-ef5381ea32ea@github.com>

On Thu, 16 Jun 2022 13:34:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread without a thread name, or native threads that attach implicitly by using a function pointer to do an up call.
> 
> The issue that raises its head periodically is that native threads that JNI attach do the initializaiton of the Thread object in the context of the attaching thread. Great care must be taken because Java code is executing in the context of a Thread that is not fully initialized. The right thing is probably to create the Thread object in another thread, using the service thread has been mentioned. The issue at this time arises when two or more native threads attempt to attach without thread names at around the same time. The first thread that needs an automatically generated name triggers the loading and initialization of a helper class.  If there are other threads attaching at the same time then they may have to wait on the monitor which can trigger the crash because the field holder with the thread status is not created at this time. Crashes in monitor enter and notify have been observed. Coleen has changed this code so that linking and initialization uses a mutex (JDK-8288064) so
  this specific crash doesn't duplicate in the main line. The short term fix for openjdk/jdk19 is to reorder the initialization so that field holder with the thread status is created before setting the name.
> 
> Creating a jtreg test with the conditions to duplicate this issue is complicated. The jtreg main wrapper creates the main thread with an automatically generated thread name before it runs the test main method. This is the reason that the test needs to launch a new VM with the right setup to exercise both explicit and implicit attach.

Looks good.

And I confirmed that the VM code will correctly handle a null name from the current Java thread.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/28

From alanb at openjdk.org  Tue Jun 21 08:16:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Jun 2022 08:16:41 GMT
Subject: RFR: 8287982: Concurrent implicit attach from native threads
 crashes VM
In-Reply-To: <IPcWzrm_4jSQEQ5E_elMU13g1SShbt62OLiFK17mFfc=.506eab72-2e02-42bc-a486-ef5381ea32ea@github.com>
References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com>
 <IPcWzrm_4jSQEQ5E_elMU13g1SShbt62OLiFK17mFfc=.506eab72-2e02-42bc-a486-ef5381ea32ea@github.com>
Message-ID: <LXvj93HE9apu07lOjAJZ_M59B5QD6oqcp4fGKVy0Ros=.bb1b8970-a5a8-4997-ae68-4a3b2bc0a1c5@github.com>

On Tue, 21 Jun 2022 07:09:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> And I confirmed that the VM code will correctly handle a null name from the current Java thread.

Thanks, I checked that one.

One thing that I'm wondering for the test is whether to move it to test/hotspot/jtreg/runtime/jni/ so it lives with the other tests for JNI. I had expected to find other tests for AttachCurrentThread in that location but we don't.

-------------

PR: https://git.openjdk.org/jdk19/pull/28

From aturbanov at openjdk.org  Tue Jun 21 08:31:52 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 21 Jun 2022 08:31:52 GMT
Subject: Integrated: 8288628: Unnecessary Hashtable usage in
 ConditionalSpecialCasing
In-Reply-To: <kf1_S_6HBNMCNOvz2IdeQ8QKgtDr-SY2IG1umSb48nI=.c8e4203c-c9b9-422c-b3cf-d68d54ed66dc@github.com>
References: <kf1_S_6HBNMCNOvz2IdeQ8QKgtDr-SY2IG1umSb48nI=.c8e4203c-c9b9-422c-b3cf-d68d54ed66dc@github.com>
Message-ID: <QfeD1ZUBmYHLce_CUW_5Cn2oXsPlUv2TTKIu-H0QmF4=.a89f317f-b157-448d-8454-b0580d531e31@github.com>

On Wed, 15 Jun 2022 19:49:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> If a thread-safe implementation is not needed, it is recommended to use HashMap in place of Hashtable.
> `ConditionalSpecialCasing.entryTable` is read-only Map which is modified only in `static` block. It means we can safely replace it with HashMap.

This pull request has now been integrated.

Changeset: 0f801fe6
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f801fe6fd2fcc181121f9846f6869ca3a03e18a
Stats:     4 lines in 1 file changed: 1 ins; 1 del; 2 mod

8288628: Unnecessary Hashtable usage in ConditionalSpecialCasing

Reviewed-by: naoto, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/9172

From sgehwolf at openjdk.org  Tue Jun 21 08:40:04 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 21 Jun 2022 08:40:04 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
Message-ID: <C3Ctx0av3zyhdDqB-bxKNTFh6ntc5XlEHoJrrNO0Mew=.44a35643-edf5-4ef0-b1c1-f3001f342413@github.com>

On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor hotspot gtest
>  - Separate into function. Fix comment.

Don't close this yet please, bot.

-------------

PR: https://git.openjdk.org/jdk/pull/8629

From alanb at openjdk.org  Tue Jun 21 08:59:54 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Jun 2022 08:59:54 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v2]
In-Reply-To: <_g36T1LwpXJmJ91PiJ4WQMjhk08mMMjPNzh5hdhV418=.08bb181d-60a8-4e86-a9e9-59203b2eabf1@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <_g36T1LwpXJmJ91PiJ4WQMjhk08mMMjPNzh5hdhV418=.08bb181d-60a8-4e86-a9e9-59203b2eabf1@github.com>
Message-ID: <4IEfG_ycHWHNgMpWF-CYbgkuL4VuP1F8F_f7D1uddgY=.bd3e663d-5041-470b-b55a-6c3b2b073323@github.com>

On Sat, 18 Jun 2022 00:31:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
>> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added c2b test

> I looked for similar test cases but ended up finding nothing. Thus I created a new test case here. Problem is that they are issued through `SharedSecrets`, which are effectively _APIs_ but treated as private methods which leads to insufficient testing. I now think that I would add not only b2c test, but also c2b test (for getBytesNoRepl() method) is needed. I will modify the test case to include it.
 
My comment was mostly asking if we need to add more tests for Files.writeString. I would have expected a test for that method to fail with this bug. Maybe we need to create a new issue to expand the tests for this method.


> BTW, I found a spec bug in `Files.writeString()` w/o `Charset` argument, where the `@throws` clause reads: "[IOException](https://urldefense.com/v3/__https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/io/IOException.html__;!!ACWV5N9M2RV99hQ!PzgRBNWQwotDtM0GEFtu0XuT7pUqLpKjdwt6awkfFaeZEhXxhdEPL5FhuTeNGYrUHdaeM-_qWB2PccxVdZIFLQ$ ) - if an I/O error occurs writing to or creating the file, or the text cannot be encoded using the specified charset", but there is no specified charset there.

It looks like description for IOException was copied from the 4-arg writeString to the 3-arg writeString. I've created JDK-8288836 to track this.

One other thing, this is a regression in 19 so I assume the PR should be against openjdk/jdk19 rather than the main line.

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From dfuchs at openjdk.org  Tue Jun 21 09:24:52 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 21 Jun 2022 09:24:52 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <YecuwWKp3-Ap4sBzBO1ZwHhRZCI3uW4OIJCc3rjAwjo=.3469f256-12a4-4104-9ac3-ed5906238646@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
 <YecuwWKp3-Ap4sBzBO1ZwHhRZCI3uW4OIJCc3rjAwjo=.3469f256-12a4-4104-9ac3-ed5906238646@github.com>
Message-ID: <jpoc5zWRwo7gB3knOTk6l_CPgfDJWm86GA7PPaQZ7r8=.cc984862-a280-4e06-b375-62938376a39f@github.com>

On Mon, 20 Jun 2022 18:28:36 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Shouldn't we use `Reference.refersTo()` instead of `Reference.get() == smth` in lines 428 and 501?

Hi Sergey, we could, and I'll do it for consistency.
Though in those two cases it doesn't really matter since the facade referent is not supposed to be null (it can't since there still exist strong references), so keeping the reference alive longer than it should is not a concern there.

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From attila at openjdk.org  Tue Jun 21 09:38:57 2022
From: attila at openjdk.org (Attila Szegedi)
Date: Tue, 21 Jun 2022 09:38:57 GMT
Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in
 java.time
In-Reply-To: <T1aGUhg2oja-wwEfNWodY5NDQu-0b_u7RrWD-Pll1Oc=.01a4d5f4-9985-43da-a45e-d5fb8bc6e966@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>
 <T1aGUhg2oja-wwEfNWodY5NDQu-0b_u7RrWD-Pll1Oc=.01a4d5f4-9985-43da-a45e-d5fb8bc6e966@github.com>
Message-ID: <usL6uqhM57HR3cx4cFvhH-T7liNKZiuzDDTJMQIHT6c=.f69117f8-1a3e-44d8-9b7c-38f4b3bdcbed@github.com>

On Mon, 20 Jun 2022 15:01:55 GMT, liach <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 319:
>> 
>>> 317:                 store = prev;
>>> 318:             }
>>> 319:         }
>> 
>> You could do better here and use `computeIfAbsent` with `createStore` as its lambda. You could even change the signature of `createStore` to take `Entry<TemporalField, Locale>` as its parameter and then you could have this method be:
>> 
>>     private Object findStore(TemporalField field, Locale locale) {
>>         return CACHE.computeIfAbsent(createEntry(field, locale), this::createStore);
>>     }
>> 
>>     ...
>> 
>>     private Object createStore(Entry<TemporalField, Locale> entry) {
>>         ...
>>     }
>> 
>> This applies to most other changes you made, the one in `ZoneOffset` is the only one that's slightly different because there you have adjustment of `ID_CACHE` too.
>
> This behaves slightly different from the old initialization; the concurrent hash map blocks when the mapping function is run, just in case if non-blocking instantiation is what we want. If that's not a problem, I would prefer szegedi's suggestion.

@liach advance apologies for nitpicking: `ConcurrentHashMap` doesn't in general block while the mapping function runs. It can block _some_ concurrent updates, namely those that [hash to the same bin](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/0f801fe6fd2fcc181121f9846f6869ca3a03e18a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java*L324__;Iw!!ACWV5N9M2RV99hQ!JBDYAOKXAgaJoVrQyfzX6Cpak1HLEt3HG254q8COTDzpz7Ui1_Jm8iUTLqBdiluzP1PMfTEA4n31sDYGYuZr2t8$ ) and it won't block concurrent reads. I'm not saying the concern you raised isn't valid, just wanted to clarify that the situation is not nearly as grave as overall blocking; after all it ain't a `Collections.synchronizedMap` :-)

-------------

PR: https://git.openjdk.org/jdk/pull/9208

From akasko at openjdk.org  Tue Jun 21 09:39:16 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Tue, 21 Jun 2022 09:39:16 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments
Message-ID: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>

jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable.

It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard.

Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points:

 - option naming inside a properties file, currently `pass-all-args` is used
 - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group
 - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination
 - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.aws.Desktop`

Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version.

Testing:
 
- [x] test to cover new logic is included
- [x] ran jtreg:jdk/tools/jpackage with no new failures

-------------

Commit messages:
 - jpackage: file association additional arguments (draft)

Changes: https://git.openjdk.org/jdk/pull/9224/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9224&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288838
  Stats: 58 lines in 7 files changed: 47 ins; 7 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9224.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9224/head:pull/9224

PR: https://git.openjdk.org/jdk/pull/9224

From coderodd3 at gmail.com  Tue Jun 21 11:20:02 2022
From: coderodd3 at gmail.com (Rodion Efremov)
Date: Tue, 21 Jun 2022 14:20:02 +0300
Subject: [JMH results for IndexedLinkedList]
Message-ID: <CADLcvW=xm=w8q34_mLdGORQOXjqrojnUmm2Lzq_-FvhdAZBuNg@mail.gmail.com>

Hi,

Data structure: IndexedLinkedList
<https://github.com/coderodde/IndexedLinkedList>
Benchmark: IndexedLinkedListBenchmark
<https://github.com/coderodde/IndexedLinkedListBenchmark>

Benchmark output:
https://github.com/coderodde/indexedLinkedList/#benchmark-output

>From the benchmark output, we can judge that IndexedLinkedList outperforms
both java.util.LinkedList and the Apache Commons Collections TreeList. It,
however, does not seem to supersede the java.util.ArrayList.

Basically, I would expect the IndexedLinkedList to beat the ArrayList where
we have a lot of following operations:

   - addFirst(E)
   - add(int, E)
   - remove(int)

So, what do you think? I am getting anywhere with that?

Best regards,
rodde
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220621/752c7d0a/attachment-0001.htm>

From sergei.tsypanov at yandex.ru  Tue Jun 21 11:35:12 2022
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Tue, 21 Jun 2022 13:35:12 +0200
Subject: DirectBufferAllocTest fails after replacement of Thread.sleep()
 with Thread.onSpinWait()
In-Reply-To: <e6232617-b4bb-f714-cb5d-4321b8c67773@oracle.com>
References: <2298281655718230@iva5-64778ce1ba26.qloud-c.yandex.net>
 <fd8fb3a1-4d3a-1a9b-70ff-2704492c0abc@oracle.com>
 <5296351655736573@vla5-8300199a0c8b.qloud-c.yandex.net>
 <e6232617-b4bb-f714-cb5d-4321b8c67773@oracle.com>
Message-ID: <5553761655811312@iva8-44e4b329128e.qloud-c.yandex.net>

> The takeaway from this exercise is that loops with sleeps can't always be replaced by loops that busy-wait.
> Functionally the logic is the same, but you can't just ignore the concurrency aspects.

Thanks for explanation!

> Which indicates yielding is having a similar effect to sleeping - though I would expect it to be less pronounced.

May I ask one last question about this: in general case when we don't care about particular wait time (like in j.n.Bits.reserveMemory())
should I prefer Thread.yield() over both Thread.sleep() and Thread.onSpinWait() providing that Thread.sleep() is expensive
and Thread.onSpinWait() might cause undesirable side effects?

Regards,
Sergey Tsypanov

From alanb at openjdk.org  Tue Jun 21 12:13:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Jun 2022 12:13:27 GMT
Subject: RFR: 8288840: StructureViolationException should not link to fork
 method
Message-ID: <atSuZvKQ0wW_08vhqloaulDw66snAT0x_Otgl4uSnNM=.10091375-db9e-41bb-83d8-380959ce48f7@github.com>

StructureViolationException has a `@see` link to a fork method that does not throw this exception. The link should be removed for JDK 19. We'll add the link back once the JEP for Extent-Local Variables is integrated.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk19/pull/52/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=52&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288840
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk19/pull/52.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/52/head:pull/52

PR: https://git.openjdk.org/jdk19/pull/52

From david.lloyd at redhat.com  Tue Jun 21 12:31:40 2022
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 21 Jun 2022 07:31:40 -0500
Subject: Handling of USR2 signal in JVM on Linux
In-Reply-To: <CAA-vtUx3apKjiCmVtJ9HW+g2rVqADTAAn30Gt+xSji2-UuNQjQ@mail.gmail.com>
References: <CAF+DQ5fPtCap3EcvUXSaPEdxuiD5W_SnEUjFfkHk-hF=4VAXgw@mail.gmail.com>
 <4d55f1ab-6734-4c20-c3ff-a9160425860b@oracle.com>
 <CAF+DQ5c7g4S9QNBMzY0vr9bxd4f5XnVtNuWiqDzhF35_8HY_mA@mail.gmail.com>
 <CAA-vtUwderH0WfXrfAbM=VfpVXnbfx1Ydz77k9Vtx76rNbOmVQ@mail.gmail.com>
 <CAA-vtUw3Me-aWMoPhmcomBf=FDGMFemJzJaKC63FvGN3tp0-cQ@mail.gmail.com>
 <be5d1b98-3fc9-5383-9513-762160fe43a1@oracle.com>
 <CAA-vtUzWCUjFCKhD8tQow8PFm1ugG8hse6U072vRtMEJ9XUpag@mail.gmail.com>
 <2014aec0-945b-a311-6fd7-46dad4899b00@oracle.com>
 <CANghgrSNrBAkbg_z3=-_pqSXQ4--QR_PAYxha9xT0D5G+3AxVg@mail.gmail.com>
 <CAA-vtUx3apKjiCmVtJ9HW+g2rVqADTAAn30Gt+xSji2-UuNQjQ@mail.gmail.com>
Message-ID: <CANghgrTY8rZUhDvy5DPozhvuxPKK3dqs15pHQSCf8FpR=QN9UA@mail.gmail.com>

On Fri, Jun 17, 2022 at 1:05 AM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>>
>>
>> > >
>> > > I see your point. I dislike crashes, especially ones they can be
>> > > reliably triggered from outside. You never can be sure about the
>> > > security implications either.
>> > >
>> > > If you dislike ignoring the signal, and since the default action for
>> > > SIGUSR1+2 is process termination, why not exit the VM with an error
>> > > message instead? At least we don?t have what looks like a random
>> > > segfault, and we could print out the sender pid  too.
>> >
>> > We could ... but then do we do that for every other signal that can be
>> > thrown at the JVM from externally and which will leads to crashes? Where
>> > do you stop?
>>
>
> It's a very limited set. I'd say we limit this to
>
> 1) signal for which we registered handlers: the handlers should at least not crash or vanish the VM without a trace
> 2) signals which may conceivably be sent to the VM in the normal course of events: if the default action is to terminate the VM, we should handle them
>
> Note that for (2), we already do this for some signals. We explicitly handle SIGPIPE (https://bugs.openjdk.org/browse/JDK-4229104) and SIGXFSZ (https://bugs.openjdk.org/browse/JDK-6499219) because they kill the VM.
>
>>
>> Well, playing devil's advocate, why not? Would it be more complex than adding a
>>
>>     if (si.si_pid != my_cached_pid) {
>>         // it came from Outside, let's exit with 128+signum
>>         // ...
>>     }
>>
>> to the top of the signal handler(s)?
>>
>> --
>> - DML ? he/him
>>
>
> I filed a JBS issue and a PR: https://github.com/openjdk/jdk/pull/9181#issuecomment-1157353776.
>
> I went with a different approach, just using Thread::current=NULL as an indicator. I was worried that Unix implementations may leave the si_pid field empty, or that it gets filled with the sender's kernel thread id, not the process pid. Just verified that on Linux, its really actually the process id (so the main threads id).

`siginfo_t` is POSIX so I wouldn't worry much about it being anything
other than the sender's process ID in the year 2022. Testing that
`Thread::current=NULL` tells you that the thread that the signal was
delivered to doesn't have a Java thread, I guess, but it doesn't tell
you if the signal was invalid in the case where the target thread does
have a corresponding Java thread; after all, a process signal sent
from outside could be sent to any thread as you say. Checking the
sending PID tells you with certainty whether or not the signal did
come from outside, which is really the salient question AFAICT.

-- 
- DML ? he/him


From rehn at openjdk.org  Tue Jun 21 15:08:02 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 21 Jun 2022 15:08:02 GMT
Subject: RFR: 8287982: Concurrent implicit attach from native threads
 crashes VM
In-Reply-To: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com>
References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com>
Message-ID: <BkwyiaectEzmGQaE2d3DYCtlYL5n4nuq8A6e14QFiQw=.46540fed-dbfd-47e6-b412-535a782ea3ac@github.com>

On Thu, 16 Jun 2022 13:34:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread without a thread name, or native threads that attach implicitly by using a function pointer to do an up call.
> 
> The issue that raises its head periodically is that native threads that JNI attach do the initializaiton of the Thread object in the context of the attaching thread. Great care must be taken because Java code is executing in the context of a Thread that is not fully initialized. The right thing is probably to create the Thread object in another thread, using the service thread has been mentioned. The issue at this time arises when two or more native threads attempt to attach without thread names at around the same time. The first thread that needs an automatically generated name triggers the loading and initialization of a helper class.  If there are other threads attaching at the same time then they may have to wait on the monitor which can trigger the crash because the field holder with the thread status is not created at this time. Crashes in monitor enter and notify have been observed. Coleen has changed this code so that linking and initialization uses a mutex (JDK-8288064) so
  this specific crash doesn't duplicate in the main line. The short term fix for openjdk/jdk19 is to reorder the initialization so that field holder with the thread status is created before setting the name.
> 
> Creating a jtreg test with the conditions to duplicate this issue is complicated. The jtreg main wrapper creates the main thread with an automatically generated thread name before it runs the test main method. This is the reason that the test needs to launch a new VM with the right setup to exercise both explicit and implicit attach.

Looks good.

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/28

From aleksej.efimov at oracle.com  Tue Jun 21 15:30:17 2022
From: aleksej.efimov at oracle.com (Aleksei Efimov)
Date: Tue, 21 Jun 2022 15:30:17 +0000
Subject: Bug JDK-8176553
In-Reply-To: <06a79df6-24fc-bfbd-476e-208ac4ec9fa7@oracle.com>
References: <04eec9b7-4995-3f88-c2db-ec8ba628dffa@redhat.com>
 <06a79df6-24fc-bfbd-476e-208ac4ec9fa7@oracle.com>
Message-ID: <CY4PR1001MB237645CBEE5610892A0A5F3FECB39@CY4PR1001MB2376.namprd10.prod.outlook.com>

Hi Ricardo,

Thank you for discovering and reproducing the issue - it looks like JDK-8176553 was incomplete in solving how referrals are limited. At first glance the attached patch (fix + test) looks like a good change to have - I think it is PR worthy :)
I've logged a bug for your change - https://bugs.openjdk.org/browse/JDK-8288895.

Best,
Aleksei

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Sean Mullan <sean.mullan at oracle.com>
Sent: Friday, June 17, 2022 3:15 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Fwd: Bug JDK-8176553

[reposting to core-libs-dev as this is in the JNDI/LDAP component]


-------- Forwarded Message --------
Subject: Bug JDK-8176553
Date: Fri, 17 Jun 2022 14:23:11 +0200
From: Ricardo Martin Camarero <rmartinc at redhat.com>
To: security-dev at openjdk.org

Hi!

I decided to send an email to the security-dev email list as ldap is
involved. Please redirect me to other list if it is not the proper audience.

The last last days I have faced the same issue that is commented in
JDK-8176553 [1]. Although it is cataloged as fixed in 12, the issue is
not solved in the openjdk master branch yet. You can test with this
simple project [2]. The project is using apache-ds and creating 12
branches with redirects from one to the other. The search should be
limited to 5 hops but you will see that all of them are followed (12).
Therefore, If there are loops, the search hangs indefinitely. So
JDK-8176553 is not fixed completely. You just need `mvn clean test` to
reproduce the problem in that project.

I have investigated and I think the attached little patch fixes the
issue. Mainly the `LdapReferralException` is not stopping the referral
loop in some situations. I have added a test in the jndi jtreg
test-suite to check everything works OK; `make test
TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java`

WDYT? Is the PR worthy?

Thanks in advance!


[1] https://bugs.openjdk.org/browse/JDK-8176553
[2]
https://urldefense.com/v3/__https://github.com/rmartinc/apache-ds-referrals__;!!ACWV5N9M2RV99hQ!IZkp5q_gOAeIP8Y9Gvr8aniLloG51lZJwlG1yN6BRDyHHLpyr0W64TDMUPAzoPu7dOBOyJrNcKYmwaOF9REM3oA$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220621/ab9ed49a/attachment.htm>

From alanb at openjdk.org  Tue Jun 21 16:12:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Jun 2022 16:12:52 GMT
Subject: RFR: 8288697: Clarify lifecycle of buffer segments and loader
 lookup
In-Reply-To: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
References: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
Message-ID: <mMZ3aaH1ZZxs0b5ygD50YxFUSKKe1Oo0Cjpqfx1NZ5E=.7b595690-74e9-45fb-bf73-3e4cddecb0ef@github.com>

On Fri, 17 Jun 2022 21:39:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases:
> 
> * when a buffer segment is created, to keep the original buffer instance reachable
> * when a loader symbol lookup is created, to keep the classloader instance reachable
> 
> Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model.
> 
> This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments.
> 
> This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 148:

> 146:      * <p>
> 147:      * The symbols obtained from the returned loader lookup are backed by the {@linkplain MemorySession#global() global session}.
> 148:      * <p>

Does the spec update mean this should have a CSR?

-------------

PR: https://git.openjdk.org/jdk19/pull/39

From mcimadamore at openjdk.org  Tue Jun 21 16:16:39 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Jun 2022 16:16:39 GMT
Subject: RFR: 8288697: Clarify lifecycle of buffer segments and loader
 lookup
In-Reply-To: <mMZ3aaH1ZZxs0b5ygD50YxFUSKKe1Oo0Cjpqfx1NZ5E=.7b595690-74e9-45fb-bf73-3e4cddecb0ef@github.com>
References: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
 <mMZ3aaH1ZZxs0b5ygD50YxFUSKKe1Oo0Cjpqfx1NZ5E=.7b595690-74e9-45fb-bf73-3e4cddecb0ef@github.com>
Message-ID: <Gx12ilNsAnx1g8Bo_SOqNVHvio3OBeSfMR0Eloib7Jk=.118ba099-83dd-45ee-8b7d-35b8ce536d33@github.com>

On Tue, 21 Jun 2022 16:10:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases:
>> 
>> * when a buffer segment is created, to keep the original buffer instance reachable
>> * when a loader symbol lookup is created, to keep the classloader instance reachable
>> 
>> Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model.
>> 
>> This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments.
>> 
>> This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case.
>
> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 148:
> 
>> 146:      * <p>
>> 147:      * The symbols obtained from the returned loader lookup are backed by the {@linkplain MemorySession#global() global session}.
>> 148:      * <p>
> 
> Does the spec update mean this should have a CSR?

Yep - note that PR is in draft mode as we need to think through what changes we actually want to pursue.

-------------

PR: https://git.openjdk.org/jdk19/pull/39

From psandoz at openjdk.org  Tue Jun 21 16:18:16 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Jun 2022 16:18:16 GMT
Subject: RFR: 8288761: SegmentAllocator:allocate(long bytesSize) not
 throwing IAEx when bytesSize < 0
In-Reply-To: <-2C9IA0kqJYX66c2BDITjapzom0cljNzid877uCRy9A=.a695bf67-1df3-4e6c-bcda-18a129e848de@github.com>
References: <-2C9IA0kqJYX66c2BDITjapzom0cljNzid877uCRy9A=.a695bf67-1df3-4e6c-bcda-18a129e848de@github.com>
Message-ID: <E5nB8WlR1K-Zxa5lApgPO2-SSZc_3ZPqsqD1WAmGLrc=.d19a534a-1abb-4bfe-83ee-8db831165640@github.com>

On Mon, 20 Jun 2022 21:22:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The various SegmentAllocator subclasses do not check for the constraints mentioned in the javadoc.
> This patch pulls the checks into a common routine in the Utils class, and then call that check routine from all the `allocate` implementations.

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/50

From psandoz at openjdk.org  Tue Jun 21 16:19:54 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Jun 2022 16:19:54 GMT
Subject: RFR: 8288840: StructureViolationException should not link to fork
 method
In-Reply-To: <atSuZvKQ0wW_08vhqloaulDw66snAT0x_Otgl4uSnNM=.10091375-db9e-41bb-83d8-380959ce48f7@github.com>
References: <atSuZvKQ0wW_08vhqloaulDw66snAT0x_Otgl4uSnNM=.10091375-db9e-41bb-83d8-380959ce48f7@github.com>
Message-ID: <OhFdLaj2ZSME76eIPMNODs7qKM9wlg_hEfEDv3aCHz4=.b4601955-132d-4e49-bfb9-5dde0ed01c36@github.com>

On Tue, 21 Jun 2022 11:20:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructureViolationException has a `@see` link to a fork method that does not throw this exception. The link should be removed for JDK 19. We'll add the link back once the JEP for Extent-Local Variables is integrated.

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/52

From mchung at openjdk.org  Tue Jun 21 16:19:54 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 21 Jun 2022 16:19:54 GMT
Subject: RFR: 8288840: StructureViolationException should not link to fork
 method
In-Reply-To: <atSuZvKQ0wW_08vhqloaulDw66snAT0x_Otgl4uSnNM=.10091375-db9e-41bb-83d8-380959ce48f7@github.com>
References: <atSuZvKQ0wW_08vhqloaulDw66snAT0x_Otgl4uSnNM=.10091375-db9e-41bb-83d8-380959ce48f7@github.com>
Message-ID: <jATmAbOJKULXc4mJN_G8moSo2irH7-p4BZPg-bdnw5Y=.d8f4c822-3ec8-482a-8f7d-0e6807d8b59e@github.com>

On Tue, 21 Jun 2022 11:20:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructureViolationException has a `@see` link to a fork method that does not throw this exception. The link should be removed for JDK 19. We'll add the link back once the JEP for Extent-Local Variables is integrated.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/52

From joehw at openjdk.org  Tue Jun 21 17:03:01 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 21 Jun 2022 17:03:01 GMT
Subject: RFR: 8288529: broken link in java.xml
Message-ID: <xt5d35nA1mPd-KviOLm6rY3Gj3S8jxGxxkW5cxKUvwQ=.402af81d-64f9-4a87-92fd-20cd952a3835@github.com>

Some of the links cause redirection, iso.org in particular took 1-2 seconds, that looks like was longer than the wait time of the doccheck and docs link checker. Changed it to the current homepage to avoid redirection. Also changed other links within this package. 

I'm limiting the change to this package only as iso.org only appears in it and other redirections have not caused any issue (tests showed they were almost instant).

-------------

Commit messages:
 - 8288529: broken link in java.xml

Changes: https://git.openjdk.org/jdk19/pull/55/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=55&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288529
  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk19/pull/55.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/55/head:pull/55

PR: https://git.openjdk.org/jdk19/pull/55

From naoto.sato at oracle.com  Tue Jun 21 17:08:36 2022
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 21 Jun 2022 10:08:36 -0700
Subject: <i18n dev> RFR: 8287868: Localized names update in COMPAT locale
 provider
In-Reply-To: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
References: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
Message-ID: <5c03e559-64ae-685e-f9ca-ed1bf776e59f@oracle.com>

Ping.

Naoto

On 6/10/22 2:05 PM, Naoto Sato wrote:
> As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.
> 
> -------------
> 
> Commit messages:
>   - 8287868: Localized names update in COMPAT locale provider
> 
> Changes: https://git.openjdk.org/jdk/pull/9134/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9134&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8287868
>    Stats: 9930 lines in 65 files changed: 17 ins; 7 del; 9906 mod
>    Patch: https://git.openjdk.org/jdk/pull/9134.diff
>    Fetch: git fetch https://git.openjdk.org/jdk pull/9134/head:pull/9134
> 
> PR: https://git.openjdk.org/jdk/pull/9134

From iris at openjdk.org  Tue Jun 21 17:09:37 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 21 Jun 2022 17:09:37 GMT
Subject: RFR: 8288529: broken link in java.xml
In-Reply-To: <xt5d35nA1mPd-KviOLm6rY3Gj3S8jxGxxkW5cxKUvwQ=.402af81d-64f9-4a87-92fd-20cd952a3835@github.com>
References: <xt5d35nA1mPd-KviOLm6rY3Gj3S8jxGxxkW5cxKUvwQ=.402af81d-64f9-4a87-92fd-20cd952a3835@github.com>
Message-ID: <An6VdIJLg3AchATAHhrrLVwIwSCHRjiRJK9EqXRP3QU=.6b592f4c-5664-4abb-bd7c-f248111ccbc1@github.com>

On Tue, 21 Jun 2022 16:52:52 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Some of the links cause redirection, iso.org in particular took 1-2 seconds, that looks like was longer than the wait time of the doccheck and docs link checker. Changed it to the current homepage to avoid redirection. Also changed other links within this package. 
> 
> I'm limiting the change to this package only as iso.org only appears in it and other redirections have not caused any issue (tests showed they were almost instant).

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/55

From duke at openjdk.org  Tue Jun 21 17:10:24 2022
From: duke at openjdk.org (liach)
Date: Tue, 21 Jun 2022 17:10:24 GMT
Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in
 java.time
In-Reply-To: <usL6uqhM57HR3cx4cFvhH-T7liNKZiuzDDTJMQIHT6c=.f69117f8-1a3e-44d8-9b7c-38f4b3bdcbed@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>
 <T1aGUhg2oja-wwEfNWodY5NDQu-0b_u7RrWD-Pll1Oc=.01a4d5f4-9985-43da-a45e-d5fb8bc6e966@github.com>
 <usL6uqhM57HR3cx4cFvhH-T7liNKZiuzDDTJMQIHT6c=.f69117f8-1a3e-44d8-9b7c-38f4b3bdcbed@github.com>
Message-ID: <Nm1e96mMDxzm49EJQw_BlSb7J2JV26p51OYm9X_HfdI=.ed235894-4b38-42ab-a539-8efb00a8b225@github.com>

On Tue, 21 Jun 2022 09:35:34 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> This behaves slightly different from the old initialization; the concurrent hash map blocks when the mapping function is run, just in case if non-blocking instantiation is what we want. If that's not a problem, I would prefer szegedi's suggestion.
>
> @liach advance apologies for nitpicking: `ConcurrentHashMap` doesn't in general block while the mapping function runs. It can block _some_ concurrent updates, namely those that [hash to the same bin](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/0f801fe6fd2fcc181121f9846f6869ca3a03e18a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java*L324__;Iw!!ACWV5N9M2RV99hQ!M8p-0NV01EacnHQD8Y5232_Rt40p54kS34M63XfK0EUN2_xI4QBo2zVeveUTw_ZurSoBFa079sXr7GdmArz-$ ) and it won't block concurrent reads. I'm not saying the concern you raised isn't valid, just wanted to clarify that the situation is not nearly as grave as overall blocking; after all it ain't a `Collections.synchronizedMap` :-)

Yeah, since `putIfAbsent` may block `get` calls, the blocking of `computeIfAbsent` is minuscule as long as the creation code is efficient enough. Just be careful that when writing the lambda for `computeIfAbsent`, preferably write static lambdas (that doesn't use `this`, instances, or local variables) so that one lambda can be reused over time than having to create a new one on each invocation.

-------------

PR: https://git.openjdk.org/jdk/pull/9208

From lancea at openjdk.org  Tue Jun 21 17:15:23 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 21 Jun 2022 17:15:23 GMT
Subject: RFR: 8288529: broken link in java.xml
In-Reply-To: <xt5d35nA1mPd-KviOLm6rY3Gj3S8jxGxxkW5cxKUvwQ=.402af81d-64f9-4a87-92fd-20cd952a3835@github.com>
References: <xt5d35nA1mPd-KviOLm6rY3Gj3S8jxGxxkW5cxKUvwQ=.402af81d-64f9-4a87-92fd-20cd952a3835@github.com>
Message-ID: <SUbpOmL4zoyWchEU82a-txht0eA7ND-r_BAQjGPb3HA=.10ab2528-5ccc-4c00-a240-d39ad8cae7dd@github.com>

On Tue, 21 Jun 2022 16:52:52 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Some of the links cause redirection, iso.org in particular took 1-2 seconds, that looks like was longer than the wait time of the doccheck and docs link checker. Changed it to the current homepage to avoid redirection. Also changed other links within this package. 
> 
> I'm limiting the change to this package only as iso.org only appears in it and other redirections have not caused any issue (tests showed they were almost instant).

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/55

From iris at openjdk.org  Tue Jun 21 17:19:20 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 21 Jun 2022 17:19:20 GMT
Subject: RFR: 8287868: Localized names update in COMPAT locale provider
 [v3]
In-Reply-To: <7TE5wWtqEEuIZFEM5-RgfVgrsH9spoCAZuXt2L0ZC6w=.e8219429-d3b0-4d72-b072-e494c62c874e@github.com>
References: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
 <7TE5wWtqEEuIZFEM5-RgfVgrsH9spoCAZuXt2L0ZC6w=.e8219429-d3b0-4d72-b072-e494c62c874e@github.com>
Message-ID: <vU85iHRs-gaxU7ETSyZr8MGdBzUwBAoolCge32FbDJM=.88d3494f-bce8-4a8c-ba02-851f816bfbf5@github.com>

On Mon, 13 Jun 2022 22:58:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed some failing tests

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9134

From bchristi at openjdk.org  Tue Jun 21 17:39:31 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 21 Jun 2022 17:39:31 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
Message-ID: <po8PP-3175ihyexUhDoAKW32oZtJmLtfN4xS4Jz4egA=.b29fd36e-12c8-4a4d-8c3b-b3b9c7cd7c24@github.com>

On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
> 
> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.

test/jdk/java/net/httpclient/AsFileDownloadTest.java line 207:

> 205:                 System.gc();
> 206:                 if (queue.remove(100) == ref) break;
> 207:             }

You might consider using the ForceGC test utility, here and in DigestEchoClient.java. E.g.:

 * @library /test/lib/
...
ForceGC gc = new ForceGC();
gc.await(ref.refersTo(null));

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From dfuchs at openjdk.org  Tue Jun 21 17:39:31 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 21 Jun 2022 17:39:31 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <po8PP-3175ihyexUhDoAKW32oZtJmLtfN4xS4Jz4egA=.b29fd36e-12c8-4a4d-8c3b-b3b9c7cd7c24@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
 <po8PP-3175ihyexUhDoAKW32oZtJmLtfN4xS4Jz4egA=.b29fd36e-12c8-4a4d-8c3b-b3b9c7cd7c24@github.com>
Message-ID: <9csaSJU5hyw5b_jwEj3WzqEg-pbRFhLYwYzD4gDf5h8=.71eaf5bf-58a9-4085-8bae-987ceffb42f1@github.com>

On Tue, 21 Jun 2022 17:31:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
>> 
>> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
>> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.
>
> test/jdk/java/net/httpclient/AsFileDownloadTest.java line 207:
> 
>> 205:                 System.gc();
>> 206:                 if (queue.remove(100) == ref) break;
>> 207:             }
> 
> You might consider using the ForceGC test utility, here and in DigestEchoClient.java. E.g.:
> 
>  * @library /test/lib/
> ...
> ForceGC gc = new ForceGC();
> gc.await(ref.refersTo(null));

Well - no - because ForceGC is using a different object and a different Cleaner thread. So it's much more efficient to wait on the reference queue (= the time to wait will be shorter, so risks of exceeding the global jtreg timeout will be lower).

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From darcy at openjdk.org  Tue Jun 21 17:39:44 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Jun 2022 17:39:44 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v31]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <JWSMaucB-aIj42Q0WMx0K0YV7Yef5yQ_el608VJL1oM=.8294f892-8cf2-472f-8c38-4a6262702474@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 47 additional commits since the last revision:

 - Expand scope of tests.
 - Merge branch 'master' into JDK-8266670
 - Add module-related tests.
 - Fix typo Exe-Boss spotted in review feedback.
 - Merge branch 'master' into JDK-8266670
 - Appease jcheck.
 - Expand regression tests.
 - Merge branch 'master' into JDK-8266670
 - Respond to review feedback from Roger Riggs.
 - Respond to review feedback.
 - ... and 37 more: https://git.openjdk.org/jdk/compare/ccdd6f93...98f12bb9

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/81bfc6d2..98f12bb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=29-30

  Stats: 804 lines in 36 files changed: 279 ins; 458 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From joehw at openjdk.org  Tue Jun 21 18:05:43 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 21 Jun 2022 18:05:43 GMT
Subject: RFR: 8287868: Localized names update in COMPAT locale provider
 [v3]
In-Reply-To: <7TE5wWtqEEuIZFEM5-RgfVgrsH9spoCAZuXt2L0ZC6w=.e8219429-d3b0-4d72-b072-e494c62c874e@github.com>
References: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
 <7TE5wWtqEEuIZFEM5-RgfVgrsH9spoCAZuXt2L0ZC6w=.e8219429-d3b0-4d72-b072-e494c62c874e@github.com>
Message-ID: <tYEvFpoOHBUw9exX-fzthsXAdio6kRIyx3Mai_RkP6Q=.2e550611-2509-45e2-9027-04d075fd80a3@github.com>

On Mon, 13 Jun 2022 22:58:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed some failing tests

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9134

From naoto at openjdk.org  Tue Jun 21 18:12:23 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Jun 2022 18:12:23 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v3]
In-Reply-To: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
Message-ID: <H1QkVDJlEiimJDANMozZlIeTkRpqzIJFimKo3wZhyaQ=.55c7dd1d-5926-42e1-8f0b-9ea0df5d268c@github.com>

> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Adding a test case in ReadWriteString.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9193/files
  - new: https://git.openjdk.org/jdk/pull/9193/files/e1afd207..f6520503

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=01-02

  Stats: 36 lines in 1 file changed: 34 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9193/head:pull/9193

PR: https://git.openjdk.org/jdk/pull/9193

From naoto at openjdk.org  Tue Jun 21 18:21:13 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Jun 2022 18:21:13 GMT
Subject: RFR: 8288529: broken link in java.xml
In-Reply-To: <xt5d35nA1mPd-KviOLm6rY3Gj3S8jxGxxkW5cxKUvwQ=.402af81d-64f9-4a87-92fd-20cd952a3835@github.com>
References: <xt5d35nA1mPd-KviOLm6rY3Gj3S8jxGxxkW5cxKUvwQ=.402af81d-64f9-4a87-92fd-20cd952a3835@github.com>
Message-ID: <KVL0h3DZEFm_GEcVEtQ5GvLa4hCg7Mgdt1CYb-B-Hcc=.5be80678-a6ca-4f75-a85a-cb932bf18791@github.com>

On Tue, 21 Jun 2022 16:52:52 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Some of the links cause redirection, iso.org in particular took 1-2 seconds, that looks like was longer than the wait time of the doccheck and docs link checker. Changed it to the current homepage to avoid redirection. Also changed other links within this package. 
> 
> I'm limiting the change to this package only as iso.org only appears in it and other redirections have not caused any issue (tests showed they were almost instant).

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/55

From naoto at openjdk.org  Tue Jun 21 18:27:20 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Jun 2022 18:27:20 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v2]
In-Reply-To: <4IEfG_ycHWHNgMpWF-CYbgkuL4VuP1F8F_f7D1uddgY=.bd3e663d-5041-470b-b55a-6c3b2b073323@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <_g36T1LwpXJmJ91PiJ4WQMjhk08mMMjPNzh5hdhV418=.08bb181d-60a8-4e86-a9e9-59203b2eabf1@github.com>
 <4IEfG_ycHWHNgMpWF-CYbgkuL4VuP1F8F_f7D1uddgY=.bd3e663d-5041-470b-b55a-6c3b2b073323@github.com>
Message-ID: <PhdzDy6d6-ZOh3YYe8lk63U2xeEHtlkCaBLtqGMw-wA=.665356f1-1d47-4114-950d-1238327dfc0e@github.com>

On Tue, 21 Jun 2022 08:55:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> My comment was mostly asking if we need to add more tests for Files.writeString. I would have expected a test for that method to fail with this bug. Maybe we need to create a new issue to expand the tests for this method.

Added a test case in ReadWriteString.java, which is the unit test for `Files.read/writeString()` methods.

> It looks like description for IOException was copied from the 4-arg writeString to the 3-arg writeString. I've created JDK-8288836 to track this.

Thanks for filing the issue.

> One other thing, this is a regression in 19 so I assume the PR should be against openjdk/jdk19 rather than the main line.

Since this PR already got a few approvals, I will backport the changeset to the jdk19 line after this PR gets integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From aturbanov at openjdk.org  Tue Jun 21 21:01:54 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 21 Jun 2022 21:01:54 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v3]
In-Reply-To: <H1QkVDJlEiimJDANMozZlIeTkRpqzIJFimKo3wZhyaQ=.55c7dd1d-5926-42e1-8f0b-9ea0df5d268c@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <H1QkVDJlEiimJDANMozZlIeTkRpqzIJFimKo3wZhyaQ=.55c7dd1d-5926-42e1-8f0b-9ea0df5d268c@github.com>
Message-ID: <xmJO_iSODcQHfMBKbGiZ4BiK7Ijf8WAuBGIS8gPxqeY=.e6259042-be34-434e-922a-a3091bfffafe@github.com>

On Tue, 21 Jun 2022 18:12:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
>> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a test case in ReadWriteString.java

test/jdk/java/lang/String/NoReplTest.java line 47:

> 45:     private final static Charset WINDOWS_1252 = Charset.forName("windows-1252");
> 46: 
> 47:     @Test

Looks confusing that annotation goes before javadoc

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From mcimadamore at openjdk.org  Tue Jun 21 21:03:34 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Jun 2022 21:03:34 GMT
Subject: Integrated: 8288761: SegmentAllocator:allocate(long bytesSize) not
 throwing IAEx when bytesSize < 0
In-Reply-To: <-2C9IA0kqJYX66c2BDITjapzom0cljNzid877uCRy9A=.a695bf67-1df3-4e6c-bcda-18a129e848de@github.com>
References: <-2C9IA0kqJYX66c2BDITjapzom0cljNzid877uCRy9A=.a695bf67-1df3-4e6c-bcda-18a129e848de@github.com>
Message-ID: <-VFp9M7MfgNoBYgJ-MY9hWbqkQMKCJFCYEFVQNNbLX4=.b84b8a01-fbcc-4732-a42f-e354dbb188d5@github.com>

On Mon, 20 Jun 2022 21:22:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The various SegmentAllocator subclasses do not check for the constraints mentioned in the javadoc.
> This patch pulls the checks into a common routine in the Utils class, and then call that check routine from all the `allocate` implementations.

This pull request has now been integrated.

Changeset: d7b43af5
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/d7b43af5914d88e5410f33db8b56f4dabdfec25d
Stats:     59 lines in 5 files changed: 43 ins; 13 del; 3 mod

8288761: SegmentAllocator:allocate(long bytesSize) not throwing IAEx when bytesSize < 0

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk19/pull/50

From almatvee at openjdk.org  Tue Jun 21 21:16:33 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 21 Jun 2022 21:16:33 GMT
Subject: Integrated: 8287971: Throw exception for missing values in
 .jpackage.xml
In-Reply-To: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
References: <QMTVMGZVlyGY6i8CbpoVGIKiZucuxl4nWCpz9sbQLug=.db03ffed-6770-4b3b-aba6-18709cd2d167@github.com>
Message-ID: <k0oATb00MpmTnJTUncFg6gxVYRmXPqtgQX6_MfG4dOA=.69c23332-d72d-4ec2-97f1-d90e390a6c13@github.com>

On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Error will be thrown if app image is generated with another JDK version or has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!MCPPHJCD6t-Japw98nbgIUCpUdM03Z6WDLlmGq6mT87cGQ31fpSgwcvIJwM7-dHEgrXUuQYej_UD5bWVI3a6r1MKgw$ .

This pull request has now been integrated.

Changeset: 70008da6
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/70008da6b47c371c4d15162ca38e1521cd09acf9
Stats:     207 lines in 11 files changed: 96 ins; 76 del; 35 mod

8287971: Throw exception for missing values in .jpackage.xml

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk19/pull/9

From naoto at openjdk.org  Tue Jun 21 21:34:16 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Jun 2022 21:34:16 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v4]
In-Reply-To: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
Message-ID: <elg5QhtVXlI9s1yxtikblbebmx1D3bMQVW0aGvmpAHw=.51e66c01-e14f-4ac5-aa66-124a8efd9805@github.com>

> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Refined the test, adding more variations.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9193/files
  - new: https://git.openjdk.org/jdk/pull/9193/files/f6520503..84d127be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=02-03

  Stats: 25 lines in 1 file changed: 14 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9193/head:pull/9193

PR: https://git.openjdk.org/jdk/pull/9193

From naoto at openjdk.org  Tue Jun 21 21:49:58 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Jun 2022 21:49:58 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v5]
In-Reply-To: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
Message-ID: <2mC9Q1w0EbczZgPu_VvD10SsAFmSsAwayIr0-P1GHds=.d91c80b9-9165-4d5e-837a-9b6c3c9b735d@github.com>

> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Moved `@Test` annotations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9193/files
  - new: https://git.openjdk.org/jdk/pull/9193/files/84d127be..864806ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=03-04

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9193/head:pull/9193

PR: https://git.openjdk.org/jdk/pull/9193

From naoto at openjdk.org  Tue Jun 21 21:49:59 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Jun 2022 21:49:59 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v3]
In-Reply-To: <xmJO_iSODcQHfMBKbGiZ4BiK7Ijf8WAuBGIS8gPxqeY=.e6259042-be34-434e-922a-a3091bfffafe@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <H1QkVDJlEiimJDANMozZlIeTkRpqzIJFimKo3wZhyaQ=.55c7dd1d-5926-42e1-8f0b-9ea0df5d268c@github.com>
 <xmJO_iSODcQHfMBKbGiZ4BiK7Ijf8WAuBGIS8gPxqeY=.e6259042-be34-434e-922a-a3091bfffafe@github.com>
Message-ID: <v2gjpQrvi2pVZbXPmBXa_Kw4KxMaW8qzSKJUdIYDRCE=.a36d4408-b4ad-4dde-80d7-901ed54bf574@github.com>

On Tue, 21 Jun 2022 20:59:40 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a test case in ReadWriteString.java
>
> test/jdk/java/lang/String/NoReplTest.java line 47:
> 
>> 45:     private final static Charset WINDOWS_1252 = Charset.forName("windows-1252");
>> 46: 
>> 47:     @Test
> 
> Looks confusing that annotation goes before javadoc

Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From jwilhelm at openjdk.org  Tue Jun 21 21:59:52 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 21 Jun 2022 21:59:52 GMT
Subject: RFR: Merge jdk19
Message-ID: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8287971: Throw exception for missing values in .jpackage.xml
 - 8288761: SegmentAllocator:allocate(long bytesSize) not throwing IAEx when bytesSize < 0
 - 8288754: GCC 12 fails to build zReferenceProcessor.cpp
 - 8286103: VThreadMonitorTest fails "assert(!current->cont_fastpath() || (current->cont_fastpath_thread_state() && !interpreted_native_or_deoptimized_on_stack(current))) failed"
 - 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp
 - 8288532: additional review changes for JDK-8286830
 - 8288139: JavaThread touches oop after GC barrier is detached
 - 8288497: add support for JavaThread::is_oop_safe()
 - 8288531: Empty spans in mobile navigation markup
 - ... and 2 more: https://git.openjdk.org/jdk/compare/9f8bfab2...cfe52474

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9227&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9227&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9227/files
  Stats: 363 lines in 31 files changed: 197 ins; 103 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/9227.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9227/head:pull/9227

PR: https://git.openjdk.org/jdk/pull/9227

From darcy at openjdk.org  Tue Jun 21 22:12:36 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Jun 2022 22:12:36 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v32]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <39KuRZVYOp0zr0iLVMFF93l02XJQ13nylzcOG25LqCA=.208e1455-1169-40d5-a947-c3bc54e6a7e3@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Improve support and tests for Class objects representing arrays and primitives.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/98f12bb9..9d72436e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=30-31

  Stats: 103 lines in 2 files changed: 102 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.org  Tue Jun 21 22:12:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Jun 2022 22:12:45 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v17]
In-Reply-To: <e-Cn_VlPZaymi0QEGmcBN2pRLOuOTopxpKbuBQ1W4UI=.5c48f7f1-bdb6-4616-827e-d1a05960e5c3@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
 <e-Cn_VlPZaymi0QEGmcBN2pRLOuOTopxpKbuBQ1W4UI=.5c48f7f1-bdb6-4616-827e-d1a05960e5c3@github.com>
Message-ID: <WpkRgg5DVVR5Q5lErErfheI1k45R0mpXrNgd6BKtPxo=.af377e16-448e-49db-bd97-ce6892257e0b@github.com>

On Fri, 29 Apr 2022 18:49:26 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
>> 
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - Make workding changes suggested in review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - Typo fix; add implSpec to Executable.
>>  - Appease jcheck.
>>  - Fix some bugs found by inspection, docs cleanup.
>>  - Merge branch 'master' into JDK-8266670
>>  - Initial support for accessFlags methods
>>  - Add mask to access flag functionality.
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/217d0507...14980605
>
> src/java.base/share/classes/java/lang/Class.java line 1328:
> 
>> 1326:      * @since 19
>> 1327:      */
>> 1328:     public Set<AccessFlag> accessFlags() {
> 
> The access flags of a hidden class has no difference than that of a normal class.  A hidden class is created with normal `ClassFile` except that it's created via `Lookup::defineHiddenClass` API. 
> 
> I think the `Class::accessFlags` method should specify the access flags for primitive type, void, and array classes as `Class::getModifiers` specified.

Expanded the spec of Class.accessFlags() to explicitly cover primitives and arrays. Small implementation update needed; test coverage expanded accordingly. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From jwilhelm at openjdk.org  Tue Jun 21 22:31:21 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 21 Jun 2022 22:31:21 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>
References: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>
Message-ID: <RtaEXqQm-pqlRMf5SwzmWrI4faWuklOfogNFfyYKL1c=.6de8258d-90ed-4d1d-9980-9fad2bf82a93@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 106 additional commits since the last revision:

 - Merge
 - 8288537: Move Devirtualizer out of hotspot/share/memory/iterator.hpp
   
   Reviewed-by: stefank, coleenp
 - 8288599: com/sun/management/OperatingSystemMXBean/TestTotalSwap.java: Expected total swap size ... but getTotalSwapSpaceSize returned ...
   
   Reviewed-by: sspitsyn, kevinw
 - 8288687: (fc) Unix version ofFileChannelImpl.transferTo0() should should return IOS_UNSUPPORTED if not Linux, macOS, nor AIX
   
   Reviewed-by: alanb
 - 8288209: SSL debug message wrong about unsupported authentication scheme
   
   Reviewed-by: djelinski, jnimeh
 - 8288628: Unnecessary Hashtable usage in ConditionalSpecialCasing
   
   Reviewed-by: naoto, jpai
 - 8288556: VM crashes if it gets sent SIGUSR2 from outside
   
   Reviewed-by: dholmes, lucy
 - 8288724: Prevent NullPointerException in serviceability/tmtools/jstack/DaemonThreadTest.java if jstack process fails
   
   Reviewed-by: kevinw, sspitsyn
 - 8288601: Consolidate static/dynamic archive tables
   
   Reviewed-by: ccheung
 - 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
   
   Reviewed-by: dfuchs, aefimov
 - ... and 96 more: https://git.openjdk.org/jdk/compare/af364408...cfe52474

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9227/files
  - new: https://git.openjdk.org/jdk/pull/9227/files/cfe52474..cfe52474

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9227&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9227&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9227.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9227/head:pull/9227

PR: https://git.openjdk.org/jdk/pull/9227

From jwilhelm at openjdk.org  Tue Jun 21 22:31:21 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 21 Jun 2022 22:31:21 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>
References: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>
Message-ID: <yFzJU6fug3J4v60tnn2oT0UC9nhK5diQbd0HFMPfxoM=.60efcd4b-f255-46b9-8bed-ec6534fd7dca@github.com>

On Tue, 21 Jun 2022 21:47:17 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 2bf5c9a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bf5c9a6877b51377a535c6021a9e38549c89029
Stats:     363 lines in 31 files changed: 197 ins; 103 del; 63 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9227

From darcy at openjdk.org  Tue Jun 21 22:30:43 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Jun 2022 22:30:43 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v33]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <_oo66oJSObuUoMgeH0Zifx35QNZ7A0-UpVkPRwecJoA=.3aed9989-1eb0-4aac-8bd7-76627c334f9e@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Remove implSpec tag from Executable.accessFlags since the class is sealed.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/9d72436e..617c9aaf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=31-32

  Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From duke at openjdk.org  Wed Jun 22 03:01:36 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Jun 2022 03:01:36 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  add comparison for direct value of compare

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9068/files
  - new: https://git.openjdk.org/jdk/pull/9068/files/b5627135..0ab881ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9068&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9068&range=01-02

  Stats: 18 lines in 2 files changed: 16 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9068.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9068/head:pull/9068

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Wed Jun 22 03:01:37 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Jun 2022 03:01:37 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <S4ek0_dLqaSUzE5L4pz_bLmffegMhjPw8N3GHIW2eVc=.23cfbd7d-2c88-42fe-ab2a-a314e278cfb0@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <yEpPoRr2VaIYoQ69FtoVXgtI2e2psS2LpdQOuGHgTzI=.0f1efe28-f560-48f1-b327-182c888d14fa@github.com>
 <S4ek0_dLqaSUzE5L4pz_bLmffegMhjPw8N3GHIW2eVc=.23cfbd7d-2c88-42fe-ab2a-a314e278cfb0@github.com>
Message-ID: <46lhnsDuITWou5doLCpqWXKDsJzHVaptYMjXfjxUICk=.041b084c-b2ef-4108-a5ac-8e86ec64e819@github.com>

On Fri, 10 Jun 2022 00:05:53 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I have added a benchmark for the intrinsic. The result is as follows, thanks a lot:
>> 
>>                                                     Before          After
>>     Benchmark                 (size)  Mode  Cnt  Score   Error  Score   Error  Units
>>     Integers.compareUnsigned     500  avgt   15  0.527 ? 0.002  0.498 ? 0.011  us/op
>>     Longs.compareUnsigned        500  avgt   15  0.677 ? 0.014  0.561 ? 0.006  us/op
>
> @merykitty Could you please also add the micro benchmark where compareUnsigned result is stored directly in an integer and show the performance of that?

Thanks @sviswa7 for the suggestion, the results of getting the value of `compareUnsigned` directly is as follow:

                                                           Before          After
    Benchmark                       (size)  Mode  Cnt   Score   Error  Score   Error  Units
    Integers.compareUnsignedDirect     500  avgt   15   0.639 ? 0.022  0.626 ? 0.002  us/op
    Longs.compareUnsignedDirect        500  avgt   15   0.672 ? 0.011  0.609 ? 0.004  us/op

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From joehw at openjdk.org  Wed Jun 22 04:53:46 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 22 Jun 2022 04:53:46 GMT
Subject: Integrated: 8288529: broken link in java.xml
In-Reply-To: <xt5d35nA1mPd-KviOLm6rY3Gj3S8jxGxxkW5cxKUvwQ=.402af81d-64f9-4a87-92fd-20cd952a3835@github.com>
References: <xt5d35nA1mPd-KviOLm6rY3Gj3S8jxGxxkW5cxKUvwQ=.402af81d-64f9-4a87-92fd-20cd952a3835@github.com>
Message-ID: <jjAeDAgl1yN9yOPSmdpsMM-kghYCT-j9htTW6HU0nOo=.b11cdf33-dcf8-4aef-a364-caf582484c1c@github.com>

On Tue, 21 Jun 2022 16:52:52 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Some of the links cause redirection, iso.org in particular took 1-2 seconds, that looks like was longer than the wait time of the doccheck and docs link checker. Changed it to the current homepage to avoid redirection. Also changed other links within this package. 
> 
> I'm limiting the change to this package only as iso.org only appears in it and other redirections have not caused any issue (tests showed they were almost instant).

This pull request has now been integrated.

Changeset: 9e2d9ac5
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/9e2d9ac59a19caa52fc661542d4257a7473636d7
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8288529: broken link in java.xml

Reviewed-by: iris, lancea, naoto

-------------

PR: https://git.openjdk.org/jdk19/pull/55

From jpai at openjdk.org  Wed Jun 22 05:55:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 22 Jun 2022 05:55:51 GMT
Subject: RFR: 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java
 from problemlist
In-Reply-To: <LT1zYZzXCl-dLrl9CSbojrPN95_aSbgAkg5A6tpecME=.f014c351-b7c5-414a-920b-dc3cde9a5db8@github.com>
References: <LT1zYZzXCl-dLrl9CSbojrPN95_aSbgAkg5A6tpecME=.f014c351-b7c5-414a-920b-dc3cde9a5db8@github.com>
Message-ID: <ecDTwfKCABcpyz_WtCRaGQYaph0tFqjfZCPynDsyfrU=.222c2229-a330-41eb-8250-fbead93e72c2@github.com>

On Tue, 21 Jun 2022 06:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to remove the `CompressorPluginTest` from the problemlist?
> 
> This test was problem listed since it had intermittently failed with odd exception in the past (https://bugs.openjdk.org/browse/JDK-8247407). Over the past several months I have attempted multiple runs of this test (with very high test repeats) both locally as well as a CI setup to see if this is still reproducible. So far, I haven't been able to reproduce it. Given the odd exception it was throwing originally, it's hard to say what the issue could have been (and whether it got fixed in recent times), but since it isn't reproducible now, I would like to remove this from the problemlist. If it does fail again, I'll go ahead and collect some additional details to help narrow this down.

Thank you Alan for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/9221

From jpai at openjdk.org  Wed Jun 22 05:55:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 22 Jun 2022 05:55:52 GMT
Subject: Integrated: 8288744: Remove
 tools/jlink/plugins/CompressorPluginTest.java from problemlist
In-Reply-To: <LT1zYZzXCl-dLrl9CSbojrPN95_aSbgAkg5A6tpecME=.f014c351-b7c5-414a-920b-dc3cde9a5db8@github.com>
References: <LT1zYZzXCl-dLrl9CSbojrPN95_aSbgAkg5A6tpecME=.f014c351-b7c5-414a-920b-dc3cde9a5db8@github.com>
Message-ID: <xIiAIKWcUdxJg5jtAO-HUNJvmwDtfYPr_akHY1ggkBo=.d1033df5-49e2-478f-899c-f3219ea8a6ce@github.com>

On Tue, 21 Jun 2022 06:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to remove the `CompressorPluginTest` from the problemlist?
> 
> This test was problem listed since it had intermittently failed with odd exception in the past (https://bugs.openjdk.org/browse/JDK-8247407). Over the past several months I have attempted multiple runs of this test (with very high test repeats) both locally as well as a CI setup to see if this is still reproducible. So far, I haven't been able to reproduce it. Given the odd exception it was throwing originally, it's hard to say what the issue could have been (and whether it got fixed in recent times), but since it isn't reproducible now, I would like to remove this from the problemlist. If it does fail again, I'll go ahead and collect some additional details to help narrow this down.

This pull request has now been integrated.

Changeset: affbd72a
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/affbd72aa3dce80e2ad54ff775c6f7469f38b05b
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9221

From david.holmes at oracle.com  Wed Jun 22 06:44:21 2022
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 Jun 2022 16:44:21 +1000
Subject: DirectBufferAllocTest fails after replacement of Thread.sleep()
 with Thread.onSpinWait()
In-Reply-To: <5553761655811312@iva8-44e4b329128e.qloud-c.yandex.net>
References: <2298281655718230@iva5-64778ce1ba26.qloud-c.yandex.net>
 <fd8fb3a1-4d3a-1a9b-70ff-2704492c0abc@oracle.com>
 <5296351655736573@vla5-8300199a0c8b.qloud-c.yandex.net>
 <e6232617-b4bb-f714-cb5d-4321b8c67773@oracle.com>
 <5553761655811312@iva8-44e4b329128e.qloud-c.yandex.net>
Message-ID: <0db5f219-60cc-c25f-8c98-bf74d4e4d5f3@oracle.com>

On 21/06/2022 9:35 pm, ?????? ??????? wrote:
>> The takeaway from this exercise is that loops with sleeps can't always be replaced by loops that busy-wait.
>> Functionally the logic is the same, but you can't just ignore the concurrency aspects.
> 
> Thanks for explanation!
> 
>> Which indicates yielding is having a similar effect to sleeping - though I would expect it to be less pronounced.
> 
> May I ask one last question about this: in general case when we don't care about particular wait time (like in j.n.Bits.reserveMemory())
> should I prefer Thread.yield() over both Thread.sleep() and Thread.onSpinWait() providing that Thread.sleep() is expensive
> and Thread.onSpinWait() might cause undesirable side effects?

Thread.yield() may also have "undesirable side-effects" as you have no 
idea for how long the thread that yields will be off-cpu.

If you need to slow down the current thread and guarantee some other 
thread has a chance to make progress then Thread.sleep is best.

Busy-waits/yields/onSpinWait should only be used to impose very brief 
pauses on a thread that needs another thread to do something to enable 
forward progress - e.g for spinlocks on multicore systems. Using them 
when flow control is needed can be problematic as you found in this test.

Cheers,
David
-----

> Regards,
> Sergey Tsypanov

From dholmes at openjdk.org  Wed Jun 22 07:03:49 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jun 2022 07:03:49 GMT
Subject: RFR: 8287982: Concurrent implicit attach from native threads
 crashes VM
In-Reply-To: <LXvj93HE9apu07lOjAJZ_M59B5QD6oqcp4fGKVy0Ros=.bb1b8970-a5a8-4997-ae68-4a3b2bc0a1c5@github.com>
References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com>
 <IPcWzrm_4jSQEQ5E_elMU13g1SShbt62OLiFK17mFfc=.506eab72-2e02-42bc-a486-ef5381ea32ea@github.com>
 <LXvj93HE9apu07lOjAJZ_M59B5QD6oqcp4fGKVy0Ros=.bb1b8970-a5a8-4997-ae68-4a3b2bc0a1c5@github.com>
Message-ID: <tGq-7nyAkHrq6NUkEt7M2jf7vDhModGCF5wjHMn0PBg=.5c950a2f-f057-4e4e-87a9-4d60077708c1@github.com>

On Tue, 21 Jun 2022 08:13:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One thing that I'm wondering for the test is whether to move it to test/hotspot/jtreg/runtime/jni/ so it lives with the other tests for JNI. I had expected to find other tests for AttachCurrentThread in that location but we don't.

As this doesn't change hotspot code it seems more appropriate to have the regression test where it is. We have a number of tests that use AttachCurrentThread but very few actual regression tests for it.

Thanks.

-------------

PR: https://git.openjdk.org/jdk19/pull/28

From alanb at openjdk.org  Wed Jun 22 07:51:58 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 07:51:58 GMT
Subject: Integrated: 8287982: Concurrent implicit attach from native threads
 crashes VM
In-Reply-To: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com>
References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com>
Message-ID: <ZcYbNIj6UEoFsk4jtYdAVNSiarxIFC-nbi972Oeqnzk=.6d2f0c3c-5daa-437a-9f72-2fe59ed7cb2f@github.com>

On Thu, 16 Jun 2022 13:34:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread without a thread name, or native threads that attach implicitly by using a function pointer to do an up call.
> 
> The issue that raises its head periodically is that native threads that JNI attach do the initializaiton of the Thread object in the context of the attaching thread. Great care must be taken because Java code is executing in the context of a Thread that is not fully initialized. The right thing is probably to create the Thread object in another thread, using the service thread has been mentioned. The issue at this time arises when two or more native threads attempt to attach without thread names at around the same time. The first thread that needs an automatically generated name triggers the loading and initialization of a helper class.  If there are other threads attaching at the same time then they may have to wait on the monitor which can trigger the crash because the field holder with the thread status is not created at this time. Crashes in monitor enter and notify have been observed. Coleen has changed this code so that linking and initialization uses a mutex (JDK-8288064) so
  this specific crash doesn't duplicate in the main line. The short term fix for openjdk/jdk19 is to reorder the initialization so that field holder with the thread status is created before setting the name.
> 
> Creating a jtreg test with the conditions to duplicate this issue is complicated. The jtreg main wrapper creates the main thread with an automatically generated thread name before it runs the test main method. This is the reason that the test needs to launch a new VM with the right setup to exercise both explicit and implicit attach.

This pull request has now been integrated.

Changeset: 7cf71bc2
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/7cf71bc2d3ae3d84552f06358e70204dc65552fc
Stats:     402 lines in 7 files changed: 364 ins; 21 del; 17 mod

8287982: Concurrent implicit attach from native threads crashes VM

Reviewed-by: dholmes, rehn

-------------

PR: https://git.openjdk.org/jdk19/pull/28

From alanb at openjdk.org  Wed Jun 22 07:53:58 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 07:53:58 GMT
Subject: Integrated: 8288840: StructureViolationException should not link to
 fork method
In-Reply-To: <atSuZvKQ0wW_08vhqloaulDw66snAT0x_Otgl4uSnNM=.10091375-db9e-41bb-83d8-380959ce48f7@github.com>
References: <atSuZvKQ0wW_08vhqloaulDw66snAT0x_Otgl4uSnNM=.10091375-db9e-41bb-83d8-380959ce48f7@github.com>
Message-ID: <Y1OAN6YyBYJp1YML2z49LKRtBgDgSvZCUEHfWeSFF-Y=.0917d23a-774b-40ca-815f-2e38f9c89e80@github.com>

On Tue, 21 Jun 2022 11:20:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructureViolationException has a `@see` link to a fork method that does not throw this exception. The link should be removed for JDK 19. We'll add the link back once the JEP for Extent-Local Variables is integrated.

This pull request has now been integrated.

Changeset: 8fa46c8f
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/8fa46c8f72201637e377190d94247e8d96646425
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8288840: StructureViolationException should not link to fork method

Reviewed-by: psandoz, mchung

-------------

PR: https://git.openjdk.org/jdk19/pull/52

From mik3hall at gmail.com  Wed Jun 22 10:40:04 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 22 Jun 2022 05:40:04 -0500
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
 <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
Message-ID: <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>



> On Jun 8, 2022, at 1:47 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jun 7, 2022, at 9:21 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
>> 
>> Hi Michael,
>> 
>> Yes, this is correct. It is a three step process as you outlined it below.
>> 
> 
> Alexander,
> 
> Could you post an example of the three invocations, without needing to include any post-processing, to 1) create app-image 2) sign 3) add to DMG
> Or indicate any tests included, or that will be included, in the jdk source where something similar is done. 
> There are not yet that I know of any documentation pages for the command? 
> 
> Thanks,
> Mike
> 

Assuming the current JDK19 ea includes this change and dependencies. Possibly this is still incorrect.

Running this to create an unsigned app-image.

${PACKAGER} \
	--verbose \
    --add-modules java.desktop,java.prefs,java.se \
    --type app-image \
	--input ./input \
	--app-version 1.0  \
	--name BlackJack\ Blastoff_Unsigned \
	--main-jar bjb.jar \
	--main-class org.bjb.BlackJackApp \
	--java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50  -Dapple.laf.useScreenMenuBar=true -Dcom.apple.mrj.application.apple.menu.about.name=BlackjackBlastoff -Dapple.awt.application.name=Blackjack\ Blastoff' 
#	--mac-signing-key-user-name "Michael Hall" \
#	--mac-sign 

Gets this for output?
[05:20:06.459] Creating app package: BlackJack Blastoff_Unsigned.app in /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg
[05:20:10.033] Command [PID: -1]:
    jlink --output /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack Blastoff_Unsigned.app/Contents/runtime/Contents/Home --module-path /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/jmods --add-modules java.desktop,java.prefs,java.se --strip-native-commands --strip-debug --no-man-pages --no-header-files
[05:20:10.034] Output:
    
[05:20:10.035] Returned: 0

[05:20:10.073] Using default package resource JavaApp.icns [icon] (add BlackJack Blastoff_Unsigned.icns to the resource-dir to customize).
[05:20:10.075] Preparing Info.plist: /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack Blastoff_Unsigned.app/Contents/Info.plist.
[05:20:10.077] Using default package resource Info-lite.plist.template [Application Info.plist] (add Info.plist to the resource-dir to customize).
[05:20:10.080] Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize).
[05:20:10.085] Running /usr/bin/codesign
[05:20:10.122] Running /usr/bin/codesign
[05:20:10.144] Running /usr/bin/codesign
...
[05:20:10.785] Running /usr/bin/codesign
[05:20:10.807] Running /usr/bin/codesign
[05:20:10.839] Running /usr/bin/codesign
[05:20:10.862] Succeeded in building Mac Application Image package

Signing should of been turned off? Is codesign being used in error or does it still have to use that for some reason on the embedded jdk? What is it using for the signing cert?

codesign -v --verbose=4 BlackJack\ Blastoff_Unsigned.app 
BlackJack Blastoff_Unsigned.app: code has no resources but signature indicates they must be present 

I think I reported this before. The intention was to have jpackage create an unsigned app-image and sign after post-processing but it seems to think some incorrect signature is there immediately.
Was this not the intent of this change?



From alanb at openjdk.org  Wed Jun 22 10:53:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 10:53:59 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v5]
In-Reply-To: <2mC9Q1w0EbczZgPu_VvD10SsAFmSsAwayIr0-P1GHds=.d91c80b9-9165-4d5e-837a-9b6c3c9b735d@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <2mC9Q1w0EbczZgPu_VvD10SsAFmSsAwayIr0-P1GHds=.d91c80b9-9165-4d5e-837a-9b6c3c9b735d@github.com>
Message-ID: <QefKUWfyt2UK41uzcu4lFdI_jIyLA_0K0nxUC2-XYzQ=.11f3bb18-5b5a-47e2-a98d-d63f565c43e2@github.com>

On Tue, 21 Jun 2022 21:49:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
>> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved `@Test` annotations

Marked as reviewed by alanb (Reviewer).

test/jdk/java/nio/file/Files/ReadWriteString.java line 304:

> 302:             throws IOException {
> 303:         Path path = Files.createTempFile("illegalInputBytes", null);
> 304:         path.toFile().deleteOnExit();

Although this is consistent with the existing tests in this source file, I think it would be better if we change it to create the temporary files in the current directory and not delete it. Leaving the file behind is useful for diagnosing issues where there re test failures. We can do that in a separate issue if you'd like.

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From alanb at openjdk.org  Wed Jun 22 10:54:01 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 10:54:01 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v2]
In-Reply-To: <PhdzDy6d6-ZOh3YYe8lk63U2xeEHtlkCaBLtqGMw-wA=.665356f1-1d47-4114-950d-1238327dfc0e@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <_g36T1LwpXJmJ91PiJ4WQMjhk08mMMjPNzh5hdhV418=.08bb181d-60a8-4e86-a9e9-59203b2eabf1@github.com>
 <4IEfG_ycHWHNgMpWF-CYbgkuL4VuP1F8F_f7D1uddgY=.bd3e663d-5041-470b-b55a-6c3b2b073323@github.com>
 <PhdzDy6d6-ZOh3YYe8lk63U2xeEHtlkCaBLtqGMw-wA=.665356f1-1d47-4114-950d-1238327dfc0e@github.com>
Message-ID: <vVrKXZUjOi9TGLQSDgl2gmWrRMgaAMfL6xxouigs6dw=.13e21de6-48ac-4174-b382-985bcbe5fae4@github.com>

On Tue, 21 Jun 2022 18:23:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > One other thing, this is a regression in 19 so I assume the PR should be against openjdk/jdk19 rather than the main line.
> 
> Since this PR already got a few approvals, I will backport the changeset to the jdk19 line after this PR gets integrated.

Okay, although doing it this way means there will need to be a PR for openjdk/jdk19 too.

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From akasko at openjdk.org  Wed Jun 22 12:00:18 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 22 Jun 2022 12:00:18 GMT
Subject: RFR: 8288961: jpackage: test MSI installation fix
Message-ID: <rjbj93A-x52yIC4nqt_tdewEovug8Sooy1WwkD2xEFU=.d9d00563-f587-4c94-bc34-2f4a06fb3ff4@github.com>

Please review this minor fix to the jpackage test suite.

When `INSTALL` and `UNINSTALL` actions are enabled for jpackage test suite runs (disabled by default), installation of `EXE` and `MSI` packages is performed. `EXE` package is invoked directly and `MSI` package is installed using `msiexec` utility. In both cases the path of the packages starts with a "." (current dir) symbol, it is processed correctly with EXE installation, but not with MSI, example:


[03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
[03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
[03:52:19.634] TRACE: exec: Execute [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
[03:52:19.790] TRACE: exec: Done. Exit code: 1619
[03:52:19.805] ERROR: Expected [0]. Actual [1619]: Check command [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code 


Is is proposed to normalize the path passed to `msiexec`, in this case installation will succeed:


[03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
[03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
[03:56:52.429] TRACE: exec: Execute [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
[03:56:57.067] TRACE: exec: Done. Exit code: 0
[03:56:57.067] TRACE: assertEquals(0): Check command [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code

-------------

Commit messages:
 - 8288961: jpackage: test MSI installation fix

Changes: https://git.openjdk.org/jdk/pull/9236/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9236&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288961
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9236.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9236/head:pull/9236

PR: https://git.openjdk.org/jdk/pull/9236

From duke at openjdk.org  Wed Jun 22 12:51:21 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Jun 2022 12:51:21 GMT
Subject: RFR: 8288933: Improve the implementation of Double/Float.isInfinite
Message-ID: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>

Improve the implementation of `Double/Float.isInfinite` to reduce branching. Using `>` comparison with `MAX_VALUE` instead of `==` with `POSITIVE_INFINITY` improves code emission on x86 and produces similar code for arm. This is also the way gcc implements `std::isinf` on x86 and arm (clang uses the pattern `Math.abs(v) == POSITIVE_INFINITY` on arm).

`test/micro/org/openjdk/bench/java/lang/FPComparison.java` has been added in #8525, the results are reshown here:

    Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
    FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
    FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98

Thank you very much.

-------------

Commit messages:
 - commit

Changes: https://git.openjdk.org/jdk/pull/9238/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9238&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288933
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9238.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9238/head:pull/9238

PR: https://git.openjdk.org/jdk/pull/9238

From djelinski at openjdk.org  Wed Jun 22 14:41:07 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 22 Jun 2022 14:41:07 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time
Message-ID: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>

This PR improves the performance of deduplication done by ResourceBundleGenerator.

The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.

The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
The files generated before and after this change have the same size.

-------------

Commit messages:
 - Speed up CLDR deduplication

Changes: https://git.openjdk.org/jdk/pull/9243/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288979
  Stats: 101 lines in 1 file changed: 56 ins; 27 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9243.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9243/head:pull/9243

PR: https://git.openjdk.org/jdk/pull/9243

From duke at openjdk.org  Wed Jun 22 15:50:02 2022
From: duke at openjdk.org (iaroslavski)
Date: Wed, 22 Jun 2022 15:50:02 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <kgzRYUhCYiSoi9JrkBYnRPLa_7yVWYhR8_41TljZ9TA=.ce7c45ad-66b1-4a20-9f6d-767974848e80@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.org> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

Improvement of parallel sorting is under progress

-------------

PR: https://git.openjdk.org/jdk/pull/3938

From naoto at openjdk.org  Wed Jun 22 15:50:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 15:50:54 GMT
Subject: Integrated: 8287868: Localized names update in COMPAT locale provider
In-Reply-To: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
References: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
Message-ID: <kKnNw9qsPBoOZn3UhNLU6cWyv1mfDiGiixbgMntwjgE=.8a240bb3-a098-47c9-a32b-ebd16c958cbb@github.com>

On Fri, 10 Jun 2022 20:58:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.

This pull request has now been integrated.

Changeset: d4de4757
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4de4757471d9f21c2a059f91504ecbc4781566e
Stats:     11617 lines in 65 files changed: 17 ins; 2367 del; 9233 mod

8287868: Localized names update in COMPAT locale provider

Reviewed-by: iris, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/9134

From rriggs at openjdk.org  Wed Jun 22 16:22:15 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 Jun 2022 16:22:15 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>

On Wed, 22 Jun 2022 14:24:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 146:

> 144:             // generic reduction of duplicated values
> 145:             Map<String, Object> newMap = new HashMap<>(map);
> 146:             Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());

LinkedHashMap could be used to retain the iteration order.
Or TreeMap if some deterministic order was desirable.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 157:

> 155:                             fmt = new Formatter();
> 156:                         }
> 157:                         String metaVal = oldEntry.metaKey();

The new instanceof pattern matching could be used avoid the cast below.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 270:

> 268:                 if (value instanceof String s) {
> 269:                     return s.equals(entry.value);
> 270:                 } else if (!(entry.value instanceof String[])) {

Could be re-written to use instanceof pattern and save a cast.

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From djelinski at openjdk.org  Wed Jun 22 17:10:55 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 22 Jun 2022 17:10:55 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time
In-Reply-To: <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
Message-ID: <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>

On Wed, 22 Jun 2022 16:11:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 146:
> 
>> 144:             // generic reduction of duplicated values
>> 145:             Map<String, Object> newMap = new HashMap<>(map);
>> 146:             Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());
> 
> LinkedHashMap could be used to retain the iteration order.
> Or TreeMap if some deterministic order was desirable.

True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From djelinski at openjdk.org  Wed Jun 22 17:30:48 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 22 Jun 2022 17:30:48 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <GNbRMZG2qKz5mTOajQDN5D2irerbicTPIuDUch-sh0Y=.f2543f76-a773-4219-8268-e43b2c0452a8@github.com>

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Use instanceof pattern matching

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9243/files
  - new: https://git.openjdk.org/jdk/pull/9243/files/c3743d18..6cb47724

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9243.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9243/head:pull/9243

PR: https://git.openjdk.org/jdk/pull/9243

From rriggs at openjdk.org  Wed Jun 22 17:30:51 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 Jun 2022 17:30:51 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
Message-ID: <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>

On Wed, 22 Jun 2022 17:07:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 146:
>> 
>>> 144:             // generic reduction of duplicated values
>>> 145:             Map<String, Object> newMap = new HashMap<>(map);
>>> 146:             Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());
>> 
>> LinkedHashMap could be used to retain the iteration order.
>> Or TreeMap if some deterministic order was desirable.
>
> True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.

A stable order is useful when comparing between builds (by a human). 
It also supports the goal of reproducible builds.
@naotoj  What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From naoto at openjdk.org  Wed Jun 22 17:46:58 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 17:46:58 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v6]
In-Reply-To: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
Message-ID: <kGgfmE6iN-AOIaYe1WNl6wLU7Ah8urVwxN_M-qBYHaw=.d6b57508-36fe-462b-b3f3-b9daa2f43d8b@github.com>

> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.

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 seven additional commits since the last revision:

 - Leave the log files in the current directory
 - Merge branch 'master' into JDK-8288589
 - Moved `@Test` annotations
 - Refined the test, adding more variations.
 - Adding a test case in ReadWriteString.java
 - Added c2b test
 - 8288589: Files.readString ignores encoding errors for UTF-16

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9193/files
  - new: https://git.openjdk.org/jdk/pull/9193/files/864806ef..09cdf5e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9193&range=04-05

  Stats: 4620 lines in 234 files changed: 2654 ins; 1073 del; 893 mod
  Patch: https://git.openjdk.org/jdk/pull/9193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9193/head:pull/9193

PR: https://git.openjdk.org/jdk/pull/9193

From naoto at openjdk.org  Wed Jun 22 17:46:59 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 17:46:59 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v2]
In-Reply-To: <vVrKXZUjOi9TGLQSDgl2gmWrRMgaAMfL6xxouigs6dw=.13e21de6-48ac-4174-b382-985bcbe5fae4@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <_g36T1LwpXJmJ91PiJ4WQMjhk08mMMjPNzh5hdhV418=.08bb181d-60a8-4e86-a9e9-59203b2eabf1@github.com>
 <4IEfG_ycHWHNgMpWF-CYbgkuL4VuP1F8F_f7D1uddgY=.bd3e663d-5041-470b-b55a-6c3b2b073323@github.com>
 <PhdzDy6d6-ZOh3YYe8lk63U2xeEHtlkCaBLtqGMw-wA=.665356f1-1d47-4114-950d-1238327dfc0e@github.com>
 <vVrKXZUjOi9TGLQSDgl2gmWrRMgaAMfL6xxouigs6dw=.13e21de6-48ac-4174-b382-985bcbe5fae4@github.com>
Message-ID: <OWtycWNTeKRhlnN-h9V88tX8ZvgTG-8w-KlOm2IFUco=.1707ad41-8816-495e-87e9-5f85cd29e62c@github.com>

On Wed, 22 Jun 2022 10:50:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > One other thing, this is a regression in 19 so I assume the PR should be against openjdk/jdk19 rather than the main line.
> > 
> > 
> > Since this PR already got a few approvals, I will backport the changeset to the jdk19 line after this PR gets integrated.
> 
> Okay, although doing it this way means there will need to be a PR for openjdk/jdk19 too.

Yes. It's much easier to backport it than to create a jdk19 PR from scratch, as `/backport` skara command does the job for me ?

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From naoto at openjdk.org  Wed Jun 22 17:47:03 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 17:47:03 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v5]
In-Reply-To: <QefKUWfyt2UK41uzcu4lFdI_jIyLA_0K0nxUC2-XYzQ=.11f3bb18-5b5a-47e2-a98d-d63f565c43e2@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <2mC9Q1w0EbczZgPu_VvD10SsAFmSsAwayIr0-P1GHds=.d91c80b9-9165-4d5e-837a-9b6c3c9b735d@github.com>
 <QefKUWfyt2UK41uzcu4lFdI_jIyLA_0K0nxUC2-XYzQ=.11f3bb18-5b5a-47e2-a98d-d63f565c43e2@github.com>
Message-ID: <AkqhzksFZp-2OoHNUIvXXvCCi-z2oO2ZFCH1h61XRkc=.2f6bdd7f-859d-428d-9a2a-8b9f954afce5@github.com>

On Wed, 22 Jun 2022 10:48:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved `@Test` annotations
>
> test/jdk/java/nio/file/Files/ReadWriteString.java line 304:
> 
>> 302:             throws IOException {
>> 303:         Path path = Files.createTempFile("illegalInputBytes", null);
>> 304:         path.toFile().deleteOnExit();
> 
> Although this is consistent with the existing tests in this source file, I think it would be better if we change it to create the temporary files in the current directory and not delete it. Leaving the file behind is useful for diagnosing issues where there re test failures. We can do that in a separate issue if you'd like.

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From naoto at openjdk.org  Wed Jun 22 18:02:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 18:02:07 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
Message-ID: <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>

On Wed, 22 Jun 2022 17:27:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.
>
> A stable order is useful when comparing between builds (by a human). 
> It also supports the goal of reproducible builds.
> @naotoj  What do you think?

IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From mchung at openjdk.org  Wed Jun 22 18:25:07 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 22 Jun 2022 18:25:07 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v33]
In-Reply-To: <_oo66oJSObuUoMgeH0Zifx35QNZ7A0-UpVkPRwecJoA=.3aed9989-1eb0-4aac-8bd7-76627c334f9e@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <_oo66oJSObuUoMgeH0Zifx35QNZ7A0-UpVkPRwecJoA=.3aed9989-1eb0-4aac-8bd7-76627c334f9e@github.com>
Message-ID: <lsE7Docwpe9FdmD1czn_oZZ-bfNmKplGD-Wu8J1Neq4=.0d858efc-2ec9-444e-a771-0ade4a048e85@github.com>

On Tue, 21 Jun 2022 22:30:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove implSpec tag from Executable.accessFlags since the class is sealed.

This version looks good.   It'd be good to extend the tests to include test cases for `Location.INNER_CLASS`.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 290:

> 288:     // Intentionally using Set rather than EnumSet since EnumSet is
> 289:     // mutable.
> 290:     private Set<Location> locations;

these instance fields can be made final.

test/jdk/java/lang/reflect/AccessFlag/BasicAccessFlagTest.java line 47:

> 45:     }
> 46: 
> 47:     private static void testSourceModifiers() throws Exception {

A comment about what this verifies would be helpful, like "for AccessFlag that is a source modifier, a Modifier constant is defined."

test/jdk/java/lang/reflect/AccessFlag/ClassAccessFlagTest.java line 27:

> 25:  * @test
> 26:  * @bug 8266670
> 27:  * @summary Test expected AccessFlag's on fields.

typo?  s/fields/classes/

test/jdk/java/lang/reflect/AccessFlag/ClassAccessFlagTest.java line 159:

> 157:     }
> 158: 
> 159:     // Is there is at least one special enum constant, the enum class

typo s/Is/If

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/7445

From rriggs at openjdk.org  Wed Jun 22 18:31:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 Jun 2022 18:31:40 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative
Message-ID: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>

The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.

Exception messages should not include newlines.

-------------

Commit messages:
 - 8288495: [test] Make OutputAnalyzer exception more informative

Changes: https://git.openjdk.org/jdk/pull/9247/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288495
  Stats: 46 lines in 2 files changed: 27 ins; 1 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9247.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9247/head:pull/9247

PR: https://git.openjdk.org/jdk/pull/9247

From lancea at openjdk.org  Wed Jun 22 19:12:16 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 22 Jun 2022 19:12:16 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
Message-ID: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>

Hi,

Please review the following patch which will:

- Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods

  - public boolean exists(Path path, LinkOption... options)
  - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)


This change allows for providers to provide optimizations when the file's attributes are not needed.

Mach5 tiers 1 - 3  run clean with this change

The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)


Best,
Lance

-------------

Commit messages:
 - Add exists and readAttributesIfExists methods to FileSystemProvider

Changes: https://git.openjdk.org/jdk/pull/9249/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283335
  Stats: 342 lines in 10 files changed: 177 ins; 129 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/9249.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249

PR: https://git.openjdk.org/jdk/pull/9249

From bpb at openjdk.org  Wed Jun 22 19:26:44 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 19:26:44 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <IPv0YFxeV14-LaD8Q4d8Dm8jM7Vix9KwBC58OX-GKIo=.2b614d9f-042f-4a04-b4a1-0524adc24acb@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1184:

> 1182:      * is present then symbolic links are not followed and the method
> 1183:      *  {@link #readAttributes(Path, Class, LinkOption...)} is called
> 1184:      *  to determine whether a file exists.

Indentation is off at lines 1183-1184.

src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1218:

> 1216: 
> 1217:     /**
> 1218:      * Reads a file's attributes as a bulk operation if it exists.

Maybe instead "it" put "the file"?

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From lancea at openjdk.org  Wed Jun 22 19:58:53 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 22 Jun 2022 19:58:53 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <IPv0YFxeV14-LaD8Q4d8Dm8jM7Vix9KwBC58OX-GKIo=.2b614d9f-042f-4a04-b4a1-0524adc24acb@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <IPv0YFxeV14-LaD8Q4d8Dm8jM7Vix9KwBC58OX-GKIo=.2b614d9f-042f-4a04-b4a1-0524adc24acb@github.com>
Message-ID: <ei9bYlBnShTRSHKymfi6vP1ktLmdmPAzuMOmIUTCBJE=.5036ae8e-d029-429f-84b6-356dbde3103d@github.com>

On Wed, 22 Jun 2022 19:22:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1184:
> 
>> 1182:      * is present then symbolic links are not followed and the method
>> 1183:      *  {@link #readAttributes(Path, Class, LinkOption...)} is called
>> 1184:      *  to determine whether a file exists.
> 
> Indentation is off at lines 1183-1184.

Thanks for catching that.  Will be addressed in the next push

> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1218:
> 
>> 1216: 
>> 1217:     /**
>> 1218:      * Reads a file's attributes as a bulk operation if it exists.
> 
> Maybe instead "it" put "the file"?

I can if you think that is better.  I followed the wording for `FileSystemProvider::deleteIfExists` trying to be consistent

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From bpb at openjdk.org  Wed Jun 22 20:02:55 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 20:02:55 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <ei9bYlBnShTRSHKymfi6vP1ktLmdmPAzuMOmIUTCBJE=.5036ae8e-d029-429f-84b6-356dbde3103d@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <IPv0YFxeV14-LaD8Q4d8Dm8jM7Vix9KwBC58OX-GKIo=.2b614d9f-042f-4a04-b4a1-0524adc24acb@github.com>
 <ei9bYlBnShTRSHKymfi6vP1ktLmdmPAzuMOmIUTCBJE=.5036ae8e-d029-429f-84b6-356dbde3103d@github.com>
Message-ID: <chEKN30cx3l8CKB4OvSIq5TUkKpEBlB-RrqgYh_75x8=.b564b407-93de-4c0e-b117-ab740e596d37@github.com>

On Wed, 22 Jun 2022 19:54:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1218:
>> 
>>> 1216: 
>>> 1217:     /**
>>> 1218:      * Reads a file's attributes as a bulk operation if it exists.
>> 
>> Maybe instead "it" put "the file"?
>
> I can if you think that is better.  I followed the wording for `FileSystemProvider::deleteIfExists` trying to be consistent

Then leave is as is.

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From joehw at openjdk.org  Wed Jun 22 20:10:16 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 22 Jun 2022 20:10:16 GMT
Subject: RFR: 8287076: Document.normalizeDocument() produces different results
Message-ID: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>

Fix a regression in Document.normalizeDocument() caused by a change in JDK 10.

Test: new test (as in the bug report) and Tier2 passed.

-------------

Commit messages:
 - 8287076: Document.normalizeDocument() produces different results

Changes: https://git.openjdk.org/jdk19/pull/59/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=59&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287076
  Stats: 62 lines in 2 files changed: 52 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk19/pull/59.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/59/head:pull/59

PR: https://git.openjdk.org/jdk19/pull/59

From mik3hall at gmail.com  Wed Jun 22 20:33:36 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 22 Jun 2022 15:33:36 -0500
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
 <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
 <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>
Message-ID: <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com>

> 
> Assuming the current JDK19 ea includes this change and dependencies. Possibly this is still incorrect.
> 
> 
> 
> codesign -v --verbose=4 BlackJack\ Blastoff_Unsigned.app 
> BlackJack Blastoff_Unsigned.app: code has no resources but signature indicates they must be present 
> 
> I think I reported this before. The intention was to have jpackage create an unsigned app-image and sign after post-processing but it seems to think some incorrect signature is there immediately.
> Was this not the intent of this change?
> 
> 

Alexander 

Sorry completing the process shows that this works as expected. First creating the app-image using jpackage without signing as previously shown.

Then signing the application as per a prior post of yours?

jpackage --type app-image --app-image BlackJack\ Blastoff_Unsigned.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)?

Codesign verifies correctly. Then adding to a dmg.

jpackage --type dmg --app-image BlackJack\ Blastoff_Unsigned.app

Completed the dmg creation successfully.

The verify error message on the signature of what?s supposed to be an unsigned app shouldn?t really matter in any way I can think of.

I should of completely checked before asking. 

Thanks again.

Mike




From mik3hall at gmail.com  Wed Jun 22 20:51:32 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 22 Jun 2022 15:51:32 -0500
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
 <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
 <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>
 <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com>
Message-ID: <C7AC3825-A29B-4C81-91D6-26E810FEE2EA@gmail.com>

Alexander,

Sorry yet again. I really should have totally completed. While the application verified on disk immediately after signing. The dmg version does not appear to verify. 

codesign -v --verbose=4 /Applications/BlackJack\ Blastoff_Unsigned.app 
/Applications/BlackJack Blastoff_Unsigned.app: a sealed resource is missing or invalid
file added: /Applications/BlackJack Blastoff_Unsigned.app/Contents/app/.package
file modified: /Applications/BlackJack Blastoff_Unsigned.app/Contents/runtime/Contents/Home/legal/java.management.rmi/LICENSE
?
A lot of those
?
file missing: /Applications/BlackJack Blastoff_Unsigned.app/Contents/app/.jpackage.xml

Same result checking while still in the mounted dmg or copied into /Applications

Should this be working?

java --version
openjdk 19-ea 2022-09-20
OpenJDK Runtime Environment (build 19-ea+27-2074)
OpenJDK 64-Bit Server VM (build 19-ea+27-2074, mixed mode, sharing)

Or should I bug report?

Mike

(Fwiw I remember this same signing issue from an earlier release - I could probably track down the bug report.)




From aturbanov at openjdk.org  Wed Jun 22 21:29:50 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 Jun 2022 21:29:50 GMT
Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in
 java.time [v2]
In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
Message-ID: <YvqHz0tTpqqN-X0evw3C0GdubG6m435J_gvFpVkCZvM=.11697c65-a20e-428d-bc8e-e56d01848b52@github.com>

> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8288723: Avoid redundant ConcurrentHashMap.get call in java.time
  use computeIfAbsent where lambda could be short and static

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9208/files
  - new: https://git.openjdk.org/jdk/pull/9208/files/73a2f6cb..aa67cdf6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=00-01

  Stats: 18 lines in 2 files changed: 0 ins; 16 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9208.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9208/head:pull/9208

PR: https://git.openjdk.org/jdk/pull/9208

From jwilhelm at openjdk.org  Wed Jun 22 21:32:40 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 22 Jun 2022 21:32:40 GMT
Subject: RFR: Merge jdk19
Message-ID: <3-PLWroZbcfL-LaQ2_R6PTYsuJi7TzLIx15dVCOdNU8=.76b664a2-58e8-4356-bdae-e39242872744@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode
 - 8288846: misc tests fail "assert(ms < 1000) failed: Un-interruptable sleep, short time use only"
 - 8288840: StructureViolationException should not link to fork method
 - 8287982: Concurrent implicit attach from native threads crashes VM
 - 8288529: broken link in java.xml

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9251&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9251&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9251/files
  Stats: 434 lines in 12 files changed: 379 ins; 22 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/9251.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9251/head:pull/9251

PR: https://git.openjdk.org/jdk/pull/9251

From joehw at openjdk.org  Wed Jun 22 21:48:35 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 22 Jun 2022 21:48:35 GMT
Subject: RFR: 8287076: Document.normalizeDocument() produces different
 results [v2]
In-Reply-To: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>
References: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>
Message-ID: <f_5Qa6DvVRTJxKh-kAxeB1nzncx5q__ZT8Npx_j_WhM=.ec714d74-88e2-4c1d-9a53-41ecaff2835a@github.com>

> Fix a regression in Document.normalizeDocument() caused by a change in JDK 10.
> 
> Test: new test (as in the bug report) and Tier2 passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Remove initialization size, use default instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/59/files
  - new: https://git.openjdk.org/jdk19/pull/59/files/d9e6a47a..d6cc5d8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=59&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=59&range=00-01

  Stats: 11 lines in 3 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk19/pull/59.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/59/head:pull/59

PR: https://git.openjdk.org/jdk19/pull/59

From joehw at openjdk.org  Wed Jun 22 21:51:47 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 22 Jun 2022 21:51:47 GMT
Subject: RFR: 8287076: Document.normalizeDocument() produces different
 results
In-Reply-To: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>
References: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>
Message-ID: <FwqOGzLV2fUf-AtjkWifRb8L5Y0TvYn5rlk8jayOFZg=.6dcc466a-fb48-42bc-aef9-f51b748d74ff@github.com>

On Wed, 22 Jun 2022 20:01:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a regression in Document.normalizeDocument() caused by a change in JDK 10.
> 
> Test: new test (as in the bug report) and Tier2 passed.

Thanks Lance. Updated the patch, also changed the corresponding nodes.

-------------

PR: https://git.openjdk.org/jdk19/pull/59

From naoto at openjdk.org  Wed Jun 22 21:51:42 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 21:51:42 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <GNbRMZG2qKz5mTOajQDN5D2irerbicTPIuDUch-sh0Y=.f2543f76-a773-4219-8268-e43b2c0452a8@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <GNbRMZG2qKz5mTOajQDN5D2irerbicTPIuDUch-sh0Y=.f2543f76-a773-4219-8268-e43b2c0452a8@github.com>
Message-ID: <3wfGl3xjVGdG52MQJnW48OogCIctlTpQkySX_oKx95c=.8ddb037c-a37b-4284-9e0d-dea038b2fc10@github.com>

On Wed, 22 Jun 2022 17:30:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use instanceof pattern matching

Thanks for the refactoring Daniel. Removing the leftover `List` was a bonus.

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From naoto at openjdk.org  Wed Jun 22 21:51:42 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 21:51:42 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
 <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
Message-ID: <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>

On Wed, 22 Jun 2022 17:57:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A stable order is useful when comparing between builds (by a human). 
>> It also supports the goal of reproducible builds.
>> @naotoj  What do you think?
>
> IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?

BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From bpb at openjdk.org  Wed Jun 22 22:21:42 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 22:21:42 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <Dho3DWC5sQTgYpk2EhWDIMz6cm19GdQS5Z3gjiLR05E=.578cdb7b-9e2b-4d2d-8773-5ebf63d3372e@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 80:

> 78:     static UnixFileAttributes getIfExists(UnixPath path) throws UnixException {
> 79:         UnixFileAttributes attrs = new UnixFileAttributes();
> 80:         int errno = UnixNativeDispatcher.stat2(path, attrs);

I think that this is the only use of `stat2()`. It could be deleted if this method were replaced with this:


    static UnixFileAttributes getIfExists(UnixPath path) throws UnixException {
        UnixFileAttributes attrs = new UnixFileAttributes();
        try {
            UnixNativeDispatcher.stat(path, attrs);
            return attrs;
        } catch (UnixException e) {
            if (e.errno() == UnixConstants.ENOENT) {
                return null;
            }
            throw e;
        }
    }

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From bpb at openjdk.org  Wed Jun 22 22:29:38 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 22:29:38 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <I-ppIZSAK4brd84-OgItZPnleOjCRlcl2SgHMOmDc9I=.ecc9fea8-35e9-40b0-99da-0d93a3e9e01d@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1236:

> 1234:      * atomic operation with respect to other file system operations.
> 1235:      *
> 1236:      *  @implSpec

One more bad indentation.

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From lancea at openjdk.org  Wed Jun 22 23:04:42 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 22 Jun 2022 23:04:42 GMT
Subject: RFR: 8287076: Document.normalizeDocument() produces different
 results [v2]
In-Reply-To: <f_5Qa6DvVRTJxKh-kAxeB1nzncx5q__ZT8Npx_j_WhM=.ec714d74-88e2-4c1d-9a53-41ecaff2835a@github.com>
References: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>
 <f_5Qa6DvVRTJxKh-kAxeB1nzncx5q__ZT8Npx_j_WhM=.ec714d74-88e2-4c1d-9a53-41ecaff2835a@github.com>
Message-ID: <4YHj_rqszZtehANUF951PrWiLhcJNwRrQ_LhfFE5YZs=.dca0b019-32d2-4c05-b6f0-5e64904193bc@github.com>

On Wed, 22 Jun 2022 21:48:35 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix a regression in Document.normalizeDocument() caused by a change in JDK 10.
>> 
>> Test: new test (as in the bug report) and Tier2 passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove initialization size, use default instead

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/59

From jwilhelm at openjdk.org  Wed Jun 22 23:25:41 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 22 Jun 2022 23:25:41 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <3-PLWroZbcfL-LaQ2_R6PTYsuJi7TzLIx15dVCOdNU8=.76b664a2-58e8-4356-bdae-e39242872744@github.com>
References: <3-PLWroZbcfL-LaQ2_R6PTYsuJi7TzLIx15dVCOdNU8=.76b664a2-58e8-4356-bdae-e39242872744@github.com>
Message-ID: <Y-N-9WAVC9A6tS4Kgxx4DHaaecrZEeC2mTF0J29hW54=.cd126033-4a8d-4c41-8f3f-a5953dc51a92@github.com>

On Wed, 22 Jun 2022 21:25:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 5b583e47
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b583e4792b1d59891495a4a050fcdd4d38dfee1
Stats:     434 lines in 12 files changed: 379 ins; 22 del; 33 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9251

From iris at openjdk.org  Wed Jun 22 23:39:52 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 22 Jun 2022 23:39:52 GMT
Subject: RFR: 8287076: Document.normalizeDocument() produces different
 results [v2]
In-Reply-To: <f_5Qa6DvVRTJxKh-kAxeB1nzncx5q__ZT8Npx_j_WhM=.ec714d74-88e2-4c1d-9a53-41ecaff2835a@github.com>
References: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>
 <f_5Qa6DvVRTJxKh-kAxeB1nzncx5q__ZT8Npx_j_WhM=.ec714d74-88e2-4c1d-9a53-41ecaff2835a@github.com>
Message-ID: <arwsTRblYqo8twuTmaSk13zdkpHlvqLOZ0H04nXd6MM=.c8493dc0-ebe8-4c02-bc20-bd00c0bd1379@github.com>

On Wed, 22 Jun 2022 21:48:35 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix a regression in Document.normalizeDocument() caused by a change in JDK 10.
>> 
>> Test: new test (as in the bug report) and Tier2 passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove initialization size, use default instead

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/59

From alexander.matveev at oracle.com  Wed Jun 22 23:57:45 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 22 Jun 2022 23:57:45 +0000
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <C7AC3825-A29B-4C81-91D6-26E810FEE2EA@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
 <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
 <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>
 <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com>
 <C7AC3825-A29B-4C81-91D6-26E810FEE2EA@gmail.com>
Message-ID: <95342BF4-8CB7-4109-9B19-B977AC38B705@oracle.com>

Hi Michael,

Did you modified app image after it was signed and before DMG was created? If yes, it is expected behavior and we will not sign app image when generating DMG.

Can you provide all steps you did to get to issue below?

Thanks,
Alexander

> On Jun 22, 2022, at 1:51 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Alexander,
> 
> Sorry yet again. I really should have totally completed. While the application verified on disk immediately after signing. The dmg version does not appear to verify. 
> 
> codesign -v --verbose=4 /Applications/BlackJack\ Blastoff_Unsigned.app 
> /Applications/BlackJack Blastoff_Unsigned.app: a sealed resource is missing or invalid
> file added: /Applications/BlackJack Blastoff_Unsigned.app/Contents/app/.package
> file modified: /Applications/BlackJack Blastoff_Unsigned.app/Contents/runtime/Contents/Home/legal/java.management.rmi/LICENSE
> ?
> A lot of those
> ?
> file missing: /Applications/BlackJack Blastoff_Unsigned.app/Contents/app/.jpackage.xml
> 
> Same result checking while still in the mounted dmg or copied into /Applications
> 
> Should this be working?
> 
> java --version
> openjdk 19-ea 2022-09-20
> OpenJDK Runtime Environment (build 19-ea+27-2074)
> OpenJDK 64-Bit Server VM (build 19-ea+27-2074, mixed mode, sharing)
> 
> Or should I bug report?
> 
> Mike
> 
> (Fwiw I remember this same signing issue from an earlier release - I could probably track down the bug report.)
> 
> 
> 


From mik3hall at gmail.com  Thu Jun 23 00:15:40 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 22 Jun 2022 19:15:40 -0500
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <95342BF4-8CB7-4109-9B19-B977AC38B705@oracle.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
 <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
 <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>
 <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com>
 <C7AC3825-A29B-4C81-91D6-26E810FEE2EA@gmail.com>
 <95342BF4-8CB7-4109-9B19-B977AC38B705@oracle.com>
Message-ID: <BD9EC94B-53A5-45D1-80F8-5E93F2191EC7@gmail.com>



> On Jun 22, 2022, at 6:57 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
> Did you modified app image after it was signed and before DMG was created? If yes, it is expected behavior and we will not sign app image when generating DMG.
> 
> Can you provide all steps you did to get to issue below?
> 
> Thanks,
> Alexander
> 
Alexander,

They were pretty much as shown. 
1). Create with script shown.
	verify with previously shown error
2). Sign as per your post
	verify showed good
3). DMG as previously shown
	DMG created and opens
Reported good
Did verify against mounted dmg, got errors shown
Copied to Applications directory, got errors shown.

No changes to application image or dmg done at any point. Nothing except codesign verifies.

Prior bug with same error appears to have not had a resolution. I wasn?t depending on successful code signing at the time I don?t think.
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
	
The three steps to create - sign - dmg should be pretty easy to reproduce with a test app.

Mike


From mik3hall at gmail.com  Thu Jun 23 00:22:38 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 22 Jun 2022 19:22:38 -0500
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <BD9EC94B-53A5-45D1-80F8-5E93F2191EC7@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
 <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
 <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>
 <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com>
 <C7AC3825-A29B-4C81-91D6-26E810FEE2EA@gmail.com>
 <95342BF4-8CB7-4109-9B19-B977AC38B705@oracle.com>
 <BD9EC94B-53A5-45D1-80F8-5E93F2191EC7@gmail.com>
Message-ID: <3262D90C-0DA4-4F49-AA75-96A0E7478AAF@gmail.com>



> On Jun 22, 2022, at 7:15 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jun 22, 2022, at 6:57 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
>> 
>> Hi Michael,
>> 
>> Did you modified app image after it was signed and before DMG was created? If yes, it is expected behavior and we will not sign app image when generating DMG.
>> 
>> Can you provide all steps you did to get to issue below?
>> 
>> Thanks,
>> Alexander
>> 
> Alexander,
> 
> They were pretty much as shown. 
> 1). Create with script shown.
> 	verify with previously shown error
> 2). Sign as per your post
> 	verify showed good
> 3). DMG as previously shown
> 	DMG created and opens
> Reported good
> Did verify against mounted dmg, got errors shown
> Copied to Applications directory, got errors shown.
> 
> No changes to application image or dmg done at any point. Nothing except codesign verifies.
> 
> Prior bug with same error appears to have not had a resolution. I wasn?t depending on successful code signing at the time I don?t think.
> 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
> 	
> The three steps to create - sign - dmg should be pretty easy to reproduce with a test app.
> 
> Mike
> 
That may of been when I was doing an incorrect copy to a test directory using ?cp?. I had some errors that corrected when I switched to the OS/X ?ditto? command.
How are you copying to the dmg for step 3? Possibly something happens there? 


From alexander.matveev at oracle.com  Thu Jun 23 00:36:58 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 23 Jun 2022 00:36:58 +0000
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <3262D90C-0DA4-4F49-AA75-96A0E7478AAF@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
 <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
 <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>
 <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com>
 <C7AC3825-A29B-4C81-91D6-26E810FEE2EA@gmail.com>
 <95342BF4-8CB7-4109-9B19-B977AC38B705@oracle.com>
 <BD9EC94B-53A5-45D1-80F8-5E93F2191EC7@gmail.com>
 <3262D90C-0DA4-4F49-AA75-96A0E7478AAF@gmail.com>
Message-ID: <A55B9B4A-024B-4B7B-9388-C14F37E31884@oracle.com>

Hi Michael,

I was able to reproduce it. Not sure what is wrong. Do you want to file a bug for this? Or I can file one myself.

Thanks,
Alexander

> On Jun 22, 2022, at 5:22 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jun 22, 2022, at 7:15 PM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>> 
>> 
>>> On Jun 22, 2022, at 6:57 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
>>> 
>>> Hi Michael,
>>> 
>>> Did you modified app image after it was signed and before DMG was created? If yes, it is expected behavior and we will not sign app image when generating DMG.
>>> 
>>> Can you provide all steps you did to get to issue below?
>>> 
>>> Thanks,
>>> Alexander
>>> 
>> Alexander,
>> 
>> They were pretty much as shown. 
>> 1). Create with script shown.
>> 	verify with previously shown error
>> 2). Sign as per your post
>> 	verify showed good
>> 3). DMG as previously shown
>> 	DMG created and opens
>> Reported good
>> Did verify against mounted dmg, got errors shown
>> Copied to Applications directory, got errors shown.
>> 
>> No changes to application image or dmg done at any point. Nothing except codesign verifies.
>> 
>> Prior bug with same error appears to have not had a resolution. I wasn?t depending on successful code signing at the time I don?t think.
>> 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
>> 	
>> The three steps to create - sign - dmg should be pretty easy to reproduce with a test app.
>> 
>> Mike
>> 
> That may of been when I was doing an incorrect copy to a test directory using ?cp?. I had some errors that corrected when I switched to the OS/X ?ditto? command.
> How are you copying to the dmg for step 3? Possibly something happens there? 
> 


From mik3hall at gmail.com  Thu Jun 23 00:40:10 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 22 Jun 2022 19:40:10 -0500
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <A55B9B4A-024B-4B7B-9388-C14F37E31884@oracle.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
 <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
 <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>
 <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com>
 <C7AC3825-A29B-4C81-91D6-26E810FEE2EA@gmail.com>
 <95342BF4-8CB7-4109-9B19-B977AC38B705@oracle.com>
 <BD9EC94B-53A5-45D1-80F8-5E93F2191EC7@gmail.com>
 <3262D90C-0DA4-4F49-AA75-96A0E7478AAF@gmail.com>
 <A55B9B4A-024B-4B7B-9388-C14F37E31884@oracle.com>
Message-ID: <0D8431F2-5E1F-4990-BA32-2748BB4336B6@gmail.com>



> On Jun 22, 2022, at 7:36 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
> I was able to reproduce it. Not sure what is wrong. Do you want to file a bug for this? Or I can file one myself.
> 
> Thanks,
> Alexander
> 

You can get it. I have no immediate need again. Just thought I might post an example of how it could be used to customize an Info.plist.
Maybe indicate the number so I can track it.

Thanks for the follow up.

Mike


From naoto at openjdk.org  Thu Jun 23 01:03:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 01:03:40 GMT
Subject: RFR: 8287076: Document.normalizeDocument() produces different
 results [v2]
In-Reply-To: <f_5Qa6DvVRTJxKh-kAxeB1nzncx5q__ZT8Npx_j_WhM=.ec714d74-88e2-4c1d-9a53-41ecaff2835a@github.com>
References: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>
 <f_5Qa6DvVRTJxKh-kAxeB1nzncx5q__ZT8Npx_j_WhM=.ec714d74-88e2-4c1d-9a53-41ecaff2835a@github.com>
Message-ID: <d0_KPuudql_wQ_Wm81kAdWenOs_cY5DlU5DB6LmVOxk=.dcec80ee-6d77-4242-91df-b13c356083c8@github.com>

On Wed, 22 Jun 2022 21:48:35 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix a regression in Document.normalizeDocument() caused by a change in JDK 10.
>> 
>> Test: new test (as in the bug report) and Tier2 passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove initialization size, use default instead

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/59

From jpai at openjdk.org  Thu Jun 23 01:17:45 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Jun 2022 01:17:45 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative
In-Reply-To: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
Message-ID: <u_SHsjvZHuo2VrbLYPpzcuiZZXTWrxgHJwQ5dOYDV-o=.17e60ba7-16d6-4955-b1a2-fc0f50837dd3@github.com>

On Wed, 22 Jun 2022 18:19:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
> 
> Exception messages should not include newlines.

The source changes look fine to me. The test file change would need a copyright year update.

test/lib-test/jdk/test/lib/process/OutputAnalyzerTest.java line 223:

> 221:             try {
> 222:                 // Verify the exception message
> 223:                 OutputAnalyzer out = ProcessTools.executeProcess("true");

Hello Roger, this test seems to run on all OS. Is `true` available on Windows? If yes, does it require a `.exe` suffix?

-------------

PR: https://git.openjdk.org/jdk/pull/9247

From smarks at openjdk.org  Thu Jun 23 01:23:57 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 23 Jun 2022 01:23:57 GMT
Subject: RFR: 8285405: add test and check for negative argument to
 HashMap::newHashMap et al [v3]
In-Reply-To: <htowLOfO1V1jUwTBmA6SkpCLU2weqCWZ4ey1PSI7viA=.ea0f21e1-a0ab-48c4-a6cf-55dff71b2c61@github.com>
References: <uGDobUFmIhzSqsHE0VoGfD9r38lRGAAoeU0VAFymEA8=.827034d6-7782-4d1f-bef5-8b7e0e9dc5c6@github.com>
 <htowLOfO1V1jUwTBmA6SkpCLU2weqCWZ4ey1PSI7viA=.ea0f21e1-a0ab-48c4-a6cf-55dff71b2c61@github.com>
Message-ID: <VcEgfO4jpQXy_puJ_bOM8JetnE-151DTUCf2f2STZNo=.f9564385-ce75-4b72-8879-36534a583407@github.com>

On Fri, 10 Jun 2022 08:26:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405?
>> 
>> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class.
>> 
>> For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add newline at the end of the new file

Changes to the files in src are all fine.

I've made a couple individual comments on the NewHashMap.java test. But modifying two files and adding three new files seems rather bulky for what is essentially five copies of the same test. Perhaps they should be consolidated. They could all be written in a single file using a single data provider for five different test methods. (They could even be written as a combo test with a data provider that provides the factory method to call, but that seems like excess complexity.)

I'd suggest adding the data provider and test cases to HashMap/WhiteBoxResizeTest. That test is already testing the factory methods for the five implementations to ensure the right capacity is allocated. Testing them for negative values is only a small step beyond that.

A combo test of {-1, -42, MIN_VALUE} x { newHM, newLHM, ... } doesn't seem to me to warrant the complexity that would entail. Testing different negative values doesn't add much. I'd suggest having a data provider that provides the different factory methods as an IntFunction and then just passes -1 and ensures that the exception is thrown.

test/jdk/java/util/HashMap/NewHashMap.java line 45:

> 43:                 new Object[]{Integer.MIN_VALUE},
> 44:                 new Object[]{-42}};
> 45:     }

Can be rewritten more concisely as follows:

    return new Object[][] { { -1 }, { Integer.MIN_VALUE }, { -42 } };

test/jdk/java/util/HashMap/NewHashMap.java line 71:

> 69:         assertNotNull(h);
> 70:         assertEquals(h.size(), 0, "Unexpected size of HashMap created with numMappings: " + val);
> 71:     }

I don't think we need tests for non-negative values. Aren't these covered in HashMap/WhiteBoxResizeTest? Testing of size is also a bit superfluous here.

-------------

PR: https://git.openjdk.org/jdk/pull/9036

From naoto at openjdk.org  Thu Jun 23 01:44:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 01:44:40 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative
In-Reply-To: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
Message-ID: <Xps8jB63JXp84XUQtKJCuBaxJzGkKdilcNrNZVBimHs=.451bc3b7-25f7-4403-9d1e-c70ba7ca7a91@github.com>

On Wed, 22 Jun 2022 18:19:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
> 
> Exception messages should not include newlines.

test/lib/jdk/test/lib/process/OutputAnalyzer.java line 505:

> 503:             reportDiagnosticSummary();
> 504:             throw new RuntimeException("Unexpected to get exit value of ["
> 505:                     + notExpectedExitValue + "], exit value is: [" + getExitValue() + "]");

This seems redundant to me. "Unexpected to get exit value of [notExpectedExitValue]." should suffice?

-------------

PR: https://git.openjdk.org/jdk/pull/9247

From alexander.matveev at oracle.com  Thu Jun 23 03:28:36 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 23 Jun 2022 03:28:36 +0000
Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing
 user provided app image [v2]
In-Reply-To: <0D8431F2-5E1F-4990-BA32-2748BB4336B6@gmail.com>
References: <h6XoPvkBlZLxro5qUcMVpR3aVLiflZjLeNvd4G_mDsY=.c40422cb-17a4-4cab-8c52-0a4d5850e9be@github.com>
 <IqmvopgUVzXaUCb_gZ7Wzqpp4TZv8YZlLnnveT9dwjU=.2c5f6fe7-be4b-4628-b68c-3fc98ebf710a@github.com>
 <jEo2TsceBff6WtaQ-0iEdM1MEOj02zyaXsuFgj9s064=.ad12b8bd-512e-4abc-a99e-606eaad9dea5@github.com>
 <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com>
 <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com>
 <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com>
 <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com>
 <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com>
 <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com>
 <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com>
 <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com>
 <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com>
 <C7AC3825-A29B-4C81-91D6-26E810FEE2EA@gmail.com>
 <95342BF4-8CB7-4109-9B19-B977AC38B705@oracle.com>
 <BD9EC94B-53A5-45D1-80F8-5E93F2191EC7@gmail.com>
 <3262D90C-0DA4-4F49-AA75-96A0E7478AAF@gmail.com>
 <A55B9B4A-024B-4B7B-9388-C14F37E31884@oracle.com>
 <0D8431F2-5E1F-4990-BA32-2748BB4336B6@gmail.com>
Message-ID: <7E5EB1E3-CA01-4955-B7B3-5967B0083615@oracle.com>

Hi Michael,

I filed it as https://bugs.openjdk.org/browse/JDK-8289030

Thanks,
Alexander

On Jun 22, 2022, at 5:40 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Jun 22, 2022, at 7:36 PM, Alexander Matveev <alexander.matveev at oracle.com<mailto:alexander.matveev at oracle.com>> wrote:

Hi Michael,

I was able to reproduce it. Not sure what is wrong. Do you want to file a bug for this? Or I can file one myself.

Thanks,
Alexander


You can get it. I have no immediate need again. Just thought I might post an example of how it could be used to customize an Info.plist.
Maybe indicate the number so I can track it.

Thanks for the follow up.

Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220623/b3be9182/attachment.htm>

From dholmes at openjdk.org  Thu Jun 23 06:12:38 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Jun 2022 06:12:38 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative
In-Reply-To: <Xps8jB63JXp84XUQtKJCuBaxJzGkKdilcNrNZVBimHs=.451bc3b7-25f7-4403-9d1e-c70ba7ca7a91@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
 <Xps8jB63JXp84XUQtKJCuBaxJzGkKdilcNrNZVBimHs=.451bc3b7-25f7-4403-9d1e-c70ba7ca7a91@github.com>
Message-ID: <fau-gm3k2xaDfthKRdciojrKLq6XN5Kkn7N4lcXiAqs=.5919a3ac-1148-4977-8d18-eade3a56cc46@github.com>

On Thu, 23 Jun 2022 01:40:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
>> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
>> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
>> 
>> Exception messages should not include newlines.
>
> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 505:
> 
>> 503:             reportDiagnosticSummary();
>> 504:             throw new RuntimeException("Unexpected to get exit value of ["
>> 505:                     + notExpectedExitValue + "], exit value is: [" + getExitValue() + "]");
> 
> This seems redundant to me. "Unexpected to get exit value of [notExpectedExitValue]." should suffice?

I agree this doesn't need changing as there is only one value to report.

-------------

PR: https://git.openjdk.org/jdk/pull/9247

From alanb at openjdk.org  Thu Jun 23 07:21:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Jun 2022 07:21:59 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <Dho3DWC5sQTgYpk2EhWDIMz6cm19GdQS5Z3gjiLR05E=.578cdb7b-9e2b-4d2d-8773-5ebf63d3372e@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <Dho3DWC5sQTgYpk2EhWDIMz6cm19GdQS5Z3gjiLR05E=.578cdb7b-9e2b-4d2d-8773-5ebf63d3372e@github.com>
Message-ID: <1qiIHaDvqIOqcxO0EybhwUiHd7dp0ujZUxTw1JHEhOQ=.56b7421b-f95a-4702-ace4-b36128811445@github.com>

On Wed, 22 Jun 2022 22:18:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I think that this is the only use of `stat2()`. It could be deleted if this method were replaced with this:

The purpose of these additions to the SPI is to improve the performance of user facing methods that don't throw an exception when the file doesn't exist. It needs a stat/equivalent that doesn't throw so this is the reason for stat2. The equivalent on Windows will need to added too.

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From chegar at openjdk.org  Thu Jun 23 08:08:38 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Thu, 23 Jun 2022 08:08:38 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <1ckyd2CtHpn1rHvV7b914_tXO5TGyEyisQ5zhEeogZ8=.ce9d6888-5597-4bd7-9c57-409d00d39cfa@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1202:

> 1200:      */
> 1201:     public boolean exists(Path path, LinkOption... options) {
> 1202:         try {

Overall, I think that this is a great change (avoiding the need for various parts of the system to communicate through exceptions).

Trivially, and easily, I often find it useful to add mock-like tests for these specified implementations (implSpec), i.e. just subclass FSP mocking out the abstract methods to ensure that the default implementations invoke the appropriate ones.

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From djelinski at openjdk.org  Thu Jun 23 08:53:37 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 08:53:37 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Sort output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9243/files
  - new: https://git.openjdk.org/jdk/pull/9243/files/6cb47724..8d26e537

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9243.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9243/head:pull/9243

PR: https://git.openjdk.org/jdk/pull/9243

From djelinski at openjdk.org  Thu Jun 23 08:59:41 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 08:59:41 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
 <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
 <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>
Message-ID: <Q4tqgNMy885ng7J5zMyZTySXn2Vl3DXVFhAJ14svPck=.68d2eae1-2d6b-4a71-9a12-24db60253304@github.com>

On Wed, 22 Jun 2022 21:45:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?
>
> BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.

> once this fix makes it to the repository, the build will be reproducible

Yes, we always produce the same source code. Given the same order of modifications, a hashmap will produce the same iteration order.

> LinkedHashMap could be used to retain the iteration order.

Just added. The input maps were always sorted in some order (they were either LinkedHashMaps or TreeMaps), and now we preserve that order.
This means a lot of changes in the generated output files now, but hopefully in the future the changes will be much easier to review.

TIL: `put` / `putIfAbsent` on an existing entry does not change the iteration order of a `LinkedHashMap` unless `accessOrder` is true.

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From djelinski at openjdk.org  Thu Jun 23 09:04:41 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 09:04:41 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <Q4tqgNMy885ng7J5zMyZTySXn2Vl3DXVFhAJ14svPck=.68d2eae1-2d6b-4a71-9a12-24db60253304@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
 <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
 <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>
 <Q4tqgNMy885ng7J5zMyZTySXn2Vl3DXVFhAJ14svPck=.68d2eae1-2d6b-4a71-9a12-24db60253304@github.com>
Message-ID: <Sxyc5_9-pgmZWN-TjJ5MAcplaRfbFxDE8LKw6_7-Ors=.89d59d50-909e-4022-beac-b3fd517495c0@github.com>

On Thu, 23 Jun 2022 08:56:08 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.
>
>> once this fix makes it to the repository, the build will be reproducible
> 
> Yes, we always produce the same source code. Given the same order of modifications, a hashmap will produce the same iteration order.
> 
>> LinkedHashMap could be used to retain the iteration order.
> 
> Just added. The input maps were always sorted in some order (they were either LinkedHashMaps or TreeMaps), and now we preserve that order.
> This means a lot of changes in the generated output files now, but hopefully in the future the changes will be much easier to review.
> 
> TIL: `put` / `putIfAbsent` on an existing entry does not change the iteration order of a `LinkedHashMap` unless `accessOrder` is true.

> BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.

It may occur if there are very few duplicates. Still, the performance impact of proper sizing is minimal here.

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From alanb at openjdk.org  Thu Jun 23 09:29:02 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Jun 2022 09:29:02 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v6]
In-Reply-To: <kGgfmE6iN-AOIaYe1WNl6wLU7Ah8urVwxN_M-qBYHaw=.d6b57508-36fe-462b-b3f3-b9daa2f43d8b@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <kGgfmE6iN-AOIaYe1WNl6wLU7Ah8urVwxN_M-qBYHaw=.d6b57508-36fe-462b-b3f3-b9daa2f43d8b@github.com>
Message-ID: <WGOR46gCj14Yzr3BwOyPnB0jrQxUeXLcnbNSf452xGw=.489abcf4-178a-4829-b12f-f06be3d63e25@github.com>

On Wed, 22 Jun 2022 17:46:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
>> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.
>
> 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 seven additional commits since the last revision:
> 
>  - Leave the log files in the current directory
>  - Merge branch 'master' into JDK-8288589
>  - Moved `@Test` annotations
>  - Refined the test, adding more variations.
>  - Adding a test case in ReadWriteString.java
>  - Added c2b test
>  - 8288589: Files.readString ignores encoding errors for UTF-16

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From alanb at openjdk.org  Thu Jun 23 09:29:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Jun 2022 09:29:04 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
 [v5]
In-Reply-To: <AkqhzksFZp-2OoHNUIvXXvCCi-z2oO2ZFCH1h61XRkc=.2f6bdd7f-859d-428d-9a2a-8b9f954afce5@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
 <2mC9Q1w0EbczZgPu_VvD10SsAFmSsAwayIr0-P1GHds=.d91c80b9-9165-4d5e-837a-9b6c3c9b735d@github.com>
 <QefKUWfyt2UK41uzcu4lFdI_jIyLA_0K0nxUC2-XYzQ=.11f3bb18-5b5a-47e2-a98d-d63f565c43e2@github.com>
 <AkqhzksFZp-2OoHNUIvXXvCCi-z2oO2ZFCH1h61XRkc=.2f6bdd7f-859d-428d-9a2a-8b9f954afce5@github.com>
Message-ID: <obASzPVGRU6wv7slY2RMj_mnlsnTSv0teHOYgKvZbsc=.6b4adbfe-638d-4f1f-b6f4-7215a7b607ea@github.com>

On Wed, 22 Jun 2022 17:41:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Done.

Thanks, that will be helpful if the test fails.

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From duke at openjdk.org  Thu Jun 23 09:44:55 2022
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 23 Jun 2022 09:44:55 GMT
Subject: Integrated: 8287760: --do-not-resolve-by-default gets overwritten if
 --warn-if-resolved flags is used
In-Reply-To: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
References: <vwGVFp7oEGawc5l-gT1yb_CIvXhtcoMrem0fYZRQ5KQ=.d3b0d35a-1bde-4cfc-a7ad-0f649d5f84a1@github.com>
Message-ID: <1oiFpWx4lrBNiCVme8mpQejB2dulWsgNu_mNyCJ_Lhs=.df893121-6a43-4701-afa5-ceb023388dd1@github.com>

On Tue, 7 Jun 2022 00:45:17 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

This pull request has now been integrated.

Changeset: a802b981
Author:    Thiago Henrique H?pner <thihup at gmail.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a802b9816ac5c0cb0fd236cc7f25ed4fdb1349ef
Stats:     139 lines in 2 files changed: 136 ins; 0 del; 3 mod

8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used

Reviewed-by: lancea, alanb, cstein

-------------

PR: https://git.openjdk.org/jdk/pull/9049

From alanb at openjdk.org  Thu Jun 23 10:59:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Jun 2022 10:59:53 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <taLnH5D0kcjcyoCbgSdY6DC5S2IOli1noHXIRU7u91o=.d8d04a00-74c2-4b49-88e6-e3d97886a220@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

This should be performance neutral for the default provider and positive for the zip provider. Do we have any micros that could be added?

The end date in the copyright header will need updated a few files, I assume you'll do that before this change is integrated.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java line 306:

> 304:                     case WRITE -> w = true;
> 305:                     case EXECUTE -> x = true;
> 306:                     default -> throw new AssertionError("Should not get here");

The switch should be exhaustive so I assume the default case is not required here.

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From alanb at openjdk.org  Thu Jun 23 11:05:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Jun 2022 11:05:43 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <_OsO1pbyNGFQJTu5nk16w-Y-c0VIW7T3qrrsZgz32-0=.f31987e8-1eab-4de0-a4da-7f9897981767@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 302:

> 300:         throws IOException
> 301:     {
> 302:         return exists(path) ? readAttributes(path, type, options) : null;

If you add the following to ZipPath then it would allow you to implement it in one step rather than two:


ZipFileAttributes readAttributesIfExits() throws IOException {
    return zfs.getFileAttributes(getResolvedPath());
 }

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From jpai at openjdk.org  Thu Jun 23 13:12:35 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Jun 2022 13:12:35 GMT
Subject: RFR: 8247407: tools/jlink/plugins/CompressorPluginTest.java test
 failing
Message-ID: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>

Can I please get a review for this change which fixes an issue in `jdk.internal.jimage.ImageReader`? 

The `ImageReader` maintains a map of `nodes` which it uses to keep track of directories/resources from within the image. When a `findNode` is called, it leads to building the `Node` if the node isn't present in the map or if isn't complete (i.e. if the directory's immediate child nodes haven't been built). During this building of nodes, the code can end up creating a directory node and then visiting the child resources to create nodes for those resources. While doing so, the code currently doesn't check if a (child) node for the resource was already created previously (during a different call) and added to the parent directory's `children` list. As a result, it ends up adding the child node more than once.

One way to solve this would have been to make the `children` in `Directory` be a `Set`. I suspect it's currently a `List` so as to keep track of the order? If we did make it a `Set`, we could still keep the order using a `LinkedHashSet`. But changing this to a `Set` doesn't look feasible because there's a `List<Node> getChildren()` API on `Directory`, which would then have to create a copy of the `Set` to return as a `List`.

The commit in this PR instead prevents adding the child more than once by checking the `nodes` map for the presence of the child. This new check is added only for "resources" and not directories, because `makeDirectory` already skips a `Node` creation if the `nodes` has the corresponding entry (line 564 in the current PR).
Additionally an `assert` has been added to `addChild` of `Directory`.

A new jtreg test has been added which reproduces the issue without this change and verifies the fix.

This part of the code is very new to me, so if there's anything more to be considered, then please let me know.

tier1, tier2, tier3 testing is currently in progress.

-------------

Commit messages:
 - 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist
 - 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing

Changes: https://git.openjdk.org/jdk19/pull/60/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=60&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8247407
  Stats: 93 lines in 3 files changed: 91 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk19/pull/60.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/60/head:pull/60

PR: https://git.openjdk.org/jdk19/pull/60

From sundar at openjdk.org  Thu Jun 23 13:20:52 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 23 Jun 2022 13:20:52 GMT
Subject: RFR: 8247407: tools/jlink/plugins/CompressorPluginTest.java test
 failing
In-Reply-To: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
References: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
Message-ID: <EV2blb52D5F2Rsx04I5TAPwfkJeBqHuOGmdkJzryL5k=.16afaa70-532b-4fae-89c7-9a91137e647e@github.com>

On Thu, 23 Jun 2022 12:59:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes an issue in `jdk.internal.jimage.ImageReader`? 
> 
> The `ImageReader` maintains a map of `nodes` which it uses to keep track of directories/resources from within the image. When a `findNode` is called, it leads to building the `Node` if the node isn't present in the map or if isn't complete (i.e. if the directory's immediate child nodes haven't been built). During this building of nodes, the code can end up creating a directory node and then visiting the child resources to create nodes for those resources. While doing so, the code currently doesn't check if a (child) node for the resource was already created previously (during a different call) and added to the parent directory's `children` list. As a result, it ends up adding the child node more than once.
> 
> One way to solve this would have been to make the `children` in `Directory` be a `Set`. I suspect it's currently a `List` so as to keep track of the order? If we did make it a `Set`, we could still keep the order using a `LinkedHashSet`. But changing this to a `Set` doesn't look feasible because there's a `List<Node> getChildren()` API on `Directory`, which would then have to create a copy of the `Set` to return as a `List`.
> 
> The commit in this PR instead prevents adding the child more than once by checking the `nodes` map for the presence of the child. This new check is added only for "resources" and not directories, because `makeDirectory` already skips a `Node` creation if the `nodes` has the corresponding entry (line 564 in the current PR).
> Additionally an `assert` has been added to `addChild` of `Directory`.
> 
> A new jtreg test has been added which reproduces the issue without this change and verifies the fix.
> 
> This part of the code is very new to me, so if there's anything more to be considered, then please let me know.
> 
> tier1, tier2, tier3 testing is currently in progress.

LGTM. Nice catch!

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/60

From rriggs at openjdk.org  Thu Jun 23 13:52:46 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Jun 2022 13:52:46 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative
In-Reply-To: <u_SHsjvZHuo2VrbLYPpzcuiZZXTWrxgHJwQ5dOYDV-o=.17e60ba7-16d6-4955-b1a2-fc0f50837dd3@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
 <u_SHsjvZHuo2VrbLYPpzcuiZZXTWrxgHJwQ5dOYDV-o=.17e60ba7-16d6-4955-b1a2-fc0f50837dd3@github.com>
Message-ID: <vHUBoeErM184gGDgfrBDCpXwI_MCOJySyvU6J2JakYs=.376999b5-6925-4f9b-8794-a066fc1b3b7f@github.com>

On Thu, 23 Jun 2022 01:13:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
>> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
>> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
>> 
>> Exception messages should not include newlines.
>
> test/lib-test/jdk/test/lib/process/OutputAnalyzerTest.java line 223:
> 
>> 221:             try {
>> 222:                 // Verify the exception message
>> 223:                 OutputAnalyzer out = ProcessTools.executeProcess("true");
> 
> Hello Roger, this test seems to run on all OS. Is `true` available on Windows? If yes, does it require a `.exe` suffix?

The Windows CreateProcess API appends ".exe".  (if there is no suffix).  
(And CI testing succeeded).

-------------

PR: https://git.openjdk.org/jdk/pull/9247

From rriggs at openjdk.org  Thu Jun 23 13:57:39 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Jun 2022 13:57:39 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative
In-Reply-To: <fau-gm3k2xaDfthKRdciojrKLq6XN5Kkn7N4lcXiAqs=.5919a3ac-1148-4977-8d18-eade3a56cc46@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
 <Xps8jB63JXp84XUQtKJCuBaxJzGkKdilcNrNZVBimHs=.451bc3b7-25f7-4403-9d1e-c70ba7ca7a91@github.com>
 <fau-gm3k2xaDfthKRdciojrKLq6XN5Kkn7N4lcXiAqs=.5919a3ac-1148-4977-8d18-eade3a56cc46@github.com>
Message-ID: <lJUO-wnjf66a0M9GSqOvWar7o0FxWXpt-W9pCMcetSc=.39ecab3e-fde1-46dc-828f-8e00b9cd208a@github.com>

On Thu, 23 Jun 2022 06:08:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 505:
>> 
>>> 503:             reportDiagnosticSummary();
>>> 504:             throw new RuntimeException("Unexpected to get exit value of ["
>>> 505:                     + notExpectedExitValue + "], exit value is: [" + getExitValue() + "]");
>> 
>> This seems redundant to me. "Unexpected to get exit value of [notExpectedExitValue]." should suffice?
>
> I agree this doesn't need changing as there is only one value to report.

Right, a bit overzealous on the expected vs actual.

-------------

PR: https://git.openjdk.org/jdk/pull/9247

From rriggs at openjdk.org  Thu Jun 23 14:09:20 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Jun 2022 14:09:20 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative [v2]
In-Reply-To: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
Message-ID: <eutM8HrHbHOjaTtUR2OS-Qa5fhzzl36hoFWJMo4Bwus=.50e73a67-43ea-4715-9c1e-d8491b70bb15@github.com>

> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
> 
> Exception messages should not include newlines.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Revert change to shouldNotHaveExitValue
  Correct OutputAnalyzerTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9247/files
  - new: https://git.openjdk.org/jdk/pull/9247/files/4e479b4a..e73bf2bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9247.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9247/head:pull/9247

PR: https://git.openjdk.org/jdk/pull/9247

From rriggs at openjdk.org  Thu Jun 23 14:12:45 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Jun 2022 14:12:45 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
Message-ID: <d3675Rh7ela5uoRkzdhFeolJTba62VmXd5YzRdHI8iU=.a7141101-6612-4def-a203-81a409f7968e@github.com>

On Thu, 23 Jun 2022 08:53:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort output

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9243

From rriggs at openjdk.org  Thu Jun 23 14:40:59 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Jun 2022 14:40:59 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v33]
In-Reply-To: <_oo66oJSObuUoMgeH0Zifx35QNZ7A0-UpVkPRwecJoA=.3aed9989-1eb0-4aac-8bd7-76627c334f9e@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <_oo66oJSObuUoMgeH0Zifx35QNZ7A0-UpVkPRwecJoA=.3aed9989-1eb0-4aac-8bd7-76627c334f9e@github.com>
Message-ID: <568BhbvXIaBNTp04x8mcXGtcDaZ0q3FNGe5-1V9EvP8=.fc1b8166-fb80-40a6-af98-2c728b9d894c@github.com>

On Tue, 21 Jun 2022 22:30:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove implSpec tag from Executable.accessFlags since the class is sealed.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 335:

> 333:             if ((mask &  accessMask) != 0) {
> 334:                 result.add(accessFlag);
> 335:                 mask = mask & ~accessMask;

The removal of the flag from the masks as they are added to set works only if there is a unique mask bit per location.
(In the future, Valhalla, the same bit mask for more than one AccessFlag can appear in a single Location.)
Removing flag bits from a copy of the input mask can have the desired effect.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From rmartinc at redhat.com  Thu Jun 23 08:22:48 2022
From: rmartinc at redhat.com (Ricardo Martin Camarero)
Date: Thu, 23 Jun 2022 10:22:48 +0200
Subject: Bug JDK-8176553
In-Reply-To: <CY4PR1001MB237645CBEE5610892A0A5F3FECB39@CY4PR1001MB2376.namprd10.prod.outlook.com>
References: <04eec9b7-4995-3f88-c2db-ec8ba628dffa@redhat.com>
 <06a79df6-24fc-bfbd-476e-208ac4ec9fa7@oracle.com>
 <CY4PR1001MB237645CBEE5610892A0A5F3FECB39@CY4PR1001MB2376.namprd10.prod.outlook.com>
Message-ID: <eb4aeaa0-3913-2b7a-1863-cd0b0d8ecbbf@redhat.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220623/2a5c2c5a/attachment-0001.htm>

From naoto at openjdk.org  Thu Jun 23 15:54:00 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 15:54:00 GMT
Subject: Integrated: 8288589: Files.readString ignores encoding errors for
 UTF-16
In-Reply-To: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
References: <0rhbAGAdBUsHZ794HbGvwcgcjuanCVfs_DRb5lM87JQ=.03b7ef7c-045f-455c-aa2d-c6b260b7fe50@github.com>
Message-ID: <N4b60Kkg6bB6HVvAsfdLcqOveDxmCZ7_p9BZihlTJ8A=.03582c7b-8fc4-4fb6-88a5-84a058d3b672@github.com>

On Thu, 16 Jun 2022 22:21:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int, Charset)` constructor, which specifically mentions the `REPLACE` mode. However, the method is invoked with `String.newStringNoRepl()` and it should NOT replace the malformed input (duh!). The fix is to throw an `Error` for the former case as before the regression, and `CharacterCodingException` for the latter via an `IllegalArgumentException`.
> In fact, `Files.readString()` stopped throwing a `MalformedInputException` since JDK17 with the fix to JDK-8259842, which started throwing an `Error`.

This pull request has now been integrated.

Changeset: 2728770e
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2728770e3d73bb11c4d6e54b5aff91588a1a780b
Stats:     231 lines in 4 files changed: 143 ins; 68 del; 20 mod

8288589: Files.readString ignores encoding errors for UTF-16

Reviewed-by: rriggs, iris, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9193

From naoto at openjdk.org  Thu Jun 23 16:23:12 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 16:23:12 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
Message-ID: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>

Hi all,

This pull request contains a backport of commit [2728770e](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/2728770e3d73bb11c4d6e54b5aff91588a1a780b__;!!ACWV5N9M2RV99hQ!N3mEnVUKBkymH2i4wvdNdT17pAtXF6773dQA7XG_uBo8CmAZNuaRhs6MMY2TvgGZ6WI7Xst8ex_Eul_yWGyTcg$ ) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Naoto Sato on 23 Jun 2022 and was reviewed by Roger Riggs, Iris Clark and Alan Bateman.

Thanks!

-------------

Commit messages:
 - Backport 2728770e3d73bb11c4d6e54b5aff91588a1a780b

Changes: https://git.openjdk.org/jdk19/pull/61/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=61&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288589
  Stats: 231 lines in 4 files changed: 143 ins; 68 del; 20 mod
  Patch: https://git.openjdk.org/jdk19/pull/61.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/61/head:pull/61

PR: https://git.openjdk.org/jdk19/pull/61

From iris at openjdk.org  Thu Jun 23 17:13:00 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 23 Jun 2022 17:13:00 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
In-Reply-To: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>
References: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>
Message-ID: <o8-Lv2IY3q2qmTDScyIcp7tmlH644X0Y92nKO0ImJ40=.eedb7dc4-1857-4c14-b1c3-4f81143e85cc@github.com>

On Thu, 23 Jun 2022 16:12:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [2728770e](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/2728770e3d73bb11c4d6e54b5aff91588a1a780b__;!!ACWV5N9M2RV99hQ!JWTXtcOlxAlKs1OamoE2hbweIBcqRBtUZoAQmPyrENX5-6Dr9ygPxqGcpC9F_ATb8jBkILMiisolDKuTAoQu$ ) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 23 Jun 2022 and was reviewed by Roger Riggs, Iris Clark and Alan Bateman.
> 
> Thanks!

Looks like a clean backport of the change in main-line.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/61

From naoto at openjdk.org  Thu Jun 23 17:13:01 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 17:13:01 GMT
Subject: Integrated: 8288589: Files.readString ignores encoding errors for
 UTF-16
In-Reply-To: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>
References: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>
Message-ID: <0mMV1oEIvmVrhVeuGIkdn8IME358T5r5y2ZdKMSjNgg=.bec849b8-2c0d-4966-b00c-32f7dd71dc8a@github.com>

On Thu, 23 Jun 2022 16:12:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [2728770e](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/2728770e3d73bb11c4d6e54b5aff91588a1a780b__;!!ACWV5N9M2RV99hQ!I5gYvkBBqN_IvjE2nbA57e5GTqsIW-Vww4LdZpqNPPIBDf4ihZbF5grAAgycsS2npzGdnMW2RoSgvvhazdQzjA$ ) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 23 Jun 2022 and was reviewed by Roger Riggs, Iris Clark and Alan Bateman.
> 
> Thanks!

This pull request has now been integrated.

Changeset: a716f793
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/a716f7934b2ce8078c27df4c87e8c1e9cceed000
Stats:     231 lines in 4 files changed: 143 ins; 68 del; 20 mod

8288589: Files.readString ignores encoding errors for UTF-16

Backport-of: 2728770e3d73bb11c4d6e54b5aff91588a1a780b

-------------

PR: https://git.openjdk.org/jdk19/pull/61

From joehw at openjdk.org  Thu Jun 23 17:16:53 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 23 Jun 2022 17:16:53 GMT
Subject: Integrated: 8287076: Document.normalizeDocument() produces different
 results
In-Reply-To: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>
References: <DxdGdbOtq_NaiNxsHRXaG7zmfTJAMstETtqwZDPJAH0=.4e14aa9b-794a-4e3f-9b86-4e6ad2c6a1a0@github.com>
Message-ID: <MhSXtfPzGUG9YOyaiK8KhriOzSiFl5cOOmnBX-GM4Zk=.56985df5-b5e0-4e92-99ed-9bad8fb1a5f0@github.com>

On Wed, 22 Jun 2022 20:01:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a regression in Document.normalizeDocument() caused by a change in JDK 10.
> 
> Test: new test (as in the bug report) and Tier2 passed.

This pull request has now been integrated.

Changeset: 1f9521e6
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/1f9521e6cb2f701f8712b4ec941ff1dbb45dad4e
Stats:     72 lines in 4 files changed: 52 ins; 3 del; 17 mod

8287076: Document.normalizeDocument() produces different results

Reviewed-by: lancea, iris, naoto

-------------

PR: https://git.openjdk.org/jdk19/pull/59

From naoto at openjdk.org  Thu Jun 23 18:10:03 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 18:10:03 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
Message-ID: <LMsVhWm07B08Ez1wuH5CO7PkHmmZ8U5GxYGakB4tuVA=.a3e42979-71d8-4159-acc2-229b6c173e4c@github.com>

On Thu, 23 Jun 2022 08:53:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort output

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From darcy at openjdk.org  Thu Jun 23 18:11:13 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Jun 2022 18:11:13 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v34]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <uLA_d0lTmgo-AmQszri-7pAZ-I-h_T_hD3dmVRkQdZU=.869e2334-8ec7-4396-bcfa-1a73d157309e@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback from Mandy and Roger.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/617c9aaf..63c48284

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=32-33

  Stats: 40 lines in 3 files changed: 14 ins; 5 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.org  Thu Jun 23 18:11:18 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Jun 2022 18:11:18 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v25]
In-Reply-To: <q3d1HdLKswVaq7lDL1Ya8JguvPsgJN2T-BQCcu9FQcE=.a9668b3d-659c-4adf-bfb9-c2f158e22eee@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <P76kZ6ab2uAGe6mm6V4sgSKTQtrc0SYumyNnCrfNJYs=.144beb9d-31ef-4e6b-b64a-3ee0f8cf4fc2@github.com>
 <q3d1HdLKswVaq7lDL1Ya8JguvPsgJN2T-BQCcu9FQcE=.a9668b3d-659c-4adf-bfb9-c2f158e22eee@github.com>
Message-ID: <6C6vSuDiJ1uXB3CZ5TLubftQ1saNBXsjynTtgrUf1ys=.97c27071-bb27-46bb-aa1e-d56d1db5c0f9@github.com>

On Tue, 14 Jun 2022 14:22:29 GMT, Roger Riggs <rriggs 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/java/lang/reflect/AccessFlag.java line 104:
> 
>> 102:      */
>> 103:     PROTECTED(Modifier.PROTECTED, true,
>> 104:               Set.of(Location.FIELD, Location.METHOD, Location.INNER_CLASS)),
> 
> In both space and startup time, creating separate sets for the same set of Locations is inefficient.

Good suggestion; in a subsequent push, I'll declare private static fields on the enclosed Location enum to hold the repeated sets of Locations used for the AccessFlag constants.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.org  Thu Jun 23 18:11:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Jun 2022 18:11:20 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v33]
In-Reply-To: <lsE7Docwpe9FdmD1czn_oZZ-bfNmKplGD-Wu8J1Neq4=.0d858efc-2ec9-444e-a771-0ade4a048e85@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <_oo66oJSObuUoMgeH0Zifx35QNZ7A0-UpVkPRwecJoA=.3aed9989-1eb0-4aac-8bd7-76627c334f9e@github.com>
 <lsE7Docwpe9FdmD1czn_oZZ-bfNmKplGD-Wu8J1Neq4=.0d858efc-2ec9-444e-a771-0ade4a048e85@github.com>
Message-ID: <3w6MHT8_BODWKrTNHKAANvbQ7hguVoyrrw1rKn2OiGM=.bb04b384-09c6-4b77-b8c3-241d75eb2969@github.com>

On Wed, 22 Jun 2022 17:33:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove implSpec tag from Executable.accessFlags since the class is sealed.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 290:
> 
>> 288:     // Intentionally using Set rather than EnumSet since EnumSet is
>> 289:     // mutable.
>> 290:     private Set<Location> locations;
> 
> these instance fields can be made final.

Agreed.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From lmesnik at openjdk.org  Thu Jun 23 18:22:53 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 23 Jun 2022 18:22:53 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative [v2]
In-Reply-To: <eutM8HrHbHOjaTtUR2OS-Qa5fhzzl36hoFWJMo4Bwus=.50e73a67-43ea-4715-9c1e-d8491b70bb15@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
 <eutM8HrHbHOjaTtUR2OS-Qa5fhzzl36hoFWJMo4Bwus=.50e73a67-43ea-4715-9c1e-d8491b70bb15@github.com>
Message-ID: <NzKhEIzRVRaAf4JNTrBLTEZTwEIKi9FInk_9BrVqsBA=.014f0b31-4fe6-4ac0-8018-7eff03e0711f@github.com>

On Thu, 23 Jun 2022 14:09:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
>> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
>> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
>> 
>> Exception messages should not include newlines.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to shouldNotHaveExitValue
>   Correct OutputAnalyzerTest

Marked as reviewed by lmesnik (Reviewer).

Please update copyrights in the test file, otherwise, the last version looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/9247

From naoto at openjdk.org  Thu Jun 23 18:34:59 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 18:34:59 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative [v2]
In-Reply-To: <eutM8HrHbHOjaTtUR2OS-Qa5fhzzl36hoFWJMo4Bwus=.50e73a67-43ea-4715-9c1e-d8491b70bb15@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
 <eutM8HrHbHOjaTtUR2OS-Qa5fhzzl36hoFWJMo4Bwus=.50e73a67-43ea-4715-9c1e-d8491b70bb15@github.com>
Message-ID: <vWPYSwGhvSj6gZNpXOvIPoEC7bevZu0aAuD_OuN9ADk=.0abe92c2-d1da-4ce9-8805-7d8719da2389@github.com>

On Thu, 23 Jun 2022 14:09:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
>> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
>> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
>> 
>> Exception messages should not include newlines.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to shouldNotHaveExitValue
>   Correct OutputAnalyzerTest

LGTM. Thanks for the change.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9247

From aturbanov at openjdk.org  Thu Jun 23 18:42:17 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 23 Jun 2022 18:42:17 GMT
Subject: RFR: 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN fields
 static in ProcessHandleImpl
Message-ID: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>

Fields `STARTTIME_ANY` and `STARTTIME_PROCESS_UNKNOWN` are actually unused, but they are useful as documentation on the interface to native.
Make them `static` to reduce memory usage.

-------------

Commit messages:
 - [PATCH] Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN fields static in ProcessHandleImpl

Changes: https://git.openjdk.org/jdk/pull/9196/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9196&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289078
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9196.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9196/head:pull/9196

PR: https://git.openjdk.org/jdk/pull/9196

From djelinski at openjdk.org  Thu Jun 23 18:49:37 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 18:49:37 GMT
Subject: Integrated: 8288979: Improve CLDRConverter run time
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <WnG_9rwqqvOULJk3UsgLKos5VRGF7GBxFMx54yxuqK8=.84b5fb49-b93e-484b-9ae7-3bddb2a5b823@github.com>

On Wed, 22 Jun 2022 14:24:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

This pull request has now been integrated.

Changeset: c8cc94a3
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8cc94a38423c0cef597986fb51938a26dc20b51
Stats:     100 lines in 1 file changed: 55 ins; 27 del; 18 mod

8288979: Improve CLDRConverter run time

Reviewed-by: naoto, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/9243

From rriggs at openjdk.org  Thu Jun 23 19:01:47 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Jun 2022 19:01:47 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative [v3]
In-Reply-To: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
Message-ID: <riheHqyM2HwxPY85Bh3dNuV0IbaByfuh0SlU7JTnvcQ=.bf689456-ebe2-4cbe-9259-a46ee9b2a4cd@github.com>

> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
> 
> Exception messages should not include newlines.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Copyright update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9247/files
  - new: https://git.openjdk.org/jdk/pull/9247/files/e73bf2bd..a46b4065

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9247.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9247/head:pull/9247

PR: https://git.openjdk.org/jdk/pull/9247

From jpai at openjdk.org  Fri Jun 24 01:13:40 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 24 Jun 2022 01:13:40 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative [v3]
In-Reply-To: <riheHqyM2HwxPY85Bh3dNuV0IbaByfuh0SlU7JTnvcQ=.bf689456-ebe2-4cbe-9259-a46ee9b2a4cd@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
 <riheHqyM2HwxPY85Bh3dNuV0IbaByfuh0SlU7JTnvcQ=.bf689456-ebe2-4cbe-9259-a46ee9b2a4cd@github.com>
Message-ID: <-KHGsoLC991hOhQ4nnQIBhfAH-3xHsJmqMB56uJBhqI=.0e308ee2-9cb4-4d91-ac7f-e36ce5fd3984@github.com>

On Thu, 23 Jun 2022 19:01:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
>> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
>> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
>> 
>> Exception messages should not include newlines.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9247

From darcy at openjdk.org  Fri Jun 24 01:43:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Jun 2022 01:43:45 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v33]
In-Reply-To: <568BhbvXIaBNTp04x8mcXGtcDaZ0q3FNGe5-1V9EvP8=.fc1b8166-fb80-40a6-af98-2c728b9d894c@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <_oo66oJSObuUoMgeH0Zifx35QNZ7A0-UpVkPRwecJoA=.3aed9989-1eb0-4aac-8bd7-76627c334f9e@github.com>
 <568BhbvXIaBNTp04x8mcXGtcDaZ0q3FNGe5-1V9EvP8=.fc1b8166-fb80-40a6-af98-2c728b9d894c@github.com>
Message-ID: <v2GcUu8PfZwCdFqBZIDbIVn-8z7xjymcBj-YZQrcnZY=.189d2541-01bf-4f41-960e-a47de201f204@github.com>

On Thu, 23 Jun 2022 14:37:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove implSpec tag from Executable.accessFlags since the class is sealed.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 335:
> 
>> 333:             if ((mask &  accessMask) != 0) {
>> 334:                 result.add(accessFlag);
>> 335:                 mask = mask & ~accessMask;
> 
> The removal of the flag from the masks as they are added to set works only if there is a unique mask bit per location.
> (In the future, Valhalla, the same bit mask for more than one AccessFlag can appear in a single Location.)
> Removing flag bits from a copy of the input mask can have the desired effect.

Once the same bit position has multiple purposes for the same construct, there will need to be some kind of expansion of the bits -> Set<AccessFlag> API to accept more context to make the disambiguation possible.

As part of that future work, I've filed

    JDK-8289106: Add model of class file versions to core reflection

The class file model would be conceptually similar to the javax.lang.model.SourceVersion enum.

I'd expect an overload of the maskToAccessFlags method that took a ClassFileFormat parameter to drive the disambiguation.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From dholmes at openjdk.org  Fri Jun 24 05:05:46 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Jun 2022 05:05:46 GMT
Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more
 informative [v3]
In-Reply-To: <riheHqyM2HwxPY85Bh3dNuV0IbaByfuh0SlU7JTnvcQ=.bf689456-ebe2-4cbe-9259-a46ee9b2a4cd@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
 <riheHqyM2HwxPY85Bh3dNuV0IbaByfuh0SlU7JTnvcQ=.bf689456-ebe2-4cbe-9259-a46ee9b2a4cd@github.com>
Message-ID: <aJDe5eWybLJhBIzAVYpbDJM5dljzi1innBNruC_77hQ=.78faffc8-59f4-4654-bf2f-f8c14d33cb09@github.com>

On Thu, 23 Jun 2022 19:01:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
>> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
>> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
>> 
>> Exception messages should not include newlines.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9247

From jpai at openjdk.org  Fri Jun 24 06:47:46 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 24 Jun 2022 06:47:46 GMT
Subject: RFR: 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN
 fields static in ProcessHandleImpl
In-Reply-To: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
References: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
Message-ID: <6jFNJMHVqcnrHTd1vBkCY9UXLX6rEue7xVl2Rd3Enfk=.ba373219-dc60-4b54-9d98-dd0fcf2e522b@github.com>

On Fri, 17 Jun 2022 08:43:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fields `STARTTIME_ANY` and `STARTTIME_PROCESS_UNKNOWN` are actually unused, but they are useful as documentation on the interface to native.
> Make them `static` to reduce memory usage.

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9196

From jpai at openjdk.org  Fri Jun 24 07:25:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 24 Jun 2022 07:25:38 GMT
Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in
 java.time [v2]
In-Reply-To: <YvqHz0tTpqqN-X0evw3C0GdubG6m435J_gvFpVkCZvM=.11697c65-a20e-428d-bc8e-e56d01848b52@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <YvqHz0tTpqqN-X0evw3C0GdubG6m435J_gvFpVkCZvM=.11697c65-a20e-428d-bc8e-e56d01848b52@github.com>
Message-ID: <OoSH2yLNim7NygIHCkn8uasHe92t8v6UqhlH8obgavM=.0011a3ac-a881-4721-b938-073d7ad0c8a1@github.com>

On Wed, 22 Jun 2022 21:29:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288723: Avoid redundant ConcurrentHashMap.get call in java.time
>   use computeIfAbsent where lambda could be short and static

src/java.base/share/classes/java/time/temporal/WeekFields.java line 331:

> 329:         String key = firstDayOfWeek.toString() + minimalDaysInFirstWeek;
> 330:         WeekFields rules = CACHE.get(key);
> 331:         if (rules == null) {

Perhaps you don't even need this `if` block and the preceding `CACHE.get(key)` and maybe it can be replaced with:


return CACHE.computeIfAbsent(key, ignore -> new WeekFields(firstDayOfWeek, minimalDaysInFirstWeek));

-------------

PR: https://git.openjdk.org/jdk/pull/9208

From lancea at openjdk.org  Fri Jun 24 10:44:02 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Jun 2022 10:44:02 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <1ckyd2CtHpn1rHvV7b914_tXO5TGyEyisQ5zhEeogZ8=.ce9d6888-5597-4bd7-9c57-409d00d39cfa@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <1ckyd2CtHpn1rHvV7b914_tXO5TGyEyisQ5zhEeogZ8=.ce9d6888-5597-4bd7-9c57-409d00d39cfa@github.com>
Message-ID: <rD6jcDzF0NmgyR3TwEhpurDXWwrDst9SSbdBFm3otI4=.bac25390-eb44-4339-9eb3-a0c8a77e51d8@github.com>

On Thu, 23 Jun 2022 08:05:42 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1202:
> 
>> 1200:      */
>> 1201:     public boolean exists(Path path, LinkOption... options) {
>> 1202:         try {
> 
> Overall, I think that this is a great change (avoiding the need for various parts of the system to communicate through exceptions).
> 
> Trivially, and easily, I often find it useful to add mock-like tests for these specified implementations (implSpec), i.e. just subclass FSP mocking out the abstract methods to ensure that the default implementations invoke the appropriate ones.

Thank you for the suggestion Chris

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From lancea at openjdk.org  Fri Jun 24 10:44:05 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Jun 2022 10:44:05 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <I-ppIZSAK4brd84-OgItZPnleOjCRlcl2SgHMOmDc9I=.ecc9fea8-35e9-40b0-99da-0d93a3e9e01d@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <I-ppIZSAK4brd84-OgItZPnleOjCRlcl2SgHMOmDc9I=.ecc9fea8-35e9-40b0-99da-0d93a3e9e01d@github.com>
Message-ID: <SRuEjy1ZbnFOmhQL9bXvTK1i0kXWfkdYbq6b0GmWIw8=.37d9fe4c-ecf5-4f55-9fe8-e82c98b79d59@github.com>

On Wed, 22 Jun 2022 22:26:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1236:
> 
>> 1234:      * atomic operation with respect to other file system operations.
>> 1235:      *
>> 1236:      *  @implSpec
> 
> One more bad indentation.

fixed in next push

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From lancea at openjdk.org  Fri Jun 24 10:44:08 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Jun 2022 10:44:08 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <taLnH5D0kcjcyoCbgSdY6DC5S2IOli1noHXIRU7u91o=.d8d04a00-74c2-4b49-88e6-e3d97886a220@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <taLnH5D0kcjcyoCbgSdY6DC5S2IOli1noHXIRU7u91o=.d8d04a00-74c2-4b49-88e6-e3d97886a220@github.com>
Message-ID: <rR1rRsQwWAJWs2t1nAjYkL_IKoZovw-Exiej5_FJq-Q=.3dc26b1d-032c-4af2-bee4-b9a0e009b505@github.com>

On Thu, 23 Jun 2022 10:55:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java line 306:
> 
>> 304:                     case WRITE -> w = true;
>> 305:                     case EXECUTE -> x = true;
>> 306:                     default -> throw new AssertionError("Should not get here");
> 
> The switch should be exhaustive so I assume the default case is not required here.

Addressed in next push

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 302:
> 
>> 300:         throws IOException
>> 301:     {
>> 302:         return exists(path) ? readAttributes(path, type, options) : null;
> 
> If you add the following to ZipPath then it would allow you to implement it in one step rather than two:
> 
> 
> ZipFileAttributes readAttributesIfExits() throws IOException {
>     return zfs.getFileAttributes(getResolvedPath());
>  }

Added the proposed change above, Mach5 tiers 1-3 continue to be clean

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From alanb at openjdk.org  Fri Jun 24 13:06:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Jun 2022 13:06:51 GMT
Subject: RFR: 8247407: tools/jlink/plugins/CompressorPluginTest.java test
 failing
In-Reply-To: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
References: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
Message-ID: <9eQkwQsadX-C-oRTb-qHYgsqsyL1WWmYYJaBG4Pw3SU=.0b6ad728-8d11-4542-87d0-919f8dc165f1@github.com>

On Thu, 23 Jun 2022 12:59:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes an issue in `jdk.internal.jimage.ImageReader`? 
> 
> The `ImageReader` maintains a map of `nodes` which it uses to keep track of directories/resources from within the image. When a `findNode` is called, it leads to building the `Node` if the node isn't present in the map or if isn't complete (i.e. if the directory's immediate child nodes haven't been built). During this building of nodes, the code can end up creating a directory node and then visiting the child resources to create nodes for those resources. While doing so, the code currently doesn't check if a (child) node for the resource was already created previously (during a different call) and added to the parent directory's `children` list. As a result, it ends up adding the child node more than once.
> 
> One way to solve this would have been to make the `children` in `Directory` be a `Set`. I suspect it's currently a `List` so as to keep track of the order? If we did make it a `Set`, we could still keep the order using a `LinkedHashSet`. But changing this to a `Set` doesn't look feasible because there's a `List<Node> getChildren()` API on `Directory`, which would then have to create a copy of the `Set` to return as a `List`.
> 
> The commit in this PR instead prevents adding the child more than once by checking the `nodes` map for the presence of the child. This new check is added only for "resources" and not directories, because `makeDirectory` already skips a `Node` creation if the `nodes` has the corresponding entry (line 564 in the current PR).
> Additionally an `assert` has been added to `addChild` of `Directory`.
> 
> A new jtreg test has been added which reproduces the issue without this change and verifies the fix.
> 
> This part of the code is very new to me, so if there's anything more to be considered, then please let me know.
> 
> tier1, tier2, tier3 testing is currently in progress.

Good sleuthing!

-------------

PR: https://git.openjdk.org/jdk19/pull/60

From rriggs at openjdk.org  Fri Jun 24 13:48:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Jun 2022 13:48:40 GMT
Subject: RFR: 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN
 fields static in ProcessHandleImpl
In-Reply-To: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
References: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
Message-ID: <hVY2d7G5xMUxgrRMfK3n5DrLwK928_2w-1Yi85eLfU8=.8fa8d80e-f1e1-467a-9f8f-78c4d64d2bd7@github.com>

On Fri, 17 Jun 2022 08:43:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fields `STARTTIME_ANY` and `STARTTIME_PROCESS_UNKNOWN` are actually unused, but they are useful as documentation on the interface to native.
> Make them `static` to reduce memory usage.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9196

From rriggs at openjdk.org  Fri Jun 24 13:50:59 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Jun 2022 13:50:59 GMT
Subject: Integrated: 8288495: [test] Make OutputAnalyzer exception more
 informative
In-Reply-To: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
References: <s7Y_3ar9pgTB84_QPb5aVIUsIYa3nZEOMy4rFmzuuvo=.0f1daaed-7ffc-4ddc-994b-11dc923ff728@github.com>
Message-ID: <TxCdVqKV3i-G-pX-plaMQ9xU616T3tRhXOfEicVq3EE=.938674bb-c4c8-4ad1-b058-8e8955aad105@github.com>

On Wed, 22 Jun 2022 18:19:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values.
> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value.  
> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr.  Including both expected and actual values in the exception makes it easier to understand.
> 
> Exception messages should not include newlines.

This pull request has now been integrated.

Changeset: fdc8455c
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fdc8455c4559a5513c46cb61bdf09f8279d44192
Stats:     47 lines in 2 files changed: 27 ins; 1 del; 19 mod

8288495: [test] Make OutputAnalyzer exception more informative

Reviewed-by: lmesnik, naoto, jpai, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/9247

From bpb at openjdk.org  Fri Jun 24 14:41:57 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Jun 2022 14:41:57 GMT
Subject: RFR: 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN
 fields static in ProcessHandleImpl
In-Reply-To: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
References: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
Message-ID: <bEGVShG0ihAH63G06vDpmS-C62qWdAKWrdetTICT6h0=.f13ec952-9db4-422b-a909-ee3d3d8330f9@github.com>

On Fri, 17 Jun 2022 08:43:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fields `STARTTIME_ANY` and `STARTTIME_PROCESS_UNKNOWN` are actually unused, but they are useful as documentation on the interface to native.
> Make them `static` to reduce memory usage.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9196

From naoto at openjdk.org  Fri Jun 24 17:41:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Jun 2022 17:41:55 GMT
Subject: RFR: 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN
 fields static in ProcessHandleImpl
In-Reply-To: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
References: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
Message-ID: <F-lpfcvS3-sgGjgTYY7P5ojgxrOLry1ZITzl4pxVPok=.85829485-2033-4c4b-97dc-f5dd08dfbf50@github.com>

On Fri, 17 Jun 2022 08:43:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fields `STARTTIME_ANY` and `STARTTIME_PROCESS_UNKNOWN` are actually unused, but they are useful as documentation on the interface to native.
> Make them `static` to reduce memory usage.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9196

From dcubed at openjdk.org  Fri Jun 24 18:49:46 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 24 Jun 2022 18:49:46 GMT
Subject: RFR: 8247407: tools/jlink/plugins/CompressorPluginTest.java test
 failing
In-Reply-To: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
References: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
Message-ID: <P_LCNtjudzV5RkzjOq435zS_g3zs9jsaBUx7ktmIYms=.3582e76b-a330-4d75-995e-f6ea48925ae4@github.com>

On Thu, 23 Jun 2022 12:59:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes an issue in `jdk.internal.jimage.ImageReader`? 
> 
> The `ImageReader` maintains a map of `nodes` which it uses to keep track of directories/resources from within the image. When a `findNode` is called, it leads to building the `Node` if the node isn't present in the map or if isn't complete (i.e. if the directory's immediate child nodes haven't been built). During this building of nodes, the code can end up creating a directory node and then visiting the child resources to create nodes for those resources. While doing so, the code currently doesn't check if a (child) node for the resource was already created previously (during a different call) and added to the parent directory's `children` list. As a result, it ends up adding the child node more than once.
> 
> One way to solve this would have been to make the `children` in `Directory` be a `Set`. I suspect it's currently a `List` so as to keep track of the order? If we did make it a `Set`, we could still keep the order using a `LinkedHashSet`. But changing this to a `Set` doesn't look feasible because there's a `List<Node> getChildren()` API on `Directory`, which would then have to create a copy of the `Set` to return as a `List`.
> 
> The commit in this PR instead prevents adding the child more than once by checking the `nodes` map for the presence of the child. This new check is added only for "resources" and not directories, because `makeDirectory` already skips a `Node` creation if the `nodes` has the corresponding entry (line 564 in the current PR).
> Additionally an `assert` has been added to `addChild` of `Directory`.
> 
> A new jtreg test has been added which reproduces the issue without this change and verifies the fix.
> 
> This part of the code is very new to me, so if there's anything more to be considered, then please let me know.
> 
> tier1, tier2, tier3 testing is currently in progress.

This bug has gotten rather noisy in the last few days. We're up to 7 sightings
in < 24 hours. I'm going to ProblemList this test again in order to reduce the
noise in the JDK20 CI for this upcoming weekend.

-------------

PR: https://git.openjdk.org/jdk19/pull/60

From duke at openjdk.org  Fri Jun 24 18:54:21 2022
From: duke at openjdk.org (rmartinc)
Date: Fri, 24 Jun 2022 18:54:21 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit
Message-ID: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>

Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895).

Any `LimitExceededException` now quits the referral loop.

Added class `ReferralLimitSearchTest`. It is a simple jtreg test which checks that `java.naming.ldap.referral.limit` is really enforced. The dummy ldap server always returns a referral for any search query. If the number of searches exceeds the limit, it throws an `IOException` and the test fails.


make test TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java

-------------

Commit messages:
 - 8288895: LdapContext doesn't honor set referrals limit

Changes: https://git.openjdk.org/jdk/pull/9256/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9256&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288895
  Stats: 183 lines in 2 files changed: 176 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9256.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9256/head:pull/9256

PR: https://git.openjdk.org/jdk/pull/9256

From bpb at openjdk.org  Fri Jun 24 19:14:41 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Jun 2022 19:14:41 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <1qiIHaDvqIOqcxO0EybhwUiHd7dp0ujZUxTw1JHEhOQ=.56b7421b-f95a-4702-ace4-b36128811445@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <Dho3DWC5sQTgYpk2EhWDIMz6cm19GdQS5Z3gjiLR05E=.578cdb7b-9e2b-4d2d-8773-5ebf63d3372e@github.com>
 <1qiIHaDvqIOqcxO0EybhwUiHd7dp0ujZUxTw1JHEhOQ=.56b7421b-f95a-4702-ace4-b36128811445@github.com>
Message-ID: <9wcML2Y3kBIA79rKn1H2Tf3gDpeugH90j-Wh02aXd2M=.8e86d8e4-0061-4709-94ee-1fe2c5bae2ec@github.com>

On Thu, 23 Jun 2022 07:18:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 80:
>> 
>>> 78:     static UnixFileAttributes getIfExists(UnixPath path) throws UnixException {
>>> 79:         UnixFileAttributes attrs = new UnixFileAttributes();
>>> 80:         int errno = UnixNativeDispatcher.stat2(path, attrs);
>> 
>> I think that this is the only use of `stat2()`. It could be deleted if this method were replaced with this:
>> 
>> 
>>     static UnixFileAttributes getIfExists(UnixPath path) throws UnixException {
>>         UnixFileAttributes attrs = new UnixFileAttributes();
>>         try {
>>             UnixNativeDispatcher.stat(path, attrs);
>>             return attrs;
>>         } catch (UnixException e) {
>>             if (e.errno() == UnixConstants.ENOENT) {
>>                 return null;
>>             }
>>             throw e;
>>         }
>>     }
>
>> I think that this is the only use of `stat2()`. It could be deleted if this method were replaced with this:
> 
> The purpose of these additions to the SPI is to improve the performance of user facing methods that don't throw an exception when the file doesn't exist. It needs a stat/equivalent that doesn't throw so this is the reason for stat2. The equivalent on Windows will need to added too.

Understood.

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From dcubed at openjdk.org  Fri Jun 24 19:17:50 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 24 Jun 2022 19:17:50 GMT
Subject: Integrated: 8289166: ProblemList
 tools/jlink/plugins/CompressorPluginTest.java
Message-ID: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com>

A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java.

-------------

Commit messages:
 - 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java

Changes: https://git.openjdk.org/jdk/pull/9285/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9285&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289166
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9285.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9285/head:pull/9285

PR: https://git.openjdk.org/jdk/pull/9285

From lmesnik at openjdk.org  Fri Jun 24 19:17:50 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 Jun 2022 19:17:50 GMT
Subject: Integrated: 8289166: ProblemList
 tools/jlink/plugins/CompressorPluginTest.java
In-Reply-To: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com>
References: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com>
Message-ID: <gg8MUy_rjYi36wpXFIBQitX2t3HFx5ekF1n0pH4b5CA=.85fdfa8c-5713-413b-84c0-a41f49cc4e6f@github.com>

On Fri, 24 Jun 2022 18:51:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9285

From bpb at openjdk.org  Fri Jun 24 19:17:51 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Jun 2022 19:17:51 GMT
Subject: Integrated: 8289166: ProblemList
 tools/jlink/plugins/CompressorPluginTest.java
In-Reply-To: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com>
References: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com>
Message-ID: <p4lXNj_5dIbTDQF67nXwghTc7lnZDqtMR4v58Az15QI=.fb8908d4-fd71-4ee6-994b-e95a46feceb6@github.com>

On Fri, 24 Jun 2022 18:51:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9285

From dcubed at openjdk.org  Fri Jun 24 19:17:52 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 24 Jun 2022 19:17:52 GMT
Subject: Integrated: 8289166: ProblemList
 tools/jlink/plugins/CompressorPluginTest.java
In-Reply-To: <gg8MUy_rjYi36wpXFIBQitX2t3HFx5ekF1n0pH4b5CA=.85fdfa8c-5713-413b-84c0-a41f49cc4e6f@github.com>
References: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com>
 <gg8MUy_rjYi36wpXFIBQitX2t3HFx5ekF1n0pH4b5CA=.85fdfa8c-5713-413b-84c0-a41f49cc4e6f@github.com>
Message-ID: <I_v2nf4dSIidToLvLKz24diKjAryu3-_C-gB7Q40N54=.91c6218a-f9c8-4e75-a303-b5a87a05654b@github.com>

On Fri, 24 Jun 2022 18:54:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java.
>
> Marked as reviewed by lmesnik (Reviewer).

@lmesnik and @bplb - Thanks for the lightning fast reviews!

-------------

PR: https://git.openjdk.org/jdk/pull/9285

From dcubed at openjdk.org  Fri Jun 24 19:17:53 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 24 Jun 2022 19:17:53 GMT
Subject: Integrated: 8289166: ProblemList
 tools/jlink/plugins/CompressorPluginTest.java
In-Reply-To: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com>
References: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com>
Message-ID: <PXD9sCv6l0FKzi3K_TWz5lrfgv3jG2BJpYIPOAtFqfg=.45c9019c-4ce9-4731-9e25-fdfe4a16e17a@github.com>

On Fri, 24 Jun 2022 18:51:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java.

This pull request has now been integrated.

Changeset: 08288819
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08288819dd915549d17af40b159233a0550db643
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java

Reviewed-by: lmesnik, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/9285

From dcubed at openjdk.org  Fri Jun 24 19:22:41 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 24 Jun 2022 19:22:41 GMT
Subject: RFR: 8247407: tools/jlink/plugins/CompressorPluginTest.java test
 failing
In-Reply-To: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
References: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
Message-ID: <iC6VsxTB-l42p7lwNp8aeKno770bOJNiDlw5MxKtspM=.55c87b40-0a68-4ae4-9957-e4590c59c45d@github.com>

On Thu, 23 Jun 2022 12:59:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes an issue in `jdk.internal.jimage.ImageReader`? 
> 
> The `ImageReader` maintains a map of `nodes` which it uses to keep track of directories/resources from within the image. When a `findNode` is called, it leads to building the `Node` if the node isn't present in the map or if isn't complete (i.e. if the directory's immediate child nodes haven't been built). During this building of nodes, the code can end up creating a directory node and then visiting the child resources to create nodes for those resources. While doing so, the code currently doesn't check if a (child) node for the resource was already created previously (during a different call) and added to the parent directory's `children` list. As a result, it ends up adding the child node more than once.
> 
> One way to solve this would have been to make the `children` in `Directory` be a `Set`. I suspect it's currently a `List` so as to keep track of the order? If we did make it a `Set`, we could still keep the order using a `LinkedHashSet`. But changing this to a `Set` doesn't look feasible because there's a `List<Node> getChildren()` API on `Directory`, which would then have to create a copy of the `Set` to return as a `List`.
> 
> The commit in this PR instead prevents adding the child more than once by checking the `nodes` map for the presence of the child. This new check is added only for "resources" and not directories, because `makeDirectory` already skips a `Node` creation if the `nodes` has the corresponding entry (line 564 in the current PR).
> Additionally an `assert` has been added to `addChild` of `Directory`.
> 
> A new jtreg test has been added which reproduces the issue without this change and verifies the fix.
> 
> This part of the code is very new to me, so if there's anything more to be considered, then please let me know.
> 
> tier1, tier2, tier3 testing is currently in progress.

@jaikiran - The test has been ProblemListed again. Please merge jdk/jdk into this PR
and then redo your change to remove the test from the ProblemList. This PR is in kind
of a weird state because it currently contains a change to remove the test from the
ProblemList, but you later did that change separately for diagnostic purposes and did
not update this PR after that change was made. I'm reasonable certain that GitHub will
resolve the situation correctly when you merge jdk/jdk into this PR.

-------------

PR: https://git.openjdk.org/jdk19/pull/60

From darcy at openjdk.org  Fri Jun 24 20:28:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Jun 2022 20:28:11 GMT
Subject: RFR: 8288596: Random:from() adapter does not delegate to supplied
 generator in all cases
In-Reply-To: <5VcKHDxn2sRglNaWKpiccebi2CohEde0Mb8JOSQh8m4=.892e04a0-3659-48a3-8776-aebb46d63757@github.com>
References: <5VcKHDxn2sRglNaWKpiccebi2CohEde0Mb8JOSQh8m4=.892e04a0-3659-48a3-8776-aebb46d63757@github.com>
Message-ID: <TOiqb7F8LQ6w0LjKF9k5kOQMtkaiqTJfEKjG7r0J-dA=.450291c9-b695-4d5c-8ed5-47e47f989c6c@github.com>

On Fri, 17 Jun 2022 16:44:30 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

> Extend delegation by instance returned by Random.from() to all methods exposed by RandomGenerator.

Looks fine. I agree this implementation is more in keeping with the intent of the specification.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/36

From darcy at openjdk.org  Fri Jun 24 20:31:01 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Jun 2022 20:31:01 GMT
Subject: RFR: 8288021: Add hard test cases to
 jdk.internal.math.DoubleToDecimalChecker
In-Reply-To: <09ta5J6B7B3tppzLNexTDnumh-XBIs629Q7saT4o70E=.7354d628-33e3-4602-ab97-6830c306c5c1@github.com>
References: <09ta5J6B7B3tppzLNexTDnumh-XBIs629Q7saT4o70E=.7354d628-33e3-4602-ab97-6830c306c5c1@github.com>
Message-ID: <3OZU8p52TGJIbmRHYQjGO_xcHn40wHvm0PWS-XElHuA=.ae228ac5-9e9f-4b5d-9d79-989b3ef8226b@github.com>

On Wed, 8 Jun 2022 13:12:09 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

> These 19'545 doubles were generated on purpose by Paul Zimmermann of INRIA as hard test cases.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9084

From iris at openjdk.org  Fri Jun 24 20:34:55 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 24 Jun 2022 20:34:55 GMT
Subject: RFR: 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN
 fields static in ProcessHandleImpl
In-Reply-To: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
References: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
Message-ID: <lzLIbo4VgxduUrpXWt5uFoRkt6BeLKJG6NavGnu_EEc=.d57ac8f0-80eb-40c2-bc54-54ae3809e76f@github.com>

On Fri, 17 Jun 2022 08:43:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fields `STARTTIME_ANY` and `STARTTIME_PROCESS_UNKNOWN` are actually unused, but they are useful as documentation on the interface to native.
> Make them `static` to reduce memory usage.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9196

From bpb at openjdk.org  Fri Jun 24 20:40:51 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Jun 2022 20:40:51 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v6]
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <_Vn69ZLtENi_Y0SQSPeUBeJMjQSAXriiNihgJL5sao8=.7c5247a7-af31-4649-a5d8-fcdba89cab6a@github.com>

> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

Brian Burkhalter has updated the pull request 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:

 - 6478546: Use dynamically sized temporary direct buffers
 - Merge
 - Merge
 - 6478546: Add break in write loop on ExceptionOccurred
 - Merge
 - 6478546: Clean up io_util.c
 - Merge
 - 6478546: Decrease malloc'ed buffer maximum size to 64 kB
 - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8235/files
  - new: https://git.openjdk.org/jdk/pull/8235/files/00521485..e6f3b457

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8235&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8235&range=04-05

  Stats: 39139 lines in 1021 files changed: 15199 ins; 12013 del; 11927 mod
  Patch: https://git.openjdk.org/jdk/pull/8235.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8235/head:pull/8235

PR: https://git.openjdk.org/jdk/pull/8235

From bpb at openjdk.org  Fri Jun 24 20:40:58 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Jun 2022 20:40:58 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v5]
In-Reply-To: <iP7AX78NRh96ngXdhMgAODuDwjuuPUBxdJ6FJ01Rp8U=.2770e2b5-43af-46a1-bd58-7dea630bcdab@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <iP7AX78NRh96ngXdhMgAODuDwjuuPUBxdJ6FJ01Rp8U=.2770e2b5-43af-46a1-bd58-7dea630bcdab@github.com>
Message-ID: <ZqWZ9w2t-kwpR7SEyDDOse_Jt8HocEa1f0yHnCrdQLc=.367b671d-1436-4fe2-b418-948f8191dd3b@github.com>

On Thu, 9 Jun 2022 18:38:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.
>
> Brian Burkhalter has updated the pull request 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
>  - 6478546: Add break in write loop on ExceptionOccurred
>  - Merge
>  - 6478546: Clean up io_util.c
>  - Merge
>  - 6478546: Decrease malloc'ed buffer maximum size to 64 kB
>  - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

The following benchmark results are for commit e6f3b4574b1c49955e5acaca618a3083eb132e05 with 5 warmup iterations of 5 seconds each, followed by 10 measurement iterations of 10 seconds each on a MacBookPro16,1.

           FileInputStream.read(byte[])

                   Score (ops/s)
(length)       Master              Branch
16384      5850.383 ? 220.209  5805.952 ? 187.870
32768      5781.410 ? 345.939  5807.587 ? 515.808
100000     5444.167 ? 409.680  5273.988 ? 159.652
500000     3748.413 ?  88.505  3803.577 ? 256.442
1000000    2647.356 ? 145.245  2700.523 ?  97.717
1048576    2759.337 ? 362.618  2631.779 ?  45.971
10485760    338.840 ?   2.706   392.126 ?   2.59
251503002    10.626 ?   0.024    20.165 ?   0.091
524288000     5.134 ?   0.024     9.826 ?   0.068
1000000000    1.806 ?   0.014     5.194 ?   0.015

           FileOutputStream.write(byte[])

                   Score (ops/s)
(length)       Master              Branch
16384      2736.489 ?  31.547  2599.203 ?  79.392
32768      2656.471 ?  72.597  2523.470 ? 158.460
100000     2476.514 ?  46.392  2225.597 ? 442.285
500000     1606.205 ? 487.787  1281.550 ? 413.797
1000000    1125.265 ?  13.969   812.184 ? 232.23
1048576    1098.608 ?  13.528   816.657 ? 218.112
10485760    136.867 ?   2.310   153.137 ?   2.93
251503002     7.266 ?   0.026    10.546 ?   0.125
524288000     3.450 ?   0.016     3.880 ?   1.355
1000000000    1.178 ?   0.007     2.637 ?   0.505


The proposed change is approximately at parity with the current code base for smaller lengths, but has higher throughput for larger lengths, at least for reading. In all cases where the length is greater than or equal to 65536 (64 KiB) or is a multiple of 8192 (8 KiB), less native memory is allocated.

-------------

PR: https://git.openjdk.org/jdk/pull/8235

From jpai at openjdk.org  Sat Jun 25 02:45:54 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 25 Jun 2022 02:45:54 GMT
Subject: RFR: 8247407: tools/jlink/plugins/CompressorPluginTest.java test
 failing [v2]
In-Reply-To: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
References: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
Message-ID: <UUlIeXXJRRIcZ5kB2-TtfYeYbkVm0C9fY3K8QnVX0No=.03f34e32-7769-4524-bf5f-9c81a7a5389d@github.com>

> Can I please get a review for this change which fixes an issue in `jdk.internal.jimage.ImageReader`? 
> 
> The `ImageReader` maintains a map of `nodes` which it uses to keep track of directories/resources from within the image. When a `findNode` is called, it leads to building the `Node` if the node isn't present in the map or if isn't complete (i.e. if the directory's immediate child nodes haven't been built). During this building of nodes, the code can end up creating a directory node and then visiting the child resources to create nodes for those resources. While doing so, the code currently doesn't check if a (child) node for the resource was already created previously (during a different call) and added to the parent directory's `children` list. As a result, it ends up adding the child node more than once.
> 
> One way to solve this would have been to make the `children` in `Directory` be a `Set`. I suspect it's currently a `List` so as to keep track of the order? If we did make it a `Set`, we could still keep the order using a `LinkedHashSet`. But changing this to a `Set` doesn't look feasible because there's a `List<Node> getChildren()` API on `Directory`, which would then have to create a copy of the `Set` to return as a `List`.
> 
> The commit in this PR instead prevents adding the child more than once by checking the `nodes` map for the presence of the child. This new check is added only for "resources" and not directories, because `makeDirectory` already skips a `Node` creation if the `nodes` has the corresponding entry (line 564 in the current PR).
> Additionally an `assert` has been added to `addChild` of `Directory`.
> 
> A new jtreg test has been added which reproduces the issue without this change and verifies the fix.
> 
> This part of the code is very new to me, so if there's anything more to be considered, then please let me know.
> 
> tier1, tier2, tier3 testing is currently in progress.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge latest from jdk19 master
 - 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist
 - 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/60/files
  - new: https://git.openjdk.org/jdk19/pull/60/files/40bc7db8..8a9aa702

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=60&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=60&range=00-01

  Stats: 443 lines in 21 files changed: 272 ins; 105 del; 66 mod
  Patch: https://git.openjdk.org/jdk19/pull/60.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/60/head:pull/60

PR: https://git.openjdk.org/jdk19/pull/60

From jlaskey at openjdk.org  Sat Jun 25 07:50:57 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 25 Jun 2022 07:50:57 GMT
Subject: RFR: 8247407: tools/jlink/plugins/CompressorPluginTest.java test
 failing [v2]
In-Reply-To: <UUlIeXXJRRIcZ5kB2-TtfYeYbkVm0C9fY3K8QnVX0No=.03f34e32-7769-4524-bf5f-9c81a7a5389d@github.com>
References: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
 <UUlIeXXJRRIcZ5kB2-TtfYeYbkVm0C9fY3K8QnVX0No=.03f34e32-7769-4524-bf5f-9c81a7a5389d@github.com>
Message-ID: <mN3KTsf1PTiljNQoueQut_q7Lgbh_iLLKCidBWGCIHQ=.29a234af-7a68-4418-a602-78407f857d55@github.com>

On Sat, 25 Jun 2022 02:45:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which fixes an issue in `jdk.internal.jimage.ImageReader`? 
>> 
>> The `ImageReader` maintains a map of `nodes` which it uses to keep track of directories/resources from within the image. When a `findNode` is called, it leads to building the `Node` if the node isn't present in the map or if isn't complete (i.e. if the directory's immediate child nodes haven't been built). During this building of nodes, the code can end up creating a directory node and then visiting the child resources to create nodes for those resources. While doing so, the code currently doesn't check if a (child) node for the resource was already created previously (during a different call) and added to the parent directory's `children` list. As a result, it ends up adding the child node more than once.
>> 
>> One way to solve this would have been to make the `children` in `Directory` be a `Set`. I suspect it's currently a `List` so as to keep track of the order? If we did make it a `Set`, we could still keep the order using a `LinkedHashSet`. But changing this to a `Set` doesn't look feasible because there's a `List<Node> getChildren()` API on `Directory`, which would then have to create a copy of the `Set` to return as a `List`.
>> 
>> The commit in this PR instead prevents adding the child more than once by checking the `nodes` map for the presence of the child. This new check is added only for "resources" and not directories, because `makeDirectory` already skips a `Node` creation if the `nodes` has the corresponding entry (line 564 in the current PR).
>> Additionally an `assert` has been added to `addChild` of `Directory`.
>> 
>> A new jtreg test has been added which reproduces the issue without this change and verifies the fix.
>> 
>> This part of the code is very new to me, so if there's anything more to be considered, then please let me know.
>> 
>> tier1, tier2, tier3 testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge latest from jdk19 master
>  - 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist
>  - 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing

LGTM

You'll now have to remove the test from the problem list.

-------------

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/60

From jpai at openjdk.org  Sat Jun 25 12:19:54 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 25 Jun 2022 12:19:54 GMT
Subject: RFR: 8247407: tools/jlink/plugins/CompressorPluginTest.java test
 failing [v2]
In-Reply-To: <UUlIeXXJRRIcZ5kB2-TtfYeYbkVm0C9fY3K8QnVX0No=.03f34e32-7769-4524-bf5f-9c81a7a5389d@github.com>
References: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
 <UUlIeXXJRRIcZ5kB2-TtfYeYbkVm0C9fY3K8QnVX0No=.03f34e32-7769-4524-bf5f-9c81a7a5389d@github.com>
Message-ID: <J4x33ErIH0D6xg_bHk5U1xpbyr-4iCuXsylilbGCsAU=.012cbd84-87ac-4161-a982-5fbb8ac7cac4@github.com>

On Sat, 25 Jun 2022 02:45:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which fixes an issue in `jdk.internal.jimage.ImageReader`? 
>> 
>> The `ImageReader` maintains a map of `nodes` which it uses to keep track of directories/resources from within the image. When a `findNode` is called, it leads to building the `Node` if the node isn't present in the map or if isn't complete (i.e. if the directory's immediate child nodes haven't been built). During this building of nodes, the code can end up creating a directory node and then visiting the child resources to create nodes for those resources. While doing so, the code currently doesn't check if a (child) node for the resource was already created previously (during a different call) and added to the parent directory's `children` list. As a result, it ends up adding the child node more than once.
>> 
>> One way to solve this would have been to make the `children` in `Directory` be a `Set`. I suspect it's currently a `List` so as to keep track of the order? If we did make it a `Set`, we could still keep the order using a `LinkedHashSet`. But changing this to a `Set` doesn't look feasible because there's a `List<Node> getChildren()` API on `Directory`, which would then have to create a copy of the `Set` to return as a `List`.
>> 
>> The commit in this PR instead prevents adding the child more than once by checking the `nodes` map for the presence of the child. This new check is added only for "resources" and not directories, because `makeDirectory` already skips a `Node` creation if the `nodes` has the corresponding entry (line 564 in the current PR).
>> Additionally an `assert` has been added to `addChild` of `Directory`.
>> 
>> A new jtreg test has been added which reproduces the issue without this change and verifies the fix.
>> 
>> This part of the code is very new to me, so if there's anything more to be considered, then please let me know.
>> 
>> tier1, tier2, tier3 testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge latest from jdk19 master
>  - 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist
>  - 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing

Thank you everyone for the reviews.

> You'll now have to remove the test from the problem list.

Hello Jim, this PR includes that removal. Once this PR is integrated and when jdk19 repo gets merged into jdk/jdk, that merge would take care of removing it from the JDK mainline code too.

-------------

PR: https://git.openjdk.org/jdk19/pull/60

From jpai at openjdk.org  Sat Jun 25 12:23:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 25 Jun 2022 12:23:20 GMT
Subject: Integrated: 8247407: tools/jlink/plugins/CompressorPluginTest.java
 test failing
In-Reply-To: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
References: <v66TnbQ1LL87MQ8GTywBbuFzKXHtkOj4tKbgCiNnuoU=.4bea7aa9-900a-4322-ae2e-60164e6147a3@github.com>
Message-ID: <NNELu2JdIkxrq1Oq4nyMZYlROXJOG2bC9WCnB7fkdRs=.457059a8-d9df-4191-b5a2-94d4c50f23e6@github.com>

On Thu, 23 Jun 2022 12:59:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes an issue in `jdk.internal.jimage.ImageReader`? 
> 
> The `ImageReader` maintains a map of `nodes` which it uses to keep track of directories/resources from within the image. When a `findNode` is called, it leads to building the `Node` if the node isn't present in the map or if isn't complete (i.e. if the directory's immediate child nodes haven't been built). During this building of nodes, the code can end up creating a directory node and then visiting the child resources to create nodes for those resources. While doing so, the code currently doesn't check if a (child) node for the resource was already created previously (during a different call) and added to the parent directory's `children` list. As a result, it ends up adding the child node more than once.
> 
> One way to solve this would have been to make the `children` in `Directory` be a `Set`. I suspect it's currently a `List` so as to keep track of the order? If we did make it a `Set`, we could still keep the order using a `LinkedHashSet`. But changing this to a `Set` doesn't look feasible because there's a `List<Node> getChildren()` API on `Directory`, which would then have to create a copy of the `Set` to return as a `List`.
> 
> The commit in this PR instead prevents adding the child more than once by checking the `nodes` map for the presence of the child. This new check is added only for "resources" and not directories, because `makeDirectory` already skips a `Node` creation if the `nodes` has the corresponding entry (line 564 in the current PR).
> Additionally an `assert` has been added to `addChild` of `Directory`.
> 
> A new jtreg test has been added which reproduces the issue without this change and verifies the fix.
> 
> This part of the code is very new to me, so if there's anything more to be considered, then please let me know.
> 
> tier1, tier2, tier3 testing is currently in progress.

This pull request has now been integrated.

Changeset: 9c92da52
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/9c92da5249a04063e8434d20860ccad7146ca507
Stats:     93 lines in 3 files changed: 91 ins; 1 del; 1 mod

8247407: tools/jlink/plugins/CompressorPluginTest.java test failing

Reviewed-by: sundar, jlaskey

-------------

PR: https://git.openjdk.org/jdk19/pull/60

From darcy at openjdk.org  Sat Jun 25 19:08:48 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 25 Jun 2022 19:08:48 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v35]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <zy-fxKanJRubPU3R2jquYM1jdi68GoalDHoudgbu_7M=.2f3776c0-2cec-409d-a71e-eee0b486bbc2@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 53 additional commits since the last revision:

 - Expand testing of Class access flags.
 - Merge branch 'master' into JDK-8266670
 - Merge branch 'master' into JDK-8266670
 - Respond to review feedback from Mandy and Roger.
 - Remove implSpec tag from Executable.accessFlags since the class is sealed.
 - Improve support and tests for Class objects representing arrays and primitives.
 - Expand scope of tests.
 - Merge branch 'master' into JDK-8266670
 - Add module-related tests.
 - Fix typo Exe-Boss spotted in review feedback.
 - ... and 43 more: https://git.openjdk.org/jdk/compare/124dc9b9...e2cccc16

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/63c48284..e2cccc16

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7445&range=33-34

  Stats: 27409 lines in 673 files changed: 8480 ins; 8784 del; 10145 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

From darcy at openjdk.org  Sat Jun 25 19:14:08 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 25 Jun 2022 19:14:08 GMT
Subject: Integrated: JDK-8266670: Better modeling of access flags in core
 reflection
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <1I_sPcCLld8TRI42IdjWeuEH6jEQtbu3UmCYSN_4R0E=.4339318d-ed36-4c89-b4db-115bb1026a5f@github.com>

On Fri, 11 Feb 2022 18:31:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

This pull request has now been integrated.

Changeset: de746714
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de7467146fc3759110299e8297628db2b0b16800
Stats:     1482 lines in 14 files changed: 1466 ins; 2 del; 14 mod

8266670: Better modeling of access flags in core reflection

Reviewed-by: mchung, rriggs, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From jpai at openjdk.org  Sun Jun 26 06:12:00 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 26 Jun 2022 06:12:00 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
Message-ID: <W9Of0GqNNko6YIlXCd69fjw1BEO3AVDoLGZQwu-pjhE=.6c702fec-660a-4a4c-b8d9-473e2a75da43@github.com>

On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
> 
> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.

Hello Daniel, the source code changes look OK to me. The test code changes I haven't finished reviewing yet. A few questions related to the `SelectorManager`:

I realize that the goal of this change is to wakeup the `SelectorManager` from its select operation so that it can then go ahead and exit from its `run()` and in the process shut itself down.

In the `SelectorManager`, I see that when it is potentially woken up, it checks if the `HttpClientImpl` (via its facade) is still referenced and if not, it will trigger the shutdown. That happens here https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java*L1240__;Iw!!ACWV5N9M2RV99hQ!LPXB1B3ZR48hZnBurd3IAPpjL1C9nZu1HeWDVics4nlcZ-NTctHmDdJAydTTm_jRwUtadK2C8vZy_pfZKa4F$ . However, that check is only done if the `select` operation (which was potentially woken up) returns `0` as the number of ready ops. The `Selector.wakeup()` javadoc notes that it's possible that when the selector is woken up, the select operation may return a non-zero value. With the change in this PR where the `HttpClientImpl` has realized that the facade is no longer in use and thus has triggered the `wakeup`, do you think we should shutdown the `SelectorManager` irrespective of what the return value of the `select` operation was? In other words, should that `if (!owner.isReferenced()) {` check in the `SelectorManager` be outside of the `if (n == 0) {` block?

Continuing further, if we do decide that the code in the `SelectorManager` is fine in its current form, do you think we should have an additional `if (!owner.isReferenced()) {` check right at the start of each loop iteration too, something like:

while (!Thread.currentThread().isInterrupted() && !closed) {
    // Check whether client is still alive, and if not,
    // gracefully stop this thread
    if (!owner.isReferenced()) {
        Log.logTrace("{0}: {1}",
                getName(),
                "HttpClient no longer referenced. Exiting...");
        return;
    }
    synchronized (this) {
        ...
    

}

because in its current form, as far as I can see, even if we wakeup the selector eagerly, it's possible that the `select` operation that it was waiting on, might return a non-zero value and we then end up back in that while loop and do another `select` which could then end up waiting for some more seconds (3 seconds by default).

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From alanb at openjdk.org  Sun Jun 26 10:39:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 Jun 2022 10:39:39 GMT
Subject: RFR: 8289079:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with
 "RuntimeException: Test failed"
Message-ID: <BUYLRglrrJy_NePpZsoHs-4UpX7RYkAekVDmwZNOaXU=.b1803969-7a19-424a-b50b-1186a8281e35@github.com>

This is a fix to a recently added test. The test uses pthread_create to create native threads that invoke a Java method via a generated "upcall stub". The upcall stub is created in an implicit memory session but the test doesn't do anything to ensure that the memory session remains open. Testing in higher tiers runs the test with options that sometimes lead to a cleaner closing the memory session before the native threads have terminated. The failure mode is exit code 133 due to a child VM exiting with SIGTRAP. The test needs to be changed to ensure that the memory session is not closed until the threads terminate. To keep it simple, I've changed it to use the global memory session. The alternative is to change it to use a shared session or a reachability fence, coupled with a pthread_join to ensure that all native threads with a reference to stub terminate before the session is closed. The test is intended to exercise concurrent implicit attaching so keeping it as simple as possible
  seems best.

The test is also changed too use shouldHaveExitValue(0) as the original test discarded the child VM exit code when the test failed.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk19/pull/73/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=73&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289079
  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk19/pull/73.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/73/head:pull/73

PR: https://git.openjdk.org/jdk19/pull/73

From lancea at openjdk.org  Sun Jun 26 11:13:58 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 26 Jun 2022 11:13:58 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v2]
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Updates based on review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9249/files
  - new: https://git.openjdk.org/jdk/pull/9249/files/d2bd45c4..37b7462f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=00-01

  Stats: 612 lines in 8 files changed: 603 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9249.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249

PR: https://git.openjdk.org/jdk/pull/9249

From alanb at openjdk.org  Sun Jun 26 13:16:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 Jun 2022 13:16:52 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v2]
In-Reply-To: <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>
Message-ID: <lBYfnG9zAaQ_dYYChCqpVuXwuChFY917ApF-z2m2GNA=.2a42bf65-3d5d-4190-90fc-e095d1542e4f@github.com>

On Sun, 26 Jun 2022 11:13:58 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates based on review feedback

The implementation changes in latest version address my previous points, thanks!  I don't the test as it duplicates most of the existing of the TestProvider in this directory and the naming is inconsistent with the existing tests. I expect you should be able to just extent TestProvider and override the two methods to record that they can been called.

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From lancea at openjdk.org  Sun Jun 26 13:36:34 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 26 Jun 2022 13:36:34 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v2]
In-Reply-To: <lBYfnG9zAaQ_dYYChCqpVuXwuChFY917ApF-z2m2GNA=.2a42bf65-3d5d-4190-90fc-e095d1542e4f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>
 <lBYfnG9zAaQ_dYYChCqpVuXwuChFY917ApF-z2m2GNA=.2a42bf65-3d5d-4190-90fc-e095d1542e4f@github.com>
Message-ID: <lYQFAewhb7no6q9Cj1QEdGvsVRWNBFrZegQtHXDFyCg=.b5e705a1-df46-4993-a963-f490de1e87f3@github.com>

On Sun, 26 Jun 2022 13:13:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The implementation changes in latest version address my previous points, thanks! I don't the test as it duplicates most of the existing of the TestProvider in this directory and the naming is inconsistent with the existing tests. I expect you should be able to just extent TestProvider and override the two methods to record that they can been called.

I thought about using TestProvider and then talked myself out of it.  So yes, I can do that.  If you have a preferred name other than `TestOverRideFSPMethods` please let me know

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From lancea at openjdk.org  Sun Jun 26 13:51:53 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 26 Jun 2022 13:51:53 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v3]
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <_WsFCTuVK9k_tTIbnbxtDE6fOtUuLnxEOT21AxFVZ9E=.fb149471-1241-4595-933c-a547ee7dc468@github.com>

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Switched Test to use TestProvideer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9249/files
  - new: https://git.openjdk.org/jdk/pull/9249/files/37b7462f..6ef8bc1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=01-02

  Stats: 596 lines in 3 files changed: 57 ins; 529 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9249.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249

PR: https://git.openjdk.org/jdk/pull/9249

From alanb at openjdk.org  Sun Jun 26 17:07:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 Jun 2022 17:07:15 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v35]
In-Reply-To: <zy-fxKanJRubPU3R2jquYM1jdi68GoalDHoudgbu_7M=.2f3776c0-2cec-409d-a71e-eee0b486bbc2@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <zy-fxKanJRubPU3R2jquYM1jdi68GoalDHoudgbu_7M=.2f3776c0-2cec-409d-a71e-eee0b486bbc2@github.com>
Message-ID: <xiUjO8OZFguvfn_ZXZF92j-6o6Mu42FcAhBzAo-f_nM=.11298acb-184a-4772-80f2-1887f63f5688@github.com>

On Sat, 25 Jun 2022 19:08:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 53 additional commits since the last revision:
> 
>  - Expand testing of Class access flags.
>  - Merge branch 'master' into JDK-8266670
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback from Mandy and Roger.
>  - Remove implSpec tag from Executable.accessFlags since the class is sealed.
>  - Improve support and tests for Class objects representing arrays and primitives.
>  - Expand scope of tests.
>  - Merge branch 'master' into JDK-8266670
>  - Add module-related tests.
>  - Fix typo Exe-Boss spotted in review feedback.
>  - ... and 43 more: https://git.openjdk.org/jdk/compare/74b04508...e2cccc16

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 217:

> 215:         /**
> 216:          * {@return an unmodifiable set of the module {@linkplain AccessFlag
> 217:          * requires flags, possibly empty}}

Did you mean to include "possibly empty" in the link? Also a minor nit is that the accessFlags methods put "possibly empty" in first sentence of the method description but the other methods have "possibly-empty" in the (more detailed) return description.

-------------

PR: https://git.openjdk.org/jdk/pull/7445

From dholmes at openjdk.org  Mon Jun 27 00:29:55 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 Jun 2022 00:29:55 GMT
Subject: RFR: 8289079:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with
 "RuntimeException: Test failed"
In-Reply-To: <BUYLRglrrJy_NePpZsoHs-4UpX7RYkAekVDmwZNOaXU=.b1803969-7a19-424a-b50b-1186a8281e35@github.com>
References: <BUYLRglrrJy_NePpZsoHs-4UpX7RYkAekVDmwZNOaXU=.b1803969-7a19-424a-b50b-1186a8281e35@github.com>
Message-ID: <hBSKF2gsaz_FUjbguBOVo-tijM3imt3ZH0zfzphZUNk=.9320bd5c-02b5-41d8-bdf0-7f424461e90f@github.com>

On Sun, 26 Jun 2022 09:50:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a fix to a recently added test. The test uses pthread_create to create native threads that invoke a Java method via a generated "upcall stub". The upcall stub is created in an implicit memory session but the test doesn't do anything to ensure that the memory session remains open. Testing in higher tiers runs the test with options that sometimes lead to a cleaner closing the memory session before the native threads have terminated. The failure mode is exit code 133 due to a child VM exiting with SIGTRAP. The test needs to be changed to ensure that the memory session is not closed until the threads terminate. To keep it simple, I've changed it to use the global memory session. The alternative is to change it to use a shared session or a reachability fence, coupled with a pthread_join to ensure that all native threads with a reference to stub terminate before the session is closed. The test is intended to exercise concurrent implicit attaching so keeping it as simple as possib
 le seems best.
> 
> The test is also changed too use shouldHaveExitValue(0) as the original test discarded the child VM exit code when the test failed.

Explanation and fix seem quite reasonable.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/73

From tvoniadka at openjdk.org  Mon Jun 27 04:59:18 2022
From: tvoniadka at openjdk.org (Thejasvi Voniadka)
Date: Mon, 27 Jun 2022 04:59:18 GMT
Subject: RFR: 8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java
 to stop HttpServer cleanly in case of exceptions
Message-ID: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>

This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.

The test passes on all supported platforms post fix.

-------------

Commit messages:
 - 8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions

Changes: https://git.openjdk.org/jdk/pull/9293/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9293&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282036
  Stats: 13 lines in 1 file changed: 6 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9293.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9293/head:pull/9293

PR: https://git.openjdk.org/jdk/pull/9293

From jpai at openjdk.org  Mon Jun 27 05:35:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 27 Jun 2022 05:35:38 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions
In-Reply-To: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
Message-ID: <mgZiVy1oe48G1R9zzMEpcndnMObkSB1pwMxFzruigTg=.c9480c8c-1203-4e44-958b-1c76c4b99b6a@github.com>

On Mon, 27 Jun 2022 04:50:09 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
> 
> The test passes on all supported platforms post fix.

Hello Thejasvi, the change looks good to me. Please update the copyright year to 2022 in this changed file.

-------------

PR: https://git.openjdk.org/jdk/pull/9293

From alanb at openjdk.org  Mon Jun 27 06:37:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Jun 2022 06:37:52 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions
In-Reply-To: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
Message-ID: <NW_fZ5ajTKUs9Ft6_qlhnLvNBuUXkkNqNS4GIO9Ud4w=.64aa6dcc-0df8-4d28-9b71-cd2ca90b7f5b@github.com>

On Mon, 27 Jun 2022 04:50:09 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
> 
> The test passes on all supported platforms post fix.

test/jdk/java/util/zip/ZipFile/DeleteTempJar.java line 89:

> 87:                 server.stop(0);
> 88:             }
> 89:         }

Is there a reason to put the server.start in the try block, I would think this is simpler:


server.start();
try {
    :
} finally {
    server.stop(0);
}

-------------

PR: https://git.openjdk.org/jdk/pull/9293

From aturbanov at openjdk.org  Mon Jun 27 07:18:05 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 27 Jun 2022 07:18:05 GMT
Subject: Integrated: 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN
 fields static in ProcessHandleImpl
In-Reply-To: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
References: <ISIP9wxFzIYLeaAns8pzG8kEcTPcW1rLREZjJ3eN0Sk=.6bf196e8-bf46-4488-b08a-a218ed27466e@github.com>
Message-ID: <xf-e7QVyfyRJKOCmHkEXtDLvi6Ey6-7x3ggJm0TwiwI=.24a5d394-2e1f-4515-b3cd-669d646725ce@github.com>

On Fri, 17 Jun 2022 08:43:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fields `STARTTIME_ANY` and `STARTTIME_PROCESS_UNKNOWN` are actually unused, but they are useful as documentation on the interface to native.
> Make them `static` to reduce memory usage.

This pull request has now been integrated.

Changeset: 47fe9ef5
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/47fe9ef5bfde73a4fa21ba085b9275bb42df6590
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN fields static in ProcessHandleImpl

Reviewed-by: jpai, rriggs, bpb, naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/9196

From asotona at openjdk.org  Mon Jun 27 08:53:01 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Jun 2022 08:53:01 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v13]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <TYFZimuHBQWcdrZsDq3i-o6gLmjjC0Ca8R8BdDsGX3Y=.5bf9fe73-3a01-4b5c-ad3d-dc8d81093d0a@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - ... and 7 more: https://git.openjdk.org/jdk/compare/7905788e...cab6ce59

-------------

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=12
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599

From mcimadamore at openjdk.org  Mon Jun 27 09:19:34 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Jun 2022 09:19:34 GMT
Subject: [jdk19] RFR: 8289079:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with
 "RuntimeException: Test failed"
In-Reply-To: <BUYLRglrrJy_NePpZsoHs-4UpX7RYkAekVDmwZNOaXU=.b1803969-7a19-424a-b50b-1186a8281e35@github.com>
References: <BUYLRglrrJy_NePpZsoHs-4UpX7RYkAekVDmwZNOaXU=.b1803969-7a19-424a-b50b-1186a8281e35@github.com>
Message-ID: <QP5po4dO25GtJGITunDFhDUjY695N8tUkH_HsSO0L_o=.f4ddfc0d-01b6-403c-b5f4-bcddf954f632@github.com>

On Sun, 26 Jun 2022 09:50:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a fix to a recently added test. The test uses pthread_create to create native threads that invoke a Java method via a generated "upcall stub". The upcall stub is created in an implicit memory session but the test doesn't do anything to ensure that the memory session remains open. Testing in higher tiers runs the test with options that sometimes lead to a cleaner closing the memory session before the native threads have terminated. The failure mode is exit code 133 due to a child VM exiting with SIGTRAP. The test needs to be changed to ensure that the memory session is not closed until the threads terminate. To keep it simple, I've changed it to use the global memory session. The alternative is to change it to use a shared session or a reachability fence, coupled with a pthread_join to ensure that all native threads with a reference to stub terminate before the session is closed. The test is intended to exercise concurrent implicit attaching so keeping it as simple as possib
 le seems best.
> 
> The test is also changed too use shouldHaveExitValue(0) as the original test discarded the child VM exit code when the test failed.

Marked as reviewed by mcimadamore (Reviewer).

For the records - the implicit upcall will be kept alive for the duration of the downcall to which it is passed to. In this case, since the downcall forks another thread and then returns (and the call to the stub occurs at some point later in the other thread), it is possible for the implicit session to be reclaimed _before_ the async thread had a chance to execute it. With fully synchronous code this would never be an issue, as the standard safety "keep-alive" provided by the linker would have been enough.

-------------

PR: https://git.openjdk.org/jdk19/pull/73

From asotona at openjdk.org  Mon Jun 27 09:25:58 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Jun 2022 09:25:58 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v14]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8599/files
  - new: https://git.openjdk.org/jdk/pull/8599/files/cab6ce59..6f32938d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=12-13

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599

From alanb at openjdk.org  Mon Jun 27 09:30:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Jun 2022 09:30:45 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v2]
In-Reply-To: <lYQFAewhb7no6q9Cj1QEdGvsVRWNBFrZegQtHXDFyCg=.b5e705a1-df46-4993-a963-f490de1e87f3@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>
 <lBYfnG9zAaQ_dYYChCqpVuXwuChFY917ApF-z2m2GNA=.2a42bf65-3d5d-4190-90fc-e095d1542e4f@github.com>
 <lYQFAewhb7no6q9Cj1QEdGvsVRWNBFrZegQtHXDFyCg=.b5e705a1-df46-4993-a963-f490de1e87f3@github.com>
Message-ID: <qL6dAmvAXIWS4DKBKwQSliLIjHr3oV-ajHSo5dPxH9I=.685c6d8d-f7ce-4f83-b6ee-68c09a4282d8@github.com>

On Sun, 26 Jun 2022 13:33:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I thought about using TestProvider and then talked myself out of it. So yes, I can do that. If you have a preferred name other than `TestOverRideFSPMethods` please let me know

The only change that should be needed to TestProvider is to implement the checkAccess method with:


        Path delegate = theFileSystem.unwrap(file);
        defaultProvider.checkAccess(delegate, modes);


With that change it should be easy to extend and override exists/readAttributesIfExists to record that they are called. The need to run with the test with -Djava.nio.file.spi.DefaultFileSystemProvider=TestProvider goes away too and and should be much simpler to test that the expected delegation.

-------------

PR: https://git.openjdk.org/jdk/pull/9249

From alanb at openjdk.org  Mon Jun 27 10:25:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Jun 2022 10:25:48 GMT
Subject: [jdk19] Integrated: 8289079:
 java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with
 "RuntimeException: Test failed"
In-Reply-To: <BUYLRglrrJy_NePpZsoHs-4UpX7RYkAekVDmwZNOaXU=.b1803969-7a19-424a-b50b-1186a8281e35@github.com>
References: <BUYLRglrrJy_NePpZsoHs-4UpX7RYkAekVDmwZNOaXU=.b1803969-7a19-424a-b50b-1186a8281e35@github.com>
Message-ID: <bwHO1Z7jT7jQ6ozkYmdmNwbZ0tFQHwcvrmtOLMl2Gj0=.89e756db-a3bc-4ee6-a501-d7b27d3a81fd@github.com>

On Sun, 26 Jun 2022 09:50:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a fix to a recently added test. The test uses pthread_create to create native threads that invoke a Java method via a generated "upcall stub". The upcall stub is created in an implicit memory session but the test doesn't do anything to ensure that the memory session remains open. Testing in higher tiers runs the test with options that sometimes lead to a cleaner closing the memory session before the native threads have terminated. The failure mode is exit code 133 due to a child VM exiting with SIGTRAP. The test needs to be changed to ensure that the memory session is not closed until the threads terminate. To keep it simple, I've changed it to use the global memory session. The alternative is to change it to use a shared session or a reachability fence, coupled with a pthread_join to ensure that all native threads with a reference to stub terminate before the session is closed. The test is intended to exercise concurrent implicit attaching so keeping it as simple as possib
 le seems best.
> 
> The test is also changed too use shouldHaveExitValue(0) as the original test discarded the child VM exit code when the test failed.

This pull request has now been integrated.

Changeset: 7e13cdb7
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/7e13cdb799ff21cfcc350e518095dda9ce815b30
Stats:     4 lines in 2 files changed: 0 ins; 2 del; 2 mod

8289079: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with "RuntimeException: Test failed"

Reviewed-by: dholmes, mcimadamore

-------------

PR: https://git.openjdk.org/jdk19/pull/73

From tvoniadka at openjdk.org  Mon Jun 27 10:58:48 2022
From: tvoniadka at openjdk.org (Thejasvi Voniadka)
Date: Mon, 27 Jun 2022 10:58:48 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions [v2]
In-Reply-To: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
Message-ID: <CKkFBvpMcJZjkZAfnhv_hugRcQNo2DhQ7_2op51ZFEE=.79e1334d-eddd-4428-a226-831f812bea45@github.com>

> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
> 
> The test passes on all supported platforms post fix.

Thejasvi Voniadka has updated the pull request incrementally with one additional commit since the last revision:

  8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9293/files
  - new: https://git.openjdk.org/jdk/pull/9293/files/03b7ea63..1a2afd8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9293&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9293&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9293.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9293/head:pull/9293

PR: https://git.openjdk.org/jdk/pull/9293

From jpai at openjdk.org  Mon Jun 27 10:58:50 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 27 Jun 2022 10:58:50 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions [v2]
In-Reply-To: <CKkFBvpMcJZjkZAfnhv_hugRcQNo2DhQ7_2op51ZFEE=.79e1334d-eddd-4428-a226-831f812bea45@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
 <CKkFBvpMcJZjkZAfnhv_hugRcQNo2DhQ7_2op51ZFEE=.79e1334d-eddd-4428-a226-831f812bea45@github.com>
Message-ID: <EnWH7vyJptseH1-MfYlaoE5o7QhbR7_P3XhSl940jE4=.22144d59-635f-4b72-bf0a-a5f5ffc270c5@github.com>

On Mon, 27 Jun 2022 10:53:56 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

>> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
>> 
>> The test passes on all supported platforms post fix.
>
> Thejasvi Voniadka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions

test/jdk/java/util/zip/ZipFile/DeleteTempJar.java line 86:

> 84:             System.out.println(f.getName());
> 85:         } finally {
> 86:             if (server != null) {

The null check can be removed here as suggested by Alan.

-------------

PR: https://git.openjdk.org/jdk/pull/9293

From tvoniadka at openjdk.org  Mon Jun 27 10:58:52 2022
From: tvoniadka at openjdk.org (Thejasvi Voniadka)
Date: Mon, 27 Jun 2022 10:58:52 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions [v2]
In-Reply-To: <NW_fZ5ajTKUs9Ft6_qlhnLvNBuUXkkNqNS4GIO9Ud4w=.64aa6dcc-0df8-4d28-9b71-cd2ca90b7f5b@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
 <NW_fZ5ajTKUs9Ft6_qlhnLvNBuUXkkNqNS4GIO9Ud4w=.64aa6dcc-0df8-4d28-9b71-cd2ca90b7f5b@github.com>
Message-ID: <HpPni__jiwbiyNsGTJ1_qgBtVGAgu8KPkoiVVw9C6QE=.448278a7-db3f-443d-b0a9-55e163fa666c@github.com>

On Mon, 27 Jun 2022 06:34:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thejasvi Voniadka has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions
>
> test/jdk/java/util/zip/ZipFile/DeleteTempJar.java line 89:
> 
>> 87:                 server.stop(0);
>> 88:             }
>> 89:         }
> 
> Is there a reason to put the server.start in the try block, I would think this is simpler:
> 
> 
> server.start();
> try {
>     :
> } finally {
>     server.stop(0);
> }

Thank you @jaikiran , @AlanBateman for your reviews. I have updated the patch with your inputs.

-------------

PR: https://git.openjdk.org/jdk/pull/9293

From dfuchs at openjdk.org  Mon Jun 27 11:16:15 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 27 Jun 2022 11:16:15 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
Message-ID: <lMlEm6Tx0r3KLxMTUQLQAcsUaZe7aEE0d26gu2DuPOc=.d3650301-0861-4ef8-b71d-4903e65369e6@github.com>

On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
> 
> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.

If the selector returns a non zero value when being woken up it means that some key is selected, which would imply that some operation is still in progress. So isReferenced() would return false in that case (since it returns true only if both the facade is no longer referenced and the operation count is reduced to 0). 
However with HTTP/2, because connections remain open, we could unfortunately receive some GOAWAY frame from a server at a time where we're trying to shutdown the client, which would then keep it alive for another round. So the assumption that if there is something to read or write an operation is still in progress may not be 100% true. 
Let me think on this.

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From tvoniadka at openjdk.org  Mon Jun 27 11:52:37 2022
From: tvoniadka at openjdk.org (Thejasvi Voniadka)
Date: Mon, 27 Jun 2022 11:52:37 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions [v3]
In-Reply-To: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
Message-ID: <-CVpBo0Es3H2UXn8Uy858SJQ8OchAsixmfDP1KKKixY=.adbbb8e3-c357-44cd-bfed-feb75e533969@github.com>

> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
> 
> The test passes on all supported platforms post fix.

Thejasvi Voniadka has updated the pull request incrementally with one additional commit since the last revision:

  8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9293/files
  - new: https://git.openjdk.org/jdk/pull/9293/files/1a2afd8c..498ed31c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9293&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9293&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9293.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9293/head:pull/9293

PR: https://git.openjdk.org/jdk/pull/9293

From tvoniadka at openjdk.org  Mon Jun 27 11:54:53 2022
From: tvoniadka at openjdk.org (Thejasvi Voniadka)
Date: Mon, 27 Jun 2022 11:54:53 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions [v3]
In-Reply-To: <HpPni__jiwbiyNsGTJ1_qgBtVGAgu8KPkoiVVw9C6QE=.448278a7-db3f-443d-b0a9-55e163fa666c@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
 <NW_fZ5ajTKUs9Ft6_qlhnLvNBuUXkkNqNS4GIO9Ud4w=.64aa6dcc-0df8-4d28-9b71-cd2ca90b7f5b@github.com>
 <HpPni__jiwbiyNsGTJ1_qgBtVGAgu8KPkoiVVw9C6QE=.448278a7-db3f-443d-b0a9-55e163fa666c@github.com>
Message-ID: <w3X3V3iH2V3Cb8uH6Sr0E8N2hA1RsGRxjqtB2RH4ybc=.0aee66ad-3ea3-481b-9626-278b321af1ef@github.com>

On Mon, 27 Jun 2022 10:52:58 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

>> test/jdk/java/util/zip/ZipFile/DeleteTempJar.java line 89:
>> 
>>> 87:                 server.stop(0);
>>> 88:             }
>>> 89:         }
>> 
>> Is there a reason to put the server.start in the try block, I would think this is simpler:
>> 
>> 
>> server.start();
>> try {
>>     :
>> } finally {
>>     server.stop(0);
>> }
>
> Thank you @jaikiran , @AlanBateman for your reviews. I have updated the patch with your inputs.

Sorry @jaikiran , I somehow missed the comment on the null check. Have fixed it now, thank you!

-------------

PR: https://git.openjdk.org/jdk/pull/9293

From jwilhelm at openjdk.org  Mon Jun 27 11:55:51 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 11:55:51 GMT
Subject: RFR: Merge jdk19
Message-ID: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8289079: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with "RuntimeException: Test failed"
 - 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing
 - 8288983: broken link in com.sun.net.httpserver.SimpleFileServer
 - 8289044: ARM32: missing LIR_Assembler::cmove metadata type support
 - 8288120: VerifyError with JEP 405 pattern match
 - 8288528: broken links in java.desktop
 - 8288080: (fc) FileChannel::map for MemorySegments should state it always throws UOE
 - 8287076: Document.normalizeDocument() produces different results
 - 8288589: Files.readString ignores encoding errors for UTF-16
 - ... and 2 more: https://git.openjdk.org/jdk/compare/7905788e...9579cc05

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9296/files
  Stats: 366 lines in 24 files changed: 274 ins; 41 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/9296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9296/head:pull/9296

PR: https://git.openjdk.org/jdk/pull/9296

From dfuchs at openjdk.org  Mon Jun 27 12:13:38 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 27 Jun 2022 12:13:38 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <W9Of0GqNNko6YIlXCd69fjw1BEO3AVDoLGZQwu-pjhE=.6c702fec-660a-4a4c-b8d9-473e2a75da43@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
 <W9Of0GqNNko6YIlXCd69fjw1BEO3AVDoLGZQwu-pjhE=.6c702fec-660a-4a4c-b8d9-473e2a75da43@github.com>
Message-ID: <FA8NmsHxhY-RUV6qp31q9QqBMUAuE7mbMgBg5saVBK8=.76f622dd-e37a-4c89-8c39-f055e562cc5e@github.com>

On Sun, 26 Jun 2022 06:08:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
>> 
>> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
>> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.
>
> Hello Daniel, the source code changes look OK to me. The test code changes I haven't finished reviewing yet. A few questions related to the `SelectorManager`:
> 
> I realize that the goal of this change is to wakeup the `SelectorManager` from its select operation so that it can then go ahead and exit from its `run()` and in the process shut itself down.
> 
> In the `SelectorManager`, I see that when it is potentially woken up, it checks if the `HttpClientImpl` (via its facade) is still referenced and if not, it will trigger the shutdown. That happens here https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java*L1240__;Iw!!ACWV5N9M2RV99hQ!JL9hqB4ORwRVy6IHKdvtBmdyVOqqyxumiBnrW7bOxTAJzd_Cjew0bUQwyIgLhB3Q5r4JFXtMG1MXI3ZqfohFozk$ . However, that check is only done if the `select` operation (which was potentially woken up) returns `0` as the number of ready ops. The `Selector.wakeup()` javadoc notes that it's possible that when the selector is woken up, the select operation may return a non-zero value. With the change in this PR where the `HttpClientImpl` has realized that the facade is no longer in use and thus has triggered the `wakeup`, do you think we should shutdown the `SelectorManager` irrespective of what the return value of the `select` operation was? In other words, should that `if (!owner.isReferenced()) {` check in the `SelectorManager` be outside of the `if (n == 0) {` block?
> 
> Continuing further, if we do decide that the code in the `SelectorManager` is fine in its current form, do you think we should have an additional `if (!owner.isReferenced()) {` check right at the start of each loop iteration too, something like:
> 
> while (!Thread.currentThread().isInterrupted() && !closed) {
>     // Check whether client is still alive, and if not,
>     // gracefully stop this thread
>     if (!owner.isReferenced()) {
>         Log.logTrace("{0}: {1}",
>                 getName(),
>                 "HttpClient no longer referenced. Exiting...");
>         return;
>     }
>     synchronized (this) {
>         ...
>     
> 
> }
> 
> because in its current form, as far as I can see, even if we wakeup the selector eagerly, it's possible that the `select` operation that it was waiting on, might return a non-zero value and we then end up back in that while loop and do another `select` which could then end up waiting for some more seconds (3 seconds by default).

@jaikiran there is already an escape hatch at line 1196: 
https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/7905788e969727c81eea4397f0d9b918cdb5286a/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java*L1196__;Iw!!ACWV5N9M2RV99hQ!JL9hqB4ORwRVy6IHKdvtBmdyVOqqyxumiBnrW7bOxTAJzd_Cjew0bUQwyIgLhB3Q5r4JFXtMG1MXI3ZqATA6QVk$ 

So we will re-check `isReferenced()` again before calling select. I believe we are fine and there's no need to change anything here.

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From mcimadamore at openjdk.org  Mon Jun 27 13:12:32 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Jun 2022 13:12:32 GMT
Subject: [jdk19] RFR: 8289188: SegmentAllocator:allocateArray(*) default
 behavior mismatch to spec
Message-ID: <3NzrBSWpuAu1C0milvC9JHayFfzmiJq8KcUlVNzQqA0=.b8851f61-af2b-4665-a853-0b847dddb209@github.com>

This patch fixes an issue where the default method implementation of the SegmentAllocator::allcoateArray methods do not conform to the javadoc. The javadoc says that specific `allocateArray` methods delegate to `allocateArray(MemoryLayout, size)` - but this does not happen; instead these methods just delegate to `allocate(MemoryLayout)`.

I've addressed this, and added a test - when doing that, I also realized that we had a problem when a `null` array was passed to the array allocation methods (possible with varargs). In such edge case, we should just skip the copy operation (and also remove the spurious `checkNonNull`).

-------------

Commit messages:
 - Remove whitespaces
 - Readd erroneously removed code
 - Merge branch 'master' into allocateArray_delegate
 - Initial push

Changes: https://git.openjdk.org/jdk19/pull/74/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=74&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289188
  Stats: 49 lines in 3 files changed: 43 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk19/pull/74.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/74/head:pull/74

PR: https://git.openjdk.org/jdk19/pull/74

From jpai at openjdk.org  Mon Jun 27 13:36:39 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 27 Jun 2022 13:36:39 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions [v3]
In-Reply-To: <-CVpBo0Es3H2UXn8Uy858SJQ8OchAsixmfDP1KKKixY=.adbbb8e3-c357-44cd-bfed-feb75e533969@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
 <-CVpBo0Es3H2UXn8Uy858SJQ8OchAsixmfDP1KKKixY=.adbbb8e3-c357-44cd-bfed-feb75e533969@github.com>
Message-ID: <uBsBm6yq3Q416F_189uXyZXugVX_vCsYOapqqNl_qEM=.754c49e3-447d-4b35-ab86-a2bd15194517@github.com>

On Mon, 27 Jun 2022 11:52:37 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

>> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
>> 
>> The test passes on all supported platforms post fix.
>
> Thejasvi Voniadka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions

Thank you for doing those changes. The latest state of this PR looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9293

From jpai at openjdk.org  Mon Jun 27 13:44:41 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 27 Jun 2022 13:44:41 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
Message-ID: <PuZ_QSoBywEG0EpjZ8zbCYqre9Qsr60U-AzUl5C9Lxc=.8739b181-fc33-4659-84f7-b52c03d3fc38@github.com>

On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
> 
> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From jpai at openjdk.org  Mon Jun 27 13:44:42 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 27 Jun 2022 13:44:42 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <W9Of0GqNNko6YIlXCd69fjw1BEO3AVDoLGZQwu-pjhE=.6c702fec-660a-4a4c-b8d9-473e2a75da43@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
 <W9Of0GqNNko6YIlXCd69fjw1BEO3AVDoLGZQwu-pjhE=.6c702fec-660a-4a4c-b8d9-473e2a75da43@github.com>
Message-ID: <4w3LpQlbbfWQc7tSa6xi-24lA2ukdEjirZ0VZHrl0r0=.7958f432-55fc-42c3-9874-5bf14fb1f2a2@github.com>

On Sun, 26 Jun 2022 06:08:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
>> 
>> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
>> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.
>
> Hello Daniel, the source code changes look OK to me. The test code changes I haven't finished reviewing yet. A few questions related to the `SelectorManager`:
> 
> I realize that the goal of this change is to wakeup the `SelectorManager` from its select operation so that it can then go ahead and exit from its `run()` and in the process shut itself down.
> 
> In the `SelectorManager`, I see that when it is potentially woken up, it checks if the `HttpClientImpl` (via its facade) is still referenced and if not, it will trigger the shutdown. That happens here https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java*L1240__;Iw!!ACWV5N9M2RV99hQ!Mo9E5YBNsuLorRTNluRjIsiee0ZUYmDHUX7hP8ontSxNORFwcNB0ZHVYt_HbmTu3Vw7xM19I2R-mTY4KAmkg$ . However, that check is only done if the `select` operation (which was potentially woken up) returns `0` as the number of ready ops. The `Selector.wakeup()` javadoc notes that it's possible that when the selector is woken up, the select operation may return a non-zero value. With the change in this PR where the `HttpClientImpl` has realized that the facade is no longer in use and thus has triggered the `wakeup`, do you think we should shutdown the `SelectorManager` irrespective of what the return value of the `select` operation was? In other words, should that `if (!owner.isReferenced()) {` check in the `SelectorManager` be outside of the `if (n == 0) {` block?
> 
> Continuing further, if we do decide that the code in the `SelectorManager` is fine in its current form, do you think we should have an additional `if (!owner.isReferenced()) {` check right at the start of each loop iteration too, something like:
> 
> while (!Thread.currentThread().isInterrupted() && !closed) {
>     // Check whether client is still alive, and if not,
>     // gracefully stop this thread
>     if (!owner.isReferenced()) {
>         Log.logTrace("{0}: {1}",
>                 getName(),
>                 "HttpClient no longer referenced. Exiting...");
>         return;
>     }
>     synchronized (this) {
>         ...
>     
> 
> }
> 
> because in its current form, as far as I can see, even if we wakeup the selector eagerly, it's possible that the `select` operation that it was waiting on, might return a non-zero value and we then end up back in that while loop and do another `select` which could then end up waiting for some more seconds (3 seconds by default).

> @jaikiran there is already an escape hatch at line 1196:
> 
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/7905788e969727c81eea4397f0d9b918cdb5286a/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java*L1196__;Iw!!ACWV5N9M2RV99hQ!Mo9E5YBNsuLorRTNluRjIsiee0ZUYmDHUX7hP8ontSxNORFwcNB0ZHVYt_HbmTu3Vw7xM19I2R-mTbinCsJn$ 
> 
> So we will re-check `isReferenced()` again before calling select. I believe we are fine and there's no need to change anything here.

Ah! Indeed. I completely missed that. That check answers my question.

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From alanb at openjdk.org  Mon Jun 27 13:51:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Jun 2022 13:51:45 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions [v3]
In-Reply-To: <-CVpBo0Es3H2UXn8Uy858SJQ8OchAsixmfDP1KKKixY=.adbbb8e3-c357-44cd-bfed-feb75e533969@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
 <-CVpBo0Es3H2UXn8Uy858SJQ8OchAsixmfDP1KKKixY=.adbbb8e3-c357-44cd-bfed-feb75e533969@github.com>
Message-ID: <_fhE0PbljxLyHKV8NYtxXi4qPKHUsImAYeoeKQF7C6A=.61efd7d1-3d8d-4aff-ae46-3058ab2d88a7@github.com>

On Mon, 27 Jun 2022 11:52:37 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

>> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
>> 
>> The test passes on all supported platforms post fix.
>
> Thejasvi Voniadka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions

Looks okay. You'll ned to edit the edit the title to align with the description of the JBS issue before you can integrate.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9293

From alanb at openjdk.org  Mon Jun 27 14:01:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Jun 2022 14:01:48 GMT
Subject: [jdk19] RFR: 8289188: SegmentAllocator:allocateArray(*) default
 behavior mismatch to spec
In-Reply-To: <3NzrBSWpuAu1C0milvC9JHayFfzmiJq8KcUlVNzQqA0=.b8851f61-af2b-4665-a853-0b847dddb209@github.com>
References: <3NzrBSWpuAu1C0milvC9JHayFfzmiJq8KcUlVNzQqA0=.b8851f61-af2b-4665-a853-0b847dddb209@github.com>
Message-ID: <N1D9-n87bupLL0N5Mvan9_ApFrRFG1bKugnbFqjxd4U=.f6089dfc-34ba-4522-875a-58e00f46d232@github.com>

On Mon, 27 Jun 2022 11:01:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes an issue where the default method implementation of the SegmentAllocator::allcoateArray methods do not conform to the javadoc. The javadoc says that specific `allocateArray` methods delegate to `allocateArray(MemoryLayout, size)` - but this does not happen; instead these methods just delegate to `allocate(MemoryLayout)`.
> 
> I've addressed this, and added a test - when doing that, I also realized that we had a problem when a `null` array was passed to the array allocation methods (possible with varargs). In such edge case, we should just skip the copy operation (and also remove the spurious `checkNonNull`).

This looks okay too to me, and the null case too.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/74

From michaelm at openjdk.org  Mon Jun 27 14:44:39 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 27 Jun 2022 14:44:39 GMT
Subject: RFR: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
Message-ID: <yR3yfmk1KfpdCXxZ0t308qiAH3hxOrJRYWLPv3vJnqY=.085ee5e4-9549-4886-b0d3-8e46bf98ac0d@github.com>

On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
> 
> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.

LGTM

-------------

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9217

From dfuchs at openjdk.org  Mon Jun 27 14:48:53 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 27 Jun 2022 14:48:53 GMT
Subject: RFR: 8282036: [Test]: Update
 java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of
 exceptions [v3]
In-Reply-To: <-CVpBo0Es3H2UXn8Uy858SJQ8OchAsixmfDP1KKKixY=.adbbb8e3-c357-44cd-bfed-feb75e533969@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
 <-CVpBo0Es3H2UXn8Uy858SJQ8OchAsixmfDP1KKKixY=.adbbb8e3-c357-44cd-bfed-feb75e533969@github.com>
Message-ID: <RPpQpqoqcg9gRYO6PyUZ5OsuGhOi_IQu89sCqArlEIY=.33e4020b-0e39-4d96-8093-677156e24fd3@github.com>

On Mon, 27 Jun 2022 11:52:37 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

>> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
>> 
>> The test passes on all supported platforms post fix.
>
> Thejasvi Voniadka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions

Looks reasonable to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9293

From dfuchs at openjdk.org  Mon Jun 27 15:01:44 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 27 Jun 2022 15:01:44 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit
In-Reply-To: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
Message-ID: <qtytlbPln_MqP3tdlUIhOwy7Yr-l5wvGJaj54tp0fTY=.1bc4ed19-6e9d-4909-96bc-d7785f4c49e8@github.com>

On Thu, 23 Jun 2022 08:20:31 GMT, rmartinc <duke at openjdk.org> wrote:

> Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895).
> 
> Any `LimitExceededException` now quits the referral loop.
> 
> Added class `ReferralLimitSearchTest`. It is a simple jtreg test which checks that `java.naming.ldap.referral.limit` is really enforced. The dummy ldap server always returns a referral for any search query. If the number of searches exceeds the limit, it throws an `IOException` and the test fails.
> 
> 
> make test TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java

Changes requested by dfuchs (Reviewer).

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 338:

> 336:                         errEx = re.getNamingException();
> 337:                         break;
> 338:                     } else if (errEx == null) {

Could we set up a local variable here to avoid calling re.getNamingException() more than once?
e.g. something like:


var cause = re.getNamingException();
if (cause instanceof ...) {


then use `cause` throughout.

-------------

PR: https://git.openjdk.org/jdk/pull/9256

From dfuchs at openjdk.org  Mon Jun 27 15:04:41 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 27 Jun 2022 15:04:41 GMT
Subject: [jdk19] RFR: 8288596: Random:from() adapter does not delegate to
 supplied generator in all cases
In-Reply-To: <5VcKHDxn2sRglNaWKpiccebi2CohEde0Mb8JOSQh8m4=.892e04a0-3659-48a3-8776-aebb46d63757@github.com>
References: <5VcKHDxn2sRglNaWKpiccebi2CohEde0Mb8JOSQh8m4=.892e04a0-3659-48a3-8776-aebb46d63757@github.com>
Message-ID: <d6NXEYrrHnqKtSUI3-5WaR2SxNIIPZsN2TEtEhzkgWI=.fd685061-164f-4813-a299-2745c3584a62@github.com>

On Fri, 17 Jun 2022 16:44:30 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

> Extend delegation by instance returned by Random.from() to all methods exposed by RandomGenerator.

just a stylistic comment in passing: it's a bit strange to see half of the methods call `this.generator` and the other half simply call `generator`.  Otherwise looks like your change is ready to be sponsored!

-------------

PR: https://git.openjdk.org/jdk19/pull/36

From dfuchs at openjdk.org  Mon Jun 27 15:15:42 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 27 Jun 2022 15:15:42 GMT
Subject: Integrated: JDK-8288746: HttpClient resources could be reclaimed more
 eagerly
In-Reply-To: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
References: <AcxI1lTVUQIu_SRzT3jbHbQlCB7VaJtXWnPjiaBhySc=.c8c07d5c-6941-47dd-89ef-cef7401a03f2@github.com>
Message-ID: <uPWwD4vFNmpHTjDROcJ7W6BE3kuomy_Q_cF-Za_GxKE=.c11184d2-ce52-44d0-83ae-86be9365a19d@github.com>

On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier.
> 
> The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is being gc'ed.
> Some tests have been modified to wait for the selector manager thread to shutdown, and some of them have been observed to timeout when the fix is not in place.

This pull request has now been integrated.

Changeset: f3f07884
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3f078846feae66d3504d50081353f74bd4891d7
Stats:     178 lines in 8 files changed: 99 ins; 13 del; 66 mod

8288746: HttpClient resources could be reclaimed more eagerly

Reviewed-by: jpai, michaelm

-------------

PR: https://git.openjdk.org/jdk/pull/9217

From duke at openjdk.org  Mon Jun 27 15:34:46 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Jun 2022 15:34:46 GMT
Subject: [jdk19] RFR: 8288596: Random:from() adapter does not delegate to
 supplied generator in all cases
In-Reply-To: <d6NXEYrrHnqKtSUI3-5WaR2SxNIIPZsN2TEtEhzkgWI=.fd685061-164f-4813-a299-2745c3584a62@github.com>
References: <5VcKHDxn2sRglNaWKpiccebi2CohEde0Mb8JOSQh8m4=.892e04a0-3659-48a3-8776-aebb46d63757@github.com>
 <d6NXEYrrHnqKtSUI3-5WaR2SxNIIPZsN2TEtEhzkgWI=.fd685061-164f-4813-a299-2745c3584a62@github.com>
Message-ID: <5fo903UxUnISZUAWQGnzEQqh7mH468GSolFQHq0nltQ=.e5b09400-7afb-476d-a31f-432fbc178aad@github.com>

On Mon, 27 Jun 2022 15:02:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Extend delegation by instance returned by Random.from() to all methods exposed by RandomGenerator.
>
> just a stylistic comment in passing: it's a bit strange to see half of the methods call `this.generator` and the other half simply call `generator`.  Otherwise looks like your change is ready to be sponsored!

@dfuch Yes, you're right.
Personally, I don't like to use `this.` when it's useless (like here) and, on the other hand, I didn't want to change too many lines to get rid of it in the existing code.

-------------

PR: https://git.openjdk.org/jdk19/pull/36

From duke at openjdk.org  Mon Jun 27 15:35:48 2022
From: duke at openjdk.org (altrisi)
Date: Mon, 27 Jun 2022 15:35:48 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <N093aAUAjCAN2JP6b_MgaNz90bvOGPG2Uod34nyn2UM=.edd15051-e37a-45f3-bd74-eac75d26c6ec@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.org> wrote:

> Changes the definition of `CollectorImpl` to be a record.

Hi, is this small PR missing anything in order to be reviewed? Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/8179

From mcimadamore at openjdk.org  Mon Jun 27 15:40:45 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Jun 2022 15:40:45 GMT
Subject: [jdk19] Integrated: 8289188: SegmentAllocator:allocateArray(*) default
 behavior mismatch to spec
In-Reply-To: <3NzrBSWpuAu1C0milvC9JHayFfzmiJq8KcUlVNzQqA0=.b8851f61-af2b-4665-a853-0b847dddb209@github.com>
References: <3NzrBSWpuAu1C0milvC9JHayFfzmiJq8KcUlVNzQqA0=.b8851f61-af2b-4665-a853-0b847dddb209@github.com>
Message-ID: <2JxSShA79vHK0D7ELs9PS43p9wfi7u4aZc5cLHrCkYI=.91bc54df-0fde-4da7-b3ec-3ac54f2c409b@github.com>

On Mon, 27 Jun 2022 11:01:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes an issue where the default method implementation of the SegmentAllocator::allcoateArray methods do not conform to the javadoc. The javadoc says that specific `allocateArray` methods delegate to `allocateArray(MemoryLayout, size)` - but this does not happen; instead these methods just delegate to `allocate(MemoryLayout)`.
> 
> I've addressed this, and added a test - when doing that, I also realized that we had a problem when a `null` array was passed to the array allocation methods (possible with varargs). In such edge case, we should just skip the copy operation (and also remove the spurious `checkNonNull`).

This pull request has now been integrated.

Changeset: 2c8ada68
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/2c8ada689f7bcfc39a04b0bf36c9aea156d47690
Stats:     49 lines in 3 files changed: 43 ins; 1 del; 5 mod

8289188: SegmentAllocator:allocateArray(*) default behavior mismatch to spec

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk19/pull/74

From lancea at openjdk.org  Mon Jun 27 16:43:55 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 27 Jun 2022 16:43:55 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v4]
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <aV6q_IIiScb9nwEkL56yfTHFHOOSKhh70qQ9ZRiQmAY=.614fc7b1-599d-47e9-9c7f-71e79370ae11@github.com>

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Updated tests based on feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9249/files
  - new: https://git.openjdk.org/jdk/pull/9249/files/6ef8bc1f..63b97ce3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=02-03

  Stats: 293 lines in 3 files changed: 156 ins; 133 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9249.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249

PR: https://git.openjdk.org/jdk/pull/9249

From jvernee at openjdk.org  Mon Jun 27 16:52:20 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 27 Jun 2022 16:52:20 GMT
Subject: [jdk19] RFR: 8289223: Canonicalize header ids in foreign API javadocs
Message-ID: <Ztm8vbJi2r2bPp_YtGHVJ7pxP6HnMZCOdq6wmQk0XcM=.49c22232-74c6-4614-88a8-5671ae16b5c9@github.com>

https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8817__;!!ACWV5N9M2RV99hQ!Kkp_j7PnK9AJEJUL817VN56eVeunFZsJPCPgXLt_Dgb1QE4PxZokFGCEF_Cf7KNASIrlkM5xZTNXSGd6ve264vZm$  added a button to copy a link to a section of javadoc to the clipboard.

This cleanup PR canonicalizes all header ids in the java.lang.foreign package to the preferred (non-legacy) style, and adds ids in places where they are missing as well.

In accordance with the Late-Enhancement Request Process [1], this is a `noreg-doc` documentation only change, which does not require an enhancement request.

[1]: https://openjdk.org/jeps/3#Late-Enhancement-Request-Process

-------------

Commit messages:
 - Canonicalize header ids in javadoc

Changes: https://git.openjdk.org/jdk19/pull/75/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=75&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289223
  Stats: 22 lines in 7 files changed: 0 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk19/pull/75.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/75/head:pull/75

PR: https://git.openjdk.org/jdk19/pull/75

From mcimadamore at openjdk.org  Mon Jun 27 16:56:20 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Jun 2022 16:56:20 GMT
Subject: [jdk19] RFR: 8289228: SegmentAllocator::allocateArray null handling is
 too lax
Message-ID: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>

Recent fix for JDK-8289188 relaxed behavior or `SegmentAllocator::allocateArray` too much w.r.t. nulls. This patch reverts null handling to what it used to be.

-------------

Commit messages:
 - Merge branch 'master' into allocateArray_null
 - Revert null changes

Changes: https://git.openjdk.org/jdk19/pull/76/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=76&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289228
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk19/pull/76.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/76/head:pull/76

PR: https://git.openjdk.org/jdk19/pull/76

From mcimadamore at openjdk.org  Mon Jun 27 17:00:45 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Jun 2022 17:00:45 GMT
Subject: [jdk19] RFR: 8289223: Canonicalize header ids in foreign API
 javadocs
In-Reply-To: <Ztm8vbJi2r2bPp_YtGHVJ7pxP6HnMZCOdq6wmQk0XcM=.49c22232-74c6-4614-88a8-5671ae16b5c9@github.com>
References: <Ztm8vbJi2r2bPp_YtGHVJ7pxP6HnMZCOdq6wmQk0XcM=.49c22232-74c6-4614-88a8-5671ae16b5c9@github.com>
Message-ID: <BdKGaT58yqJzzHL0Ch4p-RXoDAHKYyeubxVfETY-kng=.e30c4438-ebff-47a0-b4fe-07256d27cb7b@github.com>

On Mon, 27 Jun 2022 16:44:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8817__;!!ACWV5N9M2RV99hQ!ONT5MC45-Ze5UV3QSWdwMZbC1ssL29-DSmCyj3V9jPWzvOLSZctEnN4Ra-zFow08wzVe_7ufpSsxCxqgx0EIUoneRO4r7w$">https://github.com/openjdk/jdk/pull/8817</a> added a button to copy a link to a section of javadoc to the clipboard.
> 
> This cleanup PR canonicalizes all header ids in the java.lang.foreign package to the preferred (non-legacy) style, and adds ids in places where they are missing as well.
> 
> In accordance with the Late-Enhancement Request Process [1], this is a `noreg-doc` documentation only change, which does not require an enhancement request.
> 
> [1]: https://openjdk.org/jeps/3#Late-Enhancement-Request-Process

src/java.base/share/classes/java/lang/foreign/package-info.java line 30:

> 28:  * <p>Provides low-level access to memory and functions outside the Java runtime.
> 29:  *
> 30:  * <h2 id="fma">Foreign memory access</h2>

I would refrain from adding `id` if the section is never referred to.

-------------

PR: https://git.openjdk.org/jdk19/pull/75

From jvernee at openjdk.org  Mon Jun 27 17:05:43 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 27 Jun 2022 17:05:43 GMT
Subject: [jdk19] RFR: 8289223: Canonicalize header ids in foreign API
 javadocs
In-Reply-To: <BdKGaT58yqJzzHL0Ch4p-RXoDAHKYyeubxVfETY-kng=.e30c4438-ebff-47a0-b4fe-07256d27cb7b@github.com>
References: <Ztm8vbJi2r2bPp_YtGHVJ7pxP6HnMZCOdq6wmQk0XcM=.49c22232-74c6-4614-88a8-5671ae16b5c9@github.com>
 <BdKGaT58yqJzzHL0Ch4p-RXoDAHKYyeubxVfETY-kng=.e30c4438-ebff-47a0-b4fe-07256d27cb7b@github.com>
Message-ID: <tlJvjtrekgi5NfINGsgYofTPKIYx-ABKT-sOCRikJr8=.f2a3810a-b2d0-488e-ac28-7f59cd67b9d7@github.com>

On Mon, 27 Jun 2022 16:57:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8817__;!!ACWV5N9M2RV99hQ!Ooc0KcgMe7NsDGNiGbF-wfC_tK6POSNyLNDIHsrms0gVVdXsgnVAAbWZpHXSYWbAAmkJrTeqEh4N1h-1f8ZwKplq$">https://github.com/openjdk/jdk/pull/8817</a> added a button to copy a link to a section of javadoc to the clipboard.
>> 
>> This cleanup PR canonicalizes all header ids in the java.lang.foreign package to the preferred (non-legacy) style, and adds ids in places where they are missing as well.
>> 
>> In accordance with the Late-Enhancement Request Process [1], this is a `noreg-doc` documentation only change, which does not require an enhancement request.
>> 
>> [1]: https://openjdk.org/jeps/3#Late-Enhancement-Request-Process
>
> src/java.base/share/classes/java/lang/foreign/package-info.java line 30:
> 
>> 28:  * <p>Provides low-level access to memory and functions outside the Java runtime.
>> 29:  *
>> 30:  * <h2 id="fma">Foreign memory access</h2>
> 
> I would refrain from adding `id` if the section is never referred to.

The idea is that a user might want to link to this section of the javadoc (using the new copy button). For that to be possible, the section needs an `id`. That's why I've added one to all headers.

-------------

PR: https://git.openjdk.org/jdk19/pull/75

From jvernee at openjdk.org  Mon Jun 27 17:31:43 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 27 Jun 2022 17:31:43 GMT
Subject: [jdk19] RFR: 8289228: SegmentAllocator::allocateArray null
 handling is too lax
In-Reply-To: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>
References: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>
Message-ID: <hXkouClHXjLtwx-sXGxmIEGFHpWLnMoffnyaUifuxBc=.b244e544-e63d-4f17-b668-83a8ba9f035f@github.com>

On Mon, 27 Jun 2022 16:47:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Recent fix for JDK-8289188 relaxed behavior or `SegmentAllocator::allocateArray` too much w.r.t. nulls. This patch reverts null handling to what it used to be.

Should test/jdk/java/foreign/TestNulls.java also be reverted?

-------------

PR: https://git.openjdk.org/jdk19/pull/76

From asemenyuk at openjdk.org  Mon Jun 27 17:38:42 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 27 Jun 2022 17:38:42 GMT
Subject: RFR: 8288961: jpackage: test MSI installation fix
In-Reply-To: <rjbj93A-x52yIC4nqt_tdewEovug8Sooy1WwkD2xEFU=.d9d00563-f587-4c94-bc34-2f4a06fb3ff4@github.com>
References: <rjbj93A-x52yIC4nqt_tdewEovug8Sooy1WwkD2xEFU=.d9d00563-f587-4c94-bc34-2f4a06fb3ff4@github.com>
Message-ID: <wXwlMgAD2VXRaUuQtG08QYmCyFE4BV8rIKeOXCPgINk=.a5012f69-86f8-4180-832a-5ff993d26315@github.com>

On Wed, 22 Jun 2022 11:53:39 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> Please review this minor fix to the jpackage test suite.
> 
> When `INSTALL` and `UNINSTALL` actions are enabled for jpackage test suite runs (disabled by default), installation of `EXE` and `MSI` packages is performed. `EXE` package is invoked directly and `MSI` package is installed using `msiexec` utility. In both cases the path of the packages starts with a "." (current dir) symbol, it is processed correctly with EXE installation, but not with MSI, example:
> 
> 
> [03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
> [03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
> [03:52:19.634] TRACE: exec: Execute [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
> [03:52:19.790] TRACE: exec: Done. Exit code: 1619
> [03:52:19.805] ERROR: Expected [0]. Actual [1619]: Check command [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code 
> 
> 
> Is is proposed to normalize the path passed to `msiexec`, in this case installation will succeed:
> 
> 
> [03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
> [03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
> [03:56:52.429] TRACE: exec: Execute [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
> [03:56:57.067] TRACE: exec: Done. Exit code: 0
> [03:56:57.067] TRACE: assertEquals(0): Check command [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9236

From asemenyuk at openjdk.org  Mon Jun 27 17:41:41 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 27 Jun 2022 17:41:41 GMT
Subject: RFR: 8288013: jpackage: test utility Windows registry enhancement
In-Reply-To: <lFIf18LPCwDIoTtS2foBhR9ZZ-1LElZjPKcTDtktjOE=.dd399490-2bd0-4286-a256-d5d9cb61f1e3@github.com>
References: <lFIf18LPCwDIoTtS2foBhR9ZZ-1LElZjPKcTDtktjOE=.dd399490-2bd0-4286-a256-d5d9cb61f1e3@github.com>
Message-ID: <1Q2areHAyOkc_XVgVF7Ymn8IUJVN0ceN8_-lLgtOLIc=.9cb7d2f9-c22b-42d7-99c8-e5f7d891c87e@github.com>

On Wed, 8 Jun 2022 11:46:42 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> In jpackage test suite there is a test utility WindowsHelper.queryRegistryValue . It is used to verify changes to Windows registry that can be done by installer packages. It spawns `reg.exe query` process and parses its output. This patch adds support for quering empty values and additional REG_* datatypes.
> 
> Correctness was verified manually with the following registry values:
> 
> 
>         //    (Default)    REG_SZ    test1
>         //    string_val    REG_SZ    test2
>         //    string_val_empty    REG_SZ
>         //    bin_val    REG_BINARY    4242
>         //    bin_val_empty    REG_BINARY
>         //    dword_val    REG_DWORD    0x2a
>         //    qword_val    REG_QWORD    0x2a
>         //    multi_string_val    REG_MULTI_SZ    test3\0test4
>         //    multi_string_val_empty    REG_MULTI_SZ
>         //    expand_string_val    REG_EXPAND_SZ    test5
>         //    expand_string_val_empty    REG_EXPAND_SZ
> 
> 
> Corresponding utility output:
> 
> 
> [04:36:38.190] TRACE: Registry value [] at [...] path is [test1]
> [04:36:38.220] TRACE: Registry value [string_val] at [...] path is [test2]
> [04:36:38.251] TRACE: Registry value [string_val_empty] at [...] path is []
> [04:36:38.282] TRACE: Registry value [bin_val] at [...] path is [4242]
> [04:36:38.315] TRACE: Registry value [bin_val_empty] at [...] path is []
> [04:36:38.347] TRACE: Registry value [dword_val] at [...] path is [0x2a]
> [04:36:38.378] TRACE: Registry value [qword_val] at [...] path is [0x2a]
> [04:36:38.410] TRACE: Registry value [multi_string_val] at [...] path is [test3\\0test4]
> [04:36:38.441] TRACE: Registry value [multi_string_val_empty] at [...] path is []
> [04:36:38.473] TRACE: Registry value [expand_string_val] at [...] path is [test5]
> [04:36:38.506] TRACE: Registry value [expand_string_val_empty] at [...] path is []
> 
> 
> Testing:
> 
>  - [x] ran "jtreg:jdk/tools/jpackage/windows" before and after the patch

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9083

From asemenyuk at openjdk.org  Mon Jun 27 17:56:39 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 27 Jun 2022 17:56:39 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments
In-Reply-To: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
Message-ID: <hTh3uRo1rC7Ezwdsj7tz0Log-jqoFByCc5dyzKtpUcg=.9a8f6452-ac24-4775-8033-91fe0d44fe0f@github.com>

On Tue, 21 Jun 2022 09:30:30 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable.
> 
> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard.
> 
> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points:
> 
>  - option naming inside a properties file, currently `pass-all-args` is used
>  - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group
>  - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination
>  - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop`
> 
> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version.
> 
> Testing:
>  
> - [x] test to cover new logic is included
> - [x] ran jtreg:jdk/tools/jpackage with no new failures

What would be the alternative to `pass-all-args`?
What if we unconditionally add `%*` batch wildcard?

-------------

PR: https://git.openjdk.org/jdk/pull/9224

From asemenyuk at openjdk.org  Mon Jun 27 18:01:40 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 27 Jun 2022 18:01:40 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments
In-Reply-To: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
Message-ID: <w2RdOenSgmA8n-4-2CPbP_nv2KNPF2Y-8NoQPtGX6kg=.bf82c285-cadd-4d08-8d55-e354f8fecfad@github.com>

On Tue, 21 Jun 2022 09:30:30 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable.
> 
> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard.
> 
> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points:
> 
>  - option naming inside a properties file, currently `pass-all-args` is used
>  - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group
>  - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination
>  - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop`
> 
> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version.
> 
> Testing:
>  
> - [x] test to cover new logic is included
> - [x] ran jtreg:jdk/tools/jpackage with no new failures

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java line 533:

> 531:                 xml.writeAttribute("Command", "Open");
> 532:                 if (fa.passAllArguments) {
> 533:                     xml.writeAttribute("Argument", "\"%1\" %*");

Wondering if simple `"%*"` would be sufficient to preserve arguments with spaces.

-------------

PR: https://git.openjdk.org/jdk/pull/9224

From duke at openjdk.org  Mon Jun 27 18:23:57 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Jun 2022 18:23:57 GMT
Subject: Integrated: 8288021: Add hard test cases to
 jdk.internal.math.DoubleToDecimalChecker
In-Reply-To: <09ta5J6B7B3tppzLNexTDnumh-XBIs629Q7saT4o70E=.7354d628-33e3-4602-ab97-6830c306c5c1@github.com>
References: <09ta5J6B7B3tppzLNexTDnumh-XBIs629Q7saT4o70E=.7354d628-33e3-4602-ab97-6830c306c5c1@github.com>
Message-ID: <RRHmKcBJN9smf5hKtsTH-guW1ReKuYNK-xVtW5JgZO8=.eb01f23f-e5c9-4eff-a461-9503a13a3ff5@github.com>

On Wed, 8 Jun 2022 13:12:09 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

> These 19'545 doubles were generated on purpose by Paul Zimmermann of INRIA as hard test cases.

This pull request has now been integrated.

Changeset: 354ed103
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/354ed1034d6d42a672e8224aeb9eb892b73a563f
Stats:     19594 lines in 1 file changed: 19594 ins; 0 del; 0 mod

8288021: Add hard test cases to jdk.internal.math.DoubleToDecimalChecker

Co-authored-by: Paul Zimmermann <Paul.Zimmermann at inria.fr>
Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/9084

From jwilhelm at openjdk.org  Mon Jun 27 18:32:18 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 18:32:18 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
References: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
Message-ID: <QcElHQNvmhWdtuoJp8PQe_xbRrvU3U4EGBqA20EQnPw=.77ba96a7-3560-4cd8-b8ad-0aec9e1ac6ee@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 146 commits:

 - Merge
 - 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent
   
   Reviewed-by: ayang, cjplummer
 - 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN fields static in ProcessHandleImpl
   
   Reviewed-by: jpai, rriggs, bpb, naoto, iris
 - 8289147: unify os::infinite_sleep on posix platforms
   
   Reviewed-by: mdoerr, kbarrett, dholmes
 - 8266670: Better modeling of access flags in core reflection
   
   Reviewed-by: mchung, rriggs, asotona
 - 8286395: Address possibly lossy conversions in java.security.jgss
   
   Reviewed-by: chegar
 - 8286389: Address possibly lossy conversions in jdk.crypto.ec
   
   Reviewed-by: chegar, xuelei
 - 8288130: compiler error with AP and explicit record accessor
   
   Reviewed-by: jlahoda
 - 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java
   
   Reviewed-by: lmesnik, bpb
 - 8289098: clean up ported serviceability/jvmti tests
   
   Reviewed-by: kevinw, sspitsyn
 - ... and 136 more: https://git.openjdk.org/jdk/compare/7e13cdb7...9579cc05

-------------

Changes: https://git.openjdk.org/jdk/pull/9296/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=01
  Stats: 47784 lines in 1125 files changed: 22921 ins; 12915 del; 11948 mod
  Patch: https://git.openjdk.org/jdk/pull/9296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9296/head:pull/9296

PR: https://git.openjdk.org/jdk/pull/9296

From jwilhelm at openjdk.org  Mon Jun 27 18:32:18 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 18:32:18 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
References: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
Message-ID: <EOnXQGf1n2TS6psge4FEfSaSTM5kHMVXlCOMzBiffUw=.59ead9f8-4337-4c81-8b7b-55e735c78ac6@github.com>

On Mon, 27 Jun 2022 11:49:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: d4b040f4
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4b040f42dd0a9100ad1ffa55de4ae4f20e9f182
Stats:     366 lines in 24 files changed: 274 ins; 41 del; 51 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9296

From dcubed at openjdk.org  Mon Jun 27 18:44:26 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 27 Jun 2022 18:44:26 GMT
Subject: [jdk19] RFR: 8289240: ProblemList
 java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode
Message-ID: <kmaca6H1BOBz3kZzs6czC-HOMyDO4IjrmlMXTzVCATY=.69541f8c-d6f3-43dd-9ee3-cdbcf5e67b65@github.com>

A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode.

-------------

Commit messages:
 - 8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode

Changes: https://git.openjdk.org/jdk19/pull/78/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=78&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289240
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk19/pull/78.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/78/head:pull/78

PR: https://git.openjdk.org/jdk19/pull/78

From dcubed at openjdk.org  Mon Jun 27 18:44:27 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 27 Jun 2022 18:44:27 GMT
Subject: [jdk19] RFR: 8289240: ProblemList
 java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode
In-Reply-To: <_D7m0WPWPZaDi5PuvZTgzb1-xZXtRFfkaDFcc3Ykjdg=.b52f30eb-8acf-4aed-af8c-90ce8e19f2f3@github.com>
References: <kmaca6H1BOBz3kZzs6czC-HOMyDO4IjrmlMXTzVCATY=.69541f8c-d6f3-43dd-9ee3-cdbcf5e67b65@github.com>
 <_D7m0WPWPZaDi5PuvZTgzb1-xZXtRFfkaDFcc3Ykjdg=.b52f30eb-8acf-4aed-af8c-90ce8e19f2f3@github.com>
Message-ID: <ZLVPJ9v1zCQJqVpq6ttmuJ23MejsoEoCdNNvKuQwrP8=.d28d2130-373c-460f-88e7-e7ed75ddd0b6@github.com>

On Mon, 27 Jun 2022 18:38:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode.
>
> Marked as reviewed by bpb (Reviewer).

@bplb and @naotoj  - Thanks for the fast reviews!

-------------

PR: https://git.openjdk.org/jdk19/pull/78

From bpb at openjdk.org  Mon Jun 27 18:44:27 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Jun 2022 18:44:27 GMT
Subject: [jdk19] RFR: 8289240: ProblemList
 java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode
In-Reply-To: <kmaca6H1BOBz3kZzs6czC-HOMyDO4IjrmlMXTzVCATY=.69541f8c-d6f3-43dd-9ee3-cdbcf5e67b65@github.com>
References: <kmaca6H1BOBz3kZzs6czC-HOMyDO4IjrmlMXTzVCATY=.69541f8c-d6f3-43dd-9ee3-cdbcf5e67b65@github.com>
Message-ID: <_D7m0WPWPZaDi5PuvZTgzb1-xZXtRFfkaDFcc3Ykjdg=.b52f30eb-8acf-4aed-af8c-90ce8e19f2f3@github.com>

On Mon, 27 Jun 2022 18:35:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/78

From naoto at openjdk.org  Mon Jun 27 18:44:27 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Jun 2022 18:44:27 GMT
Subject: [jdk19] RFR: 8289240: ProblemList
 java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode
In-Reply-To: <kmaca6H1BOBz3kZzs6czC-HOMyDO4IjrmlMXTzVCATY=.69541f8c-d6f3-43dd-9ee3-cdbcf5e67b65@github.com>
References: <kmaca6H1BOBz3kZzs6czC-HOMyDO4IjrmlMXTzVCATY=.69541f8c-d6f3-43dd-9ee3-cdbcf5e67b65@github.com>
Message-ID: <4n5WHpwy0Qw5pR3NNpfTtb2RkeXOMsbfcK6U9EEpy3c=.37fe5513-d46b-43c4-8c23-7598832823b5@github.com>

On Mon, 27 Jun 2022 18:35:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/78

From dcubed at openjdk.org  Mon Jun 27 18:47:40 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 27 Jun 2022 18:47:40 GMT
Subject: [jdk19] Integrated: 8289240: ProblemList
 java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode
In-Reply-To: <kmaca6H1BOBz3kZzs6czC-HOMyDO4IjrmlMXTzVCATY=.69541f8c-d6f3-43dd-9ee3-cdbcf5e67b65@github.com>
References: <kmaca6H1BOBz3kZzs6czC-HOMyDO4IjrmlMXTzVCATY=.69541f8c-d6f3-43dd-9ee3-cdbcf5e67b65@github.com>
Message-ID: <38hB-Dnf-useQA0gfQMZK0WVX4-7eEJxLp2_3vpBpQk=.b38f84f9-6680-4ad6-9f0c-1ef949dd515b@github.com>

On Mon, 27 Jun 2022 18:35:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode.

This pull request has now been integrated.

Changeset: caa6b74b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/caa6b74b5b2d641ca8fe2e226e09ce1b556eb2fc
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode

Reviewed-by: bpb, naoto

-------------

PR: https://git.openjdk.org/jdk19/pull/78

From mcimadamore at openjdk.org  Mon Jun 27 20:40:43 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Jun 2022 20:40:43 GMT
Subject: [jdk19] RFR: 8289228: SegmentAllocator::allocateArray null
 handling is too lax [v2]
In-Reply-To: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>
References: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>
Message-ID: <hRqHoeAxFFiB9a7ERdtYk6aGh15Gwodmtkb2wTbew8I=.bc689979-629b-4b3b-ba89-1d62482aa9be@github.com>

> Recent fix for JDK-8289188 relaxed behavior or `SegmentAllocator::allocateArray` too much w.r.t. nulls. This patch reverts null handling to what it used to be.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Revert test

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/76/files
  - new: https://git.openjdk.org/jdk19/pull/76/files/0bbf661b..db170f14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=76&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=76&range=00-01

  Stats: 15 lines in 1 file changed: 0 ins; 14 del; 1 mod
  Patch: https://git.openjdk.org/jdk19/pull/76.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/76/head:pull/76

PR: https://git.openjdk.org/jdk19/pull/76

From mcimadamore at openjdk.org  Mon Jun 27 20:40:44 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Jun 2022 20:40:44 GMT
Subject: [jdk19] RFR: 8289228: SegmentAllocator::allocateArray null
 handling is too lax [v2]
In-Reply-To: <hXkouClHXjLtwx-sXGxmIEGFHpWLnMoffnyaUifuxBc=.b244e544-e63d-4f17-b668-83a8ba9f035f@github.com>
References: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>
 <hXkouClHXjLtwx-sXGxmIEGFHpWLnMoffnyaUifuxBc=.b244e544-e63d-4f17-b668-83a8ba9f035f@github.com>
Message-ID: <GzChfdLYdOnLTG5Z5Rv51pHNFSnLCDHbYRPoGpzePRg=.6cb6b9f3-a65c-4523-bd16-21607d1404d2@github.com>

On Mon, 27 Jun 2022 17:28:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Should test/jdk/java/foreign/TestNulls.java also be reverted?

Yes, I thought I did that, but the changes got reverted by the merge I did. Re-added the changes now.

-------------

PR: https://git.openjdk.org/jdk19/pull/76

From dcubed at openjdk.org  Mon Jun 27 21:28:45 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 27 Jun 2022 21:28:45 GMT
Subject: [jdk19] Integrated: 8289251: ProblemList
 java/lang/ref/OOMEInReferenceHandler.java
Message-ID: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com>

A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java.

-------------

Commit messages:
 - 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java

Changes: https://git.openjdk.org/jdk19/pull/80/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=80&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289251
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk19/pull/80.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/80/head:pull/80

PR: https://git.openjdk.org/jdk19/pull/80

From dholmes at openjdk.org  Mon Jun 27 21:28:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 Jun 2022 21:28:45 GMT
Subject: [jdk19] Integrated: 8289251: ProblemList
 java/lang/ref/OOMEInReferenceHandler.java
In-Reply-To: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com>
References: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com>
Message-ID: <v7fZFqU-c8i2W8iYN2GD0OmaSieiIXS6d21nTs2sIY8=.4803cb86-b6b1-4bcd-8eae-0d29ff917cf2@github.com>

On Mon, 27 Jun 2022 21:16:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java.

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/80

From dcubed at openjdk.org  Mon Jun 27 21:28:47 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 27 Jun 2022 21:28:47 GMT
Subject: [jdk19] Integrated: 8289251: ProblemList
 java/lang/ref/OOMEInReferenceHandler.java
In-Reply-To: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com>
References: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com>
Message-ID: <POLPfgLxi_DmX5v6l6IQodSmJv3GvMu_OFCjKVjnsIE=.50084ef3-a830-415c-8676-48e232c07f97@github.com>

On Mon, 27 Jun 2022 21:16:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java.

This pull request has now been integrated.

Changeset: 2efa89a8
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/2efa89a89e01003e2d161ffc0d377c39fd18acb8
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk19/pull/80

From dcubed at openjdk.org  Mon Jun 27 21:28:46 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 27 Jun 2022 21:28:46 GMT
Subject: [jdk19] Integrated: 8289251: ProblemList
 java/lang/ref/OOMEInReferenceHandler.java
In-Reply-To: <v7fZFqU-c8i2W8iYN2GD0OmaSieiIXS6d21nTs2sIY8=.4803cb86-b6b1-4bcd-8eae-0d29ff917cf2@github.com>
References: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com>
 <v7fZFqU-c8i2W8iYN2GD0OmaSieiIXS6d21nTs2sIY8=.4803cb86-b6b1-4bcd-8eae-0d29ff917cf2@github.com>
Message-ID: <abx45h6jYIynjtsikoVVY2gglB_LtBrCYFPhvvK_0mg=.2ee314f0-0a63-455c-9e1d-80ea843b1bec@github.com>

On Mon, 27 Jun 2022 21:17:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java.
>
> Marked as reviewed by dholmes (Reviewer).

@dholmes-ora - Thanks for the lightning fast review!

-------------

PR: https://git.openjdk.org/jdk19/pull/80

From almatvee at openjdk.org  Mon Jun 27 21:39:44 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 27 Jun 2022 21:39:44 GMT
Subject: RFR: 8288961: jpackage: test MSI installation fix
In-Reply-To: <rjbj93A-x52yIC4nqt_tdewEovug8Sooy1WwkD2xEFU=.d9d00563-f587-4c94-bc34-2f4a06fb3ff4@github.com>
References: <rjbj93A-x52yIC4nqt_tdewEovug8Sooy1WwkD2xEFU=.d9d00563-f587-4c94-bc34-2f4a06fb3ff4@github.com>
Message-ID: <xIv6pW9O3BzdsTjL8z7FTtyqbPAQQ1yQiW_5uqbT6AM=.955910a3-03c7-4aee-9dc3-de24d2da5557@github.com>

On Wed, 22 Jun 2022 11:53:39 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> Please review this minor fix to the jpackage test suite.
> 
> When `INSTALL` and `UNINSTALL` actions are enabled for jpackage test suite runs (disabled by default), installation of `EXE` and `MSI` packages is performed. `EXE` package is invoked directly and `MSI` package is installed using `msiexec` utility. In both cases the path of the packages starts with a "." (current dir) symbol, it is processed correctly with EXE installation, but not with MSI, example:
> 
> 
> [03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
> [03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
> [03:52:19.634] TRACE: exec: Execute [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
> [03:52:19.790] TRACE: exec: Done. Exit code: 1619
> [03:52:19.805] ERROR: Expected [0]. Actual [1619]: Check command [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code 
> 
> 
> Is is proposed to normalize the path passed to `msiexec`, in this case installation will succeed:
> 
> 
> [03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
> [03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
> [03:56:52.429] TRACE: exec: Execute [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
> [03:56:57.067] TRACE: exec: Done. Exit code: 0
> [03:56:57.067] TRACE: assertEquals(0): Check command [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9236

From almatvee at openjdk.org  Mon Jun 27 21:48:45 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 27 Jun 2022 21:48:45 GMT
Subject: RFR: 8288013: jpackage: test utility Windows registry enhancement
In-Reply-To: <lFIf18LPCwDIoTtS2foBhR9ZZ-1LElZjPKcTDtktjOE=.dd399490-2bd0-4286-a256-d5d9cb61f1e3@github.com>
References: <lFIf18LPCwDIoTtS2foBhR9ZZ-1LElZjPKcTDtktjOE=.dd399490-2bd0-4286-a256-d5d9cb61f1e3@github.com>
Message-ID: <dAmMaahh8MXDY9OUlAZNhHh8y4d2dYVR0Mh4kM8IQy0=.f4ef9496-03b7-41e2-8d92-9dd7294b63b7@github.com>

On Wed, 8 Jun 2022 11:46:42 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> In jpackage test suite there is a test utility WindowsHelper.queryRegistryValue . It is used to verify changes to Windows registry that can be done by installer packages. It spawns `reg.exe query` process and parses its output. This patch adds support for quering empty values and additional REG_* datatypes.
> 
> Correctness was verified manually with the following registry values:
> 
> 
>         //    (Default)    REG_SZ    test1
>         //    string_val    REG_SZ    test2
>         //    string_val_empty    REG_SZ
>         //    bin_val    REG_BINARY    4242
>         //    bin_val_empty    REG_BINARY
>         //    dword_val    REG_DWORD    0x2a
>         //    qword_val    REG_QWORD    0x2a
>         //    multi_string_val    REG_MULTI_SZ    test3\0test4
>         //    multi_string_val_empty    REG_MULTI_SZ
>         //    expand_string_val    REG_EXPAND_SZ    test5
>         //    expand_string_val_empty    REG_EXPAND_SZ
> 
> 
> Corresponding utility output:
> 
> 
> [04:36:38.190] TRACE: Registry value [] at [...] path is [test1]
> [04:36:38.220] TRACE: Registry value [string_val] at [...] path is [test2]
> [04:36:38.251] TRACE: Registry value [string_val_empty] at [...] path is []
> [04:36:38.282] TRACE: Registry value [bin_val] at [...] path is [4242]
> [04:36:38.315] TRACE: Registry value [bin_val_empty] at [...] path is []
> [04:36:38.347] TRACE: Registry value [dword_val] at [...] path is [0x2a]
> [04:36:38.378] TRACE: Registry value [qword_val] at [...] path is [0x2a]
> [04:36:38.410] TRACE: Registry value [multi_string_val] at [...] path is [test3\\0test4]
> [04:36:38.441] TRACE: Registry value [multi_string_val_empty] at [...] path is []
> [04:36:38.473] TRACE: Registry value [expand_string_val] at [...] path is [test5]
> [04:36:38.506] TRACE: Registry value [expand_string_val_empty] at [...] path is []
> 
> 
> Testing:
> 
>  - [x] ran "jtreg:jdk/tools/jpackage/windows" before and after the patch

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9083

From jvernee at openjdk.org  Mon Jun 27 21:55:39 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 27 Jun 2022 21:55:39 GMT
Subject: [jdk19] RFR: 8289228: SegmentAllocator::allocateArray null
 handling is too lax [v2]
In-Reply-To: <hRqHoeAxFFiB9a7ERdtYk6aGh15Gwodmtkb2wTbew8I=.bc689979-629b-4b3b-ba89-1d62482aa9be@github.com>
References: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>
 <hRqHoeAxFFiB9a7ERdtYk6aGh15Gwodmtkb2wTbew8I=.bc689979-629b-4b3b-ba89-1d62482aa9be@github.com>
Message-ID: <3bT0LOmssaPPYYaLGd7EHbg-eKXMeNA3esWDFbCSevo=.0f41a3eb-ee82-4126-aee9-3f805bb0962a@github.com>

On Mon, 27 Jun 2022 20:40:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Recent fix for JDK-8289188 relaxed behavior or `SegmentAllocator::allocateArray` too much w.r.t. nulls. This patch reverts null handling to what it used to be.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert test

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/76

From psandoz at openjdk.org  Mon Jun 27 22:35:50 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 27 Jun 2022 22:35:50 GMT
Subject: [jdk19] RFR: 8289228: SegmentAllocator::allocateArray null
 handling is too lax [v2]
In-Reply-To: <hRqHoeAxFFiB9a7ERdtYk6aGh15Gwodmtkb2wTbew8I=.bc689979-629b-4b3b-ba89-1d62482aa9be@github.com>
References: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>
 <hRqHoeAxFFiB9a7ERdtYk6aGh15Gwodmtkb2wTbew8I=.bc689979-629b-4b3b-ba89-1d62482aa9be@github.com>
Message-ID: <f2N7D1M8ZhQnBJN5Qm_5UmuphNGM8aoxzlIX8FRXUV8=.30e32aff-15a4-4980-b23d-5254da6113c2@github.com>

On Mon, 27 Jun 2022 20:40:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Recent fix for JDK-8289188 relaxed behavior or `SegmentAllocator::allocateArray` too much w.r.t. nulls. This patch reverts null handling to what it used to be.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert test

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/76

From tvoniadka at openjdk.org  Tue Jun 28 01:58:00 2022
From: tvoniadka at openjdk.org (Thejasvi Voniadka)
Date: Tue, 28 Jun 2022 01:58:00 GMT
Subject: Integrated: 8282036: Change java/util/zip/ZipFile/DeleteTempJar.java
 to stop HttpServer cleanly in case of exceptions
In-Reply-To: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
Message-ID: <Dy1G2LulGY73VGhfeFJlMTdnkmK83RJv9nUmVeMsxO8=.1896d6e6-e0b0-4f8e-99bd-cfa1da0cefa8@github.com>

On Mon, 27 Jun 2022 04:50:09 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
> 
> The test passes on all supported platforms post fix.

This pull request has now been integrated.

Changeset: 784fa0ad
Author:    Thejasvi Voniadka <tvoniadka at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/784fa0add77a3e473e2cdbdcc27b3ed076678565
Stats:     12 lines in 1 file changed: 4 ins; 1 del; 7 mod

8282036: Change java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions

Reviewed-by: jpai, alanb, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/9293

From tvoniadka at openjdk.org  Tue Jun 28 03:17:41 2022
From: tvoniadka at openjdk.org (Thejasvi Voniadka)
Date: Tue, 28 Jun 2022 03:17:41 GMT
Subject: RFR: 8282036: Change java/util/zip/ZipFile/DeleteTempJar.java to
 stop HttpServer cleanly in case of exceptions
In-Reply-To: <mgZiVy1oe48G1R9zzMEpcndnMObkSB1pwMxFzruigTg=.c9480c8c-1203-4e44-958b-1c76c4b99b6a@github.com>
References: <6Qt7llkwsAUirkzn6CepWGxuuHyHPHU1ZNuscmsSggw=.29b86e0a-eb84-4000-ac12-0a29a1e996ad@github.com>
 <mgZiVy1oe48G1R9zzMEpcndnMObkSB1pwMxFzruigTg=.c9480c8c-1203-4e44-958b-1c76c4b99b6a@github.com>
Message-ID: <TMg5YmIkIzSdgcsXp3N9t5icWUG-TmhGo9m7T4tJbGc=.5d8a552e-c695-4428-b240-d0a0f382d5c3@github.com>

On Mon, 27 Jun 2022 05:32:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This is a simple change to add some protective code to java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more complete in the event of encountering an any exceptions while running. In the present state, the server.stop() does not get executed in case of encountering a failure. As a result, the test may get hung until a timeout. This fix should address the scenario.
>> 
>> The test passes on all supported platforms post fix.
>
> Hello Thejasvi, the change looks good to me. Please update the copyright year to 2022 in this changed file.

Thank you much @jaikiran for timely reviews, feedback, and sponsoring this commit. Also thank you @AlanBateman and @dfuch for your kind review and feedback.

-------------

PR: https://git.openjdk.org/jdk/pull/9293

From jbhateja at openjdk.org  Tue Jun 28 06:11:49 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 28 Jun 2022 06:11:49 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
Message-ID: <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>

On Wed, 22 Jun 2022 03:01:36 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comparison for direct value of compare

src/hotspot/cpu/x86/x86_64.ad line 13027:

> 13025: // Manifest a CmpU result in an integer register.  Very painful.
> 13026: // This is the test to avoid.
> 13027: instruct cmpU3_reg_reg(rRegI dst, rRegI src1, rRegI src2, rFlagsReg flags)

Do you plan to add 32 bit support?
Integer pattern can be moved to common file x86.ad and 64 pattern can handled in 32/64 bit AD files.

src/hotspot/cpu/x86/x86_64.ad line 13043:

> 13041:     __ cmpl($src1$$Register, $src2$$Register);
> 13042:     __ movl($dst$$Register, -1);
> 13043:     __ jccb(Assembler::below, done);

By placing compare adjacent to conditional jump in-order frontend can trigger macro-fusion. 
Kindly refer section 3.4.2.2 of Intel's optimization manual.

src/hotspot/cpu/x86/x86_64.ad line 13095:

> 13093:     __ cmpq($src1$$Register, $src2$$Register);
> 13094:     __ movl($dst$$Register, -1);
> 13095:     __ jccb(Assembler::below, done);

Same as above.

src/hotspot/share/opto/subnode.hpp line 185:

> 183:   }
> 184:   virtual int Opcode() const;
> 185:   virtual uint ideal_reg() const { return Op_RegI; }

Value routine to handle constant folding.

src/hotspot/share/opto/subnode.hpp line 247:

> 245:     init_class_id(Class_Sub);
> 246:   }
> 247:   virtual int Opcode() const;

In-lining may connect the inputs to constant, hence a Value routine may be useful here.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Tue Jun 28 06:32:43 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Tue, 28 Jun 2022 06:32:43 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
Message-ID: <XHxgsemfZU45zxBXyKgkdOXyF5AgZc3tFrc224_eRR4=.13a1cccd-cccc-42e5-bcb9-9a0b389ee75e@github.com>

On Tue, 28 Jun 2022 05:51:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comparison for direct value of compare
>
> src/hotspot/cpu/x86/x86_64.ad line 13027:
> 
>> 13025: // Manifest a CmpU result in an integer register.  Very painful.
>> 13026: // This is the test to avoid.
>> 13027: instruct cmpU3_reg_reg(rRegI dst, rRegI src1, rRegI src2, rFlagsReg flags)
> 
> Do you plan to add 32 bit support?
> Integer pattern can be moved to common file x86.ad and 64 pattern can handled in 32/64 bit AD files.

Yes I will add support for 32-bit after this patch, basic rules are often put in the bit-specific ad file so I think it would be more preferable to follow that convention here.

> src/hotspot/share/opto/subnode.hpp line 247:
> 
>> 245:     init_class_id(Class_Sub);
>> 246:   }
>> 247:   virtual int Opcode() const;
> 
> In-lining may connect the inputs to constant, hence a Value routine may be useful here.

`CmpU3` inherits the `Value` method from its superclass `CmpU`

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Tue Jun 28 07:10:52 2022
From: duke at openjdk.org (rmartinc)
Date: Tue, 28 Jun 2022 07:10:52 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit [v2]
In-Reply-To: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
Message-ID: <uAamStjg20skBRLKyIsF-hS7AM2u1FltCkthy2TjsXw=.b7f1528d-a09b-44d8-ba17-0a55d08daaca@github.com>

> Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895).
> 
> Any `LimitExceededException` now quits the referral loop.
> 
> Added class `ReferralLimitSearchTest`. It is a simple jtreg test which checks that `java.naming.ldap.referral.limit` is really enforced. The dummy ldap server always returns a referral for any search query. If the number of searches exceeds the limit, it throws an `IOException` and the test fails.
> 
> 
> make test TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java

rmartinc 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:

  8288895: LdapContext doesn't honor set referrals limit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9256/files
  - new: https://git.openjdk.org/jdk/pull/9256/files/a04d123c..09961af7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9256&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9256&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9256.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9256/head:pull/9256

PR: https://git.openjdk.org/jdk/pull/9256

From duke at openjdk.org  Tue Jun 28 07:10:54 2022
From: duke at openjdk.org (rmartinc)
Date: Tue, 28 Jun 2022 07:10:54 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit [v2]
In-Reply-To: <qtytlbPln_MqP3tdlUIhOwy7Yr-l5wvGJaj54tp0fTY=.1bc4ed19-6e9d-4909-96bc-d7785f4c49e8@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
 <qtytlbPln_MqP3tdlUIhOwy7Yr-l5wvGJaj54tp0fTY=.1bc4ed19-6e9d-4909-96bc-d7785f4c49e8@github.com>
Message-ID: <aOo8jkuYv_-nCY_Lj1R1oH1xUBDRlnB5KdMjraY6-sI=.22c146d2-5e2f-4d1d-bc9c-4c59b3705880@github.com>

On Mon, 27 Jun 2022 14:57:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> rmartinc 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:
>> 
>>   8288895: LdapContext doesn't honor set referrals limit
>
> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 339:
> 
>> 337:                         break;
>> 338:                     } else if (errEx == null) {
>> 339:                         errEx = re.getNamingException();
> 
> Could we set up a local variable here to avoid calling re.getNamingException() more than once?
> e.g. something like:
> 
> 
> var cause = re.getNamingException();
> if (cause instanceof ...) {
> 
> 
> then use `cause` throughout.

Yes, of course, I just called the var `namingException` instead of `cause`. It's done now.

-------------

PR: https://git.openjdk.org/jdk/pull/9256

From aturbanov at openjdk.org  Tue Jun 28 07:30:42 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Jun 2022 07:30:42 GMT
Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in
 java.time [v2]
In-Reply-To: <OoSH2yLNim7NygIHCkn8uasHe92t8v6UqhlH8obgavM=.0011a3ac-a881-4721-b938-073d7ad0c8a1@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <YvqHz0tTpqqN-X0evw3C0GdubG6m435J_gvFpVkCZvM=.11697c65-a20e-428d-bc8e-e56d01848b52@github.com>
 <OoSH2yLNim7NygIHCkn8uasHe92t8v6UqhlH8obgavM=.0011a3ac-a881-4721-b938-073d7ad0c8a1@github.com>
Message-ID: <IKtphady07STgw-sX9HTmaT3_noNWFeq4pL4U5LE2nc=.cd595c0e-5a1f-42b1-902c-fd7886a2e579@github.com>

On Fri, 24 Jun 2022 07:22:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288723: Avoid redundant ConcurrentHashMap.get call in java.time
>>   use computeIfAbsent where lambda could be short and static
>
> src/java.base/share/classes/java/time/temporal/WeekFields.java line 331:
> 
>> 329:         String key = firstDayOfWeek.toString() + minimalDaysInFirstWeek;
>> 330:         WeekFields rules = CACHE.get(key);
>> 331:         if (rules == null) {
> 
> Perhaps you don't even need this `if` block and the preceding `CACHE.get(key)` and maybe it can be replaced with:
> 
> 
> return CACHE.computeIfAbsent(key, ignore -> new WeekFields(firstDayOfWeek, minimalDaysInFirstWeek));

But it will generate garbage: non-static lambda.

-------------

PR: https://git.openjdk.org/jdk/pull/9208

From jbhateja at openjdk.org  Tue Jun 28 07:39:41 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 28 Jun 2022 07:39:41 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <XHxgsemfZU45zxBXyKgkdOXyF5AgZc3tFrc224_eRR4=.13a1cccd-cccc-42e5-bcb9-9a0b389ee75e@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
 <XHxgsemfZU45zxBXyKgkdOXyF5AgZc3tFrc224_eRR4=.13a1cccd-cccc-42e5-bcb9-9a0b389ee75e@github.com>
Message-ID: <QLnfxHEgKbiD8k7sbZoxrCkZwMScDrABCKql0k7UjbQ=.edb5c5db-7735-49ff-b844-610343fc58e3@github.com>

On Tue, 28 Jun 2022 06:29:03 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> src/hotspot/share/opto/subnode.hpp line 247:
>> 
>>> 245:     init_class_id(Class_Sub);
>>> 246:   }
>>> 247:   virtual int Opcode() const;
>> 
>> In-lining may connect the inputs to constant, hence a Value routine may be useful here.
>
> `CmpU3` inherits the `Value` method from its superclass `CmpU`

Its fine then.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Tue Jun 28 07:56:43 2022
From: duke at openjdk.org (rmartinc)
Date: Tue, 28 Jun 2022 07:56:43 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit [v2]
In-Reply-To: <aOo8jkuYv_-nCY_Lj1R1oH1xUBDRlnB5KdMjraY6-sI=.22c146d2-5e2f-4d1d-bc9c-4c59b3705880@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
 <qtytlbPln_MqP3tdlUIhOwy7Yr-l5wvGJaj54tp0fTY=.1bc4ed19-6e9d-4909-96bc-d7785f4c49e8@github.com>
 <aOo8jkuYv_-nCY_Lj1R1oH1xUBDRlnB5KdMjraY6-sI=.22c146d2-5e2f-4d1d-bc9c-4c59b3705880@github.com>
Message-ID: <aHShW5BC0qefMW1SchBMIjFVXe0AHdsIEf-bEr2in90=.fabbddb4-32bb-4471-a30e-61390f5d8f9c@github.com>

On Tue, 28 Jun 2022 07:07:24 GMT, rmartinc <duke at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 339:
>> 
>>> 337:                         break;
>>> 338:                     } else if (errEx == null) {
>>> 339:                         errEx = re.getNamingException();
>> 
>> Could we set up a local variable here to avoid calling re.getNamingException() more than once?
>> e.g. something like:
>> 
>> 
>> var cause = re.getNamingException();
>> if (cause instanceof ...) {
>> 
>> 
>> then use `cause` throughout.
>
> Yes, of course, I just called the var `namingException` instead of `cause`. It's done now.

Sorry! I have squashed the two commits... I didn't know the system will do it before merging. ?

-------------

PR: https://git.openjdk.org/jdk/pull/9256

From simonis at openjdk.org  Tue Jun 28 10:02:45 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 28 Jun 2022 10:02:45 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v10]
In-Reply-To: <D0w1dcTNxXKazOefuiDTAy_q-U64OBM2LTr421SpAzw=.a5c9b665-f1f0-43db-bcbe-53b7f59209f8@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <D0w1dcTNxXKazOefuiDTAy_q-U64OBM2LTr421SpAzw=.a5c9b665-f1f0-43db-bcbe-53b7f59209f8@github.com>
Message-ID: <Rv-Deg1KFq3eyC2BA4B9OkkLXeRmWz0w1tp0jb8b9jg=.eae57b58-9539-44be-8c73-7178150525d2@github.com>

On Mon, 9 May 2022 09:56:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://urldefense.com/v3/__https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h*L400__;Iw!!ACWV5N9M2RV99hQ!LHVgTXK1fYijoD2IGaifQDAfIoGFhlxsWxgN7fkEKDO3EKvz4i65A6npmScKJirTuLiVCYftP6-q7uF8S0Q7qQPk$ )) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://urldefense.com/v3/__https://chromium.googlesource.com/chromium/src/third_party/zlib/__;!!ACWV5N9M2RV99hQ!LHVgTXK1fYijoD2IGaifQDAfIoGFhlxsWxgN7fkEKDO3EKvz4i65A6npmScKJirTuLiVCYftP6-q7uF8S-wN6HtN$ ) or [zlib-cloudflare](https://urldefense.com/v3/__https://github.com/cloudflare/zlib__;!!ACWV5N9M2RV99hQ!LHVgTXK1fYijoD2IGaifQDAfIoGFhlxsWxgN7fkEKDO3EKvz4i65A6npmScKJirTuLiVCYftP6-q7uF8S1_16CvU$ ) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://urldefense.com/v3/__https://github.com/simonis/zlib-chromium__;!!ACWV5N9M2RV99hQ!LHVgTXK1fYijoD2IGaifQDAfIoGFhlxsWxgN7fkEKDO3EKvz4i65A6npmScKJirTuLiVCYftP6-q7uF8Swurr3Vo$  for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated wording based on @JoeDarcy's third CSR review

Just to keep the PR alive...

-------------

PR: https://git.openjdk.org/jdk/pull/7986

From mcimadamore at openjdk.org  Tue Jun 28 10:10:43 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Jun 2022 10:10:43 GMT
Subject: [jdk19] Integrated: 8289228: SegmentAllocator::allocateArray null
 handling is too lax
In-Reply-To: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>
References: <up-Q08BiHkpx0bDaU3396jeMGyR47eRZGVjgka18JUo=.8e59df54-d801-4bc2-964f-7cdc0350022a@github.com>
Message-ID: <gqVLlWs7rIuWgXkpGS6JgF6T8ICKlFGxTMCXhCCk76I=.fa547345-b6d2-4fcf-899f-c28874d7b0fe@github.com>

On Mon, 27 Jun 2022 16:47:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Recent fix for JDK-8289188 relaxed behavior or `SegmentAllocator::allocateArray` too much w.r.t. nulls. This patch reverts null handling to what it used to be.

This pull request has now been integrated.

Changeset: adbd200d
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/adbd200dc59c31ad582b51468ec39af5a64db664
Stats:     17 lines in 2 files changed: 1 ins; 14 del; 2 mod

8289228: SegmentAllocator::allocateArray null handling is too lax

Reviewed-by: jvernee, psandoz

-------------

PR: https://git.openjdk.org/jdk19/pull/76

From duke at openjdk.org  Tue Jun 28 10:19:09 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Jun 2022 10:19:09 GMT
Subject: RFR: 8289260: BigDecimal movePointLeft() and movePointRight() do not
 follow their API spec
Message-ID: <GVFLjJjTSYxwy1oHLNRgD8Tej8JyFAiA241b89w1gt4=.c2dbd2b6-3d28-4372-bae0-792b48207883@github.com>

`BigDecimal.morePoint[Left|Right]()` should return the target `this` when the argument is 0 _and_ the scale is non-negative.

-------------

Commit messages:
 - 8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec
 - 8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec

Changes: https://git.openjdk.org/jdk/pull/9307/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9307&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289260
  Stats: 76 lines in 2 files changed: 74 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9307.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9307/head:pull/9307

PR: https://git.openjdk.org/jdk/pull/9307

From duke at openjdk.org  Tue Jun 28 10:32:31 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Jun 2022 10:32:31 GMT
Subject: RFR: 8289260: BigDecimal movePointLeft() and movePointRight() do
 not follow their API spec [v2]
In-Reply-To: <GVFLjJjTSYxwy1oHLNRgD8Tej8JyFAiA241b89w1gt4=.c2dbd2b6-3d28-4372-bae0-792b48207883@github.com>
References: <GVFLjJjTSYxwy1oHLNRgD8Tej8JyFAiA241b89w1gt4=.c2dbd2b6-3d28-4372-bae0-792b48207883@github.com>
Message-ID: <6IlMf8sU-acr2ck6Ao0q211RBuc1SdCDx_pMHLkqBQ8=.c422a523-6e77-4f44-b0cd-95b4f184544a@github.com>

> `BigDecimal.morePoint[Left|Right]()` should return the target `this` when the argument is 0 _and_ the scale is non-negative.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9307/files
  - new: https://git.openjdk.org/jdk/pull/9307/files/02b28330..9755bb12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9307&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9307&range=00-01

  Stats: 33 lines in 1 file changed: 32 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9307.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9307/head:pull/9307

PR: https://git.openjdk.org/jdk/pull/9307

From mcimadamore at openjdk.org  Tue Jun 28 11:19:46 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Jun 2022 11:19:46 GMT
Subject: [jdk19] RFR: 8289223: Canonicalize header ids in foreign API
 javadocs
In-Reply-To: <tlJvjtrekgi5NfINGsgYofTPKIYx-ABKT-sOCRikJr8=.f2a3810a-b2d0-488e-ac28-7f59cd67b9d7@github.com>
References: <Ztm8vbJi2r2bPp_YtGHVJ7pxP6HnMZCOdq6wmQk0XcM=.49c22232-74c6-4614-88a8-5671ae16b5c9@github.com>
 <BdKGaT58yqJzzHL0Ch4p-RXoDAHKYyeubxVfETY-kng=.e30c4438-ebff-47a0-b4fe-07256d27cb7b@github.com>
 <tlJvjtrekgi5NfINGsgYofTPKIYx-ABKT-sOCRikJr8=.f2a3810a-b2d0-488e-ac28-7f59cd67b9d7@github.com>
Message-ID: <rxoDXZ8k2_mDKrfxyp68OtpVTmMFnLGBUJLFXCj-Nvw=.356433d4-5ccb-436c-a65e-970b469a93e2@github.com>

On Mon, 27 Jun 2022 17:02:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/package-info.java line 30:
>> 
>>> 28:  * <p>Provides low-level access to memory and functions outside the Java runtime.
>>> 29:  *
>>> 30:  * <h2 id="fma">Foreign memory access</h2>
>> 
>> I would refrain from adding `id` if the section is never referred to.
>
> The idea is that a user might want to link to this section of the javadoc (using the new copy button). For that to be possible, the section needs an `id`. That's why I've added one to all headers. i.e. it's not just for referencing it from the javadoc in other places.

I see what you mean - at the same time I don't see being done anywhere else in JDK, so perhaps can wait until we settle on a more uniform solution?

-------------

PR: https://git.openjdk.org/jdk19/pull/75

From akasko at openjdk.org  Tue Jun 28 11:33:42 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Tue, 28 Jun 2022 11:33:42 GMT
Subject: RFR: 8288013: jpackage: test utility Windows registry enhancement
In-Reply-To: <lFIf18LPCwDIoTtS2foBhR9ZZ-1LElZjPKcTDtktjOE=.dd399490-2bd0-4286-a256-d5d9cb61f1e3@github.com>
References: <lFIf18LPCwDIoTtS2foBhR9ZZ-1LElZjPKcTDtktjOE=.dd399490-2bd0-4286-a256-d5d9cb61f1e3@github.com>
Message-ID: <yCBjKNxBgCz0xHoNZRPpszwtWTeH7Bz8BADHdv87Q9Q=.b9548bf1-710e-4d17-8966-56f7c478765e@github.com>

On Wed, 8 Jun 2022 11:46:42 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> In jpackage test suite there is a test utility WindowsHelper.queryRegistryValue . It is used to verify changes to Windows registry that can be done by installer packages. It spawns `reg.exe query` process and parses its output. This patch adds support for quering empty values and additional REG_* datatypes.
> 
> Correctness was verified manually with the following registry values:
> 
> 
>         //    (Default)    REG_SZ    test1
>         //    string_val    REG_SZ    test2
>         //    string_val_empty    REG_SZ
>         //    bin_val    REG_BINARY    4242
>         //    bin_val_empty    REG_BINARY
>         //    dword_val    REG_DWORD    0x2a
>         //    qword_val    REG_QWORD    0x2a
>         //    multi_string_val    REG_MULTI_SZ    test3\0test4
>         //    multi_string_val_empty    REG_MULTI_SZ
>         //    expand_string_val    REG_EXPAND_SZ    test5
>         //    expand_string_val_empty    REG_EXPAND_SZ
> 
> 
> Corresponding utility output:
> 
> 
> [04:36:38.190] TRACE: Registry value [] at [...] path is [test1]
> [04:36:38.220] TRACE: Registry value [string_val] at [...] path is [test2]
> [04:36:38.251] TRACE: Registry value [string_val_empty] at [...] path is []
> [04:36:38.282] TRACE: Registry value [bin_val] at [...] path is [4242]
> [04:36:38.315] TRACE: Registry value [bin_val_empty] at [...] path is []
> [04:36:38.347] TRACE: Registry value [dword_val] at [...] path is [0x2a]
> [04:36:38.378] TRACE: Registry value [qword_val] at [...] path is [0x2a]
> [04:36:38.410] TRACE: Registry value [multi_string_val] at [...] path is [test3\\0test4]
> [04:36:38.441] TRACE: Registry value [multi_string_val_empty] at [...] path is []
> [04:36:38.473] TRACE: Registry value [expand_string_val] at [...] path is [test5]
> [04:36:38.506] TRACE: Registry value [expand_string_val_empty] at [...] path is []
> 
> 
> Testing:
> 
>  - [x] ran "jtreg:jdk/tools/jpackage/windows" before and after the patch

Thanks for the reviews! I don't have Committer role in JDK Project, would appreciate if someone can push it.

-------------

PR: https://git.openjdk.org/jdk/pull/9083

From akasko at openjdk.org  Tue Jun 28 11:34:46 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Tue, 28 Jun 2022 11:34:46 GMT
Subject: RFR: 8288961: jpackage: test MSI installation fix
In-Reply-To: <rjbj93A-x52yIC4nqt_tdewEovug8Sooy1WwkD2xEFU=.d9d00563-f587-4c94-bc34-2f4a06fb3ff4@github.com>
References: <rjbj93A-x52yIC4nqt_tdewEovug8Sooy1WwkD2xEFU=.d9d00563-f587-4c94-bc34-2f4a06fb3ff4@github.com>
Message-ID: <SPLGEYzafb18bBdFJKW3MEXGqHVsrrvqq0Hkd33T3Ac=.f30ab6ce-1c49-44c2-b5e0-1ee24d43fe7d@github.com>

On Wed, 22 Jun 2022 11:53:39 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> Please review this minor fix to the jpackage test suite.
> 
> When `INSTALL` and `UNINSTALL` actions are enabled for jpackage test suite runs (disabled by default), installation of `EXE` and `MSI` packages is performed. `EXE` package is invoked directly and `MSI` package is installed using `msiexec` utility. In both cases the path of the packages starts with a "." (current dir) symbol, it is processed correctly with EXE installation, but not with MSI, example:
> 
> 
> [03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
> [03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
> [03:52:19.634] TRACE: exec: Execute [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
> [03:52:19.790] TRACE: exec: Done. Exit code: 1619
> [03:52:19.805] ERROR: Expected [0]. Actual [1619]: Check command [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code 
> 
> 
> Is is proposed to normalize the path passed to `msiexec`, in this case installation will succeed:
> 
> 
> [03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
> [03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
> [03:56:52.429] TRACE: exec: Execute [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
> [03:56:57.067] TRACE: exec: Done. Exit code: 0
> [03:56:57.067] TRACE: assertEquals(0): Check command [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code

Thanks for the reviews! I don't have Committer role in JDK Project, would appreciate if someone can push it.

-------------

PR: https://git.openjdk.org/jdk/pull/9236

From redestad at openjdk.org  Tue Jun 28 11:55:08 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 28 Jun 2022 11:55:08 GMT
Subject: [jdk19] RFR: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
Message-ID: <MXmGn3gkzdSBvUNMGbM_1oM7OLNGNUjohoib465-208=.8ae6c793-ee07-4c53-87fe-1496393f113c@github.com>

8288425: Footprint regression due MH creation when initializing StringConcatFactory

-------------

Commit messages:
 - 8288425: Footprint regression due MH creation when initializing StringConcatFactory

Changes: https://git.openjdk.org/jdk19/pull/83/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=83&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288425
  Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk19/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/83/head:pull/83

PR: https://git.openjdk.org/jdk19/pull/83

From jlaskey at openjdk.org  Tue Jun 28 12:10:40 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Jun 2022 12:10:40 GMT
Subject: [jdk19] RFR: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <MXmGn3gkzdSBvUNMGbM_1oM7OLNGNUjohoib465-208=.8ae6c793-ee07-4c53-87fe-1496393f113c@github.com>
References: <MXmGn3gkzdSBvUNMGbM_1oM7OLNGNUjohoib465-208=.8ae6c793-ee07-4c53-87fe-1496393f113c@github.com>
Message-ID: <RXaH-_DL9zMzoi21ipsjzsy_UKIrRpaXnTjIPl3a9pc=.a1c871a1-c4dd-48fe-b37a-098a99533803@github.com>

On Tue, 28 Jun 2022 11:46:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> 8288425: Footprint regression due MH creation when initializing StringConcatFactory

LGTM

Is it possible to set up a regression test?

-------------

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/83

From redestad at openjdk.org  Tue Jun 28 12:18:44 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 28 Jun 2022 12:18:44 GMT
Subject: [jdk19] RFR: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <RXaH-_DL9zMzoi21ipsjzsy_UKIrRpaXnTjIPl3a9pc=.a1c871a1-c4dd-48fe-b37a-098a99533803@github.com>
References: <MXmGn3gkzdSBvUNMGbM_1oM7OLNGNUjohoib465-208=.8ae6c793-ee07-4c53-87fe-1496393f113c@github.com>
 <RXaH-_DL9zMzoi21ipsjzsy_UKIrRpaXnTjIPl3a9pc=.a1c871a1-c4dd-48fe-b37a-098a99533803@github.com>
Message-ID: <M5qx-b0F6Rer9O62dO2sqZfcFWOTDtcYL3rA9cA-R3U=.0e7d66ed-62a5-4910-8d0c-ef80c69efad0@github.com>

On Tue, 28 Jun 2022 12:07:13 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> LGTM

Thanks. FWIW it's a clean backport. 

> Is it possible to set up a regression test?

We caught this automatically - albeit a bit later - using our automated startup and footprint tests. 

A functional pass-or-fail test is always a bit awkward when dealing with performance characteristics. We could consider some test that asserts that a Hello World doesn't spin up, say, any  `LambdaForm` classes dynamically, but there's nothing _wrong_ with using such things early. Future improvements could also mean we can do so for "free" (say by caching such classes in CDS or pre-generating everything in jlink).

-------------

PR: https://git.openjdk.org/jdk19/pull/83

From redestad at openjdk.org  Tue Jun 28 12:32:42 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 28 Jun 2022 12:32:42 GMT
Subject: [jdk19] Integrated: 8288425: Footprint regression due MH creation when
 initializing StringConcatFactory
In-Reply-To: <MXmGn3gkzdSBvUNMGbM_1oM7OLNGNUjohoib465-208=.8ae6c793-ee07-4c53-87fe-1496393f113c@github.com>
References: <MXmGn3gkzdSBvUNMGbM_1oM7OLNGNUjohoib465-208=.8ae6c793-ee07-4c53-87fe-1496393f113c@github.com>
Message-ID: <1f2oZprQFQpxjVsBP1gNMz6zhJD9EXD5VyMri0iCs_o=.66f5db39-dc25-4d22-92e7-54b260e220a4@github.com>

On Tue, 28 Jun 2022 11:46:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> 8288425: Footprint regression due MH creation when initializing StringConcatFactory

This pull request has now been integrated.

Changeset: 9048cef7
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/9048cef761872812106b3429c51201c765f29fe1
Stats:     11 lines in 1 file changed: 7 ins; 0 del; 4 mod

8288425: Footprint regression due MH creation when initializing StringConcatFactory

Reviewed-by: jlaskey
Backport-of: 6d595614a26ebe579268dc8216344dfb099bb3ad

-------------

PR: https://git.openjdk.org/jdk19/pull/83

From duke at openjdk.org  Tue Jun 28 12:46:43 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Tue, 28 Jun 2022 12:46:43 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
Message-ID: <J43htIhhRp0LuUsSDOaRuouD4zyPbR43L2SQWBUqgBU=.ac9a8c98-a052-4604-a3c3-1a8afca95ac6@github.com>

On Wed, 22 Jun 2022 03:01:36 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comparison for direct value of compare

@jatin-bhateja Thanks a lot for your reviews and suggestions, I have answered your comments.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Tue Jun 28 12:46:45 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Tue, 28 Jun 2022 12:46:45 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
Message-ID: <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>

On Tue, 28 Jun 2022 05:20:03 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comparison for direct value of compare
>
> src/hotspot/cpu/x86/x86_64.ad line 13043:
> 
>> 13041:     __ cmpl($src1$$Register, $src2$$Register);
>> 13042:     __ movl($dst$$Register, -1);
>> 13043:     __ jccb(Assembler::below, done);
> 
> By placing compare adjacent to conditional jump in-order frontend can trigger macro-fusion. 
> Kindly refer section 3.4.2.2 of Intel's optimization manual.

I realised that by swapping the `mov` and the `cmp` instruction, the rule needs to have `dst` different from `src1` and `src2`, which increases register pressure.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From aefimov at openjdk.org  Tue Jun 28 13:22:46 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 28 Jun 2022 13:22:46 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit [v2]
In-Reply-To: <uAamStjg20skBRLKyIsF-hS7AM2u1FltCkthy2TjsXw=.b7f1528d-a09b-44d8-ba17-0a55d08daaca@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
 <uAamStjg20skBRLKyIsF-hS7AM2u1FltCkthy2TjsXw=.b7f1528d-a09b-44d8-ba17-0a55d08daaca@github.com>
Message-ID: <zAtKcx0BCE3IDThiLSiTohHEiBU60HRvhWzs9NQz9p4=.1318aed1-4129-4c96-b939-8afa700790fd@github.com>

On Tue, 28 Jun 2022 07:10:52 GMT, rmartinc <duke at openjdk.org> wrote:

>> Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895).
>> 
>> Any `LimitExceededException` now quits the referral loop.
>> 
>> Added class `ReferralLimitSearchTest`. It is a simple jtreg test which checks that `java.naming.ldap.referral.limit` is really enforced. The dummy ldap server always returns a referral for any search query. If the number of searches exceeds the limit, it throws an `IOException` and the test fails.
>> 
>> 
>> make test TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java
>
> rmartinc 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:
> 
>   8288895: LdapContext doesn't honor set referrals limit

The latest changes look good to me - with one tiny typo spotted.
There were no issues discovered with it with existing JNDI/LDAP regressions test. 
Also, the new test runs fine on all platforms.

test/jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java line 58:

> 56: public class ReferralLimitSearchTest {
> 57: 
> 58:     // number of refarral hops to test

Small typo: `refarral` -> `referral`

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.org/jdk/pull/9256

From alanb at openjdk.org  Tue Jun 28 14:19:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Jun 2022 14:19:13 GMT
Subject: RFR: 8289284: jdk.tracePinnedThreads output confusing when pinned due
 to native frame
Message-ID: <n6SWBjly4XYojVFuvl46L09-JjRRYrAMC_naGTNBWQM=.fd82fd8f-27fa-4bab-a2b7-fad2fb66ca83@github.com>

The system property jdk.tracePinnedThreads triggers a stack trace to be printed when a virtual thread parks while pinned. If a virtual thread is pinned due to a native frame there is a spurious " <== monitors:0" added to line for the native method.

A secondary issue is that there is no stack trace when there is Panama downcall as there isn't a native method in the stack trace. A future change may annotate the downcalls, for now the entire stack trace is printed (no filtering) so there is at least some output when pinned due to a call through native code

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/9308/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9308&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289284
  Stats: 114 lines in 4 files changed: 91 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/9308.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9308/head:pull/9308

PR: https://git.openjdk.org/jdk/pull/9308

From duke at openjdk.org  Tue Jun 28 14:22:48 2022
From: duke at openjdk.org (rmartinc)
Date: Tue, 28 Jun 2022 14:22:48 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit [v3]
In-Reply-To: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
Message-ID: <sQDbydSnmaVv5Oi1Uy-hwwshQdTiHG1xLfg94YWxzyo=.243bd22f-5d04-4380-ad2e-e8571e79bf71@github.com>

> Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895).
> 
> Any `LimitExceededException` now quits the referral loop.
> 
> Added class `ReferralLimitSearchTest`. It is a simple jtreg test which checks that `java.naming.ldap.referral.limit` is really enforced. The dummy ldap server always returns a referral for any search query. If the number of searches exceeds the limit, it throws an `IOException` and the test fails.
> 
> 
> make test TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java

rmartinc has updated the pull request incrementally with one additional commit since the last revision:

  8288895: LdapContext doesn't honor set referrals limit (typo)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9256/files
  - new: https://git.openjdk.org/jdk/pull/9256/files/09961af7..81f3c146

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9256&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9256&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9256.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9256/head:pull/9256

PR: https://git.openjdk.org/jdk/pull/9256

From duke at openjdk.org  Tue Jun 28 14:22:52 2022
From: duke at openjdk.org (rmartinc)
Date: Tue, 28 Jun 2022 14:22:52 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit [v2]
In-Reply-To: <zAtKcx0BCE3IDThiLSiTohHEiBU60HRvhWzs9NQz9p4=.1318aed1-4129-4c96-b939-8afa700790fd@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
 <uAamStjg20skBRLKyIsF-hS7AM2u1FltCkthy2TjsXw=.b7f1528d-a09b-44d8-ba17-0a55d08daaca@github.com>
 <zAtKcx0BCE3IDThiLSiTohHEiBU60HRvhWzs9NQz9p4=.1318aed1-4129-4c96-b939-8afa700790fd@github.com>
Message-ID: <fiG-CN8BI32TdQP9zPSKP95Hy8mr3gh2fqX74JV5NyE=.4d333d31-f6a6-42d2-b84d-8c277bdb75ff@github.com>

On Tue, 28 Jun 2022 11:21:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> rmartinc 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:
>> 
>>   8288895: LdapContext doesn't honor set referrals limit
>
> test/jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java line 58:
> 
>> 56: public class ReferralLimitSearchTest {
>> 57: 
>> 58:     // number of refarral hops to test
> 
> Small typo: `refarral` -> `referral`

Ups! Fixed!

-------------

PR: https://git.openjdk.org/jdk/pull/9256

From aefimov at openjdk.org  Tue Jun 28 14:59:40 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 28 Jun 2022 14:59:40 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit [v3]
In-Reply-To: <sQDbydSnmaVv5Oi1Uy-hwwshQdTiHG1xLfg94YWxzyo=.243bd22f-5d04-4380-ad2e-e8571e79bf71@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
 <sQDbydSnmaVv5Oi1Uy-hwwshQdTiHG1xLfg94YWxzyo=.243bd22f-5d04-4380-ad2e-e8571e79bf71@github.com>
Message-ID: <FMUrGXLp-w_YICuyOPdGfP1W6x3soNfpJpoOnQQB9no=.ef37bb68-e861-44c5-87d3-7a456e0b6477@github.com>

On Tue, 28 Jun 2022 14:22:48 GMT, rmartinc <duke at openjdk.org> wrote:

>> Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895).
>> 
>> Any `LimitExceededException` now quits the referral loop.
>> 
>> Added class `ReferralLimitSearchTest`. It is a simple jtreg test which checks that `java.naming.ldap.referral.limit` is really enforced. The dummy ldap server always returns a referral for any search query. If the number of searches exceeds the limit, it throws an `IOException` and the test fails.
>> 
>> 
>> make test TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java
>
> rmartinc has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288895: LdapContext doesn't honor set referrals limit (typo)

Marked as reviewed by aefimov (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/9256

From phh at openjdk.org  Tue Jun 28 15:03:42 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 28 Jun 2022 15:03:42 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <O_bNXfug2W4JldPz8D0FOr4dPEA9J4RdtmsydK2B3nk=.97ae4267-64f2-4814-b4d0-e141ca740c18@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.org> wrote:

> Changes the definition of `CollectorImpl` to be a record.

Lgtm.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8179

From duke at openjdk.org  Tue Jun 28 15:42:43 2022
From: duke at openjdk.org (altrisi)
Date: Tue, 28 Jun 2022 15:42:43 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <wO4KjP5L28pxd9TkbRiP-phLJZkH2p1rpbcyZbHfz5M=.92785d9d-2861-404b-8eb7-2b215c30d62b@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.org> wrote:

> Changes the definition of `CollectorImpl` to be a record.

Thanks for the review!

-------------

PR: https://git.openjdk.org/jdk/pull/8179

From phh at openjdk.org  Tue Jun 28 15:48:43 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 28 Jun 2022 15:48:43 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <1tk-GVF8TE0Lu7iuNQRu3pYEZqS8Z1XqYV3ZQRVKRQg=.7c1a1b2e-bbdf-4a30-b422-90afb5883fd2@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.org> wrote:

> Changes the definition of `CollectorImpl` to be a record.

I believe we need another reviewer (doesn't have to be a capital-Reviewer). I'll sponsor after that.

-------------

PR: https://git.openjdk.org/jdk/pull/8179

From rriggs at openjdk.org  Tue Jun 28 16:58:43 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Jun 2022 16:58:43 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <QHiDoD5r9P8-FdTEBq4MTpCeoYp38WN_4zCSHWDYCRY=.b9d9e53a-c386-408f-a044-6aed37f0b977@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.org> wrote:

> Changes the definition of `CollectorImpl` to be a record.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/8179

From akasko at openjdk.org  Tue Jun 28 17:05:42 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Tue, 28 Jun 2022 17:05:42 GMT
Subject: Integrated: 8288013: jpackage: test utility Windows registry
 enhancement
In-Reply-To: <lFIf18LPCwDIoTtS2foBhR9ZZ-1LElZjPKcTDtktjOE=.dd399490-2bd0-4286-a256-d5d9cb61f1e3@github.com>
References: <lFIf18LPCwDIoTtS2foBhR9ZZ-1LElZjPKcTDtktjOE=.dd399490-2bd0-4286-a256-d5d9cb61f1e3@github.com>
Message-ID: <WM8nhNwIw2V8QXHs6ZQ3JhHgShMkQyVmQdoJw_46ngk=.077f375c-0c2b-4af5-8867-34bac6308c41@github.com>

On Wed, 8 Jun 2022 11:46:42 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> In jpackage test suite there is a test utility WindowsHelper.queryRegistryValue . It is used to verify changes to Windows registry that can be done by installer packages. It spawns `reg.exe query` process and parses its output. This patch adds support for quering empty values and additional REG_* datatypes.
> 
> Correctness was verified manually with the following registry values:
> 
> 
>         //    (Default)    REG_SZ    test1
>         //    string_val    REG_SZ    test2
>         //    string_val_empty    REG_SZ
>         //    bin_val    REG_BINARY    4242
>         //    bin_val_empty    REG_BINARY
>         //    dword_val    REG_DWORD    0x2a
>         //    qword_val    REG_QWORD    0x2a
>         //    multi_string_val    REG_MULTI_SZ    test3\0test4
>         //    multi_string_val_empty    REG_MULTI_SZ
>         //    expand_string_val    REG_EXPAND_SZ    test5
>         //    expand_string_val_empty    REG_EXPAND_SZ
> 
> 
> Corresponding utility output:
> 
> 
> [04:36:38.190] TRACE: Registry value [] at [...] path is [test1]
> [04:36:38.220] TRACE: Registry value [string_val] at [...] path is [test2]
> [04:36:38.251] TRACE: Registry value [string_val_empty] at [...] path is []
> [04:36:38.282] TRACE: Registry value [bin_val] at [...] path is [4242]
> [04:36:38.315] TRACE: Registry value [bin_val_empty] at [...] path is []
> [04:36:38.347] TRACE: Registry value [dword_val] at [...] path is [0x2a]
> [04:36:38.378] TRACE: Registry value [qword_val] at [...] path is [0x2a]
> [04:36:38.410] TRACE: Registry value [multi_string_val] at [...] path is [test3\\0test4]
> [04:36:38.441] TRACE: Registry value [multi_string_val_empty] at [...] path is []
> [04:36:38.473] TRACE: Registry value [expand_string_val] at [...] path is [test5]
> [04:36:38.506] TRACE: Registry value [expand_string_val_empty] at [...] path is []
> 
> 
> Testing:
> 
>  - [x] ran "jtreg:jdk/tools/jpackage/windows" before and after the patch

This pull request has now been integrated.

Changeset: 1f36ed1f
Author:    Alex Kasko <akasko at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f36ed1faeede991e8e67ded4b814be8b78a840f
Stats:     20 lines in 1 file changed: 17 ins; 0 del; 3 mod

8288013: jpackage: test utility Windows registry enhancement

Reviewed-by: asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/9083

From akasko at openjdk.org  Tue Jun 28 17:08:58 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Tue, 28 Jun 2022 17:08:58 GMT
Subject: Integrated: 8288961: jpackage: test MSI installation fix
In-Reply-To: <rjbj93A-x52yIC4nqt_tdewEovug8Sooy1WwkD2xEFU=.d9d00563-f587-4c94-bc34-2f4a06fb3ff4@github.com>
References: <rjbj93A-x52yIC4nqt_tdewEovug8Sooy1WwkD2xEFU=.d9d00563-f587-4c94-bc34-2f4a06fb3ff4@github.com>
Message-ID: <xQv6iY3-PiAT9FjPd-UgeBhkp-cbgrUEbJn4z23pibk=.8432c715-402c-4c35-8bde-6751d90a9844@github.com>

On Wed, 22 Jun 2022 11:53:39 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> Please review this minor fix to the jpackage test suite.
> 
> When `INSTALL` and `UNINSTALL` actions are enabled for jpackage test suite runs (disabled by default), installation of `EXE` and `MSI` packages is performed. `EXE` package is invoked directly and `MSI` package is installed using `msiexec` utility. In both cases the path of the packages starts with a "." (current dir) symbol, it is processed correctly with EXE installation, but not with MSI, example:
> 
> 
> [03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
> [03:52:19.634] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
> [03:52:19.634] TRACE: exec: Execute [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
> [03:52:19.790] TRACE: exec: Done. Exit code: 1619
> [03:52:19.805] ERROR: Expected [0]. Actual [1619]: Check command [msiexec /qn /norestart /i .\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code 
> 
> 
> Is is proposed to normalize the path passed to `msiexec`, in this case installation will succeed:
> 
> 
> [03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] path exists
> [03:56:52.429] TRACE: assertTrue(): Check [.\\test.bcc14973\\output\\FileAssociationsTest-1.0.msi] is a file
> [03:56:52.429] TRACE: exec: Execute [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5); discard I/O...
> [03:56:57.067] TRACE: exec: Done. Exit code: 0
> [03:56:57.067] TRACE: assertEquals(0): Check command [msiexec /qn /norestart /i test.bcc14973\\output\\FileAssociationsTest-1.0.msi](5) exited with 0 code

This pull request has now been integrated.

Changeset: c67149be
Author:    Alex Kasko <akasko at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c67149be4bd4922f9e6a55eb17deca684941d535
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288961: jpackage: test MSI installation fix

Reviewed-by: asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/9236

From duke at openjdk.org  Tue Jun 28 17:14:40 2022
From: duke at openjdk.org (altrisi)
Date: Tue, 28 Jun 2022 17:14:40 GMT
Subject: Integrated: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <mNEGr515LZwK0vWPBJVDDhz2cdzw-8J8Qn0zbYvDLzw=.a725f79a-6c49-42bf-80c2-289e192ae60f@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.org> wrote:

> Changes the definition of `CollectorImpl` to be a record.

This pull request has now been integrated.

Changeset: af008807
Author:    altrisi <altrisi.trillosierra at gmail.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af0088076dd8cb5d5bc47c59838e7f5ef4f6d8a9
Stats:     43 lines in 1 file changed: 0 ins; 37 del; 6 mod

8284640: CollectorImpl class could be a record class

Reviewed-by: phh, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/8179

From naoto at openjdk.org  Tue Jun 28 17:21:12 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Jun 2022 17:21:12 GMT
Subject: [jdk19] RFR: 8289252: Recommend Locale.of() method instead of the
 constructor
Message-ID: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>

This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

-------------

Commit messages:
 - 8289252: Recommend Locale.of() method instead of the constructor

Changes: https://git.openjdk.org/jdk19/pull/85/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=85&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289252
  Stats: 14 lines in 1 file changed: 4 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk19/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/85/head:pull/85

PR: https://git.openjdk.org/jdk19/pull/85

From simonis at openjdk.org  Tue Jun 28 17:29:44 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 28 Jun 2022 17:29:44 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <QHiDoD5r9P8-FdTEBq4MTpCeoYp38WN_4zCSHWDYCRY=.b9d9e53a-c386-408f-a044-6aed37f0b977@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
 <QHiDoD5r9P8-FdTEBq4MTpCeoYp38WN_4zCSHWDYCRY=.b9d9e53a-c386-408f-a044-6aed37f0b977@github.com>
Message-ID: <bGzrG7r-G32cZ2iRwNN1aT8uFMfg1JJAAwKotr2QiMg=.59b21e84-7df2-4117-a53a-5c26a1ae66f4@github.com>

On Tue, 28 Jun 2022 16:54:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Changes the definition of `CollectorImpl` to be a record.
>
> Marked as reviewed by rriggs (Reviewer).

Hi @RogerRiggs,

Thanks for reviewing this PR. I have a more general question. Do we have any recommendations about using new language features in the core libraries?

Thanks,
Volker

-------------

PR: https://git.openjdk.org/jdk/pull/8179

From duke at openjdk.org  Tue Jun 28 19:01:14 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Tue, 28 Jun 2022 19:01:14 GMT
Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set
 with TZ env variable
Message-ID: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>

This is a REDO of the Fix that was incompletely implemented earlier:
[8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)

Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.

I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
_(where 7200 represents 7200 seconds -> +2 hour offset)_
Sample output:
![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

-------------

Commit messages:
 - 8288377: Offset calculation fix for DST with custom TZ.

Changes: https://git.openjdk.org/jdk/pull/9312/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288377
  Stats: 118 lines in 2 files changed: 114 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9312.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9312/head:pull/9312

PR: https://git.openjdk.org/jdk/pull/9312

From joehw at openjdk.org  Tue Jun 28 19:13:50 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 28 Jun 2022 19:13:50 GMT
Subject: [jdk19] RFR: 8289252: Recommend Locale.of() method instead of the
 constructor
In-Reply-To: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
Message-ID: <r_zDjjfVpUhfb2WDhdBwvWLOvyP2yaVlRmfg5ZbOKPQ=.6a43a09d-0767-48d2-b9d2-7d0fb0cfc3db@github.com>

On Tue, 28 Jun 2022 17:11:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/85

From rriggs at openjdk.org  Tue Jun 28 19:48:43 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Jun 2022 19:48:43 GMT
Subject: [jdk19] RFR: 8289252: Recommend Locale.of() method instead of the
 constructor
In-Reply-To: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
Message-ID: <8t72emKs6l_1R62QGTZTLFVMwfUAyClhiEl-Yr7doSo=.6a2c9581-4b48-4dcc-9c32-b1cb400cc707@github.com>

On Tue, 28 Jun 2022 17:11:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

src/java.base/share/classes/java/util/Locale.java line 2608:

> 2606:      * <p>The following example shows how to obtain a {@code Locale} object
> 2607:      * using a {@code Builder}.
> 2608:      * {@snippet :

Style-wise, adding the language of the snippet would be a plus:

`@snippet lang=java :`

-------------

PR: https://git.openjdk.org/jdk19/pull/85

From rriggs at openjdk.org  Tue Jun 28 19:59:26 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Jun 2022 19:59:26 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <0ZPP7USAPvyQ8RrnnnASmgMsOWKm8Roua9R6R_WOeDQ=.d1a735f5-937d-4671-a765-b9e3b3b92fde@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.org> wrote:

> Changes the definition of `CollectorImpl` to be a record.

For some new features, its an obvious yes, though personally, it should add some value to the code, not just churn the code base to be up-to-date.

Also, there is quite a bit of core code that is sensitive to bootstrap and startup performance regressions.
And occasionally it makes backports harder, though that's not a reason to be stuck with old APIs.

Using preview features can also be a mixed bag. The dependencies and warnings about using preview features can break the build and they are not always such an improvement to suppress the warnings and have to come back later to remove or redo the code.

Some parts of the system (like javac) have to be compiled with the previous JDK, so no new features.

Use new feature judiciously, meaning think broadly about the impact across the code base, not just a bit of code here and there.

-------------

PR: https://git.openjdk.org/jdk/pull/8179

From rriggs at openjdk.org  Tue Jun 28 20:04:36 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Jun 2022 20:04:36 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <ngwLkvR_NVw2SO_bZmNmBwNwPwsoyh4WAkwjKFqrHdQ=.d398cb85-bafb-44b4-8c88-34d204f01368@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.org> wrote:

> Changes the definition of `CollectorImpl` to be a record.

I see this one languished quite a while without a review. Sorry about that; for the uninteresting, maybe it really is insufficiently interesting to even pursue except as a starter issue.

-------------

PR: https://git.openjdk.org/jdk/pull/8179

From naoto at openjdk.org  Tue Jun 28 20:17:22 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Jun 2022 20:17:22 GMT
Subject: [jdk19] RFR: 8289252: Recommend Locale.of() method instead of the
 constructor [v2]
In-Reply-To: <8t72emKs6l_1R62QGTZTLFVMwfUAyClhiEl-Yr7doSo=.6a2c9581-4b48-4dcc-9c32-b1cb400cc707@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
 <8t72emKs6l_1R62QGTZTLFVMwfUAyClhiEl-Yr7doSo=.6a2c9581-4b48-4dcc-9c32-b1cb400cc707@github.com>
Message-ID: <ezNDtr4cTp0pqwfSwZyzVic00oipqrwVjESpfUvpVu0=.71e1eecb-5de0-4f7b-8654-4133da045836@github.com>

On Tue, 28 Jun 2022 19:45:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added `lang` attribute to the snippet
>
> src/java.base/share/classes/java/util/Locale.java line 2608:
> 
>> 2606:      * <p>The following example shows how to obtain a {@code Locale} object
>> 2607:      * using a {@code Builder}.
>> 2608:      * {@snippet :
> 
> Style-wise, adding the language of the snippet would be a plus:
> 
> `@snippet lang=java :`

Good point. Added.

-------------

PR: https://git.openjdk.org/jdk19/pull/85

From naoto at openjdk.org  Tue Jun 28 20:17:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Jun 2022 20:17:21 GMT
Subject: [jdk19] RFR: 8289252: Recommend Locale.of() method instead of the
 constructor [v2]
In-Reply-To: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
Message-ID: <NmAfQ1ybOR4KQYteNZtCLgaCZp0AkWh_Br6MGIAnY-8=.cb7b2333-73ca-4d23-a0e7-79740f78fa96@github.com>

> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  added `lang` attribute to the snippet

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/85/files
  - new: https://git.openjdk.org/jdk19/pull/85/files/258aff4e..ce39f751

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=85&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=85&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk19/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/85/head:pull/85

PR: https://git.openjdk.org/jdk19/pull/85

From phh at openjdk.org  Tue Jun 28 20:25:44 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 28 Jun 2022 20:25:44 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <ohNWNbzPz3wpbW9CJUh07l6e3WKNGtiZj16bO0qsydc=.3d5d3f17-9d78-4938-83c6-74dbff485028@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.org> wrote:

> Changes the definition of `CollectorImpl` to be a record.

I assumed it was a starter issue in order to learn the patch process.

-------------

PR: https://git.openjdk.org/jdk/pull/8179

From rriggs at openjdk.org  Tue Jun 28 20:29:53 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Jun 2022 20:29:53 GMT
Subject: [jdk19] RFR: 8289252: Recommend Locale.of() method instead of the
 constructor [v2]
In-Reply-To: <NmAfQ1ybOR4KQYteNZtCLgaCZp0AkWh_Br6MGIAnY-8=.cb7b2333-73ca-4d23-a0e7-79740f78fa96@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
 <NmAfQ1ybOR4KQYteNZtCLgaCZp0AkWh_Br6MGIAnY-8=.cb7b2333-73ca-4d23-a0e7-79740f78fa96@github.com>
Message-ID: <mtRkeJw0BALR65696Skb7kL-g0-mgYD-YwX-GZPRuOg=.232b197c-5a21-4f57-b35b-087f003fb0a4@github.com>

On Tue, 28 Jun 2022 20:17:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added `lang` attribute to the snippet

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/85

From akasko at openjdk.org  Tue Jun 28 20:55:22 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Tue, 28 Jun 2022 20:55:22 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments [v2]
In-Reply-To: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
Message-ID: <leu7VmZDYUbEUV06p9vVOFW8AdiQZy1C55sPmNLqXWs=.be4a3534-0c57-4c19-be20-b3d4d1c81234@github.com>

> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable.
> 
> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard.
> 
> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points:
> 
>  - option naming inside a properties file, currently `pass-all-args` is used
>  - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group
>  - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination
>  - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop`
> 
> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version.
> 
> Testing:
>  
> - [x] test to cover new logic is included
> - [x] ran jtreg:jdk/tools/jpackage with no new failures

Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:

  use shortcut to test arguments, add argument with spaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9224/files
  - new: https://git.openjdk.org/jdk/pull/9224/files/427ff849..3b4f77e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9224&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9224&range=00-01

  Stats: 21 lines in 1 file changed: 15 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9224.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9224/head:pull/9224

PR: https://git.openjdk.org/jdk/pull/9224

From akasko at openjdk.org  Tue Jun 28 20:55:23 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Tue, 28 Jun 2022 20:55:23 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments [v2]
In-Reply-To: <w2RdOenSgmA8n-4-2CPbP_nv2KNPF2Y-8NoQPtGX6kg=.bf82c285-cadd-4d08-8d55-e354f8fecfad@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
 <w2RdOenSgmA8n-4-2CPbP_nv2KNPF2Y-8NoQPtGX6kg=.bf82c285-cadd-4d08-8d55-e354f8fecfad@github.com>
Message-ID: <yBBmLZ6MmO-i1CE0ro20K-AXIefn-8RvA8SbAggPaGg=.0eb1d1ed-5209-4b1c-9613-741bab35aaf6@github.com>

On Mon, 27 Jun 2022 17:57:53 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use shortcut to test arguments, add argument with spaces
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java line 533:
> 
>> 531:                 xml.writeAttribute("Command", "Open");
>> 532:                 if (fa.passAllArguments) {
>> 533:                     xml.writeAttribute("Argument", "\"%1\" %*");
> 
> Wondering if simple `"%*"` would be sufficient to preserve arguments with spaces.

I've added argument with spaces to the test, they seem to be passed correctly (with existing unquoted `%*`) with both command line invocation and with a shortcut.

-------------

PR: https://git.openjdk.org/jdk/pull/9224

From akasko at openjdk.org  Tue Jun 28 21:06:48 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Tue, 28 Jun 2022 21:06:48 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments
In-Reply-To: <hTh3uRo1rC7Ezwdsj7tz0Log-jqoFByCc5dyzKtpUcg=.9a8f6452-ac24-4775-8033-91fe0d44fe0f@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
 <hTh3uRo1rC7Ezwdsj7tz0Log-jqoFByCc5dyzKtpUcg=.9a8f6452-ac24-4775-8033-91fe0d44fe0f@github.com>
Message-ID: <D0ieEkV22FALpm1C4Fpcsh9Vs8Veb71l8bcTmxma7Hg=.0ea61e99-f9e0-430e-8cc0-cff1d75c9705@github.com>

On Mon, 27 Jun 2022 17:53:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> What would be the alternative to `pass-all-args`? 

As this is intended to be a public property, I assume there should be a CSR and some consistent name, perhaps with `win-` prefix - I assume we will need an additional similar property for a verb label displayed in a context menu. `pass-all-args` was intended only as a working title.

> What if we unconditionally add `%*` batch wildcard?

Can we change the existing default behaviour? Should we? It won't break existing usage, but is it actually always desired to support passing arbitrary arguments from the desktop shortcut to the target java app? I myself cannot answer any of these questions.

-------------

PR: https://git.openjdk.org/jdk/pull/9224

From jwilhelm at openjdk.org  Tue Jun 28 21:21:12 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 21:21:12 GMT
Subject: RFR: Merge jdk19
Message-ID: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again
 - 8289069: Very slow C1 arraycopy jcstress tests after JDK-8279886
 - 8288058: Broken links on constant-values page
 - 8275784: Bogus warning generated for record with compact constructor
 - 8288836: (fs) Files.writeString spec for IOException has "specified charset" when no charset is provided
 - 8288425: Footprint regression due MH creation when initializing StringConcatFactory
 - 8289228: SegmentAllocator::allocateArray null handling is too lax
 - 8288445: AArch64: C2 compilation fails with guarantee(!true || (true && (shift != 0))) failed: impossible encoding
 - 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java
 - ... and 7 more: https://git.openjdk.org/jdk/compare/af008807...d57b485f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9315/files
  Stats: 821 lines in 29 files changed: 612 ins; 71 del; 138 mod
  Patch: https://git.openjdk.org/jdk/pull/9315.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9315/head:pull/9315

PR: https://git.openjdk.org/jdk/pull/9315

From asemenyuk at openjdk.org  Tue Jun 28 21:42:31 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 28 Jun 2022 21:42:31 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments
In-Reply-To: <D0ieEkV22FALpm1C4Fpcsh9Vs8Veb71l8bcTmxma7Hg=.0ea61e99-f9e0-430e-8cc0-cff1d75c9705@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
 <hTh3uRo1rC7Ezwdsj7tz0Log-jqoFByCc5dyzKtpUcg=.9a8f6452-ac24-4775-8033-91fe0d44fe0f@github.com>
 <D0ieEkV22FALpm1C4Fpcsh9Vs8Veb71l8bcTmxma7Hg=.0ea61e99-f9e0-430e-8cc0-cff1d75c9705@github.com>
Message-ID: <L1ha-AvMYWSIsZtd3SyAufiVydVd25U5F1RUWkQGY6Q=.ae6ca49e-8b8d-46df-a4f6-2e1f3d8e1376@github.com>

On Tue, 28 Jun 2022 21:03:28 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> I assume we will need an additional similar property for a verb label displayed in a context menu.

Agree. At least we need to provide l10n for it.

> Can we change the existing default behaviour? Should we? It won't break existing usage, but is it actually always desired to support passing arbitrary arguments from the desktop shortcut to the target java app? I myself cannot answer any of these questions.

The existing behavior simply cuts off all, but the first argument from the argument array passed to the app launcher. Changing this looks more like a fix of a bug, than an enhancement. 
I'd keep it simple: replace the value of the `Argument` attribute from `%1` to `%*`. Besides, `"%1 %*"` seems to duplicate the first argument (`%1` is not referencing a path to app launcher executable, but the name of a file to open).
If fixed in this way, we don't need to introduce `pass-all-args`.

-------------

PR: https://git.openjdk.org/jdk/pull/9224

From jwilhelm at openjdk.org  Tue Jun 28 22:17:08 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 22:17:08 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
References: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
Message-ID: <cubHA4OFa8jwOIA-LZWGABo7MOx2vWK4HxANnyER4kM=.ebc33bd9-ee29-4dc6-8d77-98203c0ffcc4@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 166 commits:

 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8284640: CollectorImpl class could be a record class
   
   Reviewed-by: phh, rriggs
 - 8288961: jpackage: test MSI installation fix
   
   Reviewed-by: asemenyuk, almatvee
 - 8288013: jpackage: test utility Windows registry enhancement
   
   Reviewed-by: asemenyuk, almatvee
 - 8289071: Compute allocation sizes of stubs and nmethods outside of lock protection
   
   Reviewed-by: thartmann, phh
 - 8271252: os::reserve_memory should not use mtOther as default NMT flag
   
   Reviewed-by: zgu
 - 8287818: Shenandoah: adapt nmethod arming from Loom
   
   Reviewed-by: shade
 - 8289138: G1: Remove redundant is-marking-active checks in C1 barrier
   
   Reviewed-by: tschatzl, ehelin
 - 8288396: Always create reproducible builds
   
   Reviewed-by: amenkov, ehelin
 - 8289258: ProblemList some failing custom loader tests with ZGC
   
   Reviewed-by: dholmes
 - ... and 156 more: https://git.openjdk.org/jdk/compare/15048048...d57b485f

-------------

Changes: https://git.openjdk.org/jdk/pull/9315/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=01
  Stats: 68839 lines in 1210 files changed: 43242 ins; 13434 del; 12163 mod
  Patch: https://git.openjdk.org/jdk/pull/9315.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9315/head:pull/9315

PR: https://git.openjdk.org/jdk/pull/9315

From jwilhelm at openjdk.org  Tue Jun 28 22:17:09 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 22:17:09 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
References: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
Message-ID: <gtYlusBVnnkYR36SyDWKK3AhTK2FpOpGi5Wx7ZqufwI=.dcb880bf-bbbe-48c1-9985-75d302d4cf45@github.com>

On Tue, 28 Jun 2022 21:13:05 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 86dc760f
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86dc760f9ec0f403109bef7b06db82b9ed0739dd
Stats:     821 lines in 29 files changed: 612 ins; 71 del; 138 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9315

From naoto at openjdk.org  Tue Jun 28 22:19:31 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Jun 2022 22:19:31 GMT
Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset
 set with TZ env variable
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <pLyfFSkudoD_Mcy2Tnac0Vrteafqhghp8KO5rPhycd8=.a681a16c-8a72-4a15-b292-490e98e3f12d@github.com>

On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

I just wonder we could simply call `strftime` with `%z` conversion, rather than calculating the GMT offset ourselves. Would you like to try it out?

-------------

PR: https://git.openjdk.org/jdk/pull/9312

From darcy at openjdk.org  Tue Jun 28 22:28:56 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 28 Jun 2022 22:28:56 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core reflection
Message-ID: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>

JDK-8289106: Add model of class file versions to core reflection

-------------

Commit messages:
 - Update phrasing.
 - Augment and correct docs.
 - Correct major versions; RELEASE_0 and RELEASE_1 are both 45.
 - Make major method public.
 - Add AccessFlag.locations(ClassFileFormatVersion)
 - Add ClassFileFormatVersion <-> Runtime.Version conversions.
 - Merge branch 'master' into JDK-8289106
 - JDK-8289106: Add model of class file versions to core reflection

Changes: https://git.openjdk.org/jdk/pull/9299/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289106
  Stats: 348 lines in 3 files changed: 346 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9299.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9299/head:pull/9299

PR: https://git.openjdk.org/jdk/pull/9299

From darcy at openjdk.org  Tue Jun 28 22:28:57 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 28 Jun 2022 22:28:57 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection
In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
Message-ID: <qUJ3QbXRriUicQy3-ifCFOxDsOWDn_g8DIoyBwWEPe8=.781aabf8-aae3-447c-a8bd-6aaa1e8839da@github.com>

On Mon, 27 Jun 2022 20:26:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> JDK-8289106: Add model of class file versions to core reflection

Sending this enum to model class file format versions out for some review comments before starting to write the tests and CSR, etc.

The class file format has a rich structure that evolves over time. That evolution includes adding access flags (as modeled by the recently-added java.lang.reflect.AccessFlag enum) as well as JVM attributes (not currently modeled in core reflection). The current docs in the ClassFileFormatVersion enum partially recount the changes in each version; more of the history is encoded in the various tables in JVMS, such as 4.4-B, 4.4-C, and 4.7-B. The intention at this point is not have ClassFileFormatVersion fully model and describe the class file evolution, although that information is of use to some clients and may be added in the future.

Given access flags and a notion of class file format versioning, a natural question to be able to answer is "in what class file format versions is this access flag supported and on what structures?" Abstractly, there are a variety of ways that information could be encoded included:

public static boolean isSupported(AccessFlag, AccessFlag.Location, ClassFileFormatVersion)
public static Set<Location> locations((AccessFlag, ClassFileFormatVersion)

The current version in the PR uses a locations(ClassFileFormatVersion) instance method defined on AccessFlag instead. This design puts the primacy on the AccessFlag dimension, but it would be possible to transpose this and make the class file format the prime factor instead (i.e. ClassFileFormatVersion.supportedFlags(AccessFlag.Location)) or even AccessFlag.Location.

-------------

PR: https://git.openjdk.org/jdk/pull/9299

From jbhateja at openjdk.org  Wed Jun 29 02:15:38 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 29 Jun 2022 02:15:38 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
 <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>
Message-ID: <VFn3GC5zqMcQu3eqRRnl7rirlVQpk_PkPUvxoCvBJbA=.2618fc87-df2e-4ddf-aa28-15a416d4b2e8@github.com>

On Tue, 28 Jun 2022 12:42:57 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 13043:
>> 
>>> 13041:     __ cmpl($src1$$Register, $src2$$Register);
>>> 13042:     __ movl($dst$$Register, -1);
>>> 13043:     __ jccb(Assembler::below, done);
>> 
>> By placing compare adjacent to conditional jump in-order frontend can trigger macro-fusion. 
>> Kindly refer section 3.4.2.2 of Intel's optimization manual.
>
> I realised that by swapping the `mov` and the `cmp` instruction, the rule needs to have `dst` different from `src1` and `src2`, which increases register pressure.

I do not follow your comment, allocation decisions purely based on LRGs interferences and data flow attributes attached to operands and is agnostic to encoding block contents.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Wed Jun 29 02:25:39 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 29 Jun 2022 02:25:39 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <VFn3GC5zqMcQu3eqRRnl7rirlVQpk_PkPUvxoCvBJbA=.2618fc87-df2e-4ddf-aa28-15a416d4b2e8@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
 <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>
 <VFn3GC5zqMcQu3eqRRnl7rirlVQpk_PkPUvxoCvBJbA=.2618fc87-df2e-4ddf-aa28-15a416d4b2e8@github.com>
Message-ID: <e4HvqQqaP7FqZQwJlCkPNpE3krYWOHs5iD8PhHl_9a0=.c0dd82fd-7a52-49a8-b83c-b02a8c83d464@github.com>

On Wed, 29 Jun 2022 02:12:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I realised that by swapping the `mov` and the `cmp` instruction, the rule needs to have `dst` different from `src1` and `src2`, which increases register pressure.
>
> I do not follow your comment, allocation decisions purely based on LRGs interferences and data flow attributes attached to operands and is agnostic to encoding block contents.

Your suggestion requires us having additional `TEMP dst` for the match rule. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From almatvee at openjdk.org  Wed Jun 29 03:11:21 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 29 Jun 2022 03:11:21 GMT
Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when
 creating DMG or PKG
Message-ID: <fPZsv2fGfyPSAZyF5UcBUo3EicShZJZNv16GocbGV48=.e4ac18e3-a922-44b3-8b0f-145d1313a715@github.com>

Fixed 3 issues which made signature invalid:
- We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature.
- .package should be created when app image is generated, so this file can be signed.
- Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well.

Added additional test to validate signature when DMG or PKG is generated from predefined app image.

-------------

Commit messages:
 - 8289030: [macos] app image signature invalid when creating DMG or PKG

Changes: https://git.openjdk.org/jdk19/pull/89/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289030
  Stats: 149 lines in 5 files changed: 134 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk19/pull/89.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/89/head:pull/89

PR: https://git.openjdk.org/jdk19/pull/89

From duke at openjdk.org  Wed Jun 29 04:20:31 2022
From: duke at openjdk.org (liach)
Date: Wed, 29 Jun 2022 04:20:31 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v6]
In-Reply-To: <qdr4XR_9GE7BC8eklkGUMN35XhC0ZOxfAyFLY44eCb4=.d5b30f63-1770-4e10-9764-bc786b2e258b@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <qdr4XR_9GE7BC8eklkGUMN35XhC0ZOxfAyFLY44eCb4=.d5b30f63-1770-4e10-9764-bc786b2e258b@github.com>
Message-ID: <Wo2yNPRGqH0XzwYdzzyCU1UFH2e7STMVHCJFnZyqcRc=.295b20e6-eae5-4849-b352-2660a6e1807f@github.com>

On Thu, 26 May 2022 23:20:27 GMT, liach <duke at openjdk.org> wrote:

>> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
>> 
>> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes suggested by mandy

Would someone review or sponsor this mino improvement?

-------------

PR: https://git.openjdk.org/jdk/pull/8281

From jbhateja at openjdk.org  Wed Jun 29 04:23:45 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 29 Jun 2022 04:23:45 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <e4HvqQqaP7FqZQwJlCkPNpE3krYWOHs5iD8PhHl_9a0=.c0dd82fd-7a52-49a8-b83c-b02a8c83d464@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
 <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>
 <VFn3GC5zqMcQu3eqRRnl7rirlVQpk_PkPUvxoCvBJbA=.2618fc87-df2e-4ddf-aa28-15a416d4b2e8@github.com>
 <e4HvqQqaP7FqZQwJlCkPNpE3krYWOHs5iD8PhHl_9a0=.c0dd82fd-7a52-49a8-b83c-b02a8c83d464@github.com>
Message-ID: <t-GCTicCLWNtEIcxgHgK4DeINe2XJWdY87mXSpn6Fjo=.fa5ed48c-5d80-4a8d-b082-bb91e3731237@github.com>

On Wed, 29 Jun 2022 02:22:02 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> I do not follow your comment, allocation decisions purely based on LRGs interferences and data flow attributes attached to operands and is agnostic to encoding block contents.
>
> Your suggestion requires us having additional `TEMP dst` for the match rule. Thanks.

Yes, macro fusion is a fine microarchitectural optimization which can reduce load on entire execution pipeline and is **deterministic** for specific pair of cmp + jump instructions, you have aggregated destination's defs and its usages towards the tail which can save TEMP attribution on destination operand and may save a redundant spill only for high register pressure blocks. I am ok with existing handling.

Thanks for your explanations.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From jbhateja at openjdk.org  Wed Jun 29 06:09:33 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 29 Jun 2022 06:09:33 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
Message-ID: <452dySWhqSw4rDXLA1MQR3x3Nz3Xt4wYdJ0j7UYCVyA=.a3acfa1c-658b-4313-927a-0c47146a79e7@github.com>

On Wed, 22 Jun 2022 03:01:36 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comparison for direct value of compare

Marked as reviewed by jbhateja (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From jpai at openjdk.org  Wed Jun 29 06:21:33 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Jun 2022 06:21:33 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v6]
In-Reply-To: <Wo2yNPRGqH0XzwYdzzyCU1UFH2e7STMVHCJFnZyqcRc=.295b20e6-eae5-4849-b352-2660a6e1807f@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <qdr4XR_9GE7BC8eklkGUMN35XhC0ZOxfAyFLY44eCb4=.d5b30f63-1770-4e10-9764-bc786b2e258b@github.com>
 <Wo2yNPRGqH0XzwYdzzyCU1UFH2e7STMVHCJFnZyqcRc=.295b20e6-eae5-4849-b352-2660a6e1807f@github.com>
Message-ID: <iW9MgWjTEpBE1ZSlFQIiXZGVa-zPAg-xbTlu6A-Srog=.22de979b-c5b1-47af-b814-450068931ec0@github.com>

On Wed, 29 Jun 2022 04:17:00 GMT, liach <duke at openjdk.org> wrote:

> Would someone review or sponsor this mino improvement?

Hello @liach, I see that Mandy has already reviewed and approved this PR and there hasn't been any change in this PR after that (which is a good thing). I'll run some tests internally today and if that goes fine, then I'll go ahead and sponsor this.

-------------

PR: https://git.openjdk.org/jdk/pull/8281

From sergei.tsypanov at yandex.ru  Wed Jun 29 06:54:43 2022
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Wed, 29 Jun 2022 08:54:43 +0200
Subject: Executable.hasRealParameterData() and Parameter.isNamePresent() don't
 work as expected
Message-ID: <3890111656485683@iva2-15a880c55b23.qloud-c.yandex.net>

This question was asked originally here: https://stackoverflow.com/questions/72787286/executable-hasrealparameterdata-and-parameter-isnamepresent-dont-work-as-ex
but as soon as I got no answer I've decided to try it here adding some concerns regarding JavaDoc of Parameter.isNamePresent()

With ad-hoc built JDK 19 (having exposed `Executable.hasRealParameterData()`) I take the code

public class Main {

  public static void main(String[] args) throws NoSuchMethodException {
    Method foo = Main.class.getMethod("foo", String.class, int.class);
    System.out.println(foo.hasRealParameterData());
  }

  public void foo(String parameter1, int parameter2) {}
}

and compile it with

% javac Main.java

Then I run compiled Java class and it prints `false` into console. This is fine because decompiled `Main` class looks like

public class Main {
  //...
  public void foo(String var1, int var2) {} // parameter names are not 'real'
}

i.e. parameter names are synthetic. 

This behaviour is understandable.

Then I take the same Java sources and recompile the class with

javac -g:vars Main.java

I run the same code again and again it prints `false` to console. This puzzles me, because now the compiled code looks different:

public class Main {
  //...
  public void foo(String parameter1, int parameter2) {} // parameter names are 'real'
}

Same happens if for recompilation I use plain -g flag (generates all auxiliary data).

Now let's stop calling JDK's private API and rely only on the methods available out-of-the-box,
e.g. `Parameter.isNamePresent()` (this one calls `Executable.hasRealParameterData()` under the hood):

public static void main(String[] args) throws NoSuchMethodException {
  Method foo = Main.class.getMethod("foo", String.class, int.class);
  Parameter parameter1 = foo.getParameters()[0];
  Parameter parameter2 = foo.getParameters()[1];
  System.out.println(parameter1.isNamePresent());
  System.out.println(parameter2.isNamePresent());
}

public void foo(String parameter1, int parameter2) {}

And again, no matter how I compile the sources, this code prints `false false`.

So my two questions are
1) whether this is a bug or am I doing something wrong?
2) is it possible somehow to change the behaviour to have at least Parameter.isNamePresent() returning true

P.S. Parameter.isNamePresent() works unexpectedly even when I run it on conventional, not hacked JDK.

P.P.S. In compiled code I see 'real' parameter names, but if I stop at debug point in IDEA parameter name is suddenly `arg0` in `Parameter.name` field.

P.P.P.S. I think that JavaDoc of Parameter.isNamePresent() should be changed as soon as now it points out to 'MethodParameters' attribute of a class file
which is confusing to me as to end user of Java because I cannot understand from plain Java code what are those 'MethodParameters' and what will
be returned for any of my methods.

From duke at openjdk.org  Wed Jun 29 07:20:42 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 29 Jun 2022 07:20:42 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
Message-ID: <TzyI4fRAHpWjZd75xC2rfbcjNfO5LtYEjroQOGDaEdg=.204bd58c-67fe-49e0-b3dd-ec691f2f8c0b@github.com>

On Wed, 22 Jun 2022 03:01:36 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comparison for direct value of compare

Thank you very much for your reviews

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From aturbanov at openjdk.org  Wed Jun 29 07:47:00 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Jun 2022 07:47:00 GMT
Subject: RFR: 8289431: Avoid redundant HashMap.get in
 ZipFileSystemProvider.removeFileSystem
Message-ID: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>

There is overload method HashMap.remove(key,value) which also checks value equality.
It's shorter and faster than pair get+remove.

-------------

Commit messages:
 - [PATCH] Remove redundant HashMap.get call before HashMap.remove

Changes: https://git.openjdk.org/jdk/pull/9314/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9314&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289431
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9314.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9314/head:pull/9314

PR: https://git.openjdk.org/jdk/pull/9314

From aturbanov at openjdk.org  Wed Jun 29 08:20:31 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Jun 2022 08:20:31 GMT
Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in
 ZipFileSystemProvider.removeFileSystem [v2]
In-Reply-To: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>
References: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>
Message-ID: <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>

> There is overload method HashMap.remove(key,value) which also checks value equality.
> It's shorter and faster than pair get+remove.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem
  update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9314/files
  - new: https://git.openjdk.org/jdk/pull/9314/files/5a83b10c..d9eeaebe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9314&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9314&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9314.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9314/head:pull/9314

PR: https://git.openjdk.org/jdk/pull/9314

From dfuchs at openjdk.org  Wed Jun 29 09:32:39 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 29 Jun 2022 09:32:39 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit [v3]
In-Reply-To: <sQDbydSnmaVv5Oi1Uy-hwwshQdTiHG1xLfg94YWxzyo=.243bd22f-5d04-4380-ad2e-e8571e79bf71@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
 <sQDbydSnmaVv5Oi1Uy-hwwshQdTiHG1xLfg94YWxzyo=.243bd22f-5d04-4380-ad2e-e8571e79bf71@github.com>
Message-ID: <2gCZGfH_ZGmieqNCup9hOU1DpqnAfUzN9DCCiquF85o=.beb49c8d-3c06-46c6-94b3-605bca6c6763@github.com>

On Tue, 28 Jun 2022 14:22:48 GMT, rmartinc <duke at openjdk.org> wrote:

>> Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895).
>> 
>> Any `LimitExceededException` now quits the referral loop.
>> 
>> Added class `ReferralLimitSearchTest`. It is a simple jtreg test which checks that `java.naming.ldap.referral.limit` is really enforced. The dummy ldap server always returns a referral for any search query. If the number of searches exceeds the limit, it throws an `IOException` and the test fails.
>> 
>> 
>> make test TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java
>
> rmartinc has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288895: LdapContext doesn't honor set referrals limit (typo)

Thanks for the updates! Please run tier2 tests before integrating.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9256

From lancea at openjdk.org  Wed Jun 29 09:59:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 29 Jun 2022 09:59:40 GMT
Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in
 ZipFileSystemProvider.removeFileSystem [v2]
In-Reply-To: <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>
References: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>
 <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>
Message-ID: <82cMs13RmsxAmmPAAo2ZwZtJNjxtL_0S-umJ5VbB0ss=.b58bf96c-4025-4e38-b2f6-1e815e3dcadd@github.com>

On Wed, 29 Jun 2022 08:20:31 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> There is overload method HashMap.remove(key,value) which also checks value equality.
>> It's shorter and faster than pair get+remove.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem
>   update copyright year

The change seems OK.  Note  that the `removeFileSystem` method is only called when zipfs is closed

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9314

From duke at openjdk.org  Wed Jun 29 10:37:06 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 29 Jun 2022 10:37:06 GMT
Subject: Integrated: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <XjsZ5o4sg4nW0kEy8UHLlkhwfaMURUST2GXY1pJIV4I=.9c5e7d38-71b7-4042-b0d3-5fd60b47d098@github.com>

On Tue, 7 Jun 2022 17:14:18 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

This pull request has now been integrated.

Changeset: 108cd695
Author:    Quan Anh Mai <anhmdq99 at gmail.com>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/108cd695167f0eed7b778c29b55914998f15b90d
Stats:     271 lines in 15 files changed: 260 ins; 0 del; 11 mod

8283726: x86_64 intrinsics for compareUnsigned method in Integer and Long

Reviewed-by: kvn, jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From akasko at openjdk.org  Wed Jun 29 12:29:33 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 29 Jun 2022 12:29:33 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments [v3]
In-Reply-To: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
Message-ID: <ADhE_o9_X3pkmxLFEY28QIuZQarHGuflWlAHJI_K8I8=.417b3f67-1199-42b4-bcf9-0294ba3ced99@github.com>

> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable.
> 
> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard.
> 
> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points:
> 
>  - option naming inside a properties file, currently `pass-all-args` is used
>  - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group
>  - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination
>  - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop`
> 
> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version.
> 
> Testing:
>  
> - [x] test to cover new logic is included
> - [x] ran jtreg:jdk/tools/jpackage with no new failures

Alex Kasko has updated the pull request incrementally with one additional commit since the last revision:

  drop pass-all-args property

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9224/files
  - new: https://git.openjdk.org/jdk/pull/9224/files/3b4f77e8..7e14f614

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9224&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9224&range=01-02

  Stats: 60 lines in 7 files changed: 0 ins; 37 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/9224.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9224/head:pull/9224

PR: https://git.openjdk.org/jdk/pull/9224

From akasko at openjdk.org  Wed Jun 29 12:33:41 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 29 Jun 2022 12:33:41 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments
In-Reply-To: <L1ha-AvMYWSIsZtd3SyAufiVydVd25U5F1RUWkQGY6Q=.ae6ca49e-8b8d-46df-a4f6-2e1f3d8e1376@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
 <hTh3uRo1rC7Ezwdsj7tz0Log-jqoFByCc5dyzKtpUcg=.9a8f6452-ac24-4775-8033-91fe0d44fe0f@github.com>
 <D0ieEkV22FALpm1C4Fpcsh9Vs8Veb71l8bcTmxma7Hg=.0ea61e99-f9e0-430e-8cc0-cff1d75c9705@github.com>
 <L1ha-AvMYWSIsZtd3SyAufiVydVd25U5F1RUWkQGY6Q=.ae6ca49e-8b8d-46df-a4f6-2e1f3d8e1376@github.com>
Message-ID: <KArep8u6e0n71iS-Vo20te4RjLMnNX49JjLKdwCm7tY=.eee252ec-9c96-4b38-8a5d-4275b686441e@github.com>

On Tue, 28 Jun 2022 21:38:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> > I assume we will need an additional similar property for a verb label displayed in a context menu.
> 
> Agree. At least we need to provide l10n for it.

For runtime installers it would be great to have a custom verb label, to be able to use something like: "Open with VendorName OpenJDK". I intend to prototype this and file in a separate PR (there is a related point about the "ampersand for keyboard shortcut" in this label, that is currently unclear).

-------------

PR: https://git.openjdk.org/jdk/pull/9224

From akasko at openjdk.org  Wed Jun 29 12:58:27 2022
From: akasko at openjdk.org (Alex Kasko)
Date: Wed, 29 Jun 2022 12:58:27 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments
In-Reply-To: <L1ha-AvMYWSIsZtd3SyAufiVydVd25U5F1RUWkQGY6Q=.ae6ca49e-8b8d-46df-a4f6-2e1f3d8e1376@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
 <hTh3uRo1rC7Ezwdsj7tz0Log-jqoFByCc5dyzKtpUcg=.9a8f6452-ac24-4775-8033-91fe0d44fe0f@github.com>
 <D0ieEkV22FALpm1C4Fpcsh9Vs8Veb71l8bcTmxma7Hg=.0ea61e99-f9e0-430e-8cc0-cff1d75c9705@github.com>
 <L1ha-AvMYWSIsZtd3SyAufiVydVd25U5F1RUWkQGY6Q=.ae6ca49e-8b8d-46df-a4f6-2e1f3d8e1376@github.com>
Message-ID: <d3MbGe9nHpu_Xc7Pi2DwIUN7tU2SkOApqG1HyQXnNAM=.1d3edce0-cea5-4fc9-855b-309ff96e2ea2@github.com>

On Tue, 28 Jun 2022 21:38:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The existing behavior simply cuts off all, but the first argument from the argument array passed to the app launcher. Changing this looks more like a fix of a bug, than an enhancement. I'd keep it simple: replace the value of the `Argument` attribute from `%1` to `%*`. Besides, `"%1 %*"` seems to duplicate the first argument (`%1` is not referencing a path to app launcher executable, but the name of a file to open). If fixed in this way, we don't need to introduce `pass-all-args`.

I've experimented with this, used following example app:

 - `hello.jar` - java application
 - `hello.exe` - launcher created by jpackage
 - `hello.foo` - file with a `.foo` extension associated with `hello.exe`

Arguments placeholders specified In a `progid[...]\shell\open\command` registry entry are received in java app in a following form:

 - `%0` points to `c:\path\too\hello.foo`, that is a selected file path (for context menu invocation) or a `shortcut.TargetPath` property (for `LNK` shortcut invocation)
 - `%1` is the same as `%0` 
 - `%2` points to the first argument in `shortcut.Arguments` property
 - `%*` contains all the arguments beginning from `%2`

`%1` must be quoted, otherwise it only contains the part of path before the first space and other path parts are passed as `%2` and following arguments.

`%*` must not be quoted, it passes arguments with spaces correctly.

Based on the above I've updated the patch dropping the property and changing the `Argument` to `"%1" %*`.

I would appreciate the guidance on the test changes (note, `packageTest.forTypes` and `packageTest.run` changes are temporary). Foremost, should we cover all three ways to invoke the associated file (command line, desktop open associated file, desktop open LNK) and (if yes) should they be split into separate test runs?

-------------

PR: https://git.openjdk.org/jdk/pull/9224

From duke at openjdk.org  Wed Jun 29 12:59:42 2022
From: duke at openjdk.org (liach)
Date: Wed, 29 Jun 2022 12:59:42 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v4]
In-Reply-To: <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
Message-ID: <YS8Q5CRXuxtthC-hBXt1eCLJvXyLNc88bMzxi2OdaX0=.67ab2a7d-7980-495b-878d-612042dbc918@github.com>

On Fri, 6 May 2022 22:05:35 GMT, liach <duke at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Move tests
>  - Merge branch 'master' into fix/identityhashmap-default
>  - Fix assertions
>  - Revamp test and changes. Let ci run the tests
>  - Fix indent
>  - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)

Could anyone take a look at this collections-related patch?

-------------

PR: https://git.openjdk.org/jdk/pull/8259

From jpai at openjdk.org  Wed Jun 29 14:22:44 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Jun 2022 14:22:44 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v6]
In-Reply-To: <qdr4XR_9GE7BC8eklkGUMN35XhC0ZOxfAyFLY44eCb4=.d5b30f63-1770-4e10-9764-bc786b2e258b@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <qdr4XR_9GE7BC8eklkGUMN35XhC0ZOxfAyFLY44eCb4=.d5b30f63-1770-4e10-9764-bc786b2e258b@github.com>
Message-ID: <19N7yUS_3EtdikFqotIIo_qi1CJNAeaijOTe5mQ_RZk=.d20a61d3-7f70-4712-a9a2-3ed03df14e8c@github.com>

On Thu, 26 May 2022 23:20:27 GMT, liach <duke at openjdk.org> wrote:

>> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
>> 
>> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes suggested by mandy

Locally, I merged the latest master branch with this PR and then ran tier1, tier2 and tier3 tests. The tests passed without any related failures. I'll go ahead and sponsor this now.

-------------

PR: https://git.openjdk.org/jdk/pull/8281

From duke at openjdk.org  Wed Jun 29 14:26:43 2022
From: duke at openjdk.org (liach)
Date: Wed, 29 Jun 2022 14:26:43 GMT
Subject: Integrated: 8284942: Proxy building can just iterate superinterfaces
 once
In-Reply-To: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
Message-ID: <2J9BP95Bi-YxEGTB41DFkp220cp_lpzIqVNJ0FM2dbg=.cd347046-a764-43fb-8509-0ec3a98c5ed0@github.com>

On Mon, 18 Apr 2022 06:15:54 GMT, liach <duke at openjdk.org> wrote:

> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
> 
> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.

This pull request has now been integrated.

Changeset: 0709a6a1
Author:    liach <liach at users.noreply.github.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0709a6a1fb6bfc8aecde7eb827d1628e181e3253
Stats:     74 lines in 1 file changed: 19 ins; 22 del; 33 mod

8284942: Proxy building can just iterate superinterfaces once

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/8281

From duke at openjdk.org  Wed Jun 29 14:38:45 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Wed, 29 Jun 2022 14:38:45 GMT
Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset
 set with TZ env variable
In-Reply-To: <pLyfFSkudoD_Mcy2Tnac0Vrteafqhghp8KO5rPhycd8=.a681a16c-8a72-4a15-b292-490e98e3f12d@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
 <pLyfFSkudoD_Mcy2Tnac0Vrteafqhghp8KO5rPhycd8=.a681a16c-8a72-4a15-b292-490e98e3f12d@github.com>
Message-ID: <GzJE-76Yq4vmpqmkLOG9jR8epmrgmrzBPjBt_vO09bs=.226101a5-4f0c-4ab4-8c69-6de5ffcd87bf@github.com>

On Tue, 28 Jun 2022 22:15:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a REDO of the Fix that was incompletely implemented earlier:
>> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
>> 
>> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
>> 
>> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
>> _(where 7200 represents 7200 seconds -> +2 hour offset)_
>> Sample output:
>> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)
>
> I just wonder we could simply call `strftime` with `%z` conversion, rather than calculating the GMT offset ourselves. Would you like to try it out?

@naotoj Thanks for letting me know, hadn't tried that function yet. At first look it seems to working exactly as needed, but I will need to parse the result into substrings to put a semi-colon between the hour and minute offset, in order to match the output required. But definitely looks much simpler in comparison ...

-------------

PR: https://git.openjdk.org/jdk/pull/9312

From rriggs at openjdk.org  Wed Jun 29 14:45:43 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Jun 2022 14:45:43 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection
In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
Message-ID: <W-Ud53i3hx6UXq9S8baesgYYxz0dR5iYPloR-x6Fqt0=.1336b254-f18b-4721-97b6-36f46c478475@github.com>

On Mon, 27 Jun 2022 20:26:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> JDK-8289106: Add model of class file versions to core reflection

A static method to map from classfile version (as in the JVMS) to ClassFileVersion enum will be useful too.

-------------

PR: https://git.openjdk.org/jdk/pull/9299

From duke at openjdk.org  Wed Jun 29 14:59:44 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Wed, 29 Jun 2022 14:59:44 GMT
Subject: [jdk19] Integrated: 8288596: Random:from() adapter does not delegate
 to supplied generator in all cases
In-Reply-To: <5VcKHDxn2sRglNaWKpiccebi2CohEde0Mb8JOSQh8m4=.892e04a0-3659-48a3-8776-aebb46d63757@github.com>
References: <5VcKHDxn2sRglNaWKpiccebi2CohEde0Mb8JOSQh8m4=.892e04a0-3659-48a3-8776-aebb46d63757@github.com>
Message-ID: <QTxq_q6aQYt-GD5xHhv_kpk7NXF6hlhJgX2RYUTc9jw=.ccee883d-9692-4746-9667-7ed87251cbd7@github.com>

On Fri, 17 Jun 2022 16:44:30 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

> Extend delegation by instance returned by Random.from() to all methods exposed by RandomGenerator.

This pull request has now been integrated.

Changeset: 57089749
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/570897498baeab8d10f7d9525328a6d85d8c73ec
Stats:     100 lines in 2 files changed: 97 ins; 0 del; 3 mod

8288596: Random:from() adapter does not delegate to supplied generator in all cases

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk19/pull/36

From ecaspole at openjdk.org  Wed Jun 29 15:43:43 2022
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 29 Jun 2022 15:43:43 GMT
Subject: RFR: 8288732: Reduce runtime of java.util.concurrent
 microbenchmarks
In-Reply-To: <mYymzOgt__HGcR6_bQzrxGIn6Tko1idFcukgBT3rc40=.fd7868c2-2993-44b1-8131-ca7ac5f17b79@github.com>
References: <mYymzOgt__HGcR6_bQzrxGIn6Tko1idFcukgBT3rc40=.fd7868c2-2993-44b1-8131-ca7ac5f17b79@github.com>
Message-ID: <aQxF05WIQPhO90qIJnQhDw0-3SuPiCDKQUNNea41eZ8=.dd7de0eb-96e5-4aa7-83c9-b5402d3fed9e@github.com>

On Mon, 20 Jun 2022 10:47:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Refactor so that various baseline micros are not run repeatedly with different parameter values that does not affect the baseline
> - Tune iteration times, counts, forks..
> 
> Reduces runtime of java.util.concurrent micros from an estimated 14h43m to 1h21m

Nice cleanup. The quicker these run with stable performance, the more we can use them every week.

-------------

Marked as reviewed by ecaspole (Committer).

PR: https://git.openjdk.org/jdk/pull/9214

From naoto at openjdk.org  Wed Jun 29 15:51:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Jun 2022 15:51:48 GMT
Subject: [jdk19] Integrated: 8289252: Recommend Locale.of() method instead of
 the constructor
In-Reply-To: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
Message-ID: <hehC3ivvST5ilsD0K28vL7Rh7amTc2sROVQiSNiM30M=.eadda121-9dd5-452b-83f4-c2fa7dc9c686@github.com>

On Tue, 28 Jun 2022 17:11:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: cf715449
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/cf7154498fffba202b74b41a074f25c657b2e591
Stats:     14 lines in 1 file changed: 4 ins; 2 del; 8 mod

8289252: Recommend Locale.of() method instead of the constructor

Reviewed-by: joehw, rriggs

-------------

PR: https://git.openjdk.org/jdk19/pull/85

From naoto at openjdk.org  Wed Jun 29 15:57:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Jun 2022 15:57:40 GMT
Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset
 set with TZ env variable
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <4OE16SpqusTjcAqccMuhmDhyFNCM0P_gMX4FCY92VEI=.3e13d96e-53d1-498d-b6d1-81aa532e2303@github.com>

On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

I think you could simplify the code further, i.e. there will be no need to separate the function with `#if defined(MACOSX)`. The code can be shared with all Unix platforms.

-------------

PR: https://git.openjdk.org/jdk/pull/9312

From daniel.fuchs at oracle.com  Wed Jun 29 16:27:39 2022
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 Jun 2022 17:27:39 +0100
Subject: Executable.hasRealParameterData() and Parameter.isNamePresent()
 don't work as expected
In-Reply-To: <3890111656485683@iva2-15a880c55b23.qloud-c.yandex.net>
References: <3890111656485683@iva2-15a880c55b23.qloud-c.yandex.net>
Message-ID: <c73a84e0-9a8d-a552-255c-9617336ffa92@oracle.com>

Hi Sergey,

I believe you need to compile with `-parameters`

https://docs.oracle.com/en/java/javase/18/docs/specs/man/javac.html

best regards,

-- daniel

On 29/06/2022 07:54, ?????? ??????? wrote:
> This question was asked originally here: https://stackoverflow.com/questions/72787286/executable-hasrealparameterdata-and-parameter-isnamepresent-dont-work-as-ex
> but as soon as I got no answer I've decided to try it here adding some concerns regarding JavaDoc of Parameter.isNamePresent()
> 
> With ad-hoc built JDK 19 (having exposed `Executable.hasRealParameterData()`) I take the code
> 
> public class Main {
> 
>    public static void main(String[] args) throws NoSuchMethodException {
>      Method foo = Main.class.getMethod("foo", String.class, int.class);
>      System.out.println(foo.hasRealParameterData());
>    }
> 
>    public void foo(String parameter1, int parameter2) {}
> }
> 
> and compile it with
> 
> % javac Main.java
> 
> Then I run compiled Java class and it prints `false` into console. This is fine because decompiled `Main` class looks like
> 
> public class Main {
>    //...
>    public void foo(String var1, int var2) {} // parameter names are not 'real'
> }
> 
> i.e. parameter names are synthetic.
> 
> This behaviour is understandable.
> 
> Then I take the same Java sources and recompile the class with
> 
> javac -g:vars Main.java
> 
> I run the same code again and again it prints `false` to console. This puzzles me, because now the compiled code looks different:
> 
> public class Main {
>    //...
>    public void foo(String parameter1, int parameter2) {} // parameter names are 'real'
> }
> 
> Same happens if for recompilation I use plain -g flag (generates all auxiliary data).
> 
> Now let's stop calling JDK's private API and rely only on the methods available out-of-the-box,
> e.g. `Parameter.isNamePresent()` (this one calls `Executable.hasRealParameterData()` under the hood):
> 
> public static void main(String[] args) throws NoSuchMethodException {
>    Method foo = Main.class.getMethod("foo", String.class, int.class);
>    Parameter parameter1 = foo.getParameters()[0];
>    Parameter parameter2 = foo.getParameters()[1];
>    System.out.println(parameter1.isNamePresent());
>    System.out.println(parameter2.isNamePresent());
> }
> 
> public void foo(String parameter1, int parameter2) {}
> 
> And again, no matter how I compile the sources, this code prints `false false`.
> 
> So my two questions are
> 1) whether this is a bug or am I doing something wrong?
> 2) is it possible somehow to change the behaviour to have at least Parameter.isNamePresent() returning true
> 
> P.S. Parameter.isNamePresent() works unexpectedly even when I run it on conventional, not hacked JDK.
> 
> P.P.S. In compiled code I see 'real' parameter names, but if I stop at debug point in IDEA parameter name is suddenly `arg0` in `Parameter.name` field.
> 
> P.P.P.S. I think that JavaDoc of Parameter.isNamePresent() should be changed as soon as now it points out to 'MethodParameters' attribute of a class file
> which is confusing to me as to end user of Java because I cannot understand from plain Java code what are those 'MethodParameters' and what will
> be returned for any of my methods.


From darcy at openjdk.org  Wed Jun 29 16:34:41 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Jun 2022 16:34:41 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection
In-Reply-To: <W-Ud53i3hx6UXq9S8baesgYYxz0dR5iYPloR-x6Fqt0=.1336b254-f18b-4721-97b6-36f46c478475@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
 <W-Ud53i3hx6UXq9S8baesgYYxz0dR5iYPloR-x6Fqt0=.1336b254-f18b-4721-97b6-36f46c478475@github.com>
Message-ID: <LDxsjBwcCeuoRkgxX7_m7rxKzJ9mQk4VRS3O-BSwqXw=.e3f6a0c4-4d8d-4ab7-bf20-7e7e6554b732@github.com>

On Wed, 29 Jun 2022 14:42:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A static method to map from classfile version (as in the JVMS) to ClassFileVersion enum will be useful too.

Just to confirm, you're asking for a method that would map 63 to RELEASE_19, 64 to RELEASE_20, etc.?

Seems reasonable, although there will need to be special treating for 45 since both RELEASE_0 and RELEASE_1 have a major number of 45.

-------------

PR: https://git.openjdk.org/jdk/pull/9299

From darcy at openjdk.org  Wed Jun 29 16:46:47 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Jun 2022 16:46:47 GMT
Subject: RFR: 8289260: BigDecimal movePointLeft() and movePointRight() do
 not follow their API spec [v2]
In-Reply-To: <6IlMf8sU-acr2ck6Ao0q211RBuc1SdCDx_pMHLkqBQ8=.c422a523-6e77-4f44-b0cd-95b4f184544a@github.com>
References: <GVFLjJjTSYxwy1oHLNRgD8Tej8JyFAiA241b89w1gt4=.c2dbd2b6-3d28-4372-bae0-792b48207883@github.com>
 <6IlMf8sU-acr2ck6Ao0q211RBuc1SdCDx_pMHLkqBQ8=.c422a523-6e77-4f44-b0cd-95b4f184544a@github.com>
Message-ID: <Y1ha8DLzRT8alIZiGsWM1vuYnevUNCGv-Tf9mVazl64=.46641dd0-8eef-4ffa-8e4b-b7014ecf32f8@github.com>

On Tue, 28 Jun 2022 10:32:31 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> `BigDecimal.morePoint[Left|Right]()` should return the target `this` when the argument is 0 _and_ the scale is non-negative.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec

@rgiulietti , please file a CSR for the behavioral change.

-------------

PR: https://git.openjdk.org/jdk/pull/9307

From rriggs at openjdk.org  Wed Jun 29 16:54:37 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Jun 2022 16:54:37 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection
In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
Message-ID: <nQoPohoRMp-RNYcb6y5cu61UkXTExwohufCdxoJaJXk=.841fd580-70f6-41be-8b53-467ae9d0b3cf@github.com>

On Mon, 27 Jun 2022 20:26:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> JDK-8289106: Add model of class file versions to core reflection

I'm thinking of the case where I'm reading class file bytes and pull out the major classfile version and want to map it to the enum. If the semantic was the "earliest version" supporting the major version then it would be unambiguous.

-------------

PR: https://git.openjdk.org/jdk/pull/9299

From smarks at openjdk.org  Wed Jun 29 17:01:45 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 29 Jun 2022 17:01:45 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v4]
In-Reply-To: <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
Message-ID: <0mk76aBlYb5FFsDiXyMIh6XTyDsSwMrID7Ixm2Maj-k=.32204cf5-67b0-4c9d-bd13-cc46fad611cb@github.com>

On Fri, 6 May 2022 22:05:35 GMT, liach <duke at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Move tests
>  - Merge branch 'master' into fix/identityhashmap-default
>  - Fix assertions
>  - Revamp test and changes. Let ci run the tests
>  - Fix indent
>  - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)

OK, I will sponsor this.

-------------

PR: https://git.openjdk.org/jdk/pull/8259

From duke at openjdk.org  Wed Jun 29 18:18:53 2022
From: duke at openjdk.org (liach)
Date: Wed, 29 Jun 2022 18:18:53 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v4]
In-Reply-To: <CYXUywvj-GH7yGtI6zT2CgCV79sk_Uaes9_288H1BQI=.f00fbd19-5aa1-4f20-86fa-336a92d413ac@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <CYXUywvj-GH7yGtI6zT2CgCV79sk_Uaes9_288H1BQI=.f00fbd19-5aa1-4f20-86fa-336a92d413ac@github.com>
Message-ID: <CxTLR2vk-7AL2YV-4Rhn4bYFpsrpbkOxa25pzS06-Iw=.69c53473-cf6a-4e7e-877b-f070cf6c9c05@github.com>

On Fri, 17 Jun 2022 11:21:49 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
>> 
>> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288327: Mark ParameterData.parameters as @Stable and rename real -> isReal

src/java.base/share/classes/java/lang/reflect/Executable.java line 413:

> 411:     }
> 412: 
> 413:     boolean hasRealParameterData() {

Since `privateGetParameters` and `hasRealParameterData` are now both simple methods with only one use site, they can be simply inlined in `getParameters()` and `getAllGenericParameterTypes()` instead:


    public Parameter[] getParameters() {
        // Need to copy the cached array to prevent users from messing
        // with it.  Since parameters are immutable, we can
        // shallow-copy.
        return parameterData().parameters.clone();
    }
...
            final boolean realParamData = parameterData().isReal();
            final Type[] genericParamTypes = getGenericParameterTypes();
            final Type[] nonGenericParamTypes = getParameterTypes();

src/java.base/share/classes/java/lang/reflect/Executable.java line 419:

> 417:     private ParameterData parameterData() {
> 418:         ParameterData parameterData = this.parameterData;
> 419:         if (parameterData != null){

Suggestion:

        if (parameterData != null) {

src/java.base/share/classes/java/lang/reflect/Executable.java line 777:

> 775:     }
> 776: 
> 777:     record ParameterData(@Stable Parameter[] parameters, boolean isReal) {}

I recommend declaring this right next to `parameterData` field for the ease of maintenance, like how `EntrySet` in map implementations are declared right next to `entrySet` methods.

-------------

PR: https://git.openjdk.org/jdk/pull/9143

From joe.darcy at oracle.com  Wed Jun 29 19:47:15 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 29 Jun 2022 12:47:15 -0700
Subject: Executable.hasRealParameterData() and Parameter.isNamePresent()
 don't work as expected
In-Reply-To: <3890111656485683@iva2-15a880c55b23.qloud-c.yandex.net>
References: <3890111656485683@iva2-15a880c55b23.qloud-c.yandex.net>
Message-ID: <5b037acf-ee02-9201-7d0d-9284bce03ae7@oracle.com>

If you want more information about parameters, use javac with its 
"-parameters" option.

-Joe

On 6/28/2022 11:54 PM, ?????? ??????? wrote:
> This question was asked originally here: https://stackoverflow.com/questions/72787286/executable-hasrealparameterdata-and-parameter-isnamepresent-dont-work-as-ex
> but as soon as I got no answer I've decided to try it here adding some concerns regarding JavaDoc of Parameter.isNamePresent()
>
> With ad-hoc built JDK 19 (having exposed `Executable.hasRealParameterData()`) I take the code
>
> public class Main {
>
>    public static void main(String[] args) throws NoSuchMethodException {
>      Method foo = Main.class.getMethod("foo", String.class, int.class);
>      System.out.println(foo.hasRealParameterData());
>    }
>
>    public void foo(String parameter1, int parameter2) {}
> }
>
> and compile it with
>
> % javac Main.java
>
> Then I run compiled Java class and it prints `false` into console. This is fine because decompiled `Main` class looks like
>
> public class Main {
>    //...
>    public void foo(String var1, int var2) {} // parameter names are not 'real'
> }
>
> i.e. parameter names are synthetic.
>
> This behaviour is understandable.
>
> Then I take the same Java sources and recompile the class with
>
> javac -g:vars Main.java
>
> I run the same code again and again it prints `false` to console. This puzzles me, because now the compiled code looks different:
>
> public class Main {
>    //...
>    public void foo(String parameter1, int parameter2) {} // parameter names are 'real'
> }
>
> Same happens if for recompilation I use plain -g flag (generates all auxiliary data).
>
> Now let's stop calling JDK's private API and rely only on the methods available out-of-the-box,
> e.g. `Parameter.isNamePresent()` (this one calls `Executable.hasRealParameterData()` under the hood):
>
> public static void main(String[] args) throws NoSuchMethodException {
>    Method foo = Main.class.getMethod("foo", String.class, int.class);
>    Parameter parameter1 = foo.getParameters()[0];
>    Parameter parameter2 = foo.getParameters()[1];
>    System.out.println(parameter1.isNamePresent());
>    System.out.println(parameter2.isNamePresent());
> }
>
> public void foo(String parameter1, int parameter2) {}
>
> And again, no matter how I compile the sources, this code prints `false false`.
>
> So my two questions are
> 1) whether this is a bug or am I doing something wrong?
> 2) is it possible somehow to change the behaviour to have at least Parameter.isNamePresent() returning true
>
> P.S. Parameter.isNamePresent() works unexpectedly even when I run it on conventional, not hacked JDK.
>
> P.P.S. In compiled code I see 'real' parameter names, but if I stop at debug point in IDEA parameter name is suddenly `arg0` in `Parameter.name` field.
>
> P.P.P.S. I think that JavaDoc of Parameter.isNamePresent() should be changed as soon as now it points out to 'MethodParameters' attribute of a class file
> which is confusing to me as to end user of Java because I cannot understand from plain Java code what are those 'MethodParameters' and what will
> be returned for any of my methods.

From darcy at openjdk.org  Wed Jun 29 20:10:36 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Jun 2022 20:10:36 GMT
Subject: RFR: 8289260: BigDecimal movePointLeft() and movePointRight() do
 not follow their API spec [v2]
In-Reply-To: <6IlMf8sU-acr2ck6Ao0q211RBuc1SdCDx_pMHLkqBQ8=.c422a523-6e77-4f44-b0cd-95b4f184544a@github.com>
References: <GVFLjJjTSYxwy1oHLNRgD8Tej8JyFAiA241b89w1gt4=.c2dbd2b6-3d28-4372-bae0-792b48207883@github.com>
 <6IlMf8sU-acr2ck6Ao0q211RBuc1SdCDx_pMHLkqBQ8=.c422a523-6e77-4f44-b0cd-95b4f184544a@github.com>
Message-ID: <-refdnYsBulpNaic2VNdLMhLu0jxBO_c5BCs-xBBSWg=.82f910ee-7039-4bfc-864e-db5ea1c7ce64@github.com>

On Tue, 28 Jun 2022 10:32:31 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> `BigDecimal.morePoint[Left|Right]()` should return the target `this` when the argument is 0 _and_ the scale is non-negative.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9307

From asemenyuk at openjdk.org  Wed Jun 29 20:10:54 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 29 Jun 2022 20:10:54 GMT
Subject: RFR: 8288838: jpackage: file association additional arguments
In-Reply-To: <KArep8u6e0n71iS-Vo20te4RjLMnNX49JjLKdwCm7tY=.eee252ec-9c96-4b38-8a5d-4275b686441e@github.com>
References: <Jqlqabap2saCg4FTMLHMFPprPU760Ay99xsqNz23OCg=.f2a47567-ff5a-4b9b-99bc-1dd29993b3f3@github.com>
 <hTh3uRo1rC7Ezwdsj7tz0Log-jqoFByCc5dyzKtpUcg=.9a8f6452-ac24-4775-8033-91fe0d44fe0f@github.com>
 <D0ieEkV22FALpm1C4Fpcsh9Vs8Veb71l8bcTmxma7Hg=.0ea61e99-f9e0-430e-8cc0-cff1d75c9705@github.com>
 <L1ha-AvMYWSIsZtd3SyAufiVydVd25U5F1RUWkQGY6Q=.ae6ca49e-8b8d-46df-a4f6-2e1f3d8e1376@github.com>
 <KArep8u6e0n71iS-Vo20te4RjLMnNX49JjLKdwCm7tY=.eee252ec-9c96-4b38-8a5d-4275b686441e@github.com>
Message-ID: <GDhGQZKlOjbuxSB5q4g5kQCzea9I6n7l4wzK2N9KzdQ=.f4c506c4-b33e-41d7-b3f2-c166c534c322@github.com>

On Wed, 29 Jun 2022 12:30:05 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> For runtime installers it would be great to have a custom verb label, to be able to use something like: "Open with VendorName OpenJDK". I intend to prototype this and file in a separate PR

Sounds good.

> %* contains all the arguments beginning from %2

Oh, interesting. I didn't know that! Thank you for providing a detailed explanation.

> I would appreciate the guidance on the test changes

I put proposed changes to test classes in https://github.com/openjdk/jdk/pull/9331 PR. I hope the approach gives enough flexibility to configure testing of fa. We can configure all possible test configurations in `FileAssociationTest` test and have basic testing of fa in tests where it is not primary focus. Code in https://github.com/openjdk/jdk/pull/9331 is a sketch, it compiles, but I didn't run it.

-------------

PR: https://git.openjdk.org/jdk/pull/9224

From aturbanov at openjdk.org  Wed Jun 29 21:19:58 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Jun 2022 21:19:58 GMT
Subject: RFR: 8289484: Cleanup unnecessary null comparison before instanceof
 check in java.rmi
Message-ID: <bidV5csA9Q9bg-ocjED8hepzD_rRu2PQ8ZJXiipVa4U=.83ee1b08-8c54-4ef1-85a9-8bc3db5dd652@github.com>

Update code checks both non-null and instance of a class in jdk.hotspot.agent module classes.
The checks and explicit casts could also be replaced with pattern matching for the instanceof operator.

For example, the following code:

        if ((obj != null) && (obj instanceof TCPEndpoint)) {
            TCPEndpoint ep = (TCPEndpoint) obj;
            if (port != ep.port || !host.equals(ep.host))

Can be simplified to:

        if (obj instanceof TCPEndpoint ep) {
            if (port != ep.port || !host.equals(ep.host))


See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422)

-------------

Commit messages:
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.rmi module

Changes: https://git.openjdk.org/jdk/pull/9332/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9332&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289484
  Stats: 9 lines in 3 files changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9332.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9332/head:pull/9332

PR: https://git.openjdk.org/jdk/pull/9332

From darcy at openjdk.org  Wed Jun 29 21:32:29 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Jun 2022 21:32:29 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection [v2]
In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
Message-ID: <nq_0z5CMvZStb7PRycQjoeiKiWil4j6FsQYnLXwANDA=.298b19b4-37f6-4c6a-a804-59d7148b4a25@github.com>

> JDK-8289106: Add model of class file versions to core reflection

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Add method to map from major class file version.
 - Merge branch 'master' into JDK-8289106
 - Update phrasing.
 - Augment and correct docs.
 - Correct major versions; RELEASE_0 and RELEASE_1 are both 45.
 - Make major method public.
 - Add AccessFlag.locations(ClassFileFormatVersion)
 - Add ClassFileFormatVersion <-> Runtime.Version conversions.
 - Merge branch 'master' into JDK-8289106
 - JDK-8289106: Add model of class file versions to core reflection

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9299/files
  - new: https://git.openjdk.org/jdk/pull/9299/files/cf144d66..27a8e194

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=00-01

  Stats: 6369 lines in 171 files changed: 3641 ins; 1373 del; 1355 mod
  Patch: https://git.openjdk.org/jdk/pull/9299.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9299/head:pull/9299

PR: https://git.openjdk.org/jdk/pull/9299

From darcy at openjdk.org  Wed Jun 29 21:32:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Jun 2022 21:32:30 GMT
Subject: RFR: JDK-8289106: Add model of class file versions to core
 reflection
In-Reply-To: <nQoPohoRMp-RNYcb6y5cu61UkXTExwohufCdxoJaJXk=.841fd580-70f6-41be-8b53-467ae9d0b3cf@github.com>
References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com>
 <nQoPohoRMp-RNYcb6y5cu61UkXTExwohufCdxoJaJXk=.841fd580-70f6-41be-8b53-467ae9d0b3cf@github.com>
Message-ID: <ojlpYDKm7wlw8V6oKHH1d4-MjtAHFFCYdA0V7Nn6GOg=.01f9cf3a-bff5-4eb3-b444-23426427f9e0@github.com>

On Wed, 29 Jun 2022 16:51:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I'm thinking of the case where I'm reading class file bytes and pull out the major classfile version and want to map it to the enum. If the semantic was the "earliest version" supporting the major version then it would be unambiguous.

Method to map from major class file version added.

-------------

PR: https://git.openjdk.org/jdk/pull/9299

From jwilhelm at openjdk.org  Wed Jun 29 23:29:28 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 29 Jun 2022 23:29:28 GMT
Subject: RFR: Merge jdk19
Message-ID: <qbz6O1eYKsoroZdGs8jNszLJV6UryTXlA0o_O_83o5M=.855e3031-b34e-412e-ac2a-a17daad15323@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289252: Recommend Locale.of() method instead of the constructor
 - 8288596: Random:from() adapter does not delegate to supplied generator in all cases
 - 8289399: Update SourceVersion to use snippets

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9330&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9330&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9330/files
  Stats: 116 lines in 4 files changed: 102 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9330.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9330/head:pull/9330

PR: https://git.openjdk.org/jdk/pull/9330

From jwilhelm at openjdk.org  Wed Jun 29 23:37:38 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 29 Jun 2022 23:37:38 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <qbz6O1eYKsoroZdGs8jNszLJV6UryTXlA0o_O_83o5M=.855e3031-b34e-412e-ac2a-a17daad15323@github.com>
References: <qbz6O1eYKsoroZdGs8jNszLJV6UryTXlA0o_O_83o5M=.855e3031-b34e-412e-ac2a-a17daad15323@github.com>
Message-ID: <jxYKBVWkUN-a9BQuUJqxJJ3EWvqH5H3uOHBCFBkLe5w=.e801259a-1af5-4c80-a6cc-4e3a53379d53@github.com>

On Wed, 29 Jun 2022 19:38:59 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 048bffad
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/048bffad79b302890059ffc1bc559bfc601de92c
Stats:     116 lines in 4 files changed: 102 ins; 2 del; 12 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9330

From stuart.marks at oracle.com  Wed Jun 29 23:54:54 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 29 Jun 2022 16:54:54 -0700
Subject: Result: new Core Libraries Group member: Naoto Sato
Message-ID: <760171d9-9056-0462-7748-dc901fecb519@oracle.com>

The vote for Naoto Sato [1] is now closed.

Yes: 5
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient to approve 
the nomination.

s'marks

[1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091198.html

From stuart.marks at oracle.com  Wed Jun 29 23:59:28 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 29 Jun 2022 16:59:28 -0700
Subject: Result: new Core Libraries Group member: Roger Riggs
Message-ID: <bc500616-f633-6061-ecc3-cc443a704734@oracle.com>

The vote for Roger Riggs [1] is now closed.

Yes: 5
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient to approve 
the nomination.

s'marks

[1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091258.html

From jpai at openjdk.org  Thu Jun 30 01:51:32 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 30 Jun 2022 01:51:32 GMT
Subject: RFR: 8289484: Cleanup unnecessary null comparison before
 instanceof check in java.rmi
In-Reply-To: <bidV5csA9Q9bg-ocjED8hepzD_rRu2PQ8ZJXiipVa4U=.83ee1b08-8c54-4ef1-85a9-8bc3db5dd652@github.com>
References: <bidV5csA9Q9bg-ocjED8hepzD_rRu2PQ8ZJXiipVa4U=.83ee1b08-8c54-4ef1-85a9-8bc3db5dd652@github.com>
Message-ID: <LkH4SVob-qSzjp633Ua3Y8ryEtqD1X8G-r-wnPoLrvo=.f4132df5-fba3-4aea-8656-12db42ebae5c@github.com>

On Wed, 29 Jun 2022 21:11:09 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Update code checks both non-null and instance of a class in jdk.hotspot.agent module classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator.
> 
> For example, the following code:
> 
>         if ((obj != null) && (obj instanceof TCPEndpoint)) {
>             TCPEndpoint ep = (TCPEndpoint) obj;
>             if (port != ep.port || !host.equals(ep.host))
> 
> Can be simplified to:
> 
>         if (obj instanceof TCPEndpoint ep) {
>             if (port != ep.port || !host.equals(ep.host))
> 
> 
> See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422)

Looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9332

From jpai at openjdk.org  Thu Jun 30 06:03:43 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 30 Jun 2022 06:03:43 GMT
Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in
 ZipFileSystemProvider.removeFileSystem [v2]
In-Reply-To: <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>
References: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>
 <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>
Message-ID: <uLujEmOemCQX_ZZC0unstjTk4BbDIBPZ-JncCh1_nMg=.ce7a1543-a23a-496f-a5ce-9280eed6db57@github.com>

On Wed, 29 Jun 2022 08:20:31 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> There is overload method HashMap.remove(key,value) which also checks value equality.
>> It's shorter and faster than pair get+remove.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem
>   update copyright year

Hello Andrey,

The `HashMap.remove(k, v)` uses `equals()` call to do a equality check on the passed value unlike the if condition here. Right now, the `ZipFileSystem` (the value type) doesn't have an `equals()` implementation of its own and instead the `Object.equals()` gets used, which does the instance identity check. So this change should be fine.

I personally prefer the previous/existing version because it's  bit more intuitive to understand that the specific instance of filesystem is being removed.

No objections to this change if others prefer this new version.

-------------

PR: https://git.openjdk.org/jdk/pull/9314

From duke at openjdk.org  Thu Jun 30 06:29:45 2022
From: duke at openjdk.org (rmartinc)
Date: Thu, 30 Jun 2022 06:29:45 GMT
Subject: RFR: 8288895: LdapContext doesn't honor set referrals limit [v3]
In-Reply-To: <FMUrGXLp-w_YICuyOPdGfP1W6x3soNfpJpoOnQQB9no=.ef37bb68-e861-44c5-87d3-7a456e0b6477@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
 <sQDbydSnmaVv5Oi1Uy-hwwshQdTiHG1xLfg94YWxzyo=.243bd22f-5d04-4380-ad2e-e8571e79bf71@github.com>
 <FMUrGXLp-w_YICuyOPdGfP1W6x3soNfpJpoOnQQB9no=.ef37bb68-e861-44c5-87d3-7a456e0b6477@github.com>
Message-ID: <MAMNax2CrxR47denrgxV1wVB2itf4Y6MTyF-3sV0bR8=.c3fe005d-b681-4047-8b05-89724b68a457@github.com>

On Tue, 28 Jun 2022 14:56:30 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> rmartinc has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288895: LdapContext doesn't honor set referrals limit (typo)
>
> Marked as reviewed by aefimov (Committer).

Thanks @AlekseiEfimov @dfuch! Please sponsor the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9256

From duke at openjdk.org  Thu Jun 30 09:21:33 2022
From: duke at openjdk.org (rmartinc)
Date: Thu, 30 Jun 2022 09:21:33 GMT
Subject: Integrated: 8288895: LdapContext doesn't honor set referrals limit
In-Reply-To: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
References: <H7snDF65MmnqTOv16P4ZZkvmKZKaA6zWXvY9aXZQV7c=.bd857d75-dbf8-42c1-8be3-61f6fe215ee4@github.com>
Message-ID: <zeY0w8l9JSZC51n0cSGkBV1weEd8o8INfzLktW4o_TY=.d842152b-d212-4bee-9eb5-79cf995c8e4d@github.com>

On Thu, 23 Jun 2022 08:20:31 GMT, rmartinc <duke at openjdk.org> wrote:

> Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895).
> 
> Any `LimitExceededException` now quits the referral loop.
> 
> Added class `ReferralLimitSearchTest`. It is a simple jtreg test which checks that `java.naming.ldap.referral.limit` is really enforced. The dummy ldap server always returns a referral for any search query. If the number of searches exceeds the limit, it throws an `IOException` and the test fails.
> 
> 
> make test TEST=jtreg:jdk/com/sun/jndi/ldap/ReferralLimitSearchTest.java

This pull request has now been integrated.

Changeset: c3addbb1
Author:    rmartinc <rmartinc at redhat.com>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3addbb1c01483e10189cc46d8f2378e5b56dcee
Stats:     185 lines in 2 files changed: 177 ins; 2 del; 6 mod

8288895: LdapContext doesn't honor set referrals limit

Reviewed-by: dfuchs, aefimov

-------------

PR: https://git.openjdk.org/jdk/pull/9256

From duke at openjdk.org  Thu Jun 30 11:55:34 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 30 Jun 2022 11:55:34 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v5]
In-Reply-To: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
Message-ID: <IrdWiy2Bml_gYhUCjkHI3Czw0vNRVp7RRNNaCVQ9xvA=.31b12cdb-676f-4901-a65c-5a86f42b0b59@github.com>

> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
> 
> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.

?????? ??????? 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:

 - 8288327: Move ParameterData declaration closer to its usage
 - 8288327: Mark ParameterData.parameters as @Stable and rename real -> isReal
 - Merge branch 'master' into 8288327
 - 8288327: Use record store
 - 8288327: Add clarifying comments
 - 8288327: Executable.hasRealParameterData should not be volatile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9143/files
  - new: https://git.openjdk.org/jdk/pull/9143/files/8ead0357..711e175f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=03-04

  Stats: 58742 lines in 1081 files changed: 35110 ins; 11520 del; 12112 mod
  Patch: https://git.openjdk.org/jdk/pull/9143.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9143/head:pull/9143

PR: https://git.openjdk.org/jdk/pull/9143

From duke at openjdk.org  Thu Jun 30 12:04:31 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 30 Jun 2022 12:04:31 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v6]
In-Reply-To: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
Message-ID: <oqt8d0rj07rOPlyfuDxpYuE74bwrXyWkSO7YfN_-x9k=.d2b5cc9e-2b82-44c8-8df6-a33618ab9202@github.com>

> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
> 
> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/reflect/Executable.java
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9143/files
  - new: https://git.openjdk.org/jdk/pull/9143/files/711e175f..e1da00b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9143.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9143/head:pull/9143

PR: https://git.openjdk.org/jdk/pull/9143

From duke at openjdk.org  Thu Jun 30 12:04:32 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 30 Jun 2022 12:04:32 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v4]
In-Reply-To: <CxTLR2vk-7AL2YV-4Rhn4bYFpsrpbkOxa25pzS06-Iw=.69c53473-cf6a-4e7e-877b-f070cf6c9c05@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
 <CYXUywvj-GH7yGtI6zT2CgCV79sk_Uaes9_288H1BQI=.f00fbd19-5aa1-4f20-86fa-336a92d413ac@github.com>
 <CxTLR2vk-7AL2YV-4Rhn4bYFpsrpbkOxa25pzS06-Iw=.69c53473-cf6a-4e7e-877b-f070cf6c9c05@github.com>
Message-ID: <hyUqUStzb-bgkIXXk8u8tRttnUhDxzgIIRT3tBc9c8Q=.268003cf-3c32-451f-b22e-1655f241028b@github.com>

On Wed, 29 Jun 2022 18:11:50 GMT, liach <duke at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288327: Mark ParameterData.parameters as @Stable and rename real -> isReal
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 413:
> 
>> 411:     }
>> 412: 
>> 413:     boolean hasRealParameterData() {
> 
> Since `privateGetParameters` and `hasRealParameterData` are now both simple methods with only one use site, they can be simply inlined in `getParameters()` and `getAllGenericParameterTypes()` instead:
> 
> 
>     public Parameter[] getParameters() {
>         // Need to copy the cached array to prevent users from messing
>         // with it.  Since parameters are immutable, we can
>         // shallow-copy.
>         return parameterData().parameters.clone();
>     }
> ...
>             final boolean realParamData = parameterData().isReal();
>             final Type[] genericParamTypes = getGenericParameterTypes();
>             final Type[] nonGenericParamTypes = getParameterTypes();

True for `privateGetParameters`, but `hasRealParameterData` is called also from `Parameter.isNamePresent()`, so I suggest to keep it

> src/java.base/share/classes/java/lang/reflect/Executable.java line 777:
> 
>> 775:     }
>> 776: 
>> 777:     record ParameterData(@Stable Parameter[] parameters, boolean isReal) {}
> 
> I recommend declaring this right next to `parameterData` field for the ease of maintenance, like how `EntrySet` in map implementations are declared right next to `entrySet` methods.

Done!

-------------

PR: https://git.openjdk.org/jdk/pull/9143

From duke at openjdk.org  Thu Jun 30 12:08:19 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 30 Jun 2022 12:08:19 GMT
Subject: RFR: 8288327: Executable.hasRealParameterData should not be
 volatile [v7]
In-Reply-To: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
References: <GfRgsnIuV6YNm6SyhRi30tJ9FmBC0TpOmdJ0u-UlP_A=.cfc06d96-bc92-4480-be7b-acd6ecd49fc6@github.com>
Message-ID: <hx0Gwb64XLSSsrrcuNpxJ1cnHRaFAghk4VSfxecrY0c=.a8512bfa-446a-42ec-8fdc-1059cdba3586@github.com>

> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before  _releasing store_.
> 
> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior.

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8288327: Inline privateGetParameters()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9143/files
  - new: https://git.openjdk.org/jdk/pull/9143/files/e1da00b2..b9fcce44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9143&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9143.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9143/head:pull/9143

PR: https://git.openjdk.org/jdk/pull/9143

From xuelei at openjdk.org  Thu Jun 30 15:26:32 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 30 Jun 2022 15:26:32 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
Message-ID: <1_N-rntAbDIB3XXzrMZho1VD8VnVh8gOP9pRscyNt8w=.b3616afc-b9d6-40c1-a627-5f49cd44b764@github.com>

On Sat, 18 Jun 2022 05:55:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Master
>  - use Reference.refersTo
>  - remove trailing whitespaces
>  - use timeout factor
>  - Merge
>  - Merge master
>  - Merge
>  - add timeout parameter
>  - rollback is not in this branch
>  - rollback JDK-8287384
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282

ping ...

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From rriggs at openjdk.org  Thu Jun 30 15:57:45 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Jun 2022 15:57:45 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
Message-ID: <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>

On Sat, 18 Jun 2022 05:55:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Master
>  - use Reference.refersTo
>  - remove trailing whitespaces
>  - use timeout factor
>  - Merge
>  - Merge master
>  - Merge
>  - add timeout parameter
>  - rollback is not in this branch
>  - rollback JDK-8287384
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282

Sorry for the delay.

test/lib/jdk/test/lib/util/ForceGC.java line 37:

> 35:     // The jtreg testing timeout factor.
> 36:     private static final double TIMEOUT_FACTOR = Double.valueOf(
> 37:             System.getProperty("test.timeout.factor", "1.0"));

If you don't mind the dependency, you can use jdk.test.lib.Utils.TIMEOUT_FACTOR
or `Utils.adjustTimeout(xx)` in the usage below.

test/lib/jdk/test/lib/util/ForceGC.java line 42:

> 40:      * Causes the current thread to wait until the {@code booleanSupplier}
> 41:      * returns true, or a specific waiting time elapses.  The waiting time
> 42:      * is 1 second scalled with the jtreg testing timeout factor.

typo: "scalled" -> "scaled"

test/lib/jdk/test/lib/util/ForceGC.java line 58:

> 56:         Reference.reachabilityFence(ref);
> 57: 
> 58:         for (int retries = (int)(timeout / 200); retries >= 0; retries--) {

The logic around the timeout might be clearer if it was only based on the number of retries,
and can be scaled by the TIMEOUT_FACTOR too.

test/lib/jdk/test/lib/util/ForceGC.java line 70:

> 68:                 // But it is fine.  For most cases, the 1st GC is sufficient
> 69:                 // to trigger and complete the cleanup.
> 70:                 queue.remove(200L);

If `remove()` returns a non-null value, then it is safe to break out of the loop.
The GC has cleared the ref. And the final `getAsBoolean()` below will return the condition.

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From duke at openjdk.org  Thu Jun 30 16:20:43 2022
From: duke at openjdk.org (iaroslavski)
Date: Thu, 30 Jun 2022 16:20:43 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v13]
In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
Message-ID: <uyOvVaqDt2KejVfN7uBPlKAyUcgJOJuF0xEvjLS2uS4=.ab3cb8d0-1697-4eb5-8f02-a679aa4dd3bb@github.com>

> Sorting:
> 
> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single element
> - minor javadoc and comment changes
> 
> Testing:
> - add new data inputs in tests for sorting
> - add min/max/infinity values to float/double testing
> - add tests for radix sort

iaroslavski has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
  
  * Improved parallel sorting
  * Optimized buffer allocation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/3938/files
  - new: https://git.openjdk.org/jdk/pull/3938/files/8a373741..6acc0bdb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=11-12

  Stats: 655 lines in 3 files changed: 163 ins; 294 del; 198 mod
  Patch: https://git.openjdk.org/jdk/pull/3938.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/3938/head:pull/3938

PR: https://git.openjdk.org/jdk/pull/3938

From duke at openjdk.org  Thu Jun 30 16:41:36 2022
From: duke at openjdk.org (iaroslavski)
Date: Thu, 30 Jun 2022 16:41:36 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v14]
In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
Message-ID: <U0qp5eDiLJu5JyY-7pzkUxjg0QfkXNErPs1n_DVPT-s=.9a0f752b-abf0-4f14-a886-32cfe60f6f48@github.com>

> Sorting:
> 
> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single element
> - minor javadoc and comment changes
> 
> Testing:
> - add new data inputs in tests for sorting
> - add min/max/infinity values to float/double testing
> - add tests for radix sort

iaroslavski has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
  
  * Fix @since version

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/3938/files
  - new: https://git.openjdk.org/jdk/pull/3938/files/6acc0bdb..1cb6fd7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=12-13

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/3938.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/3938/head:pull/3938

PR: https://git.openjdk.org/jdk/pull/3938

From hannesw at openjdk.org  Thu Jun 30 16:54:18 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 30 Jun 2022 16:54:18 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page
Message-ID: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>

Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 

While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.

The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 

The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 

Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method since these are mostly just used once in that very method. On the other hand, the associated Builder is used in many methods and had previously to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 

Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.

I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.

The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.

There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 

Demo output for the new preview page as well as other pages is available here:
http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html

-------------

Commit messages:
 - JDK-8287597: List all preview features on the javadoc PREVIEW page

Changes: https://git.openjdk.org/jdk/pull/9336/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9336&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287597
  Stats: 462 lines in 22 files changed: 291 ins; 66 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/9336.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9336/head:pull/9336

PR: https://git.openjdk.org/jdk/pull/9336

From vdyakov at openjdk.org  Thu Jun 30 17:21:40 2022
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Thu, 30 Jun 2022 17:21:40 GMT
Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when
 creating DMG or PKG
In-Reply-To: <fPZsv2fGfyPSAZyF5UcBUo3EicShZJZNv16GocbGV48=.e4ac18e3-a922-44b3-8b0f-145d1313a715@github.com>
References: <fPZsv2fGfyPSAZyF5UcBUo3EicShZJZNv16GocbGV48=.e4ac18e3-a922-44b3-8b0f-145d1313a715@github.com>
Message-ID: <yCrIDFjPsOXCRP5O8GpjHxYOL0m3nFadevcULcwvQuM=.b3786605-8490-41f3-ae37-27da041ea792@github.com>

On Wed, 29 Jun 2022 03:03:15 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Fixed 3 issues which made signature invalid:
> - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature.
> - .package should be created when app image is generated, so this file can be signed.
> - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well.
> 
> Added additional test to validate signature when DMG or PKG is generated from predefined app image.

@alexeysemenyukoracle please review

-------------

PR: https://git.openjdk.org/jdk19/pull/89

From xuelei at openjdk.org  Thu Jun 30 18:27:46 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 30 Jun 2022 18:27:46 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
Message-ID: <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>

On Thu, 30 Jun 2022 15:53:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Master
>>  - use Reference.refersTo
>>  - remove trailing whitespaces
>>  - use timeout factor
>>  - Merge
>>  - Merge master
>>  - Merge
>>  - add timeout parameter
>>  - rollback is not in this branch
>>  - rollback JDK-8287384
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282
>
> test/lib/jdk/test/lib/util/ForceGC.java line 70:
> 
>> 68:                 // But it is fine.  For most cases, the 1st GC is sufficient
>> 69:                 // to trigger and complete the cleanup.
>> 70:                 queue.remove(200L);
> 
> If `remove()` returns a non-null value, then it is safe to break out of the loop.
> The GC has cleared the ref. And the final `getAsBoolean()` below will return the condition.

I'm not sure if all unused object will be collected in one GC call always.  The gc() specification says "When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all unused objects. ... There is also no guarantee that this effort will determine the change of reachability in any particular number of objects, or that any particular number of {@link java.lang.ref.Reference Reference} objects will be cleared and enqueued."  But from the spec, I did not get a clear answer for the question.

If the `booleanSupplier` object could be cleared in a collection other than the `ref` collection, the current code may be safer.

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From duke at openjdk.org  Thu Jun 30 18:32:56 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Thu, 30 Jun 2022 18:32:56 GMT
Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset
 set with TZ env variable [v2]
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <C_c-ceEEIWA2iC__QiKGiYQhiIbeJU1Nr-uFC6UcEFA=.eff78830-d60c-43d6-a07b-263a115adb17@github.com>

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:

  8288377: Simplified TZ offset calc and consolidate MACOS impl.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9312/files
  - new: https://git.openjdk.org/jdk/pull/9312/files/f9230150..7e462d95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=00-01

  Stats: 81 lines in 1 file changed: 1 ins; 75 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9312.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9312/head:pull/9312

PR: https://git.openjdk.org/jdk/pull/9312

From duke at openjdk.org  Thu Jun 30 18:32:57 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Thu, 30 Jun 2022 18:32:57 GMT
Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset
 set with TZ env variable
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <GjL6c_nM43XFR-uz23WrJnAfPlyjbBjGR8YHL_mk--k=.b7c8c836-6e58-4314-8135-c9eeb412f941@github.com>

On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

I have simplified the implementation and tested that it works on Linux ... I still need to check this on a MAC OS computer and see if it working like before without any issues.

-------------

PR: https://git.openjdk.org/jdk/pull/9312

From xuelei at openjdk.org  Thu Jun 30 18:44:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 30 Jun 2022 18:44:30 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  update per feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8979/files
  - new: https://git.openjdk.org/jdk/pull/8979/files/0f196282..31dffa98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=09-10

  Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.org/jdk/pull/8979

From xuelei at openjdk.org  Thu Jun 30 18:44:33 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 30 Jun 2022 18:44:33 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
Message-ID: <VbltzvNUauy1u4WSzKZh_nCRBijebSNfSWWgSxW-3j4=.5e0d6fd6-0e87-4578-8b49-4e4db5ae0fe1@github.com>

On Thu, 30 Jun 2022 15:48:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Master
>>  - use Reference.refersTo
>>  - remove trailing whitespaces
>>  - use timeout factor
>>  - Merge
>>  - Merge master
>>  - Merge
>>  - add timeout parameter
>>  - rollback is not in this branch
>>  - rollback JDK-8287384
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/47b86690...0f196282
>
> test/lib/jdk/test/lib/util/ForceGC.java line 58:
> 
>> 56:         Reference.reachabilityFence(ref);
>> 57: 
>> 58:         for (int retries = (int)(timeout / 200); retries >= 0; retries--) {
> 
> The logic around the timeout might be clearer if it was only based on the number of retries,
> and can be scaled by the TIMEOUT_FACTOR too.

I just curious if the factor could be set to some unusual values like "1.25".  Scaling on timeout, and then calculating the retires could be more accuracy for such circumstances, although it may be not necessary.  I moved the retries calculation close to the for-loop.  Hope it is better for readers.

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From hseigel at openjdk.org  Thu Jun 30 18:47:05 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Thu, 30 Jun 2022 18:47:05 GMT
Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options
Message-ID: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>

Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits.  This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.

Thanks, Harold

-------------

Commit messages:
 - 8289534: Change 'uncomplicated' hotspot runtime options

Changes: https://git.openjdk.org/jdk/pull/9338/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9338&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289534
  Stats: 42 lines in 10 files changed: 1 ins; 0 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/9338.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9338/head:pull/9338

PR: https://git.openjdk.org/jdk/pull/9338

From coleenp at openjdk.org  Thu Jun 30 20:01:51 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 30 Jun 2022 20:01:51 GMT
Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options
In-Reply-To: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
References: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
Message-ID: <QiqgG29zeLP_czhaTGLdNJM1WTLKgwVGUTPfs7vgCDg=.d6d1e705-a67d-4e7f-b65a-40bc4de329c8@github.com>

On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits.  This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Looks good!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9338

From naoto at openjdk.org  Thu Jun 30 20:10:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Jun 2022 20:10:44 GMT
Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset
 set with TZ env variable [v2]
In-Reply-To: <C_c-ceEEIWA2iC__QiKGiYQhiIbeJU1Nr-uFC6UcEFA=.eff78830-d60c-43d6-a07b-263a115adb17@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
 <C_c-ceEEIWA2iC__QiKGiYQhiIbeJU1Nr-uFC6UcEFA=.eff78830-d60c-43d6-a07b-263a115adb17@github.com>
Message-ID: <9HAc2av3J84YjjL6VgQLfSlMAUkicHuic2ONLc7x3ZA=.4b01d5f6-6a96-4996-bd83-be9ce5d19c41@github.com>

On Thu, 30 Jun 2022 18:32:56 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

>> This is a REDO of the Fix that was incompletely implemented earlier:
>> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
>> 
>> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
>> 
>> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
>> _(where 7200 represents 7200 seconds -> +2 hour offset)_
>> Sample output:
>> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)
>
> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288377: Simplified TZ offset calc and consolidate MACOS impl.

src/java.base/unix/native/libjava/TimeZone_md.c line 569:

> 567:     }
> 568: 
> 569:     strftime(offset, 6, "%z", &localtm);

Return value has to be examined. If it is not `5`, then I'd expect falling back to "GMT".

src/java.base/unix/native/libjava/TimeZone_md.c line 572:

> 570:     char gmt_offset[] = {offset[0], offset[1], offset[2], ':', offset[3], offset[4], '\0'};
> 571: 
> 572:     sprintf(buf, (const char *)"GMT%s", gmt_offset);

You could use the format string as "GMT%c%c%c:%c%c" so that the extra `gmt_offset` variable can be eliminated.

-------------

PR: https://git.openjdk.org/jdk/pull/9312

From naoto at openjdk.org  Thu Jun 30 20:16:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Jun 2022 20:16:40 GMT
Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset
 set with TZ env variable
In-Reply-To: <GjL6c_nM43XFR-uz23WrJnAfPlyjbBjGR8YHL_mk--k=.b7c8c836-6e58-4314-8135-c9eeb412f941@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
 <GjL6c_nM43XFR-uz23WrJnAfPlyjbBjGR8YHL_mk--k=.b7c8c836-6e58-4314-8135-c9eeb412f941@github.com>
Message-ID: <pQJTEz5U99DoxoMhjisgoauNuKBBD_08tjhccHvNHJo=.a454b408-d0c9-4eb8-b7ed-94f2cb1bb206@github.com>

On Thu, 30 Jun 2022 18:29:42 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> One more thing to note/I'd like to make sure is what the output looks like when TZ is GMT. Want to ensure that the final string being passed down is just "GMT" and that `strftime` invocation returns an empty result. If the result is coming out to be slightly different, then it could be a problem.

You could compare GMT's hour/miute with localtime's. If they are identical, then return "GMT". For that, we may end up reviving `#if defined (MACOSX)` since macOS's tm struct has `tm_gmtoff`, but limited to that piece of code.

-------------

PR: https://git.openjdk.org/jdk/pull/9312

From rriggs at openjdk.org  Thu Jun 30 20:38:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Jun 2022 20:38:40 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
 <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>
Message-ID: <iHdGR-wS_iXFAw4KrXdpIT6Y5d1CLM7ZHZiYGyGrzqc=.6994b6c0-195e-4b94-92fe-b1111f2986c3@github.com>

On Thu, 30 Jun 2022 18:24:14 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 70:
>> 
>>> 68:                 // But it is fine.  For most cases, the 1st GC is sufficient
>>> 69:                 // to trigger and complete the cleanup.
>>> 70:                 queue.remove(200L);
>> 
>> If `remove()` returns a non-null value, then it is safe to break out of the loop.
>> The GC has cleared the ref. And the final `getAsBoolean()` below will return the condition.
>
> I'm not sure if all unused object will be collected in one GC call always.  The gc() specification says "When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all unused objects. ... There is also no guarantee that this effort will determine the change of reachability in any particular number of objects, or that any particular number of {@link java.lang.ref.Reference Reference} objects will be cleared and enqueued."  But from the spec, I did not get a clear answer for the question.
> 
> If the `booleanSupplier` object could be cleared in a collection other than the `ref` collection, the current code may be safer.

True, knowing when GC is 'done' is not deterministic except for a specify Reference to a specific object.
System.gc is just a request, the checking for an object can more quickly exit the loop.
The code is as is, and already commented, might wait an extra cycle, but only in the case of a race between the requested predicate and the object being reclaimed.  Ok as it.

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From rriggs at openjdk.org  Thu Jun 30 20:49:42 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Jun 2022 20:49:42 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11]
In-Reply-To: <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>
Message-ID: <kdeNVRI0a2WhTZ4QHKXQQUib_H0ZEzLT4lnwKovAO-U=.87564f83-7bf2-431e-9e62-90e226b8e097@github.com>

On Thu, 30 Jun 2022 18:44:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update per feedback

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8979

From rriggs at openjdk.org  Thu Jun 30 20:49:44 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Jun 2022 20:49:44 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <VbltzvNUauy1u4WSzKZh_nCRBijebSNfSWWgSxW-3j4=.5e0d6fd6-0e87-4578-8b49-4e4db5ae0fe1@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
 <VbltzvNUauy1u4WSzKZh_nCRBijebSNfSWWgSxW-3j4=.5e0d6fd6-0e87-4578-8b49-4e4db5ae0fe1@github.com>
Message-ID: <a3HMm9632zy9X53fvV3ePez8zQs0rc79nM6SBCtNPaE=.daad8e84-e8ec-4234-abd8-5db289581d24@github.com>

On Thu, 30 Jun 2022 18:39:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 58:
>> 
>>> 56:         Reference.reachabilityFence(ref);
>>> 57: 
>>> 58:         for (int retries = (int)(timeout / 200); retries >= 0; retries--) {
>> 
>> The logic around the timeout might be clearer if it was only based on the number of retries,
>> and can be scaled by the TIMEOUT_FACTOR too.
>
> I just curious if the factor could be set to some unusual values like "1.25".  Scaling on timeout, and then calculating the retires could be more accuracy for such circumstances, although it may be not necessary.  I moved the retries calculation close to the for-loop.  Hope it is better for readers.

Yes, `Utils.adjustTimeout(long x)` uses floating point and then converts back.

-------------

PR: https://git.openjdk.org/jdk/pull/8979

From naoto at openjdk.org  Thu Jun 30 22:14:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Jun 2022 22:14:10 GMT
Subject: [jdk19] RFR: 8289549: ISO 4217 Amendment 172 Update
Message-ID: <szwIwxcF_DyOJa2pAznznyymjlzwQFZ6CUxnQ9514WQ=.327ba08a-82f2-42cf-9269-1510253c78ac@github.com>

Trivial fix to currency data files. The change was only made to its amendment number, as the new Sierra Leone currency has already been active with amendment 171.

-------------

Commit messages:
 - 8289549: ISO 4217 Amendment 172 Update

Changes: https://git.openjdk.org/jdk19/pull/96/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=96&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289549
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk19/pull/96.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/96/head:pull/96

PR: https://git.openjdk.org/jdk19/pull/96

From duke at openjdk.org  Thu Jun 30 23:42:49 2022
From: duke at openjdk.org (duke)
Date: Thu, 30 Jun 2022 23:42:49 GMT
Subject: Withdrawn: JDK-8277520: Implement JDK-8 default methods for
 IdentityHashMap
In-Reply-To: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
References: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
Message-ID: <cxpxndo8HbJugjkcDnrTwQ0iAuRCyP7vR0UcGu8jLho=.b256184a-8b8d-4f30-a630-e7a7c635e6d5@github.com>

On Wed, 24 Nov 2021 05:16:40 GMT, liach <duke at openjdk.org> wrote:

> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/6532

From iris at openjdk.org  Thu Jun 30 23:44:42 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 30 Jun 2022 23:44:42 GMT
Subject: [jdk19] RFR: 8289549: ISO 4217 Amendment 172 Update
In-Reply-To: <szwIwxcF_DyOJa2pAznznyymjlzwQFZ6CUxnQ9514WQ=.327ba08a-82f2-42cf-9269-1510253c78ac@github.com>
References: <szwIwxcF_DyOJa2pAznznyymjlzwQFZ6CUxnQ9514WQ=.327ba08a-82f2-42cf-9269-1510253c78ac@github.com>
Message-ID: <UxURvZE0yIOuW77HSr9QjpUp2OxwW1M9gHCQRCZNMHU=.371997e1-2f5c-4523-8e22-2d8b6618625a@github.com>

On Thu, 30 Jun 2022 22:05:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial fix to currency data files. The change was only made to its amendment number, as the new Sierra Leone currency has already been active with amendment 171.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/96