From jboes at openjdk.java.net  Wed Dec  1 10:40:31 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Wed, 1 Dec 2021 10:40:31 GMT
Subject: Integrated: 8277459: Add jwebserver tool
In-Reply-To: <X7q4-8QRakCUqvwwpFvMluE7DdBlF1QlW_AkOzghyro=.52324617-b30e-4ecc-aada-909de0111bc5@github.com>
References: <X7q4-8QRakCUqvwwpFvMluE7DdBlF1QlW_AkOzghyro=.52324617-b30e-4ecc-aada-909de0111bc5@github.com>
Message-ID: <gGfcUXKzdIB9nCcdBWmy_9zkVjZRhYCEF2BjKPKiABI=.2f1b9e53-82a1-40c9-a243-be80394e9ff3@github.com>

On Mon, 22 Nov 2021 09:43:19 GMT, Julia Boes <jboes at openjdk.org> wrote:

> This change introduces jwebserver, a dedicated JDK tool for the Simple Web Server. 
> 
> A description is provided in a follow-up comment.

This pull request has now been integrated.

Changeset: f505396c
Author:    Julia Boes <jboes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f505396cccdd00a284b516dee1e314d1bf285f9e
Stats:     682 lines in 17 files changed: 587 ins; 27 del; 68 mod

8277459: Add jwebserver tool

Reviewed-by: michaelm, dfuchs, ihse

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

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


From aleonard at openjdk.java.net  Wed Dec  1 15:22:09 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 15:22:09 GMT
Subject: RFR: 8277762: Allow configuration of HOTSPOT_BUILD_USER [v2]
In-Reply-To: <boBTfj4nIeivinSvRqVMnpjdAZcP-bSAd_iOnDI4zcg=.a8bc592d-93cd-40cd-b580-dffb4797d4f2@github.com>
References: <boBTfj4nIeivinSvRqVMnpjdAZcP-bSAd_iOnDI4zcg=.a8bc592d-93cd-40cd-b580-dffb4797d4f2@github.com>
Message-ID: <nX3uEA4jgXkpEzH4IkRn0WO9liHVyHtoiKReJVnT14Q=.37fa122d-1da9-4704-b655-4a73ae4b45e4@github.com>

> To better allow "reproducible builds", a new configure parameter is added to set the USERNAME build variable, rather than always using the current user:
>     --with-build-user=<username> 
> HOTSPOT_BUILD_USER is then set to a reproducible USERNAME if required.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

 - 8277762: Allow configuration of HOTSPOT_BUILD_USER
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into builduser
 - 8277762: Allow configuration of HOTSPOT_BUILD_USER
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8277762: Allow configuration of HOTSPOT_BUILD_USER
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8277762: Allow configuration of HOTSPOT_BUILD_USER
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6542/files
  - new: https://git.openjdk.java.net/jdk/pull/6542/files/f9fb274a..3896df55

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

  Stats: 6325 lines in 236 files changed: 4145 ins; 1326 del; 854 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6542.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6542/head:pull/6542

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


From aleonard at openjdk.java.net  Wed Dec  1 15:22:10 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 15:22:10 GMT
Subject: RFR: 8277762: Allow configuration of HOTSPOT_BUILD_USER [v2]
In-Reply-To: <ikgnhMCoh2YJY73dFniaUiEfkyEP10iDq7wUmQBK-v0=.c5efc315-513d-4ae2-a456-0e13dc7ba2cd@github.com>
References: <boBTfj4nIeivinSvRqVMnpjdAZcP-bSAd_iOnDI4zcg=.a8bc592d-93cd-40cd-b580-dffb4797d4f2@github.com>
 <D7OrBii46yVMH8lWvq8lt7yOe24tVvXqwozXoN-9tyA=.f89b585d-efaa-4613-9312-c8b17cc78e17@github.com>
 <ThOpHQiQ837yIb2-zgMt4lfgTsaPWZAko-C3KJzwrEk=.a8b3ed24-10c1-46e7-927e-63bb09ab538f@github.com>
 <ikgnhMCoh2YJY73dFniaUiEfkyEP10iDq7wUmQBK-v0=.c5efc315-513d-4ae2-a456-0e13dc7ba2cd@github.com>
Message-ID: <-4k2pUB0nx_RZK_xf1PFsraYWcdLqkIzAJOAz1S53_o=.0bb74970-126a-4cf5-93a7-345c07f32730@github.com>

On Wed, 24 Nov 2021 18:59:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> it's also used in make/hotspot/lib/CompileJvm.gmk, but agree moving to jdk-versions.m4 makes sense
>
> Right, I meant the only place it's used within configure.

done, moved

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

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


From aleonard at openjdk.java.net  Wed Dec  1 15:27:32 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 15:27:32 GMT
Subject: RFR: 8277762: Allow configuration of HOTSPOT_BUILD_USER [v2]
In-Reply-To: <nX3uEA4jgXkpEzH4IkRn0WO9liHVyHtoiKReJVnT14Q=.37fa122d-1da9-4704-b655-4a73ae4b45e4@github.com>
References: <boBTfj4nIeivinSvRqVMnpjdAZcP-bSAd_iOnDI4zcg=.a8bc592d-93cd-40cd-b580-dffb4797d4f2@github.com>
 <nX3uEA4jgXkpEzH4IkRn0WO9liHVyHtoiKReJVnT14Q=.37fa122d-1da9-4704-b655-4a73ae4b45e4@github.com>
Message-ID: <ni-mRIDIESvA_Z8VqE7BfpZiZ9B1_6VRuSqQjh2xwWc=.ae5accec-4bc5-4035-8aae-931efd923d4f@github.com>

On Wed, 1 Dec 2021 15:22:09 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> To better allow "reproducible builds", a new configure parameter is added to set the USERNAME build variable, rather than always using the current user:
>>     --with-build-user=<username> 
>> HOTSPOT_BUILD_USER is then set to a reproducible USERNAME if required.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8277762: Allow configuration of HOTSPOT_BUILD_USER
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into builduser
>  - 8277762: Allow configuration of HOTSPOT_BUILD_USER
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8277762: Allow configuration of HOTSPOT_BUILD_USER
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8277762: Allow configuration of HOTSPOT_BUILD_USER
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

@erikj79 ready for review again please
thanks

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

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


From erikj at openjdk.java.net  Wed Dec  1 17:08:25 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 1 Dec 2021 17:08:25 GMT
Subject: RFR: 8277762: Allow configuration of HOTSPOT_BUILD_USER [v2]
In-Reply-To: <nX3uEA4jgXkpEzH4IkRn0WO9liHVyHtoiKReJVnT14Q=.37fa122d-1da9-4704-b655-4a73ae4b45e4@github.com>
References: <boBTfj4nIeivinSvRqVMnpjdAZcP-bSAd_iOnDI4zcg=.a8bc592d-93cd-40cd-b580-dffb4797d4f2@github.com>
 <nX3uEA4jgXkpEzH4IkRn0WO9liHVyHtoiKReJVnT14Q=.37fa122d-1da9-4704-b655-4a73ae4b45e4@github.com>
Message-ID: <r9PTVD4w9-BuyPgdIZr92mf59XPSryzGRI_Q8F2k4ks=.bcdfd15f-7b0f-4610-b158-d5d19302dc9a@github.com>

On Wed, 1 Dec 2021 15:22:09 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> To better allow "reproducible builds", a new configure parameter is added to set the USERNAME build variable, rather than always using the current user:
>>     --with-build-user=<username> 
>> HOTSPOT_BUILD_USER is then set to a reproducible USERNAME if required.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8277762: Allow configuration of HOTSPOT_BUILD_USER
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into builduser
>  - 8277762: Allow configuration of HOTSPOT_BUILD_USER
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8277762: Allow configuration of HOTSPOT_BUILD_USER
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8277762: Allow configuration of HOTSPOT_BUILD_USER
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Looks good!

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

Marked as reviewed by erikj (Reviewer).

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


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

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

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

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

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

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


From aleonard at openjdk.java.net  Wed Dec  1 18:16:28 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 18:16:28 GMT
Subject: Integrated: 8277762: Allow configuration of HOTSPOT_BUILD_USER
In-Reply-To: <boBTfj4nIeivinSvRqVMnpjdAZcP-bSAd_iOnDI4zcg=.a8bc592d-93cd-40cd-b580-dffb4797d4f2@github.com>
References: <boBTfj4nIeivinSvRqVMnpjdAZcP-bSAd_iOnDI4zcg=.a8bc592d-93cd-40cd-b580-dffb4797d4f2@github.com>
Message-ID: <IYsGS0ksiKyDxSW33iUdOCriCVd-_WjQR8myyo3Y5Fs=.ee5736d2-43e9-42f0-866b-8bb3adfbea81@github.com>

On Wed, 24 Nov 2021 16:49:31 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> To better allow "reproducible builds", a new configure parameter is added to set the USERNAME build variable, rather than always using the current user:
>     --with-build-user=<username> 
> HOTSPOT_BUILD_USER is then set to a reproducible USERNAME if required.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: f41e768b
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f41e768bba2b2ce3b3cc5813ccb1ac4984dcefbd
Stats:     17 lines in 2 files changed: 11 ins; 5 del; 1 mod

8277762: Allow configuration of HOTSPOT_BUILD_USER

Reviewed-by: erikj

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

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


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

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

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

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

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

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

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


From mikael at openjdk.java.net  Wed Dec  1 18:45:43 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Wed, 1 Dec 2021 18:45:43 GMT
Subject: RFR: 8266839: Enable pandoc on macosx-aarch64 at Oracle
Message-ID: <eB3RMP_9CiqYQI1SuYkLq4KL_GqG2uWamOiib28PF-4=.26582b43-f4b5-4bfe-a632-7c25b9edbdcb@github.com>

Enabling pandoc on macosx-aarch64 at Oracle to produce man pages etc.

Testing:

* Passes tier1
* Verified that the product bundle includes man pages as expected
* Sampling a few of the man pages they look as expected

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

Commit messages:
 - 8266839: Enable pandoc on macosx-aarch64

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

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


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

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

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

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

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

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

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

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


From erikj at openjdk.java.net  Wed Dec  1 18:53:30 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 1 Dec 2021 18:53:30 GMT
Subject: RFR: 8266839: Enable pandoc on macosx-aarch64 at Oracle
In-Reply-To: <eB3RMP_9CiqYQI1SuYkLq4KL_GqG2uWamOiib28PF-4=.26582b43-f4b5-4bfe-a632-7c25b9edbdcb@github.com>
References: <eB3RMP_9CiqYQI1SuYkLq4KL_GqG2uWamOiib28PF-4=.26582b43-f4b5-4bfe-a632-7c25b9edbdcb@github.com>
Message-ID: <cMKwva286XXdRxN8eyixEPfWJcvHW81ZgowY0iuO4VU=.ec79ce23-0153-444a-8e0e-d039a93204e2@github.com>

On Wed, 1 Dec 2021 18:37:53 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Enabling pandoc on macosx-aarch64 at Oracle to produce man pages etc.
> 
> Testing:
> 
> * Passes tier1
> * Verified that the product bundle includes man pages as expected
> * Sampling a few of the man pages they look as expected

Looks good.

Would it be possible to rebuild pandoc packages for all platforms with the same version? (As a separate change at some point)

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

Marked as reviewed by erikj (Reviewer).

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


From mikael at openjdk.java.net  Wed Dec  1 20:12:28 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Wed, 1 Dec 2021 20:12:28 GMT
Subject: RFR: 8266839: Enable pandoc on macosx-aarch64 at Oracle
In-Reply-To: <eB3RMP_9CiqYQI1SuYkLq4KL_GqG2uWamOiib28PF-4=.26582b43-f4b5-4bfe-a632-7c25b9edbdcb@github.com>
References: <eB3RMP_9CiqYQI1SuYkLq4KL_GqG2uWamOiib28PF-4=.26582b43-f4b5-4bfe-a632-7c25b9edbdcb@github.com>
Message-ID: <Iz0sBgPWX6iqvXEB0J6-2VObUhwI2JzaNrnzdTEX20c=.2e9ed8da-f1f8-45f3-8bb1-406c953eba3d@github.com>

On Wed, 1 Dec 2021 18:37:53 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Enabling pandoc on macosx-aarch64 at Oracle to produce man pages etc.
> 
> Testing:
> 
> * Passes tier1
> * Verified that the product bundle includes man pages as expected
> * Sampling a few of the man pages they look as expected

Yes, I agree that we can and should investigate using the same pandoc version across all the platforms.

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

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


From mikael at openjdk.java.net  Wed Dec  1 20:25:26 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Wed, 1 Dec 2021 20:25:26 GMT
Subject: Integrated: 8266839: Enable pandoc on macosx-aarch64 at Oracle
In-Reply-To: <eB3RMP_9CiqYQI1SuYkLq4KL_GqG2uWamOiib28PF-4=.26582b43-f4b5-4bfe-a632-7c25b9edbdcb@github.com>
References: <eB3RMP_9CiqYQI1SuYkLq4KL_GqG2uWamOiib28PF-4=.26582b43-f4b5-4bfe-a632-7c25b9edbdcb@github.com>
Message-ID: <VxQWYsNZQzL4x1RbWVxF4FrkqHWY8SEhPH3_BwQhi_A=.c3b4137e-2664-4b0b-9898-565faaf06b91@github.com>

On Wed, 1 Dec 2021 18:37:53 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Enabling pandoc on macosx-aarch64 at Oracle to produce man pages etc.
> 
> Testing:
> 
> * Passes tier1
> * Verified that the product bundle includes man pages as expected
> * Sampling a few of the man pages they look as expected

This pull request has now been integrated.

Changeset: 51d6d7a3
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51d6d7a36b760b2b2b77269cc06438108a9931a2
Stats:     13 lines in 1 file changed: 11 ins; 0 del; 2 mod

8266839: Enable pandoc on macosx-aarch64 at Oracle

Reviewed-by: erikj

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

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


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

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

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

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

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

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


From duke at openjdk.java.net  Thu Dec  2 09:20:53 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 2 Dec 2021 09:20:53 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v8]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <ue9jx_EB_PYjuXUE_CRXxV8zT139PB72ynaFjFXF1Tc=.07860107-8942-481a-a541-f6c240c7aa24@github.com>

> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value when it is loaded back from the stack. If an
> attacker were to try to change control flow by editing the stack then
> the authentication check of the Link Register will fail, causing a
> segfault when the function returns.
> 
> On a system with PAC enabled, it is expected that all applications will
> be compiled with ROP protection. Fedora 33 and upwards already provide
> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
> PAC instructions that exist in the NOP space - on hardware without PAC,
> these instructions act as NOPs, allowing backward compatibility for
> negligible performance cost (2 NOPs per non-leaf function).
> 
> Hardware is currently limited to the Apple M1 MacBooks. All testing has
> been done within a Fedora Docker image. A run of SpecJVM showed no
> difference to that of noise - which was surprising.
> 
> The most important part of this patch is simply compiling using branch
> protection provided by GCC/LLVM. This protects all C++ code from being
> used in ROP attacks, removing all static ROP gadgets from use.
> 
> The remainder of the patch adds ROP protection to runtime generated
> code, in both stubs and compiled Java code. Attacks here are much harder
> as ROP gadgets must be found dynamically at runtime. If/when AOT
> compilation is added to JDK, then all stubs and compiled Java will be
> susceptible ROP gadgets being found by static analysis and therefore
> potentially as vulnerable as C++ code.
> 
> There are a number of places where the VM changes control flow by
> rewriting the stack or otherwise. I?ve done some analysis as to how
> these could also be used for attacks (which I didn?t want to post here).
> These areas can be protected ensuring the pointers to various stubs and
> entry points are stored in memory as signed pointers. These changes are
> simple to make (they can be reduced to a type change in common code and
> a few addition sign/auth calls in the backend), but there a lot of them
> and the total code change is fairly large. I?m happy to provide a few
> work in progress patches.
> 
> In order to match the security benefits of the Apple Arm64e ABI across
> the whole of JDK, then all the changes mentioned above would be
> required.

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

  Fix up UseROPProtection flag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/280abc41..995d8aa3

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

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

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


From duke at openjdk.java.net  Thu Dec  2 09:20:57 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 2 Dec 2021 09:20:57 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v7]
In-Reply-To: <WwQPhroyXJ8tpaHYZQR37O6WxFzpcN9OLJb-3kSa-54=.e6c1dd83-3c1c-4dd9-9a0f-eef981d27bf2@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <WwQPhroyXJ8tpaHYZQR37O6WxFzpcN9OLJb-3kSa-54=.e6c1dd83-3c1c-4dd9-9a0f-eef981d27bf2@github.com>
Message-ID: <5IotnN-721orMatHakGGJ0sIMpiWb506D-mrK5aFMCI=.45757405-3547-498e-b280-3e5f42e9eda6@github.com>

On Mon, 22 Nov 2021 17:35:41 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value when it is loaded back from the stack. If an
>> attacker were to try to change control flow by editing the stack then
>> the authentication check of the Link Register will fail, causing a
>> segfault when the function returns.
>> 
>> On a system with PAC enabled, it is expected that all applications will
>> be compiled with ROP protection. Fedora 33 and upwards already provide
>> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
>> PAC instructions that exist in the NOP space - on hardware without PAC,
>> these instructions act as NOPs, allowing backward compatibility for
>> negligible performance cost (2 NOPs per non-leaf function).
>> 
>> Hardware is currently limited to the Apple M1 MacBooks. All testing has
>> been done within a Fedora Docker image. A run of SpecJVM showed no
>> difference to that of noise - which was surprising.
>> 
>> The most important part of this patch is simply compiling using branch
>> protection provided by GCC/LLVM. This protects all C++ code from being
>> used in ROP attacks, removing all static ROP gadgets from use.
>> 
>> The remainder of the patch adds ROP protection to runtime generated
>> code, in both stubs and compiled Java code. Attacks here are much harder
>> as ROP gadgets must be found dynamically at runtime. If/when AOT
>> compilation is added to JDK, then all stubs and compiled Java will be
>> susceptible ROP gadgets being found by static analysis and therefore
>> potentially as vulnerable as C++ code.
>> 
>> There are a number of places where the VM changes control flow by
>> rewriting the stack or otherwise. I?ve done some analysis as to how
>> these could also be used for attacks (which I didn?t want to post here).
>> These areas can be protected ensuring the pointers to various stubs and
>> entry points are stored in memory as signed pointers. These changes are
>> simple to make (they can be reduced to a type change in common code and
>> a few addition sign/auth calls in the backend), but there a lot of them
>> and the total code change is fairly large. I?m happy to provide a few
>> work in progress patches.
>> 
>> In order to match the security benefits of the Apple Arm64e ABI across
>> the whole of JDK, then all the changes mentioned above would be
>> required.
>
> Alan Hayward has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge master
>  - Merge master
>  - Rename pauth_authenticate_or_strip_return_address
>  - Fix windows aarch64 by restoring pauth file split
>  - Don't keep LR live across restore_live_registers
>  - Merge master
>  - Document pauth functions && remove OS split
>  - Update UseROPProtection description
>  - Simplify branch protection configure check
>  - 8264130: PAC-RET protection for Linux/AArch64
>    
>    PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>    of its uses is to protect against ROP based attacks. This is done by
>    signing the Link Register whenever it is stored on the stack, and
>    authenticating the value when it is loaded back from the stack. If an
>    attacker were to try to change control flow by editing the stack then
>    the authentication check of the Link Register will fail, causing a
>    segfault when the function returns.
>    
>    On a system with PAC enabled, it is expected that all applications will
>    be compiled with ROP protection. Fedora 33 and upwards already provide
>    this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
>    PAC instructions that exist in the NOP space - on hardware without PAC,
>    these instructions act as NOPs, allowing backward compatibility for
>    negligible performance cost (2 NOPs per non-leaf function).
>    
>    Hardware is currently limited to the Apple M1 MacBooks. All testing has
>    been done within a Fedora Docker image. A run of SpecJVM showed no
>    difference to that of noise - which was surprising.
>    
>    The most important part of this patch is simply compiling using branch
>    protection provided by GCC/LLVM. This protects all C++ code from being
>    used in ROP attacks, removing all static ROP gadgets from use.
>    
>    The remainder of the patch adds ROP protection to runtime generated
>    code, in both stubs and compiled Java code. Attacks here are much harder
>    as ROP gadgets must be found dynamically at runtime. If/when AOT
>    compilation is added to JDK, then all stubs and compiled Java will be
>    susceptible ROP gadgets being found by static analysis and therefore
>    potentially as vulnerable as C++ code.
>    
>    There are a number of places where the VM changes control flow by
>    rewriting the stack or otherwise. I?ve done some analysis as to how
>    these could also be used for attacks (which I didn?t want to post here).
>    These areas can be protected ensuring the pointers to various stubs and
>    entry points are stored in memory as signed pointers. These changes are
>    simple to make (they can be reduced to a type change in common code and
>    a few addition sign/auth calls in the backend), but there a lot of them
>    and the total code change is fairly large. I?m happy to provide a few
>    work in progress patches.
>    
>    In order to match the security benefits of the Apple Arm64e ABI across
>    the whole of JDK, then all the changes mentioned above would be
>    required.
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/ca31ed53...280abc41

@dholmes-ora 

Fixed flags based on comments on the CSR:

> However, the proposed implementation does not match the description. VM_Version::initialize() is called after argument processing so even if the user has explicitly set the flag to false, if this is a PAC enabled system it will be turned back on. The code needs to check if the flag has been set before overriding the value; further the warning at line 389 should only be given if the user actually turned the flag on. But this should be taken up in the PR.

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

>> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/autoconf/jdk-options.m4 line 176:
> 
>> 174:       [specify alternative cacerts source folder containing certificates])])
>> 175:   AC_MSG_CHECKING([for cacerts source])
>> 176:   if test "x$with_cacerts_src" == x; then
> 
> Before this if block, please assign an empty value to CACERTS_SRC. Otherwise, if the user happens to have that variable set in the environment, that value will get recorded by configure, which is usually not something we want.

done

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

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


From dholmes at openjdk.java.net  Thu Dec  2 12:24:24 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Dec 2021 12:24:24 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v7]
In-Reply-To: <5IotnN-721orMatHakGGJ0sIMpiWb506D-mrK5aFMCI=.45757405-3547-498e-b280-3e5f42e9eda6@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <WwQPhroyXJ8tpaHYZQR37O6WxFzpcN9OLJb-3kSa-54=.e6c1dd83-3c1c-4dd9-9a0f-eef981d27bf2@github.com>
 <5IotnN-721orMatHakGGJ0sIMpiWb506D-mrK5aFMCI=.45757405-3547-498e-b280-3e5f42e9eda6@github.com>
Message-ID: <KfHpb76m7JfBgS2v1SYDVlXoYS3V2xCKf50VFE-LF7w=.0a805b7b-5343-411f-87d7-4edd77b11d74@github.com>

On Thu, 2 Dec 2021 09:16:59 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> @dholmes-ora
> 
> Fixed flags based on comments on the CSR:

Flag updates look good - thanks.

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

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


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

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

>> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Looks good!

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

Marked as reviewed by erikj (Reviewer).

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


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

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

>> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

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

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


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

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

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

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

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

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


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

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

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

This pull request has now been integrated.

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

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

Reviewed-by: erikj

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

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


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

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

>> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

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

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

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

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


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

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

>> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/modules/java.base/Gendata.gmk line 76:
> 
>> 74: ifneq ($(CACERTS_SRC), )
>> 75:   GENDATA_CACERTS_SRC := $(CACERTS_SRC)
>> 76: endif
> 
> Does this even work?! You are reassigning the variable after it has been used. The := assignment means that it not a macro.

I would have expected to see something like:

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

at line 63.

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

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


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

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

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

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

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

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


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

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

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

my assumption was the recipe gets resolved later

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

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


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

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

>> you make a valid point, but i've tested this numerous times, but let me check again
>
> my assumption was the recipe gets resolved later

this was my understanding: https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html

This occurs after make has finished reading all the makefiles and the target is determined to be out of date; so, the recipes for targets which are not rebuilt are never expanded. 

but i'm going to double check I was checking the resultant cacerts correctly in my tests

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

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


From darcy at openjdk.java.net  Thu Dec  2 18:29:41 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Dec 2021 18:29:41 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v7]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <VyhYwb8d_zFqpeKiat7Gi4ooytJrD6Lb-NdvUkHFcrA=.d22c2f8c-8eda-409c-ab3b-35d7ba34c3ad@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol information for JDK 18 b25.
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Remove SharedSpaces options from VMDeprecatedOptions.java.
 - Merge branch 'master' into JDK-8273146
 - Respond to review feedback.
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/8b042d14...b1b4ae2b

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

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=06
  Stats: 3280 lines in 67 files changed: 3237 ins; 4 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

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


From erikj at openjdk.java.net  Thu Dec  2 18:49:18 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 2 Dec 2021 18:49:18 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <mmBV0SG_q3Ko0fbrdD1FSWJWOZxVMy7OF5nw562_ZKY=.ce521db4-5cd5-453f-abaf-414d0877781f@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
 <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
 <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>
 <d0EXlPXv_oDqZWTqyd3jwYQ0kDXonvzsJvjaLgE2iPc=.85f6bb20-a5f1-41e4-a8e0-14df740b0f50@github.com>
 <mmBV0SG_q3Ko0fbrdD1FSWJWOZxVMy7OF5nw562_ZKY=.ce521db4-5cd5-453f-abaf-414d0877781f@github.com>
Message-ID: <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com>

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

>> my assumption was the recipe gets resolved later
>
> this was my understanding: https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html
> 
> This occurs after make has finished reading all the makefiles and the target is determined to be out of date; so, the recipes for targets which are not rebuilt are never expanded. 
> 
> but i'm going to double check I was checking the resultant cacerts correctly in my tests

Oh, I didn't expand the diff far enough to actually see the context correctly when I reviewed this as I would never have imagined the conditional to be placed after the rule. While this will work as so far as using the correct files, incremental builds will not be correct, because the rules are defined in the first pass.

I very much agree with Magnus that this conditional belongs around line 63.

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

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


From ihse at openjdk.java.net  Thu Dec  2 18:53:45 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 18:53:45 GMT
Subject: RFR: 8277069: [REDO] JDK-8276743 Make openjdk build Zip Archive
 generation "reproducible"
Message-ID: <U8lHJEo_EholzE68GtDiK7ixlEzU5_s0uL_BTYPwrFw=.0fe63063-c51e-47a0-95f7-d48f917fa706@github.com>

This is basically Andrew's old patch that was backed out, with a single change: I'm using  ZipFile instead of ZipInputStream to read in the original zip. The latter is not capable of reading the extended attributes that contain the unix permissions. (Why this is so, is not fully clear to me. What's worse, it's by no means clear from the documentation. We should probably file a follow-up bug to improve the Javadoc for ZipInputStream, warning the users to stay away if they can.)

I have also added the possibility to opt-out of reproducible building by an argument to SetupZipArchive. This is used in the closed Oracle part of the build, where we create some temporary zip files that are later discarded, and not part of the deliverables. This saves us some unnecessary overhead.

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

Commit messages:
 - Allow user to override reproducible building of zip file
 - Use ZipFile instead of ZipInputStream, which can handle Unix permissions
 - 8276743: Make openjdk build Zip Archive generation "reproducible"

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

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


From ihse at openjdk.java.net  Thu Dec  2 19:05:22 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 19:05:22 GMT
Subject: RFR: 8277069: [REDO] JDK-8276743 Make openjdk build Zip Archive
 generation "reproducible"
In-Reply-To: <U8lHJEo_EholzE68GtDiK7ixlEzU5_s0uL_BTYPwrFw=.0fe63063-c51e-47a0-95f7-d48f917fa706@github.com>
References: <U8lHJEo_EholzE68GtDiK7ixlEzU5_s0uL_BTYPwrFw=.0fe63063-c51e-47a0-95f7-d48f917fa706@github.com>
Message-ID: <xpzUyoHmssfUQtVaiXbmzjjnwmmYIQsgHAOkfxzozh4=.2ece7fbc-fb96-460a-bc80-33ad3fdf9bb5@github.com>

On Thu, 2 Dec 2021 14:55:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is basically Andrew's old patch that was backed out, with a single change: I'm using  ZipFile instead of ZipInputStream to read in the original zip. The latter is not capable of reading the extended attributes that contain the unix permissions. (Why this is so, is not fully clear to me. What's worse, it's by no means clear from the documentation. We should probably file a follow-up bug to improve the Javadoc for ZipInputStream, warning the users to stay away if they can.)
> 
> I have also added the possibility to opt-out of reproducible building by an argument to SetupZipArchive. This is used in the closed Oracle part of the build, where we create some temporary zip files that are later discarded, and not part of the deliverables. This saves us some unnecessary overhead.

I tried to find a way to make GitHub display the difference wrt the original, backed out, patch, but utterly failed. So here's a simple diff. This is the only way in which this patch differs from the original.


--- ./make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java	2021-12-02 19:57:38.000000000 +0100
+++ ../../jdk-ALT/open/make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java	2021-12-02 15:11:22.000000000 +0100
@@ -162,13 +162,8 @@

     // Process input zip file and add to sorted entries set
     boolean processInputEntries(File inFile) throws IOException {
-        try (FileInputStream fis = new FileInputStream(inFile);
-             ZipInputStream  zis = new ZipInputStream(fis)) {
-            ZipEntry entry;
-            while ((entry = zis.getNextEntry()) != null) {
-                entries.put(entry.getName(), entry);
-            }
-        }
+        ZipFile zipFile = new ZipFile(inFile);
+        zipFile.stream().forEach(entry -> entries.put(entry.getName(), entry));

         return true;
     }

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

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


From aleonard at openjdk.java.net  Thu Dec  2 19:15:22 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 19:15:22 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
 <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
 <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>
 <d0EXlPXv_oDqZWTqyd3jwYQ0kDXonvzsJvjaLgE2iPc=.85f6bb20-a5f1-41e4-a8e0-14df740b0f50@github.com>
 <mmBV0SG_q3Ko0fbrdD1FSWJWOZxVMy7OF5nw562_ZKY=.ce521db4-5cd5-453f-abaf-414d0877781f@github.com>
 <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com>
Message-ID: <M8K_4WettXBRsfwxU1mMIUsk8Wi79uyLXPnnml5Kiac=.37d440fb-edd7-4e74-ae2f-790324426b30@github.com>

On Thu, 2 Dec 2021 18:46:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> this was my understanding: https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html
>> 
>> This occurs after make has finished reading all the makefiles and the target is determined to be out of date; so, the recipes for targets which are not rebuilt are never expanded. 
>> 
>> but i'm going to double check I was checking the resultant cacerts correctly in my tests
>
> Oh, I didn't expand the diff far enough to actually see the context correctly when I reviewed this as I would never have imagined the conditional to be placed after the rule. While this will work as so far as using the correct files, incremental builds will not be correct, because the rules are defined in the first pass.
> 
> I very much agree with Magnus that this conditional belongs around line 63.

yes, thanks, feeling rather stupid here! i'll raise an issue to fix

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

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


From erikj at openjdk.java.net  Thu Dec  2 19:25:15 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 2 Dec 2021 19:25:15 GMT
Subject: RFR: 8277069: [REDO] JDK-8276743 Make openjdk build Zip Archive
 generation "reproducible"
In-Reply-To: <U8lHJEo_EholzE68GtDiK7ixlEzU5_s0uL_BTYPwrFw=.0fe63063-c51e-47a0-95f7-d48f917fa706@github.com>
References: <U8lHJEo_EholzE68GtDiK7ixlEzU5_s0uL_BTYPwrFw=.0fe63063-c51e-47a0-95f7-d48f917fa706@github.com>
Message-ID: <Zy2jkibUPI3FcIbu6a9ZII6mBnb9kHYkhFIT88LuKHk=.4a328dde-5fa4-492e-a3b3-69520a8f17e4@github.com>

On Thu, 2 Dec 2021 14:55:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is basically Andrew's old patch that was backed out, with a single change: I'm using  ZipFile instead of ZipInputStream to read in the original zip. The latter is not capable of reading the extended attributes that contain the unix permissions. (Why this is so, is not fully clear to me. What's worse, it's by no means clear from the documentation. We should probably file a follow-up bug to improve the Javadoc for ZipInputStream, warning the users to stay away if they can.)
> 
> I have also added the possibility to opt-out of reproducible building by an argument to SetupZipArchive. This is used in the closed Oracle part of the build, where we create some temporary zip files that are later discarded, and not part of the deliverables. This saves us some unnecessary overhead.

Marked as reviewed by erikj (Reviewer).

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

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


From ihse at openjdk.java.net  Thu Dec  2 19:55:16 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 19:55:16 GMT
Subject: RFR: 8277069: [REDO] JDK-8276743 Make openjdk build Zip Archive
 generation "reproducible"
In-Reply-To: <U8lHJEo_EholzE68GtDiK7ixlEzU5_s0uL_BTYPwrFw=.0fe63063-c51e-47a0-95f7-d48f917fa706@github.com>
References: <U8lHJEo_EholzE68GtDiK7ixlEzU5_s0uL_BTYPwrFw=.0fe63063-c51e-47a0-95f7-d48f917fa706@github.com>
Message-ID: <Vs1cDgXhCg0CcAmCXKd155GMjgAo6rDjQh12o--2gp0=.560e20dc-871e-44a2-b4e6-455498a4b404@github.com>

On Thu, 2 Dec 2021 14:55:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is basically Andrew's old patch that was backed out, with a single change: I'm using  ZipFile instead of ZipInputStream to read in the original zip. The latter is not capable of reading the extended attributes that contain the unix permissions. (Why this is so, is not fully clear to me. What's worse, it's by no means clear from the documentation. We should probably file a follow-up bug to improve the Javadoc for ZipInputStream, warning the users to stay away if they can.)
> 
> I have also added the possibility to opt-out of reproducible building by an argument to SetupZipArchive. This is used in the closed Oracle part of the build, where we create some temporary zip files that are later discarded, and not part of the deliverables. This saves us some unnecessary overhead.

FWIW, I've opened https://bugs.openjdk.java.net/browse/JDK-8278165 to at least get some documentation on the limitations of ZipInputStream.

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

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


From ihse at openjdk.java.net  Thu Dec  2 19:57:18 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 19:57:18 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <M8K_4WettXBRsfwxU1mMIUsk8Wi79uyLXPnnml5Kiac=.37d440fb-edd7-4e74-ae2f-790324426b30@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
 <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
 <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>
 <d0EXlPXv_oDqZWTqyd3jwYQ0kDXonvzsJvjaLgE2iPc=.85f6bb20-a5f1-41e4-a8e0-14df740b0f50@github.com>
 <mmBV0SG_q3Ko0fbrdD1FSWJWOZxVMy7OF5nw562_ZKY=.ce521db4-5cd5-453f-abaf-414d0877781f@github.com>
 <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com>
 <M8K_4WettXBRsfwxU1mMIUsk8Wi79uyLXPnnml5Kiac=.37d440fb-edd7-4e74-ae2f-790324426b30@github.com>
Message-ID: <Vf4tCn1i2Yp63w0m-RNBeYG1C6CinVTB0iHjxfvRmoM=.48f54590-6569-424a-8437-3a5059e19ceb@github.com>

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

>> Oh, I didn't expand the diff far enough to actually see the context correctly when I reviewed this as I would never have imagined the conditional to be placed after the rule. While this will work as so far as using the correct files, incremental builds will not be correct, because the rules are defined in the first pass.
>> 
>> I very much agree with Magnus that this conditional belongs around line 63.
>
> yes, thanks, feeling rather stupid here! i'll raise an issue to fix

@andrew-m-leonard Don't be. Make is a horrible programming language, both syntactically and semantically. It's taken me years to be somewhat comfortable with it, and often I just manage to get it right only by sticking to a few, well-proven and battle-hardened patterns. :)

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

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


From aleonard at openjdk.java.net  Thu Dec  2 21:19:33 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 21:19:33 GMT
Subject: RFR: 8278163: --with-cacerts-src variable resolved after
 GenerateCacerts recipe setup
Message-ID: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>

PR https://github.com/openjdk/jdk/pull/6647 resolved the GENDATA_CACERTS_SRC fir --with-cacerts-src after the recipe, which meant the dependencies were wrong.
This PR moves it before the recipe.

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

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

Commit messages:
 - 8278163: --with-cacerts-src variable resolved after GenerateCacerts recipe setup

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

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


From ihse at openjdk.java.net  Thu Dec  2 21:31:17 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 21:31:17 GMT
Subject: RFR: 8278163: --with-cacerts-src variable resolved after
 GenerateCacerts recipe setup
In-Reply-To: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>
References: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>
Message-ID: <8ZHSQLfnU9pKXYLszivJbGapQ2M0D5Q6lpdEsY_suhc=.ea652bbb-3b6d-49dd-8114-171d23b9aa0f@github.com>

On Thu, 2 Dec 2021 21:07:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> PR https://github.com/openjdk/jdk/pull/6647 resolved the GENDATA_CACERTS_SRC fir --with-cacerts-src after the recipe, which meant the dependencies were wrong.
> This PR moves it before the recipe.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Thanks for fixing so quickly.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Thu Dec  2 21:35:25 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 21:35:25 GMT
Subject: Integrated: 8277069: [REDO] JDK-8276743 Make openjdk build Zip Archive
 generation "reproducible"
In-Reply-To: <U8lHJEo_EholzE68GtDiK7ixlEzU5_s0uL_BTYPwrFw=.0fe63063-c51e-47a0-95f7-d48f917fa706@github.com>
References: <U8lHJEo_EholzE68GtDiK7ixlEzU5_s0uL_BTYPwrFw=.0fe63063-c51e-47a0-95f7-d48f917fa706@github.com>
Message-ID: <EAyr4x7WrMSxMnTBcyOd5YtAEVAveGtIDWsJexUXbW4=.facd8a2f-97df-4d24-b28d-f62b03672f39@github.com>

On Thu, 2 Dec 2021 14:55:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is basically Andrew's old patch that was backed out, with a single change: I'm using  ZipFile instead of ZipInputStream to read in the original zip. The latter is not capable of reading the extended attributes that contain the unix permissions. (Why this is so, is not fully clear to me. What's worse, it's by no means clear from the documentation. We should probably file a follow-up bug to improve the Javadoc for ZipInputStream, warning the users to stay away if they can.)
> 
> I have also added the possibility to opt-out of reproducible building by an argument to SetupZipArchive. This is used in the closed Oracle part of the build, where we create some temporary zip files that are later discarded, and not part of the deliverables. This saves us some unnecessary overhead.

This pull request has now been integrated.

Changeset: c93552c8
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c93552c8bbcdabb6219327d67409bf63432f49d8
Stats:     262 lines in 4 files changed: 255 ins; 0 del; 7 mod

8277069: [REDO] JDK-8276743 Make openjdk build Zip Archive generation "reproducible"

Co-authored-by: Andrew Leonard <aleonard at openjdk.org>
Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Reviewed-by: erikj

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

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


From ihse at openjdk.java.net  Thu Dec  2 22:53:29 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 22:53:29 GMT
Subject: RFR: 8251400: Fix incorrect addition of library to test in JDK-8237858
Message-ID: <CwOqYYf9-yXuKeClw684g57u-ooFNjCo9Jt3P4C6SSY=.7a606a09-0aeb-4447-8660-e4dddba6bb90@github.com>

In JDK-8237858, -pthread was added to all native tests, instead of the one single test that needed it. In the meantime, two new tests with pthread dependencies has crept in unnoticed due to this.

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

Commit messages:
 - 8251400: Fix incorrect addition of library to test in JDK-8237858

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

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


From jjg at openjdk.java.net  Fri Dec  3 00:35:34 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Dec 2021 00:35:34 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
Message-ID: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>

Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.

One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)

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

Commit messages:
 - JDK-8272945: Use snippets in java.compiler documentation

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

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


From ihse at openjdk.java.net  Fri Dec  3 00:44:16 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 3 Dec 2021 00:44:16 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
Message-ID: <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>

On Fri, 3 Dec 2021 00:26:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
> 
> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)

make/modules/java.compiler/Java.gmk line 30:

> 28: 
> 29: EXCLUDES += \
> 30:     javax/tools/snippet-files \

You can put this just on a single line :-). 

And I'm frankly not sure if make is happy about having a trailing backslash but no additional line...

src/java.compiler/share/classes/javax/tools/snippet-files/JavaSourceFromString.java line 29:

> 27:         return code;
> 28:     }
> 29: }

Missing newline..?

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

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


From darcy at openjdk.java.net  Fri Dec  3 01:25:33 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 3 Dec 2021 01:25:33 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
Message-ID: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>

In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

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

Commit messages:
 - JDK-8278175: Enable all doclint warnings for build of java.desktop

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

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


From jjg at openjdk.java.net  Fri Dec  3 01:41:15 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Dec 2021 01:41:15 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <yjrXkkRAV00sp4zj3ioEVzJmQ1OTb6dWWYcK37P0f_c=.ac1be279-c5f8-416f-bd05-81cbfafe0b67@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

Looks OK to me, although I don't consider myself a Reviewer for this code.

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

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


From dholmes at openjdk.java.net  Fri Dec  3 03:25:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 3 Dec 2021 03:25:16 GMT
Subject: RFR: 8251400: Fix incorrect addition of library to test in
 JDK-8237858
In-Reply-To: <CwOqYYf9-yXuKeClw684g57u-ooFNjCo9Jt3P4C6SSY=.7a606a09-0aeb-4447-8660-e4dddba6bb90@github.com>
References: <CwOqYYf9-yXuKeClw684g57u-ooFNjCo9Jt3P4C6SSY=.7a606a09-0aeb-4447-8660-e4dddba6bb90@github.com>
Message-ID: <1Rh4eAO6asVsEjAImt2nDEwT38_jcKv1ogP9LqkvlsA=.8cf662e9-fe18-4619-b257-a51ddede3c27@github.com>

On Thu, 2 Dec 2021 22:45:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8237858, -pthread was added to all native tests, instead of the one single test that needed it. In the meantime, two new tests with pthread dependencies has crept in unnoticed due to this.

Looks good.

I don't think `-pthread` would actually hurt anything though.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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


From darcy at openjdk.java.net  Fri Dec  3 03:34:30 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 3 Dec 2021 03:34:30 GMT
Subject: RFR: JDK-8278179: Enable all doclint warnings for build of java.naming
Message-ID: <LxGYAJTF-FIYOS-4sTYNlkyJr0MqPhMEbFDQBO_H7MU=.d769a22d-2005-4ee4-a48d-1d44c9046120@github.com>

An exploratory build indicates that it is not necessary to disable the accessibility doclint check for the java.naming module.

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

Commit messages:
 - JDK-8278179: Enable all doclint warnings for build of java.naming

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

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


From iris at openjdk.java.net  Fri Dec  3 06:21:15 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 3 Dec 2021 06:21:15 GMT
Subject: RFR: JDK-8278179: Enable all doclint warnings for build of
 java.naming
In-Reply-To: <LxGYAJTF-FIYOS-4sTYNlkyJr0MqPhMEbFDQBO_H7MU=.d769a22d-2005-4ee4-a48d-1d44c9046120@github.com>
References: <LxGYAJTF-FIYOS-4sTYNlkyJr0MqPhMEbFDQBO_H7MU=.d769a22d-2005-4ee4-a48d-1d44c9046120@github.com>
Message-ID: <KZfT6Zxd7M8GHWMzS2byIwkUH0HQ-ABM5VeDcJH_5FA=.db6470e1-e64d-4d43-97d2-7d6b7394a838@github.com>

On Fri, 3 Dec 2021 03:28:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> An exploratory build indicates that it is not necessary to disable the accessibility doclint check for the java.naming module.

?

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

Marked as reviewed by iris (Reviewer).

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


From darcy at openjdk.java.net  Fri Dec  3 06:45:45 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 3 Dec 2021 06:45:45 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v8]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <iVjwPPaqi-iB1ndHo7Qjil89hrQang7YS_MmMYyWK0g=.9f7e829b-e635-4ad5-a13b-ed369c0a231e@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

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

  Update symbol files to JDK 18 b26.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6493/files
  - new: https://git.openjdk.java.net/jdk/pull/6493/files/b1b4ae2b..88273596

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

  Stats: 610 lines in 3 files changed: 593 ins; 3 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

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


From alanb at openjdk.java.net  Fri Dec  3 08:02:13 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Dec 2021 08:02:13 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
Message-ID: <qwL7_OXVZICHrqhEdI2CsLfRSaRKykeSwqyE58IpTxA=.4fd139e9-a339-4402-b2d6-939df0eb79d4@github.com>

On Fri, 3 Dec 2021 00:26:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
> 
> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)

src/java.compiler/share/classes/javax/tools/JavaCompiler.java line 189:

> 187:  *     source code stored in a string:
> 188:  *
> 189:  *     {@snippet id=fileObject class=JavaSourceFromString }

JEP 413 uses the "file" attribute for external snippets, so using "class" here is new (to me anyway). Maybe the JEP should include an example that uses it.

Is this the first use of an external snippet in the src tree? I suspect files in the snippet-files directory will need a copyright header (downstream builders will report issues on this). It's not clear to me how that works if @replace region replacement="" isn't the first line of the external file.

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

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


From aleonard at openjdk.java.net  Fri Dec  3 08:33:20 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 3 Dec 2021 08:33:20 GMT
Subject: Integrated: 8278163: --with-cacerts-src variable resolved after
 GenerateCacerts recipe setup
In-Reply-To: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>
References: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>
Message-ID: <A1BC3lVYZPAgVgRGgKyX_oLwbZs78DNLC6iZT1C0VEA=.b357b38c-2d1f-4626-a23c-bf54f9aafd65@github.com>

On Thu, 2 Dec 2021 21:07:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> PR https://github.com/openjdk/jdk/pull/6647 resolved the GENDATA_CACERTS_SRC fir --with-cacerts-src after the recipe, which meant the dependencies were wrong.
> This PR moves it before the recipe.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: 45da3aea
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45da3aea22fd85f214e661b2c98631cb91ddb55d
Stats:     8 lines in 1 file changed: 4 ins; 3 del; 1 mod

8278163: --with-cacerts-src variable resolved after GenerateCacerts recipe setup

Reviewed-by: ihse

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

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


From erikj at openjdk.java.net  Fri Dec  3 13:40:22 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 3 Dec 2021 13:40:22 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <8e0538sQHtH4cYq5PU1oDgvcfFiUsvtB1gD3UACkFzc=.72d78b9e-5b18-4f05-8fe6-57acaccf9a99@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

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


From erikj at openjdk.java.net  Fri Dec  3 13:43:15 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 3 Dec 2021 13:43:15 GMT
Subject: RFR: 8251400: Fix incorrect addition of library to test in
 JDK-8237858
In-Reply-To: <CwOqYYf9-yXuKeClw684g57u-ooFNjCo9Jt3P4C6SSY=.7a606a09-0aeb-4447-8660-e4dddba6bb90@github.com>
References: <CwOqYYf9-yXuKeClw684g57u-ooFNjCo9Jt3P4C6SSY=.7a606a09-0aeb-4447-8660-e4dddba6bb90@github.com>
Message-ID: <7nBibp4Qcr4niJa0cN2pe_SsRP0sleKZQCnTXhYmL0E=.f84b9a8c-1365-477b-afbf-1c6f9ce884f0@github.com>

On Thu, 2 Dec 2021 22:45:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8237858, -pthread was added to all native tests, instead of the one single test that needed it. In the meantime, two new tests with pthread dependencies has crept in unnoticed due to this.

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.java.net  Fri Dec  3 13:44:16 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 3 Dec 2021 13:44:16 GMT
Subject: RFR: JDK-8278179: Enable all doclint warnings for build of
 java.naming
In-Reply-To: <LxGYAJTF-FIYOS-4sTYNlkyJr0MqPhMEbFDQBO_H7MU=.d769a22d-2005-4ee4-a48d-1d44c9046120@github.com>
References: <LxGYAJTF-FIYOS-4sTYNlkyJr0MqPhMEbFDQBO_H7MU=.d769a22d-2005-4ee4-a48d-1d44c9046120@github.com>
Message-ID: <bZWseNkKe7rzOp-I_HygZ7wtLBLuXVCLsff5iRxUtcM=.e21ef376-754b-4986-bb33-e38a6ab84762@github.com>

On Fri, 3 Dec 2021 03:28:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> An exploratory build indicates that it is not necessary to disable the accessibility doclint check for the java.naming module.

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.java.net  Fri Dec  3 13:50:14 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 3 Dec 2021 13:50:14 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
 <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
Message-ID: <uo4yeuURIFG7XRaFewIpilv2KicNpj7FjTUZxEjTvQM=.c9c5a06b-c130-4bda-b84c-0237d6922426@github.com>

On Fri, 3 Dec 2021 00:41:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
>> 
>> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)
>
> make/modules/java.compiler/Java.gmk line 30:
> 
>> 28: 
>> 29: EXCLUDES += \
>> 30:     javax/tools/snippet-files \
> 
> You can put this just on a single line :-). 
> 
> And I'm frankly not sure if make is happy about having a trailing backslash but no additional line...

As long as the next line is empty, it works, but it's not a good idea. That's why we came up with the terminating # in our 1 element per line lists. In this case, I would prefer a single line assignment without any backslashes.

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

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


From ihse at openjdk.java.net  Fri Dec  3 17:00:18 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 3 Dec 2021 17:00:18 GMT
Subject: RFR: 8251400: Fix incorrect addition of library to test in
 JDK-8237858
In-Reply-To: <1Rh4eAO6asVsEjAImt2nDEwT38_jcKv1ogP9LqkvlsA=.8cf662e9-fe18-4619-b257-a51ddede3c27@github.com>
References: <CwOqYYf9-yXuKeClw684g57u-ooFNjCo9Jt3P4C6SSY=.7a606a09-0aeb-4447-8660-e4dddba6bb90@github.com>
 <1Rh4eAO6asVsEjAImt2nDEwT38_jcKv1ogP9LqkvlsA=.8cf662e9-fe18-4619-b257-a51ddede3c27@github.com>
Message-ID: <CzL1ZPRtT3cL7yfLJaVNdaqoHmq6F0LdeThkR6wxg0g=.71c682b6-7405-4054-8f67-15f47e3d5086@github.com>

On Fri, 3 Dec 2021 03:22:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In JDK-8237858, -pthread was added to all native tests, instead of the one single test that needed it. In the meantime, two new tests with pthread dependencies has crept in unnoticed due to this.
>
> Looks good.
> 
> I don't think `-pthread` would actually hurt anything though.
> 
> Thanks,
> David

@dholmes-ora I agree that it's mostly benign in this case, but where do you draw the line? For every library you can argue "this does not really hurt to include on all tests" and suddenly you have a very complex testing environment if all tests have all libraries all the time...

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

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


From ihse at openjdk.java.net  Fri Dec  3 17:00:19 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 3 Dec 2021 17:00:19 GMT
Subject: Integrated: 8251400: Fix incorrect addition of library to test in
 JDK-8237858
In-Reply-To: <CwOqYYf9-yXuKeClw684g57u-ooFNjCo9Jt3P4C6SSY=.7a606a09-0aeb-4447-8660-e4dddba6bb90@github.com>
References: <CwOqYYf9-yXuKeClw684g57u-ooFNjCo9Jt3P4C6SSY=.7a606a09-0aeb-4447-8660-e4dddba6bb90@github.com>
Message-ID: <7Xlws_sQmuBDz9zG2zv-EYqvCi_ExoiJjHL60HwQb9k=.744d2f09-f8a8-4d03-aa15-d1b7084f8ee9@github.com>

On Thu, 2 Dec 2021 22:45:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8237858, -pthread was added to all native tests, instead of the one single test that needed it. In the meantime, two new tests with pthread dependencies has crept in unnoticed due to this.

This pull request has now been integrated.

Changeset: fbf096ee
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fbf096eea46756bdac6f474266caec500c4dc5c5
Stats:     13 lines in 2 files changed: 5 ins; 7 del; 1 mod

8251400: Fix incorrect addition of library to test in JDK-8237858

Reviewed-by: dholmes, erikj

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

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


From darcy at openjdk.java.net  Fri Dec  3 18:18:22 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 3 Dec 2021 18:18:22 GMT
Subject: Integrated: JDK-8278179: Enable all doclint warnings for build of
 java.naming
In-Reply-To: <LxGYAJTF-FIYOS-4sTYNlkyJr0MqPhMEbFDQBO_H7MU=.d769a22d-2005-4ee4-a48d-1d44c9046120@github.com>
References: <LxGYAJTF-FIYOS-4sTYNlkyJr0MqPhMEbFDQBO_H7MU=.d769a22d-2005-4ee4-a48d-1d44c9046120@github.com>
Message-ID: <QDQs_1_qX73TLsauTyw1trP2bM0oM7JnrtrmXTvrf6Q=.913c6892-02fe-46aa-8ec2-54a7139a08d9@github.com>

On Fri, 3 Dec 2021 03:28:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> An exploratory build indicates that it is not necessary to disable the accessibility doclint check for the java.naming module.

This pull request has now been integrated.

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

8278179: Enable all doclint warnings for build of java.naming

Reviewed-by: iris, erikj

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

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


From serb at openjdk.java.net  Fri Dec  3 18:58:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Dec 2021 18:58:16 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation
In-Reply-To: <YUGA1y62YYO6pW3TmVVA6u2FVCGBeSI0fm68BKcFhxs=.4ff07036-f6eb-4c88-8b77-2c16da437308@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <OYXY3EfnLesP0j3ctkTaMLftQoKHmzeCYBxO3J8Z6Iw=.0414edba-4953-4d77-901b-de1cccb696d1@github.com>
 <YUGA1y62YYO6pW3TmVVA6u2FVCGBeSI0fm68BKcFhxs=.4ff07036-f6eb-4c88-8b77-2c16da437308@github.com>
Message-ID: <oHHnesKTjVCKyV3HfD2iTkfDbQhUWWgl3xNyO7g6A9M=.78d853a7-3b6d-4e61-bb4d-8ddc5fcb4c83@github.com>

On Thu, 2 Dec 2021 10:55:57 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This is the case at Adoptium for example, which uses the Mozilla trusted CA certs.

But they didn't think skipping this test was too strong a step? For example validation of the certs expiration is quite useful. I tried to update the test to take into account additional certs, but it caused a merge conflict each time the certs in OpenJDK are updated. Probably we can add a config file that can inject/override some info in the test(at least skip the checksum validation)? By default this config file will be empty and will not be modified in the OpenJDK, but the vendors will be able to modify it. @wangweij @rhalade what do you think?

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

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


From rhalade at openjdk.java.net  Fri Dec  3 19:09:23 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 3 Dec 2021 19:09:23 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
Message-ID: <D4HFIhEOharaQH0yIUShMNuLSm5C1d1o6UFG1b6L8K4=.2138739c-5d93-4045-859e-58d86447931b@github.com>

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

>> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

The purpose of this test is to ensure integrity of the cacerts file along with basic validation of included roots. Having a config file with this information sounds like a good idea for now to be able to handle multiple files.

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

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


From prr at openjdk.java.net  Sat Dec  4 00:48:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 4 Dec 2021 00:48:13 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <lq-_QB_2lqzAo79lab-b5ME_S7lJYWlfGCiAumNXm8w=.c890f4f2-612d-4822-b20a-399e2010fd77@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

Looks OK. Could you file a P4 bug showing the warnings/errors that would be generated so that we know what we need to work on to later remove these the right way.

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

Marked as reviewed by prr (Reviewer).

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


From darcy at openjdk.java.net  Sat Dec  4 02:16:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 4 Dec 2021 02:16:15 GMT
Subject: RFR: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <hHoiIcihO5v4zEoXp7iiAAmwEY552379dJq5puMYzp8=.5e5ce6fa-a1fe-4491-b4eb-6998e1a8c941@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

> 

Sure; filed JDK-8278254 Cleanup doclint warnings in java.desktop module

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

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


From darcy at openjdk.java.net  Sat Dec  4 02:16:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 4 Dec 2021 02:16:15 GMT
Subject: Integrated: JDK-8278175: Enable all doclint warnings for build of
 java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <zgNP6WHnr2gT8YTi2LlPqdYrbyyF7uBjvaJM2fSeV70=.739ab508-0f62-4bd1-a437-9826b68e50f6@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

This pull request has now been integrated.

Changeset: 02ee337a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02ee337ae0d163ae44b1691eb9de12c5608ba178
Stats:     34 lines in 20 files changed: 16 ins; 0 del; 18 mod

8278175: Enable all doclint warnings for build of java.desktop

Reviewed-by: erikj, prr

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

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


From serb at openjdk.java.net  Sat Dec  4 06:47:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 4 Dec 2021 06:47:31 GMT
Subject: RFR: 8278251: Enable "missing-explicit-ctor" check in the
 jdk.unsupported.desktop module
Message-ID: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>

The "missing-explicit-ctor" check was disabled by the [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853). So we can re-enable this check again.

The fix will remove the "Java.gmk" file and as a result the "jdk.unsupported.desktop" folder.

All "Pre-submit tests" builds are green.

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

Commit messages:
 - Delete Java.gmk

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

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


From darcy at openjdk.java.net  Sun Dec  5 23:53:39 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sun, 5 Dec 2021 23:53:39 GMT
Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
Message-ID: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>

Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.

(Enabling the reference checks is left for future work.)

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

Commit messages:
 - JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks

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

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


From iris at openjdk.java.net  Mon Dec  6 06:19:14 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 6 Dec 2021 06:19:14 GMT
Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
In-Reply-To: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
References: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
Message-ID: <53hKkuTiEAI3u8ktsivvFxPwR0ZS-B8rgpLDmApjyIs=.00cd21e6-1731-4507-955a-a125b416aa13@github.com>

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

Marked as reviewed by iris (Reviewer).

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

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


From alanb at openjdk.java.net  Mon Dec  6 07:08:12 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 07:08:12 GMT
Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
In-Reply-To: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
References: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
Message-ID: <9SgzaJHojLAPSAitHsNAMOfU1ghzZWmKXT6OJEUsteQ=.c09933d0-7ce6-4bcd-8a58-d3a87d44ca88@github.com>

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

Marked as reviewed by alanb (Reviewer).

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

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


From shade at openjdk.java.net  Mon Dec  6 11:23:26 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Dec 2021 11:23:26 GMT
Subject: RFR: 8244602: Add JTREG_REPEAT_COUNT to repeat execution of a test
Message-ID: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>

This adds the test repeat feature in the build system. This is convenient to follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run the test multiple times, until we run out of repeats or the tests fail.

With this sample test:


/*
 * @test
 * @run driver IntermittentTest
 */
public class IntermittentTest {
    public static void main(String... args) {
        if (Math.random() < 0.05) {
            throw new IllegalStateException("Oops");
        }
    }
}


...a lucky run looks like this:


$ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=5"
Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
Running tests using JTREG control variable 'REPEAT_COUNT=5'
Test selection 'sanity/IntermittentTest.java', will run:
* jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java

Running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'

Repeating Jtreg run: 1 out of 5
Passed: sanity/IntermittentTest.java
Test results: passed: 1
Report written to ...
Results written to ...

Repeating Jtreg run: 2 out of 5
Passed: sanity/IntermittentTest.java
Test results: passed: 1
Report written to ...
Results written to ...

Repeating Jtreg run: 3 out of 5
Passed: sanity/IntermittentTest.java
Test results: passed: 1
Report written to ...
Results written to ...

Repeating Jtreg run: 4 out of 5
Passed: sanity/IntermittentTest.java
Test results: passed: 1
Report written to ...
Results written to ...

Repeating Jtreg run: 5 out of 5
Passed: sanity/IntermittentTest.java
Test results: passed: 1
Report written to ...
Results written to ...
Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
Test report is stored in ...

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
                                                         1     1     0     0   
==============================
TEST SUCCESS


...and unlucky run looks like this:


$ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=50"
Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
Running tests using JTREG control variable 'REPEAT_COUNT=50'
Test selection 'sanity/IntermittentTest.java', will run:
* jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
...
Repeating Jtreg run: 9 out of 50
Passed: sanity/IntermittentTest.java
Test results: passed: 1
Report written to ...
Results written to ...

Repeating Jtreg run: 10 out of 50
--------------------------------------------------
TEST: sanity/IntermittentTest.java
TEST JDK: ...

...

STDERR:
java.lang.IllegalStateException: Oops
	at IntermittentTest.main(IntermittentTest.java:8)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:833)

JavaTest Message: Test threw exception: java.lang.IllegalStateException
JavaTest Message: shutting down test


TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.IllegalStateException: Oops
--------------------------------------------------
Test results: failed: 1
Report written to ...
Results written to ...
Error: Some tests failed or other problems occurred.

Failures detected, no more repeats.
Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
Test report is stored in ...

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
>>                                                       1     0     1     0 <<
==============================
TEST FAILURE

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

Commit messages:
 - Fix

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

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


From ihse at openjdk.java.net  Mon Dec  6 11:50:16 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 6 Dec 2021 11:50:16 GMT
Subject: RFR: 8278251: Enable "missing-explicit-ctor" check in the
 jdk.unsupported.desktop module
In-Reply-To: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
References: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
Message-ID: <LFzMNyGzsoDVxrY4PmSvwWJ_Oukb_Y2skwa9XNGbg6k=.d6852cf1-920e-4a1e-a90e-34ac941d10f0@github.com>

On Fri, 3 Dec 2021 20:55:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "missing-explicit-ctor" check was disabled by the [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853). So we can re-enable this check again.
> 
> The fix will remove the "Java.gmk" file and as a result the "jdk.unsupported.desktop" folder.
> 
> All "Pre-submit tests" builds are green.

LGTM.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Mon Dec  6 11:52:13 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 6 Dec 2021 11:52:13 GMT
Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
In-Reply-To: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
References: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
Message-ID: <M43NwMLrzLg5w5zG-jkuYauBK7tju7uJceREYeZsYBE=.b62af4b6-91e6-4c87-8aa8-8217400fb12c@github.com>

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

?

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Mon Dec  6 11:55:12 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 6 Dec 2021 11:55:12 GMT
Subject: RFR: 8244602: Add JTREG_REPEAT_COUNT to repeat execution of a test
In-Reply-To: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
References: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
Message-ID: <Ee-1t789Fhunq0PpmE97GjnSCMzF90GewCVY-mphnLI=.7e941057-b2e7-4551-8662-886fcff328b4@github.com>

On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This adds the test repeat feature in the build system. This is convenient to follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run the test multiple times, until we run out of repeats or the tests fail.
> 
> With this sample test:
> 
> 
> /*
>  * @test
>  * @run driver IntermittentTest
>  */
> public class IntermittentTest {
>     public static void main(String... args) {
>         if (Math.random() < 0.05) {
>             throw new IllegalStateException("Oops");
>         }
>     }
> }
> 
> 
> ...a lucky run looks like this:
> 
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=5"
> Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> Running tests using JTREG control variable 'REPEAT_COUNT=5'
> Test selection 'sanity/IntermittentTest.java', will run:
> * jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
> 
> Running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> 
> Repeating Jtreg run: 1 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 2 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 3 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 4 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 5 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> Test report is stored in ...
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
>                                                          1     1     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> ...and unlucky run looks like this:
> 
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=50"
> Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> Running tests using JTREG control variable 'REPEAT_COUNT=50'
> Test selection 'sanity/IntermittentTest.java', will run:
> * jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
> ...
> Repeating Jtreg run: 9 out of 50
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 10 out of 50
> --------------------------------------------------
> TEST: sanity/IntermittentTest.java
> TEST JDK: ...
> 
> ...
> 
> STDERR:
> java.lang.IllegalStateException: Oops
> 	at IntermittentTest.main(IntermittentTest.java:8)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> JavaTest Message: Test threw exception: java.lang.IllegalStateException
> JavaTest Message: shutting down test
> 
> 
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.IllegalStateException: Oops
> --------------------------------------------------
> Test results: failed: 1
> Report written to ...
> Results written to ...
> Error: Some tests failed or other problems occurred.
> 
> Failures detected, no more repeats.
> Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> Test report is stored in ...
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
>>>                                                       1     0     1     0 <<
> ==============================
> TEST FAILURE

Looks good. Thank you for fixing this!

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

Marked as reviewed by ihse (Reviewer).

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


From erikj at openjdk.java.net  Mon Dec  6 14:58:21 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 6 Dec 2021 14:58:21 GMT
Subject: RFR: 8244602: Add JTREG_REPEAT_COUNT to repeat execution of a test
In-Reply-To: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
References: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
Message-ID: <23ch8dCEaalBpkyM4DdEmmUmLb88Nm-DT6HTj7HJDm8=.114e8c6f-f56b-4e12-a1bf-5f68e6172c75@github.com>

On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This adds the test repeat feature in the build system. This is convenient to follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run the test multiple times, until we run out of repeats or the tests fail.
> 
> With this sample test:
> 
> 
> /*
>  * @test
>  * @run driver IntermittentTest
>  */
> public class IntermittentTest {
>     public static void main(String... args) {
>         if (Math.random() < 0.05) {
>             throw new IllegalStateException("Oops");
>         }
>     }
> }
> 
> 
> ...a lucky run looks like this:
> 
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=5"
> Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> Running tests using JTREG control variable 'REPEAT_COUNT=5'
> Test selection 'sanity/IntermittentTest.java', will run:
> * jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
> 
> Running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> 
> Repeating Jtreg run: 1 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 2 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 3 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 4 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 5 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> Test report is stored in ...
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
>                                                          1     1     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> ...and unlucky run looks like this:
> 
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=50"
> Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> Running tests using JTREG control variable 'REPEAT_COUNT=50'
> Test selection 'sanity/IntermittentTest.java', will run:
> * jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
> ...
> Repeating Jtreg run: 9 out of 50
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 10 out of 50
> --------------------------------------------------
> TEST: sanity/IntermittentTest.java
> TEST JDK: ...
> 
> ...
> 
> STDERR:
> java.lang.IllegalStateException: Oops
> 	at IntermittentTest.main(IntermittentTest.java:8)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> JavaTest Message: Test threw exception: java.lang.IllegalStateException
> JavaTest Message: shutting down test
> 
> 
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.IllegalStateException: Oops
> --------------------------------------------------
> Test results: failed: 1
> Report written to ...
> Results written to ...
> Error: Some tests failed or other problems occurred.
> 
> Failures detected, no more repeats.
> Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> Test report is stored in ...
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
>>>                                                       1     0     1     0 <<
> ==============================
> TEST FAILURE

Marked as reviewed by erikj (Reviewer).

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

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


From darcy at openjdk.java.net  Mon Dec  6 17:00:19 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Dec 2021 17:00:19 GMT
Subject: Integrated: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
In-Reply-To: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
References: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
Message-ID: <VWMQuiOsa2iCff9JBfJVQ1whou8KgJBEI_4gti100rI=.7c9de73f-e287-47cf-8e1b-1620f79b2a1c@github.com>

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

This pull request has now been integrated.

Changeset: 5045eb53
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5045eb538b3afc6cf646642f1109473597b3004a
Stats:     14 lines in 7 files changed: 0 ins; 0 del; 14 mod

8278273: Remove unnecessary exclusion of doclint accessibility checks

Reviewed-by: iris, alanb, ihse

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

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


From prr at openjdk.java.net  Mon Dec  6 17:45:16 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:45:16 GMT
Subject: RFR: 8278251: Enable "missing-explicit-ctor" check in the
 jdk.unsupported.desktop module
In-Reply-To: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
References: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
Message-ID: <YhvPTCkgQWagURe3CpwEs582yZPqAHtcxwER3W9T3Kc=.e827d8c3-f24d-46b5-8698-c2c4b7ce49be@github.com>

On Fri, 3 Dec 2021 20:55:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "missing-explicit-ctor" check was disabled by the [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853). So we can re-enable this check again.
> 
> The fix will remove the "Java.gmk" file and as a result the "jdk.unsupported.desktop" folder.
> 
> All "Pre-submit tests" builds are green.

Marked as reviewed by prr (Reviewer).

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

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


From darcy at openjdk.java.net  Mon Dec  6 19:35:17 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Dec 2021 19:35:17 GMT
Subject: RFR: 8278251: Enable "missing-explicit-ctor" check in the
 jdk.unsupported.desktop module
In-Reply-To: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
References: <4f-QfTpojcbsiww5G7DrU7daNRNW0scSjxsPOUODdTo=.c578c7b1-2f75-4734-ae75-9c1a5c3214f4@github.com>
Message-ID: <Lbkh72MTEv9ywiDHMpwLFAfJhdZ3TUikp0qztfJ2WFs=.dfc74aa8-a33e-401f-8c27-f1fb2106d8bd@github.com>

On Fri, 3 Dec 2021 20:55:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "missing-explicit-ctor" check was disabled by the [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853). So we can re-enable this check again.
> 
> The fix will remove the "Java.gmk" file and as a result the "jdk.unsupported.desktop" folder.
> 
> All "Pre-submit tests" builds are green.

Not a reviewer for this particular change, but I support its goals.

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

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


From darcy at openjdk.java.net  Mon Dec  6 21:52:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Dec 2021 21:52:37 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v9]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <BEusjHE7fm_NEwQ_f8OXu9JsbamDJicDAIidVxJnHU8=.94cbc3cc-5e3e-447c-b86d-463e971bc506@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol files to JDK 18 b26.
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol information for JDK 18 b25.
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...9f68398a

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

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=08
  Stats: 3870 lines in 67 files changed: 3827 ins; 4 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

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


From jjg at openjdk.java.net  Tue Dec  7 02:57:10 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Dec 2021 02:57:10 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <uo4yeuURIFG7XRaFewIpilv2KicNpj7FjTUZxEjTvQM=.c9c5a06b-c130-4bda-b84c-0237d6922426@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
 <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
 <uo4yeuURIFG7XRaFewIpilv2KicNpj7FjTUZxEjTvQM=.c9c5a06b-c130-4bda-b84c-0237d6922426@github.com>
Message-ID: <ZEai3kb60xfUkUHDYyk4sPTCiUWOOBw8fAksBb1te2E=.5c6fa96f-d77d-4958-94a5-2c432c95cc6e@github.com>

On Fri, 3 Dec 2021 13:47:05 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/modules/java.compiler/Java.gmk line 30:
>> 
>>> 28: 
>>> 29: EXCLUDES += \
>>> 30:     javax/tools/snippet-files \
>> 
>> You can put this just on a single line :-). 
>> 
>> And I'm frankly not sure if make is happy about having a trailing backslash but no additional line...
>
> As long as the next line is empty, it works, but it's not a good idea. That's why we came up with the terminating # in our 1 element per line lists. In this case, I would prefer a single line assignment without any backslashes.

Fixed to single line

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

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


From jjg at openjdk.java.net  Tue Dec  7 02:57:10 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Dec 2021 02:57:10 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
 <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
Message-ID: <4YcA9pBfgNQpQ7UmFfKwwL7OOXmdsGgKpD-QSJb6pt4=.04ff3193-bc64-413d-aa96-f62aaa48c3b1@github.com>

On Fri, 3 Dec 2021 00:40:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
>> 
>> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)
>
> src/java.compiler/share/classes/javax/tools/snippet-files/JavaSourceFromString.java line 29:
> 
>> 27:         return code;
>> 28:     }
>> 29: }
> 
> Missing newline..?

Fixed

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

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


From jjg at openjdk.java.net  Tue Dec  7 03:05:41 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Dec 2021 03:05:41 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation [v2]
In-Reply-To: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
Message-ID: <iWmwew4LLM1HKRYe1qbwMDC5unpzk_VUmDb-h2pkB8w=.20ce25ff-0c1a-4c2e-913c-ae1d2143456b@github.com>

> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
> 
> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6686/files
  - new: https://git.openjdk.java.net/jdk/pull/6686/files/97cedc9a..27467bf2

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

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

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


From shade at openjdk.java.net  Tue Dec  7 11:35:17 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Dec 2021 11:35:17 GMT
Subject: RFR: 8244602: Add JTREG_REPEAT_COUNT to repeat execution of a test
In-Reply-To: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
References: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
Message-ID: <nZMSyKuhsfHROm4j1nwLM_ClqfOe1YzxDZoybzNi2ts=.5ebf796c-37f2-4bec-9d6e-b65f7b210207@github.com>

On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This adds the test repeat feature in the build system. This is convenient to follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run the test multiple times, until we run out of repeats or the tests fail.
> 
> With this sample test:
> 
> 
> /*
>  * @test
>  * @run driver IntermittentTest
>  */
> public class IntermittentTest {
>     public static void main(String... args) {
>         if (Math.random() < 0.05) {
>             throw new IllegalStateException("Oops");
>         }
>     }
> }
> 
> 
> ...a lucky run looks like this:
> 
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=5"
> Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> Running tests using JTREG control variable 'REPEAT_COUNT=5'
> Test selection 'sanity/IntermittentTest.java', will run:
> * jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
> 
> Running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> 
> Repeating Jtreg run: 1 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 2 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 3 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 4 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 5 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> Test report is stored in ...
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
>                                                          1     1     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> ...and unlucky run looks like this:
> 
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=50"
> Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> Running tests using JTREG control variable 'REPEAT_COUNT=50'
> Test selection 'sanity/IntermittentTest.java', will run:
> * jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
> ...
> Repeating Jtreg run: 9 out of 50
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 10 out of 50
> --------------------------------------------------
> TEST: sanity/IntermittentTest.java
> TEST JDK: ...
> 
> ...
> 
> STDERR:
> java.lang.IllegalStateException: Oops
> 	at IntermittentTest.main(IntermittentTest.java:8)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> JavaTest Message: Test threw exception: java.lang.IllegalStateException
> JavaTest Message: shutting down test
> 
> 
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.IllegalStateException: Oops
> --------------------------------------------------
> Test results: failed: 1
> Report written to ...
> Results written to ...
> Error: Some tests failed or other problems occurred.
> 
> Failures detected, no more repeats.
> Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> Test report is stored in ...
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
>>>                                                       1     0     1     0 <<
> ==============================
> TEST FAILURE

Thanks, folks!

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

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


From shade at openjdk.java.net  Tue Dec  7 11:35:18 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Dec 2021 11:35:18 GMT
Subject: Integrated: 8244602: Add JTREG_REPEAT_COUNT to repeat execution of a
 test
In-Reply-To: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
References: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
Message-ID: <8GJM0Gpo6nEIpAb5ZyGmN6e7ELyuuT0bBd7JCBqIh9E=.d5cf615f-b45c-4499-80fb-f4f6c9526601@github.com>

On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This adds the test repeat feature in the build system. This is convenient to follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run the test multiple times, until we run out of repeats or the tests fail.
> 
> With this sample test:
> 
> 
> /*
>  * @test
>  * @run driver IntermittentTest
>  */
> public class IntermittentTest {
>     public static void main(String... args) {
>         if (Math.random() < 0.05) {
>             throw new IllegalStateException("Oops");
>         }
>     }
> }
> 
> 
> ...a lucky run looks like this:
> 
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=5"
> Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> Running tests using JTREG control variable 'REPEAT_COUNT=5'
> Test selection 'sanity/IntermittentTest.java', will run:
> * jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
> 
> Running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> 
> Repeating Jtreg run: 1 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 2 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 3 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 4 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 5 out of 5
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> Test report is stored in ...
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
>                                                          1     1     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> ...and unlucky run looks like this:
> 
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=sanity/IntermittentTest.java JTREG="REPEAT_COUNT=50"
> Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> Running tests using JTREG control variable 'REPEAT_COUNT=50'
> Test selection 'sanity/IntermittentTest.java', will run:
> * jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
> ...
> Repeating Jtreg run: 9 out of 50
> Passed: sanity/IntermittentTest.java
> Test results: passed: 1
> Report written to ...
> Results written to ...
> 
> Repeating Jtreg run: 10 out of 50
> --------------------------------------------------
> TEST: sanity/IntermittentTest.java
> TEST JDK: ...
> 
> ...
> 
> STDERR:
> java.lang.IllegalStateException: Oops
> 	at IntermittentTest.main(IntermittentTest.java:8)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> JavaTest Message: Test threw exception: java.lang.IllegalStateException
> JavaTest Message: shutting down test
> 
> 
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.IllegalStateException: Oops
> --------------------------------------------------
> Test results: failed: 1
> Report written to ...
> Results written to ...
> Error: Some tests failed or other problems occurred.
> 
> Failures detected, no more repeats.
> Finished running test 'jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java'
> Test report is stored in ...
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/sanity/IntermittentTest.java
>>>                                                       1     0     1     0 <<
> ==============================
> TEST FAILURE

This pull request has now been integrated.

Changeset: b2638e5e
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b2638e5efd3c2b1abe790ab59baf28afa308614f
Stats:     28 lines in 3 files changed: 27 ins; 0 del; 1 mod

8244602: Add JTREG_REPEAT_COUNT to repeat execution of a test

Reviewed-by: ihse, erikj

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

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


From erikj at openjdk.java.net  Tue Dec  7 13:30:15 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 7 Dec 2021 13:30:15 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation [v2]
In-Reply-To: <iWmwew4LLM1HKRYe1qbwMDC5unpzk_VUmDb-h2pkB8w=.20ce25ff-0c1a-4c2e-913c-ae1d2143456b@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
 <iWmwew4LLM1HKRYe1qbwMDC5unpzk_VUmDb-h2pkB8w=.20ce25ff-0c1a-4c2e-913c-ae1d2143456b@github.com>
Message-ID: <322owcuKtMUGmQvVrIZC223CtXQrUxPswORBfLGZv0o=.617c1da6-b354-4578-86b0-addf79d7bd97@github.com>

On Tue, 7 Dec 2021 03:05:41 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
>> 
>> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Build changes look ok.

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

Marked as reviewed by erikj (Reviewer).

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


From darcy at openjdk.java.net  Thu Dec  9 17:07:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Dec 2021 17:07:18 GMT
Subject: Integrated: JDK-8273146: Start of release updates for JDK 19
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <qJE3l7bbGSefMtF1mI5-Sd-2nDoul8oEzCgvQr4LMis=.1f8167ad-2d8f-4c84-b3a1-afa5493430e1@github.com>

On Mon, 22 Nov 2021 03:15:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

This pull request has now been integrated.

Changeset: 09831e7a
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/09831e7aa47ebe41eab2f3014ebbacf338097ef6
Stats:     4252 lines in 67 files changed: 4206 ins; 7 del; 39 mod

8273146: Start of release updates for JDK 19
8277511: Add SourceVersion.RELEASE_19
8277513: Add source 19 and target 19 to javac

Reviewed-by: dholmes, alanb, erikj, iris, mikael, ihse

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

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


From aph at openjdk.java.net  Thu Dec  9 17:16:20 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 9 Dec 2021 17:16:20 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v8]
In-Reply-To: <ue9jx_EB_PYjuXUE_CRXxV8zT139PB72ynaFjFXF1Tc=.07860107-8942-481a-a541-f6c240c7aa24@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <ue9jx_EB_PYjuXUE_CRXxV8zT139PB72ynaFjFXF1Tc=.07860107-8942-481a-a541-f6c240c7aa24@github.com>
Message-ID: <IuimK2NeTDQYITs7SEr5oK-jyqZCUu1taGs5Qx5TdRQ=.64b779c6-35e0-4d46-b2de-4c9b7e612157@github.com>

On Thu, 2 Dec 2021 09:20:53 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value when it is loaded back from the stack. If an
>> attacker were to try to change control flow by editing the stack then
>> the authentication check of the Link Register will fail, causing a
>> segfault when the function returns.
>> 
>> On a system with PAC enabled, it is expected that all applications will
>> be compiled with ROP protection. Fedora 33 and upwards already provide
>> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
>> PAC instructions that exist in the NOP space - on hardware without PAC,
>> these instructions act as NOPs, allowing backward compatibility for
>> negligible performance cost (2 NOPs per non-leaf function).
>> 
>> Hardware is currently limited to the Apple M1 MacBooks. All testing has
>> been done within a Fedora Docker image. A run of SpecJVM showed no
>> difference to that of noise - which was surprising.
>> 
>> The most important part of this patch is simply compiling using branch
>> protection provided by GCC/LLVM. This protects all C++ code from being
>> used in ROP attacks, removing all static ROP gadgets from use.
>> 
>> The remainder of the patch adds ROP protection to runtime generated
>> code, in both stubs and compiled Java code. Attacks here are much harder
>> as ROP gadgets must be found dynamically at runtime. If/when AOT
>> compilation is added to JDK, then all stubs and compiled Java will be
>> susceptible ROP gadgets being found by static analysis and therefore
>> potentially as vulnerable as C++ code.
>> 
>> There are a number of places where the VM changes control flow by
>> rewriting the stack or otherwise. I?ve done some analysis as to how
>> these could also be used for attacks (which I didn?t want to post here).
>> These areas can be protected ensuring the pointers to various stubs and
>> entry points are stored in memory as signed pointers. These changes are
>> simple to make (they can be reduced to a type change in common code and
>> a few addition sign/auth calls in the backend), but there a lot of them
>> and the total code change is fairly large. I?m happy to provide a few
>> work in progress patches.
>> 
>> In order to match the security benefits of the Apple Arm64e ABI across
>> the whole of JDK, then all the changes mentioned above would be
>> required.
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix up UseROPProtection flag

make/autoconf/flags-cflags.m4 line 902:

> 900:   BRANCH_PROTECTION_CFLAGS=""
> 901:   UTIL_ARG_ENABLE(NAME: branch-protection, DEFAULT: auto,
> 902:       RESULT: USE_BRANCH_PROTECTION, AVAILABLE: $BRANCH_PROTECTION_AVAILABLE,

What exactly is going on here? Is it that if the host compiler has "branch protection" supported, we will build with it on by default? if so, no, we don't want to do that. For now, branch protection should be an explicit opt in.

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

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


From duke at openjdk.java.net  Fri Dec 10 11:06:17 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Fri, 10 Dec 2021 11:06:17 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v8]
In-Reply-To: <IuimK2NeTDQYITs7SEr5oK-jyqZCUu1taGs5Qx5TdRQ=.64b779c6-35e0-4d46-b2de-4c9b7e612157@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <ue9jx_EB_PYjuXUE_CRXxV8zT139PB72ynaFjFXF1Tc=.07860107-8942-481a-a541-f6c240c7aa24@github.com>
 <IuimK2NeTDQYITs7SEr5oK-jyqZCUu1taGs5Qx5TdRQ=.64b779c6-35e0-4d46-b2de-4c9b7e612157@github.com>
Message-ID: <OvUkfLQN20cnp02fERCNDuh2qSbf131AHruEW3bPThg=.adea21b6-5e90-4de0-bd61-c1a614dda265@github.com>

On Thu, 9 Dec 2021 17:12:45 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix up UseROPProtection flag
>
> make/autoconf/flags-cflags.m4 line 902:
> 
>> 900:   BRANCH_PROTECTION_CFLAGS=""
>> 901:   UTIL_ARG_ENABLE(NAME: branch-protection, DEFAULT: auto,
>> 902:       RESULT: USE_BRANCH_PROTECTION, AVAILABLE: $BRANCH_PROTECTION_AVAILABLE,
> 
> What exactly is going on here? Is it that if the host compiler has "branch protection" supported, we will build with it on by default? if so, no, we don't want to do that. For now, branch protection should be an explicit opt in.

The idea was that the same JDK could be used on PAC and non PAC systems. I agree that right now it's probably better being explicit opt in. Will update.

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

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


From duke at openjdk.java.net  Fri Dec 10 12:39:50 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Fri, 10 Dec 2021 12:39:50 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v9]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <8qhvLwNTzv5KxwJo93xrYA3GQSAX9NJm24EmbqFc3l8=.ba92bad8-0983-4519-9255-6913569f2638@github.com>

> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value when it is loaded back from the stack. If an
> attacker were to try to change control flow by editing the stack then
> the authentication check of the Link Register will fail, causing a
> segfault when the function returns.
> 
> On a system with PAC enabled, it is expected that all applications will
> be compiled with ROP protection. Fedora 33 and upwards already provide
> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
> PAC instructions that exist in the NOP space - on hardware without PAC,
> these instructions act as NOPs, allowing backward compatibility for
> negligible performance cost (2 NOPs per non-leaf function).
> 
> Hardware is currently limited to the Apple M1 MacBooks. All testing has
> been done within a Fedora Docker image. A run of SpecJVM showed no
> difference to that of noise - which was surprising.
> 
> The most important part of this patch is simply compiling using branch
> protection provided by GCC/LLVM. This protects all C++ code from being
> used in ROP attacks, removing all static ROP gadgets from use.
> 
> The remainder of the patch adds ROP protection to runtime generated
> code, in both stubs and compiled Java code. Attacks here are much harder
> as ROP gadgets must be found dynamically at runtime. If/when AOT
> compilation is added to JDK, then all stubs and compiled Java will be
> susceptible ROP gadgets being found by static analysis and therefore
> potentially as vulnerable as C++ code.
> 
> There are a number of places where the VM changes control flow by
> rewriting the stack or otherwise. I?ve done some analysis as to how
> these could also be used for attacks (which I didn?t want to post here).
> These areas can be protected ensuring the pointers to various stubs and
> entry points are stored in memory as signed pointers. These changes are
> simple to make (they can be reduced to a type change in common code and
> a few addition sign/auth calls in the backend), but there a lot of them
> and the total code change is fairly large. I?m happy to provide a few
> work in progress patches.
> 
> In order to match the security benefits of the Apple Arm64e ABI across
> the whole of JDK, then all the changes mentioned above would be
> required.

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

  Default to building without branch-protection

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/995d8aa3..38c08ef5

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

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

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


From aph at openjdk.java.net  Fri Dec 10 13:25:21 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 10 Dec 2021 13:25:21 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v9]
In-Reply-To: <8qhvLwNTzv5KxwJo93xrYA3GQSAX9NJm24EmbqFc3l8=.ba92bad8-0983-4519-9255-6913569f2638@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8qhvLwNTzv5KxwJo93xrYA3GQSAX9NJm24EmbqFc3l8=.ba92bad8-0983-4519-9255-6913569f2638@github.com>
Message-ID: <5g4s-czewXTVHX027JYGJIXapsXAjGYmScabO9Nk8nA=.6bc890fd-9394-4b77-9c87-890c8364d980@github.com>

On Fri, 10 Dec 2021 12:39:50 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value when it is loaded back from the stack. If an
>> attacker were to try to change control flow by editing the stack then
>> the authentication check of the Link Register will fail, causing a
>> segfault when the function returns.
>> 
>> On a system with PAC enabled, it is expected that all applications will
>> be compiled with ROP protection. Fedora 33 and upwards already provide
>> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
>> PAC instructions that exist in the NOP space - on hardware without PAC,
>> these instructions act as NOPs, allowing backward compatibility for
>> negligible performance cost (2 NOPs per non-leaf function).
>> 
>> Hardware is currently limited to the Apple M1 MacBooks. All testing has
>> been done within a Fedora Docker image. A run of SpecJVM showed no
>> difference to that of noise - which was surprising.
>> 
>> The most important part of this patch is simply compiling using branch
>> protection provided by GCC/LLVM. This protects all C++ code from being
>> used in ROP attacks, removing all static ROP gadgets from use.
>> 
>> The remainder of the patch adds ROP protection to runtime generated
>> code, in both stubs and compiled Java code. Attacks here are much harder
>> as ROP gadgets must be found dynamically at runtime. If/when AOT
>> compilation is added to JDK, then all stubs and compiled Java will be
>> susceptible ROP gadgets being found by static analysis and therefore
>> potentially as vulnerable as C++ code.
>> 
>> There are a number of places where the VM changes control flow by
>> rewriting the stack or otherwise. I?ve done some analysis as to how
>> these could also be used for attacks (which I didn?t want to post here).
>> These areas can be protected ensuring the pointers to various stubs and
>> entry points are stored in memory as signed pointers. These changes are
>> simple to make (they can be reduced to a type change in common code and
>> a few addition sign/auth calls in the backend), but there a lot of them
>> and the total code change is fairly large. I?m happy to provide a few
>> work in progress patches.
>> 
>> In order to match the security benefits of the Apple Arm64e ABI across
>> the whole of JDK, then all the changes mentioned above would be
>> required.
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to building without branch-protection

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 419:

> 417:     if (UseROPProtection) {
> 418:       warning("UseROPProtection specified, but not supported on this CPU.");
> 419:       FLAG_SET_DEFAULT(UseROPProtection, false);

Suggestion:

      FLAG_SET_DEFAULT(UseROPProtection, true);

Given that the instructions used are in NOP space, this won't do any harm, and it will allow developers without PAC-enabled systems to see what code PAC would generate.

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

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


From duke at openjdk.java.net  Fri Dec 10 15:14:47 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Fri, 10 Dec 2021 15:14:47 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v10]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <WQrjSwcX4oJYHIWr2rcKgvs4mw-hS9jGcRubt36Xi_0=.ada0810c-aad6-49b5-8e6a-f1e2f5fd7cc6@github.com>

> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value when it is loaded back from the stack. If an
> attacker were to try to change control flow by editing the stack then
> the authentication check of the Link Register will fail, causing a
> segfault when the function returns.
> 
> On a system with PAC enabled, it is expected that all applications will
> be compiled with ROP protection. Fedora 33 and upwards already provide
> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
> PAC instructions that exist in the NOP space - on hardware without PAC,
> these instructions act as NOPs, allowing backward compatibility for
> negligible performance cost (2 NOPs per non-leaf function).
> 
> Hardware is currently limited to the Apple M1 MacBooks. All testing has
> been done within a Fedora Docker image. A run of SpecJVM showed no
> difference to that of noise - which was surprising.
> 
> The most important part of this patch is simply compiling using branch
> protection provided by GCC/LLVM. This protects all C++ code from being
> used in ROP attacks, removing all static ROP gadgets from use.
> 
> The remainder of the patch adds ROP protection to runtime generated
> code, in both stubs and compiled Java code. Attacks here are much harder
> as ROP gadgets must be found dynamically at runtime. If/when AOT
> compilation is added to JDK, then all stubs and compiled Java will be
> susceptible ROP gadgets being found by static analysis and therefore
> potentially as vulnerable as C++ code.
> 
> There are a number of places where the VM changes control flow by
> rewriting the stack or otherwise. I?ve done some analysis as to how
> these could also be used for attacks (which I didn?t want to post here).
> These areas can be protected ensuring the pointers to various stubs and
> entry points are stored in memory as signed pointers. These changes are
> simple to make (they can be reduced to a type change in common code and
> a few addition sign/auth calls in the backend), but there a lot of them
> and the total code change is fairly large. I?m happy to provide a few
> work in progress patches.
> 
> In order to match the security benefits of the Apple Arm64e ABI across
> the whole of JDK, then all the changes mentioned above would be
> required.

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

  Remove BSD/Apple specific code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/38c08ef5..63f7515f

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

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

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


From duke at openjdk.java.net  Fri Dec 10 15:19:21 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Fri, 10 Dec 2021 15:19:21 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v9]
In-Reply-To: <5g4s-czewXTVHX027JYGJIXapsXAjGYmScabO9Nk8nA=.6bc890fd-9394-4b77-9c87-890c8364d980@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8qhvLwNTzv5KxwJo93xrYA3GQSAX9NJm24EmbqFc3l8=.ba92bad8-0983-4519-9255-6913569f2638@github.com>
 <5g4s-czewXTVHX027JYGJIXapsXAjGYmScabO9Nk8nA=.6bc890fd-9394-4b77-9c87-890c8364d980@github.com>
Message-ID: <1O5M3usjaNAhxthALcIb-fLeJUMrNiLc9OQ5nrlXMkg=.d7c5dc66-61b9-4fb6-813e-e74f9d536baf@github.com>

On Fri, 10 Dec 2021 13:21:46 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Default to building without branch-protection
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 419:
> 
>> 417:     if (UseROPProtection) {
>> 418:       warning("UseROPProtection specified, but not supported on this CPU.");
>> 419:       FLAG_SET_DEFAULT(UseROPProtection, false);
> 
> Suggestion:
> 
>       FLAG_SET_DEFAULT(UseROPProtection, true);
> 
> Given that the instructions used are in NOP space, this won't do any harm, and it will allow developers without PAC-enabled systems to see what code PAC would generate.

Ok, I think that's fine. How about on a non pac system allowing it for development only ?

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

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


From aph at openjdk.java.net  Sat Dec 11 09:33:12 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 11 Dec 2021 09:33:12 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v9]
In-Reply-To: <1O5M3usjaNAhxthALcIb-fLeJUMrNiLc9OQ5nrlXMkg=.d7c5dc66-61b9-4fb6-813e-e74f9d536baf@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8qhvLwNTzv5KxwJo93xrYA3GQSAX9NJm24EmbqFc3l8=.ba92bad8-0983-4519-9255-6913569f2638@github.com>
 <5g4s-czewXTVHX027JYGJIXapsXAjGYmScabO9Nk8nA=.6bc890fd-9394-4b77-9c87-890c8364d980@github.com>
 <1O5M3usjaNAhxthALcIb-fLeJUMrNiLc9OQ5nrlXMkg=.d7c5dc66-61b9-4fb6-813e-e74f9d536baf@github.com>
Message-ID: <ZnAkQtCXS15bfrk0LqqfYZZZwdJ-E2EpyhT2zi7IbSg=.16878ca6-f850-4809-ab75-79dec44ac317@github.com>

On Fri, 10 Dec 2021 15:16:19 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 419:
>> 
>>> 417:     if (UseROPProtection) {
>>> 418:       warning("UseROPProtection specified, but not supported on this CPU.");
>>> 419:       FLAG_SET_DEFAULT(UseROPProtection, false);
>> 
>> Suggestion:
>> 
>>       FLAG_SET_DEFAULT(UseROPProtection, true);
>> 
>> Given that the instructions used are in NOP space, this won't do any harm, and it will allow developers without PAC-enabled systems to see what code PAC would generate.
>
> Ok, I think that's fine. How about on a non pac system allowing it for development only ?

Maybe. Mind you, a lot of the time I'm looking at the output from production systems.
>From a rather philosophical point of view, I assume that if the user of a computer asks for something that isn't going to break anything or confuse anyone, we should honour their request.

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

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


From aph at openjdk.java.net  Sat Dec 11 14:08:12 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 11 Dec 2021 14:08:12 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v10]
In-Reply-To: <WQrjSwcX4oJYHIWr2rcKgvs4mw-hS9jGcRubt36Xi_0=.ada0810c-aad6-49b5-8e6a-f1e2f5fd7cc6@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <WQrjSwcX4oJYHIWr2rcKgvs4mw-hS9jGcRubt36Xi_0=.ada0810c-aad6-49b5-8e6a-f1e2f5fd7cc6@github.com>
Message-ID: <QRUBo-CBnbOHM6QInZZCEmm29oCHqXpEcN6cQ9RtlYY=.c35297c9-c808-4ea0-84e0-26b4eb612b57@github.com>

On Fri, 10 Dec 2021 15:14:47 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value when it is loaded back from the stack. If an
>> attacker were to try to change control flow by editing the stack then
>> the authentication check of the Link Register will fail, causing a
>> segfault when the function returns.
>> 
>> On a system with PAC enabled, it is expected that all applications will
>> be compiled with ROP protection. Fedora 33 and upwards already provide
>> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
>> PAC instructions that exist in the NOP space - on hardware without PAC,
>> these instructions act as NOPs, allowing backward compatibility for
>> negligible performance cost (2 NOPs per non-leaf function).
>> 
>> Hardware is currently limited to the Apple M1 MacBooks. All testing has
>> been done within a Fedora Docker image. A run of SpecJVM showed no
>> difference to that of noise - which was surprising.
>> 
>> The most important part of this patch is simply compiling using branch
>> protection provided by GCC/LLVM. This protects all C++ code from being
>> used in ROP attacks, removing all static ROP gadgets from use.
>> 
>> The remainder of the patch adds ROP protection to runtime generated
>> code, in both stubs and compiled Java code. Attacks here are much harder
>> as ROP gadgets must be found dynamically at runtime. If/when AOT
>> compilation is added to JDK, then all stubs and compiled Java will be
>> susceptible ROP gadgets being found by static analysis and therefore
>> potentially as vulnerable as C++ code.
>> 
>> There are a number of places where the VM changes control flow by
>> rewriting the stack or otherwise. I?ve done some analysis as to how
>> these could also be used for attacks (which I didn?t want to post here).
>> These areas can be protected ensuring the pointers to various stubs and
>> entry points are stored in memory as signed pointers. These changes are
>> simple to make (they can be reduced to a type change in common code and
>> a few addition sign/auth calls in the backend), but there a lot of them
>> and the total code change is fairly large. I?m happy to provide a few
>> work in progress patches.
>> 
>> In order to match the security benefits of the Apple Arm64e ABI across
>> the whole of JDK, then all the changes mentioned above would be
>> required.
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove BSD/Apple specific code

src/hotspot/cpu/aarch64/globals_aarch64.hpp line 122:

> 120:           "It cannot be used with OnSpinWaitInst=none.")                \
> 121:           range(1, 99)                                                  \
> 122:   product(bool, UseROPProtection, false,                                \

Question: this is called "UseROPProtection", the configure option is called "enable-branch-protection", and GCC option is called "-mbranch-protection". This is confusing. I would have thought we would want the same name, and use it for all branch protection. So why is this not "UseBranchProtection"?

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

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


From fweimer at openjdk.java.net  Sat Dec 11 15:42:13 2021
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Sat, 11 Dec 2021 15:42:13 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v10]
In-Reply-To: <QRUBo-CBnbOHM6QInZZCEmm29oCHqXpEcN6cQ9RtlYY=.c35297c9-c808-4ea0-84e0-26b4eb612b57@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <WQrjSwcX4oJYHIWr2rcKgvs4mw-hS9jGcRubt36Xi_0=.ada0810c-aad6-49b5-8e6a-f1e2f5fd7cc6@github.com>
 <QRUBo-CBnbOHM6QInZZCEmm29oCHqXpEcN6cQ9RtlYY=.c35297c9-c808-4ea0-84e0-26b4eb612b57@github.com>
Message-ID: <Jfuqhe1TwVXGdXHzRk7OU2LL5QOEV2cA_b6DzU2G6Hs=.ce7ecd6b-5f9a-40b3-ae11-32e6c4b3fb97@github.com>

On Sat, 11 Dec 2021 14:05:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove BSD/Apple specific code
>
> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 122:
> 
>> 120:           "It cannot be used with OnSpinWaitInst=none.")                \
>> 121:           range(1, 99)                                                  \
>> 122:   product(bool, UseROPProtection, false,                                \
> 
> Question: this is called "UseROPProtection", the configure option is called "enable-branch-protection", and GCC option is called "-mbranch-protection". This is confusing. I would have thought we would want the same name, and use it for all branch protection. So why is this not "UseBranchProtection"?

`-mbranch-protection` switches on both PAC-RET and BTI. This PR only covers a use of PAC that looks very ROP-focused to me.

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

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


From aph at openjdk.java.net  Sun Dec 12 10:22:16 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sun, 12 Dec 2021 10:22:16 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v10]
In-Reply-To: <Jfuqhe1TwVXGdXHzRk7OU2LL5QOEV2cA_b6DzU2G6Hs=.ce7ecd6b-5f9a-40b3-ae11-32e6c4b3fb97@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <WQrjSwcX4oJYHIWr2rcKgvs4mw-hS9jGcRubt36Xi_0=.ada0810c-aad6-49b5-8e6a-f1e2f5fd7cc6@github.com>
 <QRUBo-CBnbOHM6QInZZCEmm29oCHqXpEcN6cQ9RtlYY=.c35297c9-c808-4ea0-84e0-26b4eb612b57@github.com>
 <Jfuqhe1TwVXGdXHzRk7OU2LL5QOEV2cA_b6DzU2G6Hs=.ce7ecd6b-5f9a-40b3-ae11-32e6c4b3fb97@github.com>
Message-ID: <DWx_HJ1cf65G-hxGGXLyEX9AdZireGcKr20BYxeEXkw=.d6802b9f-f474-422d-9c17-0b5a9406e05c@github.com>

On Sat, 11 Dec 2021 15:39:24 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 122:
>> 
>>> 120:           "It cannot be used with OnSpinWaitInst=none.")                \
>>> 121:           range(1, 99)                                                  \
>>> 122:   product(bool, UseROPProtection, false,                                \
>> 
>> Question: this is called "UseROPProtection", the configure option is called "enable-branch-protection", and GCC option is called "-mbranch-protection". This is confusing. I would have thought we would want the same name, and use it for all branch protection. So why is this not "UseBranchProtection"?
>
> `-mbranch-protection` switches on both PAC-RET and BTI. This PR only covers a use of PAC that looks very ROP-focused to me.

True, because we don't (yet) support BTI. Is there any point having two separate flags for BTI and PAC-RET? If someone wants one, they'll very likely want the other, won't they?

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

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


From dholmes at openjdk.java.net  Mon Dec 13 06:02:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Dec 2021 06:02:23 GMT
Subject: RFR: 8278275: Initial nroff manpage generation for JDK 19
Message-ID: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>

Trivial update to change the version to 19-ea, and update the single reference to the "current release".

Content changes for 19 will follow.

Thanks,
David

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

Commit messages:
 - 8278275:Initial nroff manpage generation for JDK 19

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

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


From dholmes at openjdk.java.net  Mon Dec 13 06:02:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Dec 2021 06:02:23 GMT
Subject: RFR: 8278275: Initial nroff manpage generation for JDK 19
In-Reply-To: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
References: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
Message-ID: <jC_cA6XJ_Dg7cpNuhDgAjeaBRjdk_saFcRmtsHcgv1Q=.f94897c9-b9d5-420c-92c6-05166b4e34ab@github.com>

On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Trivial update to change the version to 19-ea, and update the single reference to the "current release".
> 
> Content changes for 19 will follow.
> 
> Thanks,
> David

This "mechanical" update is just being sent to the build mailing list for review.

Paging @jonathan-gibbons too :)

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

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


From duke at openjdk.java.net  Mon Dec 13 09:53:17 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 13 Dec 2021 09:53:17 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v10]
In-Reply-To: <DWx_HJ1cf65G-hxGGXLyEX9AdZireGcKr20BYxeEXkw=.d6802b9f-f474-422d-9c17-0b5a9406e05c@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <WQrjSwcX4oJYHIWr2rcKgvs4mw-hS9jGcRubt36Xi_0=.ada0810c-aad6-49b5-8e6a-f1e2f5fd7cc6@github.com>
 <QRUBo-CBnbOHM6QInZZCEmm29oCHqXpEcN6cQ9RtlYY=.c35297c9-c808-4ea0-84e0-26b4eb612b57@github.com>
 <Jfuqhe1TwVXGdXHzRk7OU2LL5QOEV2cA_b6DzU2G6Hs=.ce7ecd6b-5f9a-40b3-ae11-32e6c4b3fb97@github.com>
 <DWx_HJ1cf65G-hxGGXLyEX9AdZireGcKr20BYxeEXkw=.d6802b9f-f474-422d-9c17-0b5a9406e05c@github.com>
Message-ID: <uscb8oOymcqvhrNvRWgJq25csKYtUjbwF-Ryae7596U=.74ce11bf-77eb-45c7-976a-834ec6648bad@github.com>

On Sun, 12 Dec 2021 10:19:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> `-mbranch-protection` switches on both PAC-RET and BTI. This PR only covers a use of PAC that looks very ROP-focused to me.
>
> True, because we don't (yet) support BTI. Is there any point having two separate flags for BTI and PAC-RET? If someone wants one, they'll very likely want the other, won't they?

You can support one without the other.
The architecture allows you to have one without the other.
The GCC flag is an enum of "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on which cpu you specify to -mcpu (8.0,8.3,8.5 etc).
Clang has the same flags. Interestingly, on MacOS Clang, -mbranch-protection is available but it'll give incorrect code. Instead you build with -arch arm64e.

If your system had both, the only scenario I could see for only wanting just one would be for test/dev purposes. In a real production scenario you would want everything the system supports or nothing.

An earlier version of my code had a UseBranchProtection="pac|bti|pac+bti|all|none" style option

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

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


From aph at openjdk.java.net  Mon Dec 13 10:00:18 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 13 Dec 2021 10:00:18 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v10]
In-Reply-To: <uscb8oOymcqvhrNvRWgJq25csKYtUjbwF-Ryae7596U=.74ce11bf-77eb-45c7-976a-834ec6648bad@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <WQrjSwcX4oJYHIWr2rcKgvs4mw-hS9jGcRubt36Xi_0=.ada0810c-aad6-49b5-8e6a-f1e2f5fd7cc6@github.com>
 <QRUBo-CBnbOHM6QInZZCEmm29oCHqXpEcN6cQ9RtlYY=.c35297c9-c808-4ea0-84e0-26b4eb612b57@github.com>
 <Jfuqhe1TwVXGdXHzRk7OU2LL5QOEV2cA_b6DzU2G6Hs=.ce7ecd6b-5f9a-40b3-ae11-32e6c4b3fb97@github.com>
 <DWx_HJ1cf65G-hxGGXLyEX9AdZireGcKr20BYxeEXkw=.d6802b9f-f474-422d-9c17-0b5a9406e05c@github.com>
 <uscb8oOymcqvhrNvRWgJq25csKYtUjbwF-Ryae7596U=.74ce11bf-77eb-45c7-976a-834ec6648bad@github.com>
Message-ID: <kV4VzIZaqjvZMU7gOFCHkkA0XLY_P0pxRdnu9syNQHo=.ccd9add0-60cf-486c-816f-c6e99f21ae58@github.com>

On Mon, 13 Dec 2021 09:50:26 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> You can support one without the other. The architecture allows you to have one without the other. The GCC flag is an enum of "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on which cpu you specify to -mcpu (8.0,8.3,8.5 etc). Clang has the same flags. 

OK, so we have a precedent.

> If your system had both, the only scenario I could see for only wanting just one would be for test/dev purposes. In a real production scenario you would want everything the system supports or nothing.

Yes.

> An earlier version of my code had a UseBranchProtection="pac|bti|pac+bti|all|none" style option

That sounds great.

It seems to me that following the GCC/Clang precedent is the wisest thing we could do. I can see no possible advantage in diverging: it only confuses programmers.

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

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


From duke at openjdk.java.net  Mon Dec 13 11:52:20 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 13 Dec 2021 11:52:20 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v10]
In-Reply-To: <kV4VzIZaqjvZMU7gOFCHkkA0XLY_P0pxRdnu9syNQHo=.ccd9add0-60cf-486c-816f-c6e99f21ae58@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <WQrjSwcX4oJYHIWr2rcKgvs4mw-hS9jGcRubt36Xi_0=.ada0810c-aad6-49b5-8e6a-f1e2f5fd7cc6@github.com>
 <QRUBo-CBnbOHM6QInZZCEmm29oCHqXpEcN6cQ9RtlYY=.c35297c9-c808-4ea0-84e0-26b4eb612b57@github.com>
 <Jfuqhe1TwVXGdXHzRk7OU2LL5QOEV2cA_b6DzU2G6Hs=.ce7ecd6b-5f9a-40b3-ae11-32e6c4b3fb97@github.com>
 <DWx_HJ1cf65G-hxGGXLyEX9AdZireGcKr20BYxeEXkw=.d6802b9f-f474-422d-9c17-0b5a9406e05c@github.com>
 <uscb8oOymcqvhrNvRWgJq25csKYtUjbwF-Ryae7596U=.74ce11bf-77eb-45c7-976a-834ec6648bad@github.com>
 <kV4VzIZaqjvZMU7gOFCHkkA0XLY_P0pxRdnu9syNQHo=.ccd9add0-60cf-486c-816f-c6e99f21ae58@github.com>
Message-ID: <9LgothtcvZnEscN5EaEo_reN-J77pTeSzTwKrR8zgQk=.723b7b37-cf5f-4746-a910-7d99df07749e@github.com>

On Mon, 13 Dec 2021 09:56:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> You can support one without the other.
>> The architecture allows you to have one without the other.
>> The GCC flag is an enum of "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on which cpu you specify to -mcpu (8.0,8.3,8.5 etc).
>> Clang has the same flags. Interestingly, on MacOS Clang, -mbranch-protection is available but it'll give incorrect code. Instead you build with -arch arm64e.
>> 
>> If your system had both, the only scenario I could see for only wanting just one would be for test/dev purposes. In a real production scenario you would want everything the system supports or nothing.
>> 
>> An earlier version of my code had a UseBranchProtection="pac|bti|pac+bti|all|none" style option
>
>> You can support one without the other. The architecture allows you to have one without the other. The GCC flag is an enum of "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on which cpu you specify to -mcpu (8.0,8.3,8.5 etc). Clang has the same flags. 
> 
> OK, so we have a precedent.
> 
>> If your system had both, the only scenario I could see for only wanting just one would be for test/dev purposes. In a real production scenario you would want everything the system supports or nothing.
> 
> Yes.
> 
>> An earlier version of my code had a UseBranchProtection="pac|bti|pac+bti|all|none" style option
> 
> That sounds great.
> 
> It seems to me that following the GCC/Clang precedent is the wisest thing we could do. I can see no possible advantage in diverging: it only confuses programmers.

That gives us:

A new flag -XX:UseBranchProtection

With the options:
none - no PAC support. (Default)
standard - PAC support if the system supports it and the java binary was compiled with PAC. Otherwise off.
pac-ret - PAC support, regardless if the system supports it or the java binary was compiled with PAC.

A later BTI patch would add:
standard - also adds BTI if the system supports it and the java binary was compiled with BTI.
bti - BTI support, regardless if the system supports it or the java binary was compiled with BTI.
Also, concat the flags with "+". Eg: standard+bti. No need to do this until BTI is added.


For MacOS, you can only use PAC functionality when compiled for arm64e. Therefore arm64e would be supported by compiling the java binary for the arm64e and would always be enabled in that scenario. UseBranchProtection on MacoOS will only support the none option.

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

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


From fweimer at redhat.com  Mon Dec 13 13:21:23 2021
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 13 Dec 2021 14:21:23 +0100
Subject: glibc 2.12 support
Message-ID: <87ilvszlm4.fsf@oldenburg.str.redhat.com>

It seems that building against glibc 2.12 is still supported.  Is this
something that is still needed?

I'm mostly concerned with this fallback code on x86-64:

// Unfortunately we have to bring all these macros here from vsyscall.h
// to be able to compile on old linuxes.
  #define __NR_vgetcpu 2
  #define VSYSCALL_START (-10UL << 20)
  #define VSYSCALL_SIZE 1024
  #define VSYSCALL_ADDR(vsyscall_nr) (VSYSCALL_START+VSYSCALL_SIZE*(vsyscall_nr))
  typedef long (*vgetcpu_t)(unsigned int *cpu, unsigned int *node, unsigned long *tcache);
  vgetcpu_t vgetcpu = (vgetcpu_t)VSYSCALL_ADDR(__NR_vgetcpu);
  retval = vgetcpu(&cpu, NULL, NULL);

There is no way to check that the kernel actually supports vsyscall, and
on some kernels, this will crash because they have disabled vsyscall.

I would like to remove this or switch over to the system call (as
already used on i386).  This is fallback code only, so performance does
not really matter: on newer glibc (starting with 2.14), sched_getcpu
will be found, and it will use vDSO or rseq as appropriate.

Thanks,
Florian



From erikj at openjdk.java.net  Mon Dec 13 13:51:08 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 13 Dec 2021 13:51:08 GMT
Subject: RFR: 8278275: Initial nroff manpage generation for JDK 19
In-Reply-To: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
References: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
Message-ID: <ChhPQ4Lsi6FSkAiETAXFJLRDcwD8T8IgpfGV_VLaCpc=.37142fbb-cc8d-4978-acc3-231fa8fc0846@github.com>

On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Trivial update to change the version to 19-ea, and update the single reference to the "current release".
> 
> Content changes for 19 will follow.
> 
> Thanks,
> David

Looks good to me.

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

Marked as reviewed by erikj (Reviewer).

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


From erik.joelsson at oracle.com  Mon Dec 13 13:58:44 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 13 Dec 2021 05:58:44 -0800
Subject: glibc 2.12 support
In-Reply-To: <87ilvszlm4.fsf@oldenburg.str.redhat.com>
References: <87ilvszlm4.fsf@oldenburg.str.redhat.com>
Message-ID: <f530db55-bd47-69be-476b-80757ac9711b@oracle.com>

Hello Florian,

We still build with glibc 2.12 in the sysroot at Oracle as we still 
support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still 
need it.

/Erik

On 2021-12-13 05:21, Florian Weimer wrote:
> It seems that building against glibc 2.12 is still supported.  Is this
> something that is still needed?
>
> I'm mostly concerned with this fallback code on x86-64:
>
> // Unfortunately we have to bring all these macros here from vsyscall.h
> // to be able to compile on old linuxes.
>    #define __NR_vgetcpu 2
>    #define VSYSCALL_START (-10UL << 20)
>    #define VSYSCALL_SIZE 1024
>    #define VSYSCALL_ADDR(vsyscall_nr) (VSYSCALL_START+VSYSCALL_SIZE*(vsyscall_nr))
>    typedef long (*vgetcpu_t)(unsigned int *cpu, unsigned int *node, unsigned long *tcache);
>    vgetcpu_t vgetcpu = (vgetcpu_t)VSYSCALL_ADDR(__NR_vgetcpu);
>    retval = vgetcpu(&cpu, NULL, NULL);
>
> There is no way to check that the kernel actually supports vsyscall, and
> on some kernels, this will crash because they have disabled vsyscall.
>
> I would like to remove this or switch over to the system call (as
> already used on i386).  This is fallback code only, so performance does
> not really matter: on newer glibc (starting with 2.14), sched_getcpu
> will be found, and it will use vDSO or rseq as appropriate.
>
> Thanks,
> Florian
>


From fweimer at redhat.com  Mon Dec 13 15:38:31 2021
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 13 Dec 2021 16:38:31 +0100
Subject: glibc 2.12 support
In-Reply-To: <f530db55-bd47-69be-476b-80757ac9711b@oracle.com> (erik
 joelsson's message of "Mon, 13 Dec 2021 05:58:44 -0800")
References: <87ilvszlm4.fsf@oldenburg.str.redhat.com>
 <f530db55-bd47-69be-476b-80757ac9711b@oracle.com>
Message-ID: <87mtl4y0p4.fsf@oldenburg.str.redhat.com>

* erik joelsson:

> Hello Florian,
>
> We still build with glibc 2.12 in the sysroot at Oracle as we still
> support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still 
> need it.

Fair enough.  I will tack another thing to the side of this then. 8->

Thanks,
Florian



From jjg at openjdk.java.net  Mon Dec 13 16:33:21 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 13 Dec 2021 16:33:21 GMT
Subject: RFR: 8278275: Initial nroff manpage generation for JDK 19
In-Reply-To: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
References: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
Message-ID: <17fCdvTJndvbz78MdjblBn-Y9_19Vg2uTGXKXrul0A4=.872bba6c-30de-4ef5-9aad-06e4b7c75dac@github.com>

On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Trivial update to change the version to 19-ea, and update the single reference to the "current release".
> 
> Content changes for 19 will follow.
> 
> Thanks,
> David

Marked as reviewed by jjg (Reviewer).

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

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


From iris at openjdk.java.net  Mon Dec 13 17:07:14 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 13 Dec 2021 17:07:14 GMT
Subject: RFR: 8278275: Initial nroff manpage generation for JDK 19
In-Reply-To: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
References: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
Message-ID: <lNOQHaaswt5NZXCfjfuCz9fm9QA1OanxhDDF2VUKrAM=.039ab7eb-510e-4330-a8fc-2a2aed722870@github.com>

On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Trivial update to change the version to 19-ea, and update the single reference to the "current release".
> 
> Content changes for 19 will follow.
> 
> Thanks,
> David

Marked as reviewed by iris (Reviewer).

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

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


From dholmes at openjdk.java.net  Mon Dec 13 21:40:21 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Dec 2021 21:40:21 GMT
Subject: RFR: 8278275: Initial nroff manpage generation for JDK 19
In-Reply-To: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
References: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
Message-ID: <nz4JUW6tbjJjbRt5FUr9v0aO57lgf33Xj9nSUs12944=.29e8ca56-6613-4748-b901-edab8566e62f@github.com>

On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Trivial update to change the version to 19-ea, and update the single reference to the "current release".
> 
> Content changes for 19 will follow.
> 
> Thanks,
> David

Thanks for the reviews Erik, Jon and Iris!

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

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


From dholmes at openjdk.java.net  Mon Dec 13 21:40:22 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Dec 2021 21:40:22 GMT
Subject: Integrated: 8278275: Initial nroff manpage generation for JDK 19
In-Reply-To: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
References: <dg5k4IU3DLjCVMbWj98U-XQ3aTGBKfQb1uLLcRXw54M=.3a98d242-4202-4598-bfad-f5af7540e543@github.com>
Message-ID: <8UVOV6FsDdOrk2AfOb91is5bloex_1XMgUddiZ1_Pa4=.9c8e6e6f-a4df-4873-bb28-424003bc2d37@github.com>

On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Trivial update to change the version to 19-ea, and update the single reference to the "current release".
> 
> Content changes for 19 will follow.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 624f3094
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/624f3094b89976a0be0a1d1d4ce304f4be38fb9e
Stats:     29 lines in 28 files changed: 0 ins; 0 del; 29 mod

8278275: Initial nroff manpage generation for JDK 19

Reviewed-by: erikj, jjg, iris

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

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


From duke at openjdk.java.net  Tue Dec 14 09:40:03 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Tue, 14 Dec 2021 09:40:03 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v11]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <imt57f8ms-TPW030GNf47ixU_zxpIH785uty3hM7G9s=.0d6c08c0-3b2f-440b-add2-1614698078b8@github.com>

> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value when it is loaded back from the stack. If an
> attacker were to try to change control flow by editing the stack then
> the authentication check of the Link Register will fail, causing a
> segfault when the function returns.
> 
> On a system with PAC enabled, it is expected that all applications will
> be compiled with ROP protection. Fedora 33 and upwards already provide
> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
> PAC instructions that exist in the NOP space - on hardware without PAC,
> these instructions act as NOPs, allowing backward compatibility for
> negligible performance cost (2 NOPs per non-leaf function).
> 
> Hardware is currently limited to the Apple M1 MacBooks. All testing has
> been done within a Fedora Docker image. A run of SpecJVM showed no
> difference to that of noise - which was surprising.
> 
> The most important part of this patch is simply compiling using branch
> protection provided by GCC/LLVM. This protects all C++ code from being
> used in ROP attacks, removing all static ROP gadgets from use.
> 
> The remainder of the patch adds ROP protection to runtime generated
> code, in both stubs and compiled Java code. Attacks here are much harder
> as ROP gadgets must be found dynamically at runtime. If/when AOT
> compilation is added to JDK, then all stubs and compiled Java will be
> susceptible ROP gadgets being found by static analysis and therefore
> potentially as vulnerable as C++ code.
> 
> There are a number of places where the VM changes control flow by
> rewriting the stack or otherwise. I?ve done some analysis as to how
> these could also be used for attacks (which I didn?t want to post here).
> These areas can be protected ensuring the pointers to various stubs and
> entry points are stored in memory as signed pointers. These changes are
> simple to make (they can be reduced to a type change in common code and
> a few addition sign/auth calls in the backend), but there a lot of them
> and the total code change is fairly large. I?m happy to provide a few
> work in progress patches.
> 
> In order to match the security benefits of the Apple Arm64e ABI across
> the whole of JDK, then all the changes mentioned above would be
> required.

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

  Change UseROPProtection to UseBranchProtection
  
  Change-Id: I31c5e1bb5c285262f262459c13057a46221682f1
  CustomizedGitHooks: yes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/63f7515f..9c4f3498

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

  Stats: 41 lines in 7 files changed: 15 ins; 7 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6334.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6334/head:pull/6334

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


From duke at openjdk.java.net  Tue Dec 14 09:40:04 2021
From: duke at openjdk.java.net (Alan Hayward)
Date: Tue, 14 Dec 2021 09:40:04 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v10]
In-Reply-To: <9LgothtcvZnEscN5EaEo_reN-J77pTeSzTwKrR8zgQk=.723b7b37-cf5f-4746-a910-7d99df07749e@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <WQrjSwcX4oJYHIWr2rcKgvs4mw-hS9jGcRubt36Xi_0=.ada0810c-aad6-49b5-8e6a-f1e2f5fd7cc6@github.com>
 <QRUBo-CBnbOHM6QInZZCEmm29oCHqXpEcN6cQ9RtlYY=.c35297c9-c808-4ea0-84e0-26b4eb612b57@github.com>
 <Jfuqhe1TwVXGdXHzRk7OU2LL5QOEV2cA_b6DzU2G6Hs=.ce7ecd6b-5f9a-40b3-ae11-32e6c4b3fb97@github.com>
 <DWx_HJ1cf65G-hxGGXLyEX9AdZireGcKr20BYxeEXkw=.d6802b9f-f474-422d-9c17-0b5a9406e05c@github.com>
 <uscb8oOymcqvhrNvRWgJq25csKYtUjbwF-Ryae7596U=.74ce11bf-77eb-45c7-976a-834ec6648bad@github.com>
 <kV4VzIZaqjvZMU7gOFCHkkA0XLY_P0pxRdnu9syNQHo=.ccd9add0-60cf-486c-816f-c6e99f21ae58@github.com>
 <9LgothtcvZnEscN5EaEo_reN-J77pTeSzTwKrR8zgQk=.723b7b37-cf5f-4746-a910-7d99df07749e@github.com>
Message-ID: <xC9RM7ihPNSDL1DXR8REPHONWFG3s9FCCYOuh3sfmo4=.e92d82ee-f4a3-49fd-b97a-f773271c0bc2@github.com>

On Mon, 13 Dec 2021 11:48:52 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>>> You can support one without the other. The architecture allows you to have one without the other. The GCC flag is an enum of "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on which cpu you specify to -mcpu (8.0,8.3,8.5 etc). Clang has the same flags. 
>> 
>> OK, so we have a precedent.
>> 
>>> If your system had both, the only scenario I could see for only wanting just one would be for test/dev purposes. In a real production scenario you would want everything the system supports or nothing.
>> 
>> Yes.
>> 
>>> An earlier version of my code had a UseBranchProtection="pac|bti|pac+bti|all|none" style option
>> 
>> That sounds great.
>> 
>> It seems to me that following the GCC/Clang precedent is the wisest thing we could do. I can see no possible advantage in diverging: it only confuses programmers.
>
> That gives us:
> 
> A new flag -XX:UseBranchProtection
> 
> With the options:
> none - no PAC support. (Default)
> standard - PAC support if the system supports it and the java binary was compiled with PAC. Otherwise off.
> pac-ret - PAC support, regardless if the system supports it or the java binary was compiled with PAC.
> 
> A later BTI patch would add:
> standard - also adds BTI if the system supports it and the java binary was compiled with BTI.
> bti - BTI support, regardless if the system supports it or the java binary was compiled with BTI.
> Also, concat the flags with "+". Eg: standard+bti. No need to do this until BTI is added.
> 
> 
> For MacOS, you can only use PAC functionality when compiled for arm64e. Therefore arm64e would be supported by compiling the java binary for the arm64e and would always be enabled in that scenario. UseBranchProtection on MacoOS will only support the none option.

Updated to the above. The CSR will need an update too.

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

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


From aph at openjdk.java.net  Tue Dec 14 10:16:24 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 14 Dec 2021 10:16:24 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v11]
In-Reply-To: <imt57f8ms-TPW030GNf47ixU_zxpIH785uty3hM7G9s=.0d6c08c0-3b2f-440b-add2-1614698078b8@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <imt57f8ms-TPW030GNf47ixU_zxpIH785uty3hM7G9s=.0d6c08c0-3b2f-440b-add2-1614698078b8@github.com>
Message-ID: <o0fvpgC5C0msamZYPEbsg0Oc-LlrrzvlnlseK1hVcEY=.726e70e7-18c2-4a24-86af-ffbef65efe31@github.com>

On Tue, 14 Dec 2021 09:40:03 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value when it is loaded back from the stack. If an
>> attacker were to try to change control flow by editing the stack then
>> the authentication check of the Link Register will fail, causing a
>> segfault when the function returns.
>> 
>> On a system with PAC enabled, it is expected that all applications will
>> be compiled with ROP protection. Fedora 33 and upwards already provide
>> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
>> PAC instructions that exist in the NOP space - on hardware without PAC,
>> these instructions act as NOPs, allowing backward compatibility for
>> negligible performance cost (2 NOPs per non-leaf function).
>> 
>> Hardware is currently limited to the Apple M1 MacBooks. All testing has
>> been done within a Fedora Docker image. A run of SpecJVM showed no
>> difference to that of noise - which was surprising.
>> 
>> The most important part of this patch is simply compiling using branch
>> protection provided by GCC/LLVM. This protects all C++ code from being
>> used in ROP attacks, removing all static ROP gadgets from use.
>> 
>> The remainder of the patch adds ROP protection to runtime generated
>> code, in both stubs and compiled Java code. Attacks here are much harder
>> as ROP gadgets must be found dynamically at runtime. If/when AOT
>> compilation is added to JDK, then all stubs and compiled Java will be
>> susceptible ROP gadgets being found by static analysis and therefore
>> potentially as vulnerable as C++ code.
>> 
>> There are a number of places where the VM changes control flow by
>> rewriting the stack or otherwise. I?ve done some analysis as to how
>> these could also be used for attacks (which I didn?t want to post here).
>> These areas can be protected ensuring the pointers to various stubs and
>> entry points are stored in memory as signed pointers. These changes are
>> simple to make (they can be reduced to a type change in common code and
>> a few addition sign/auth calls in the backend), but there a lot of them
>> and the total code change is fairly large. I?m happy to provide a few
>> work in progress patches.
>> 
>> In order to match the security benefits of the Apple Arm64e ABI across
>> the whole of JDK, then all the changes mentioned above would be
>> required.
>
> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change UseROPProtection to UseBranchProtection
>   
>   Change-Id: I31c5e1bb5c285262f262459c13057a46221682f1
>   CustomizedGitHooks: yes

Looks fine. I've done some basic testing on Graviton 3, which all seems to work.

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

Marked as reviewed by aph (Reviewer).

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


From anamarsh at microsoft.com  Wed Dec 15 20:27:23 2021
From: anamarsh at microsoft.com (Ana Marsh)
Date: Wed, 15 Dec 2021 20:27:23 +0000
Subject: Requiring a New Minimum VS Version for Windows/ARM64
Message-ID: <DM5PR21MB0186E4347E0DB9C10F9AB331CA769@DM5PR21MB0186.namprd21.prod.outlook.com>

Hello,

My name is Ana Marsh and I am a Software Engineer at Microsoft on the Java Engineering team. A few of my colleagues worked on the Windows AArch64 support commit <https://github.com/openjdk/jdk/commit/9604ee82690f89320614b37bfef4178abc869777#diff-f18c276bab77ace41193e6fb0b80752e18b8409815bd46546f936908ba10009f> in 2020 and now I am looking to revert one of their changes. Specifically, the change to src/hotspot/share/gc/g1/g1HeapRegionAttr.hpp. This change to g1HeapRegionAttr.hpp was added to provide a workaround for this MSVC bug<https://developercommunity.visualstudio.com/t/arm64-bad-code-generation-around-signed-char-arith/1079221> that has now been fixed in VS 16.8 and newer. As it stands now, Windows/ARM64 users must already be using VS 2019<https://github.com/microsoft/openjdk-aarch64#build-dependencies> (VS 16.0+), so reverting this change would consequently require users to have one of the last four minor versions of VS 2019 (16.8, 16.9, 16.10, 16.11) or VS 2022 (17.0+) with its release last month.

I wanted to communicate this future change before submitting a Pull Request. I also plan on documenting the minimum required VS version for ARM64 in a comment in the build scripts. Let me know if you have any questions or concerns.

Best,

Ana



From erik.joelsson at oracle.com  Wed Dec 15 20:41:02 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 15 Dec 2021 12:41:02 -0800
Subject: Requiring a New Minimum VS Version for Windows/ARM64
In-Reply-To: <DM5PR21MB0186E4347E0DB9C10F9AB331CA769@DM5PR21MB0186.namprd21.prod.outlook.com>
References: <DM5PR21MB0186E4347E0DB9C10F9AB331CA769@DM5PR21MB0186.namprd21.prod.outlook.com>
Message-ID: <93950d0b-0a47-f44a-5bcb-ccd274a4053d@oracle.com>

Hello Ana,

This all sounds good to me. Adding something about this in 
doc/building.* would be nice.

/Erik

On 2021-12-15 12:27, Ana Marsh wrote:
> Hello,
>
> My name is Ana Marsh and I am a Software Engineer at Microsoft on the Java Engineering team. A few of my colleagues worked on the Windows AArch64 support commit <https://github.com/openjdk/jdk/commit/9604ee82690f89320614b37bfef4178abc869777#diff-f18c276bab77ace41193e6fb0b80752e18b8409815bd46546f936908ba10009f> in 2020 and now I am looking to revert one of their changes. Specifically, the change to src/hotspot/share/gc/g1/g1HeapRegionAttr.hpp. This change to g1HeapRegionAttr.hpp was added to provide a workaround for this MSVC bug<https://developercommunity.visualstudio.com/t/arm64-bad-code-generation-around-signed-char-arith/1079221> that has now been fixed in VS 16.8 and newer. As it stands now, Windows/ARM64 users must already be using VS 2019<https://github.com/microsoft/openjdk-aarch64#build-dependencies> (VS 16.0+), so reverting this change would consequently require users to have one of the last four minor versions of VS 2019 (16.8, 16.9, 16.10, 16.11) or VS 2022 (17.0+) with its release last month.
>
> I wanted to communicate this future change before submitting a Pull Request. I also plan on documenting the minimum required VS version for ARM64 in a comment in the build scripts. Let me know if you have any questions or concerns.
>
> Best,
>
> Ana
>

From aleonard at openjdk.java.net  Fri Dec 17 09:26:52 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 17 Dec 2021 09:26:52 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars and
 jmods using --date
Message-ID: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>

If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
Validating the boot jdk supports --date for the building of the jars.

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

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

Commit messages:
 - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date

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

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


From ihse at openjdk.java.net  Fri Dec 17 11:21:25 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 17 Dec 2021 11:21:25 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date
In-Reply-To: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
Message-ID: <qr0gnjSoRmYeVGMNfl4Tx6I8cicyGg4ALP8YcV7tNak=.703496b7-c987-40ac-9934-ac66739091ab@github.com>

On Fri, 17 Dec 2021 09:18:03 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
> Validating the boot jdk supports --date for the building of the jars.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

make/common/MakeBase.gmk line 145:

> 143: # If reproducible builds are enabled then set SOURCE_DATE_ISO_8601 string variable
> 144: ifeq ($(ENABLE_REPRODUCIBLE_BUILD), true)
> 145:   SOURCE_DATE_ISO_8601 := $(shell $(DATE) --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)

This should be set up by the configure script. Look for where we are currently doing the SOURCE_DATE_EPOCH stuff.

Also consider the possibility to *just* use this variable, and pass it on to jar if it is present, and not if it's missing. That way you can get rid of the redundant boolean variable.

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

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


From gdub at openjdk.java.net  Fri Dec 17 11:46:41 2021
From: gdub at openjdk.java.net (Gilles Duboscq)
Date: Fri, 17 Dec 2021 11:46:41 GMT
Subject: RFR: 8278954: Using clang together with devkit on linux doesn't work
 for building
Message-ID: <BGcdQrSL5nFZlNBXlYpzUP8572rIZ6hiRCmH_8aa-1A=.1788f526-8166-4539-87b6-88f1bd5e2e61@github.com>

When running `configure`, using `--with-devkit=` to point to a typical linux devkit along with `--with-toolchain-path=` and `--with-toolchain-type=clang` to point to a clang-based toolchain results in:

configure:75064: checking whether the C compiler works
configure:75086: /dl/tools/clang -m64 -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot -m64 -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot conftest.c >&5
d.lld: error: cannot open crt1.o: No such file or directory
ld.lld: error: cannot open crti.o: No such file or directory
ld.lld: error: cannot open crtbegin.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lc
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtend.o: No such file or directory
ld.lld: error: cannot open crtn.o: No such file or directory
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
``` 
This is because clang is unable to locate the gcc installation from the devkit.
The gcc toolchain is not in the location clang expects in the sysroot (that's not how our devkits are structured).
Note that it might go unnoticed on machines that have gcc installed because clang will fallback to system-global locations.

We can help clang by letting it now about the gcc location in the devkit with `--gcc-toolchain=`.
However that's not enough and we then get:

ld.lld: error: cannot open crt1.o: No such file or directory
ld.lld: error: cannot open crti.o: No such file or directory
ld.lld: error: unable to find library -lc
ld.lld: error: cannot open crtn.o: No such file or directory

clang was able to locate the gcc support libraries but is not able to locate required system libraries.
That's because `-isysroot` is not intended for libraries (only headers) but also because `-isysroot` has no effect for clang on linux (see [llvm#11503](https://bugs.llvm.org/show_bug.cgi?id=11503)).
Using `--sysroot=` in this case (clang on linux) resolves this issue.

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

Commit messages:
 - 8278954: Using clang together with devkit on linux doesn't work for building

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

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


From erikj at openjdk.java.net  Fri Dec 17 13:38:19 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 17 Dec 2021 13:38:19 GMT
Subject: RFR: 8278954: Using clang together with devkit on linux doesn't
 work for building
In-Reply-To: <BGcdQrSL5nFZlNBXlYpzUP8572rIZ6hiRCmH_8aa-1A=.1788f526-8166-4539-87b6-88f1bd5e2e61@github.com>
References: <BGcdQrSL5nFZlNBXlYpzUP8572rIZ6hiRCmH_8aa-1A=.1788f526-8166-4539-87b6-88f1bd5e2e61@github.com>
Message-ID: <0Z0L77FshWgfJ9cAabHAAnCC2FrFNP12A4DSwRM49lE=.ca0861cf-6aca-46fb-80cf-dae5b44b7121@github.com>

On Fri, 17 Dec 2021 11:27:43 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

> When running `configure`, using `--with-devkit=` to point to a typical linux devkit along with `--with-toolchain-path=` and `--with-toolchain-type=clang` to point to a clang-based toolchain results in:
> 
> configure:75064: checking whether the C compiler works
> configure:75086: /dl/tools/clang -m64 -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot -m64 -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot conftest.c >&5
> d.lld: error: cannot open crt1.o: No such file or directory
> ld.lld: error: cannot open crti.o: No such file or directory
> ld.lld: error: cannot open crtbegin.o: No such file or directory
> ld.lld: error: unable to find library -lgcc
> ld.lld: error: unable to find library -lgcc_s
> ld.lld: error: unable to find library -lc
> ld.lld: error: unable to find library -lgcc
> ld.lld: error: unable to find library -lgcc_s
> ld.lld: error: cannot open crtend.o: No such file or directory
> ld.lld: error: cannot open crtn.o: No such file or directory
> clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
> ``` 
> This is because clang is unable to locate the gcc installation from the devkit.
> The gcc toolchain is not in the location clang expects in the sysroot (that's not how our devkits are structured).
> Note that it might go unnoticed on machines that have gcc installed because clang will fallback to system-global locations.
> 
> We can help clang by letting it now about the gcc location in the devkit with `--gcc-toolchain=`.
> However that's not enough and we then get:
> 
> ld.lld: error: cannot open crt1.o: No such file or directory
> ld.lld: error: cannot open crti.o: No such file or directory
> ld.lld: error: unable to find library -lc
> ld.lld: error: cannot open crtn.o: No such file or directory
> 
> clang was able to locate the gcc support libraries but is not able to locate required system libraries.
> That's because `-isysroot` is not intended for libraries (only headers) but also because `-isysroot` has no effect for clang on linux (see [llvm#11503](https://bugs.llvm.org/show_bug.cgi?id=11503)).
> Using `--sysroot=` in this case (clang on linux) resolves this issue.

Marked as reviewed by erikj (Reviewer).

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

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


From gdub at openjdk.java.net  Fri Dec 17 13:51:19 2021
From: gdub at openjdk.java.net (Gilles Duboscq)
Date: Fri, 17 Dec 2021 13:51:19 GMT
Subject: RFR: 8278954: Using clang together with devkit on linux doesn't
 work for building
In-Reply-To: <0Z0L77FshWgfJ9cAabHAAnCC2FrFNP12A4DSwRM49lE=.ca0861cf-6aca-46fb-80cf-dae5b44b7121@github.com>
References: <BGcdQrSL5nFZlNBXlYpzUP8572rIZ6hiRCmH_8aa-1A=.1788f526-8166-4539-87b6-88f1bd5e2e61@github.com>
 <0Z0L77FshWgfJ9cAabHAAnCC2FrFNP12A4DSwRM49lE=.ca0861cf-6aca-46fb-80cf-dae5b44b7121@github.com>
Message-ID: <Gf_macb4vncj2Lz7nhaXmCmraD-idgQJElnhf5da_Ys=.9b59f49e-e468-458a-9eb1-3362bed559d3@github.com>

On Fri, 17 Dec 2021 13:35:04 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> When running `configure`, using `--with-devkit=` to point to a typical linux devkit along with `--with-toolchain-path=` and `--with-toolchain-type=clang` to point to a clang-based toolchain results in:
>> 
>> configure:75064: checking whether the C compiler works
>> configure:75086: /dl/tools/clang -m64 -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot -m64 -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot conftest.c >&5
>> d.lld: error: cannot open crt1.o: No such file or directory
>> ld.lld: error: cannot open crti.o: No such file or directory
>> ld.lld: error: cannot open crtbegin.o: No such file or directory
>> ld.lld: error: unable to find library -lgcc
>> ld.lld: error: unable to find library -lgcc_s
>> ld.lld: error: unable to find library -lc
>> ld.lld: error: unable to find library -lgcc
>> ld.lld: error: unable to find library -lgcc_s
>> ld.lld: error: cannot open crtend.o: No such file or directory
>> ld.lld: error: cannot open crtn.o: No such file or directory
>> clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
>> ``` 
>> This is because clang is unable to locate the gcc installation from the devkit.
>> The gcc toolchain is not in the location clang expects in the sysroot (that's not how our devkits are structured).
>> Note that it might go unnoticed on machines that have gcc installed because clang will fallback to system-global locations.
>> 
>> We can help clang by letting it now about the gcc location in the devkit with `--gcc-toolchain=`.
>> However that's not enough and we then get:
>> 
>> ld.lld: error: cannot open crt1.o: No such file or directory
>> ld.lld: error: cannot open crti.o: No such file or directory
>> ld.lld: error: unable to find library -lc
>> ld.lld: error: cannot open crtn.o: No such file or directory
>> 
>> clang was able to locate the gcc support libraries but is not able to locate required system libraries.
>> That's because `-isysroot` is not intended for libraries (only headers) but also because `-isysroot` has no effect for clang on linux (see [llvm#11503](https://bugs.llvm.org/show_bug.cgi?id=11503)).
>> Using `--sysroot=` in this case (clang on linux) resolves this issue.
>
> Marked as reviewed by erikj (Reviewer).

Thanks for the prompt review @erikj79!

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

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


From aleonard at openjdk.java.net  Fri Dec 17 13:54:19 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 17 Dec 2021 13:54:19 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date
In-Reply-To: <qr0gnjSoRmYeVGMNfl4Tx6I8cicyGg4ALP8YcV7tNak=.703496b7-c987-40ac-9934-ac66739091ab@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <qr0gnjSoRmYeVGMNfl4Tx6I8cicyGg4ALP8YcV7tNak=.703496b7-c987-40ac-9934-ac66739091ab@github.com>
Message-ID: <cQk-XSFq2LgdwfIpSAGFvLx1I0aNm6bUGhyMV34baIk=.1ace5924-d42e-48db-b260-bfdfcab942b8@github.com>

On Fri, 17 Dec 2021 11:18:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
>> Validating the boot jdk supports --date for the building of the jars.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/common/MakeBase.gmk line 145:
> 
>> 143: # If reproducible builds are enabled then set SOURCE_DATE_ISO_8601 string variable
>> 144: ifeq ($(ENABLE_REPRODUCIBLE_BUILD), true)
>> 145:   SOURCE_DATE_ISO_8601 := $(shell $(DATE) --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
> 
> This should be set up by the configure script. Look for where we are currently doing the SOURCE_DATE_EPOCH stuff.
> 
> Also consider the possibility to *just* use this variable, and pass it on to jar if it is present, and not if it's missing. That way you can get rid of the redundant boolean variable.

@magicus I looked at that, but the problem is SOURCE_DATE_EPOCH is set in InitSupport.gmk depending on whether SOURCE_DATE=="updated" : https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/make/InitSupport.gmk#L315
I also couldn't add it in InitSupport.gmk because that marco is not included from every place SetupJarArchive is resolved.
Thoughts?

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

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


From gdub at openjdk.java.net  Fri Dec 17 15:39:28 2021
From: gdub at openjdk.java.net (Gilles Duboscq)
Date: Fri, 17 Dec 2021 15:39:28 GMT
Subject: Integrated: 8278954: Using clang together with devkit on linux doesn't
 work for building
In-Reply-To: <BGcdQrSL5nFZlNBXlYpzUP8572rIZ6hiRCmH_8aa-1A=.1788f526-8166-4539-87b6-88f1bd5e2e61@github.com>
References: <BGcdQrSL5nFZlNBXlYpzUP8572rIZ6hiRCmH_8aa-1A=.1788f526-8166-4539-87b6-88f1bd5e2e61@github.com>
Message-ID: <g8fonE37JP7Uw_wl_cMH2ysxvDEuF7oj5q9Wbq_c4OY=.2ca7bca3-3180-499e-a808-bc2a52a7e63b@github.com>

On Fri, 17 Dec 2021 11:27:43 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

> When running `configure`, using `--with-devkit=` to point to a typical linux devkit along with `--with-toolchain-path=` and `--with-toolchain-type=clang` to point to a clang-based toolchain results in:
> 
> configure:75064: checking whether the C compiler works
> configure:75086: /dl/tools/clang -m64 -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot -m64 -isysroot /dl/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot conftest.c >&5
> d.lld: error: cannot open crt1.o: No such file or directory
> ld.lld: error: cannot open crti.o: No such file or directory
> ld.lld: error: cannot open crtbegin.o: No such file or directory
> ld.lld: error: unable to find library -lgcc
> ld.lld: error: unable to find library -lgcc_s
> ld.lld: error: unable to find library -lc
> ld.lld: error: unable to find library -lgcc
> ld.lld: error: unable to find library -lgcc_s
> ld.lld: error: cannot open crtend.o: No such file or directory
> ld.lld: error: cannot open crtn.o: No such file or directory
> clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
> ``` 
> This is because clang is unable to locate the gcc installation from the devkit.
> The gcc toolchain is not in the location clang expects in the sysroot (that's not how our devkits are structured).
> Note that it might go unnoticed on machines that have gcc installed because clang will fallback to system-global locations.
> 
> We can help clang by letting it now about the gcc location in the devkit with `--gcc-toolchain=`.
> However that's not enough and we then get:
> 
> ld.lld: error: cannot open crt1.o: No such file or directory
> ld.lld: error: cannot open crti.o: No such file or directory
> ld.lld: error: unable to find library -lc
> ld.lld: error: cannot open crtn.o: No such file or directory
> 
> clang was able to locate the gcc support libraries but is not able to locate required system libraries.
> That's because `-isysroot` is not intended for libraries (only headers) but also because `-isysroot` has no effect for clang on linux (see [llvm#11503](https://bugs.llvm.org/show_bug.cgi?id=11503)).
> Using `--sysroot=` in this case (clang on linux) resolves this issue.

This pull request has now been integrated.

Changeset: b17f8d5b
Author:    Gilles Duboscq <gdub at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b17f8d5b6c4d4ec75bb57f1d2009e30332bdb3ce
Stats:     15 lines in 1 file changed: 13 ins; 0 del; 2 mod

8278954: Using clang together with devkit on linux doesn't work for building

Reviewed-by: erikj

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

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


From ihse at openjdk.java.net  Fri Dec 17 16:32:26 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 17 Dec 2021 16:32:26 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date
In-Reply-To: <cQk-XSFq2LgdwfIpSAGFvLx1I0aNm6bUGhyMV34baIk=.1ace5924-d42e-48db-b260-bfdfcab942b8@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <qr0gnjSoRmYeVGMNfl4Tx6I8cicyGg4ALP8YcV7tNak=.703496b7-c987-40ac-9934-ac66739091ab@github.com>
 <cQk-XSFq2LgdwfIpSAGFvLx1I0aNm6bUGhyMV34baIk=.1ace5924-d42e-48db-b260-bfdfcab942b8@github.com>
Message-ID: <ci9J5BoqDgZudO4FAu8-DtA6uXcgHuAFi2p0C-3VWZA=.19aac980-5df7-436a-a4e8-a6695f77b7f5@github.com>

On Fri, 17 Dec 2021 13:51:28 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> make/common/MakeBase.gmk line 145:
>> 
>>> 143: # If reproducible builds are enabled then set SOURCE_DATE_ISO_8601 string variable
>>> 144: ifeq ($(ENABLE_REPRODUCIBLE_BUILD), true)
>>> 145:   SOURCE_DATE_ISO_8601 := $(shell $(DATE) --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
>> 
>> This should be set up by the configure script. Look for where we are currently doing the SOURCE_DATE_EPOCH stuff.
>> 
>> Also consider the possibility to *just* use this variable, and pass it on to jar if it is present, and not if it's missing. That way you can get rid of the redundant boolean variable.
>
> @magicus I looked at that, but the problem is SOURCE_DATE_EPOCH is set in InitSupport.gmk depending on whether SOURCE_DATE=="updated" : https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/make/InitSupport.gmk#L315
> I also couldn't add it in InitSupport.gmk because that marco is not included from every place SetupJarArchive is resolved.
> Thoughts?

Oh, that's ... interesting. (I'm pretty sure I wrote that code myself :))

I still think it would be good to keep the new code close to the old. If we set SOURCE_DATE to "updated", I think that should reflect in SOURCE_DATE_ISO_8601 as well. Maybe it does by the current design, but if it does, it could be more obvious.

I'm sorry I don't have any ready-made suggestion. :( I'm really on vacation now and can't really dive into this, so if you can't find any better solution, then this'll have to do.

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

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


From ihse at openjdk.java.net  Fri Dec 17 16:32:26 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 17 Dec 2021 16:32:26 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date
In-Reply-To: <ci9J5BoqDgZudO4FAu8-DtA6uXcgHuAFi2p0C-3VWZA=.19aac980-5df7-436a-a4e8-a6695f77b7f5@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <qr0gnjSoRmYeVGMNfl4Tx6I8cicyGg4ALP8YcV7tNak=.703496b7-c987-40ac-9934-ac66739091ab@github.com>
 <cQk-XSFq2LgdwfIpSAGFvLx1I0aNm6bUGhyMV34baIk=.1ace5924-d42e-48db-b260-bfdfcab942b8@github.com>
 <ci9J5BoqDgZudO4FAu8-DtA6uXcgHuAFi2p0C-3VWZA=.19aac980-5df7-436a-a4e8-a6695f77b7f5@github.com>
Message-ID: <90OeqZiTLSgTZJcd4iyu6LI8xb-8HKZlduABiVcTP4g=.10beb9dd-8106-4b86-a8c5-4f08b4614924@github.com>

On Fri, 17 Dec 2021 16:27:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @magicus I looked at that, but the problem is SOURCE_DATE_EPOCH is set in InitSupport.gmk depending on whether SOURCE_DATE=="updated" : https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/make/InitSupport.gmk#L315
>> I also couldn't add it in InitSupport.gmk because that marco is not included from every place SetupJarArchive is resolved.
>> Thoughts?
>
> Oh, that's ... interesting. (I'm pretty sure I wrote that code myself :))
> 
> I still think it would be good to keep the new code close to the old. If we set SOURCE_DATE to "updated", I think that should reflect in SOURCE_DATE_ISO_8601 as well. Maybe it does by the current design, but if it does, it could be more obvious.
> 
> I'm sorry I don't have any ready-made suggestion. :( I'm really on vacation now and can't really dive into this, so if you can't find any better solution, then this'll have to do.

But I think the code in InitSupport will be executed always; Init.gmk is our "bootstrapper" / "trampoline" which wraps all calls to make (and InitSupport.gmk contains gory implementation details of Init.gmk).

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

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


From erikj at openjdk.java.net  Fri Dec 17 17:59:24 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 17 Dec 2021 17:59:24 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date
In-Reply-To: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
Message-ID: <oeTN3EAyeJ3cnZAH76K3WwHQLcTqRTngywm6gjhn2A0=.6bca8025-3e49-41ed-b4c1-d824975a113c@github.com>

On Fri, 17 Dec 2021 09:18:03 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
> Validating the boot jdk supports --date for the building of the jars.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

make/common/JarArchive.gmk line 234:

> 232:     endif
> 233:   else
> 234:     $1_JAR_OPTIONS := $$($1_JAR_SOURCE_DATE)

Instead of adding $$($1_JAR_SOURCE_DATE) to every branch of this conditional, you can use += to build the $1_JAR_OPTIONS variable one step at a time. I don't think we need a separate variable JAR_SOURCE_DATE.

make/common/MakeBase.gmk line 148:

> 146:   ifeq ($(SOURCE_DATE_ISO_8601), )
> 147:     # GNU date format did not work, try BSD date options
> 148:     SOURCE_DATE_ISO_8601 := $(shell $(DATE) -u -j -f "%s" "$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)

Could we maybe figure out the date command line to use in configure instead to avoid the trial and error at build time?

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

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


From erikj at openjdk.java.net  Fri Dec 17 17:59:25 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 17 Dec 2021 17:59:25 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date
In-Reply-To: <90OeqZiTLSgTZJcd4iyu6LI8xb-8HKZlduABiVcTP4g=.10beb9dd-8106-4b86-a8c5-4f08b4614924@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <qr0gnjSoRmYeVGMNfl4Tx6I8cicyGg4ALP8YcV7tNak=.703496b7-c987-40ac-9934-ac66739091ab@github.com>
 <cQk-XSFq2LgdwfIpSAGFvLx1I0aNm6bUGhyMV34baIk=.1ace5924-d42e-48db-b260-bfdfcab942b8@github.com>
 <ci9J5BoqDgZudO4FAu8-DtA6uXcgHuAFi2p0C-3VWZA=.19aac980-5df7-436a-a4e8-a6695f77b7f5@github.com>
 <90OeqZiTLSgTZJcd4iyu6LI8xb-8HKZlduABiVcTP4g=.10beb9dd-8106-4b86-a8c5-4f08b4614924@github.com>
Message-ID: <6l5-OLoPG6_Jvih1_w3PcXZMO2GFZsnlP6ElaxUdoFg=.8b226e2d-659b-495b-99bc-14cdca0c3142@github.com>

On Fri, 17 Dec 2021 16:29:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Oh, that's ... interesting. (I'm pretty sure I wrote that code myself :))
>> 
>> I still think it would be good to keep the new code close to the old. If we set SOURCE_DATE to "updated", I think that should reflect in SOURCE_DATE_ISO_8601 as well. Maybe it does by the current design, but if it does, it could be more obvious.
>> 
>> I'm sorry I don't have any ready-made suggestion. :( I'm really on vacation now and can't really dive into this, so if you can't find any better solution, then this'll have to do.
>
> But I think the code in InitSupport will be executed always; Init.gmk is our "bootstrapper" / "trampoline" which wraps all calls to make (and InitSupport.gmk contains gory implementation details of Init.gmk).

SOURCE_DATE_EPOCH is initialized and exported in InitSupport.gmk so it's always available in the environment. We did this because we want various tools to pick this variable up from the environment, as this is a commonly expected variable name for doing so. The new variable SOURCE_DATE_ISO_8601 is a variant with a different format and there is no standard for reading this from the environment, so it's not as obvious that we should just export it the same way. 

On the other hand, we do not want to execute a shell expression every time we import MakeBase.gmk, so I would still vote for doing this in InitSupport.gmk and export SOURCE_DATE_ISO_8601.

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

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


From aleonard at openjdk.java.net  Fri Dec 17 20:07:26 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 17 Dec 2021 20:07:26 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date
In-Reply-To: <oeTN3EAyeJ3cnZAH76K3WwHQLcTqRTngywm6gjhn2A0=.6bca8025-3e49-41ed-b4c1-d824975a113c@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <oeTN3EAyeJ3cnZAH76K3WwHQLcTqRTngywm6gjhn2A0=.6bca8025-3e49-41ed-b4c1-d824975a113c@github.com>
Message-ID: <nPbPLbiQjmmKjnwOm2t3iNbOnFI0-NMUWRQLqvd-pkk=.783bab63-c2a2-4f7a-9b05-a7415db213b9@github.com>

On Fri, 17 Dec 2021 17:54:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
>> Validating the boot jdk supports --date for the building of the jars.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/common/MakeBase.gmk line 148:
> 
>> 146:   ifeq ($(SOURCE_DATE_ISO_8601), )
>> 147:     # GNU date format did not work, try BSD date options
>> 148:     SOURCE_DATE_ISO_8601 := $(shell $(DATE) -u -j -f "%s" "$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
> 
> Could we maybe figure out the date command line to use in configure instead to avoid the trial and error at build time?

I based this trial and error based on util.m4 code and copied the method, so yes I can store the result from then...

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

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


From aleonard at openjdk.java.net  Fri Dec 17 20:07:25 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 17 Dec 2021 20:07:25 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date
In-Reply-To: <6l5-OLoPG6_Jvih1_w3PcXZMO2GFZsnlP6ElaxUdoFg=.8b226e2d-659b-495b-99bc-14cdca0c3142@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <qr0gnjSoRmYeVGMNfl4Tx6I8cicyGg4ALP8YcV7tNak=.703496b7-c987-40ac-9934-ac66739091ab@github.com>
 <cQk-XSFq2LgdwfIpSAGFvLx1I0aNm6bUGhyMV34baIk=.1ace5924-d42e-48db-b260-bfdfcab942b8@github.com>
 <ci9J5BoqDgZudO4FAu8-DtA6uXcgHuAFi2p0C-3VWZA=.19aac980-5df7-436a-a4e8-a6695f77b7f5@github.com>
 <90OeqZiTLSgTZJcd4iyu6LI8xb-8HKZlduABiVcTP4g=.10beb9dd-8106-4b86-a8c5-4f08b4614924@github.com>
 <6l5-OLoPG6_Jvih1_w3PcXZMO2GFZsnlP6ElaxUdoFg=.8b226e2d-659b-495b-99bc-14cdca0c3142@github.com>
Message-ID: <Xk09u51L3IDFvELASWRjemQgmRxdYS6mhG-C91LsbEU=.d4da7da5-b2ea-4a5b-b12e-9e5aed110434@github.com>

On Fri, 17 Dec 2021 17:53:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> But I think the code in InitSupport will be executed always; Init.gmk is our "bootstrapper" / "trampoline" which wraps all calls to make (and InitSupport.gmk contains gory implementation details of Init.gmk).
>
> SOURCE_DATE_EPOCH is initialized and exported in InitSupport.gmk so it's always available in the environment. We did this because we want various tools to pick this variable up from the environment, as this is a commonly expected variable name for doing so. The new variable SOURCE_DATE_ISO_8601 is a variant with a different format and there is no standard for reading this from the environment, so it's not as obvious that we should just export it the same way. 
> 
> On the other hand, we do not want to execute a shell expression every time we import MakeBase.gmk, so I would still vote for doing this in InitSupport.gmk and export SOURCE_DATE_ISO_8601.

@erikj79 Interesting, I tried adding it to InitSupport.gmk, but it wasn't always set... odd, I will revisit, I probably did something wrong...! will give that another try, thanks

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

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


From aleonard at openjdk.java.net  Fri Dec 17 20:11:23 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 17 Dec 2021 20:11:23 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date
In-Reply-To: <90OeqZiTLSgTZJcd4iyu6LI8xb-8HKZlduABiVcTP4g=.10beb9dd-8106-4b86-a8c5-4f08b4614924@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <qr0gnjSoRmYeVGMNfl4Tx6I8cicyGg4ALP8YcV7tNak=.703496b7-c987-40ac-9934-ac66739091ab@github.com>
 <cQk-XSFq2LgdwfIpSAGFvLx1I0aNm6bUGhyMV34baIk=.1ace5924-d42e-48db-b260-bfdfcab942b8@github.com>
 <ci9J5BoqDgZudO4FAu8-DtA6uXcgHuAFi2p0C-3VWZA=.19aac980-5df7-436a-a4e8-a6695f77b7f5@github.com>
 <90OeqZiTLSgTZJcd4iyu6LI8xb-8HKZlduABiVcTP4g=.10beb9dd-8106-4b86-a8c5-4f08b4614924@github.com>
Message-ID: <9iDC1w4QBf7cAVBk6ofKHhpanhZF-8I0YeU9ZgxOLs0=.7ecaf76d-62ac-4e78-bbfc-766add0630a2@github.com>

On Fri, 17 Dec 2021 16:29:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Oh, that's ... interesting. (I'm pretty sure I wrote that code myself :))
>> 
>> I still think it would be good to keep the new code close to the old. If we set SOURCE_DATE to "updated", I think that should reflect in SOURCE_DATE_ISO_8601 as well. Maybe it does by the current design, but if it does, it could be more obvious.
>> 
>> I'm sorry I don't have any ready-made suggestion. :( I'm really on vacation now and can't really dive into this, so if you can't find any better solution, then this'll have to do.
>
> But I think the code in InitSupport will be executed always; Init.gmk is our "bootstrapper" / "trampoline" which wraps all calls to make (and InitSupport.gmk contains gory implementation details of Init.gmk).

@magicus don't worry, enjoy your holiday, I think @erik has pointed out it should work, so I probably made a mistake when I tried it...

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

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


From smarks at openjdk.java.net  Fri Dec 17 23:53:41 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 17 Dec 2021 23:53:41 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
Message-ID: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>

Enable the security manager in rmiregistry's launcher arguments.

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

Commit messages:
 - Add security manager property to rmiregistry launcher arguments.

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

PR: https://git.openjdk.java.net/jdk18/pull/45


From dholmes at openjdk.java.net  Sat Dec 18 00:43:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 18 Dec 2021 00:43:41 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <8ibvHIgXuqqV0tcgTnnqCH4a4EvarfU35CiT1ybPEjU=.49fee24f-cdeb-4718-922c-26f2370f3760@github.com>

On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Enable the security manager in rmiregistry's launcher arguments.

Hi Stuart,

I think specifying "allow" would be the behaviour preserving change here. That avoids any risk that enabling the SM earlier changes some behaviour during VM initialization.

Cheers,
David

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/45


From suenaga at oss.nttdata.com  Sat Dec 18 09:18:57 2021
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Sat, 18 Dec 2021 18:18:57 +0900
Subject: Internal Error in build process on Windows
Message-ID: <0861d0f3dbaeb3d0b2973ec0d5423e93@oss.nttdata.com>

Hi all,

I use Visual Studio 2022 (17.0.4) on WSL 1 Ubuntu to build OpenJDK for 
Windows on Windows 11.
I sometimes saw Internal Error in masm as following:

```
  Assembling: 
c:\github-forked\jdk\src\jdk.incubator.vector\windows\native\libjsvml\jsvml_d_cos_windows_x86.S

MASM : fatal error A1016: Internal error
```

I saw same errors in other asm files in jdk.incubator.vector .
I can finish build normally when I run `make` some times.
I guess it is a problem in masm, but I haven't found out the condition 
to reproduce, so I've not yet reported this problem to Microsoft 
community.

Have you ever seen similar errors? Please share if you know how to avoid 
this.


Thanks,

Yasumasa


From smarks at openjdk.java.net  Sat Dec 18 19:09:21 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Sat, 18 Dec 2021 19:09:21 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <8ibvHIgXuqqV0tcgTnnqCH4a4EvarfU35CiT1ybPEjU=.49fee24f-cdeb-4718-922c-26f2370f3760@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
 <8ibvHIgXuqqV0tcgTnnqCH4a4EvarfU35CiT1ybPEjU=.49fee24f-cdeb-4718-922c-26f2370f3760@github.com>
Message-ID: <hwya5p47RLVN7n-5XswXlrfpRwrNKyJEOniU5DUamk8=.f4eca881-fb4e-44cb-a544-4e967e626a76@github.com>

On Sat, 18 Dec 2021 00:40:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think specifying "allow" would be the behaviour preserving change here.

This is strictly true. I did think about doing this. However, I don't think it makes much of a practical difference. It's always been fully supported to enable the security manager using properties, and the rmiregistry main hardly does anything before enabling the security manager. As long as we're going to the trouble of setting a property to _allow_ the security manager, might as well _enable_ it at the same time, I think.

In addition, the warning messages emitted by enabling the security manager with the API are worse than those from the command line. Using the API gives this:


WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by sun.rmi.registry.RegistryImpl
WARNING: Please consider reporting this to the maintainers of sun.rmi.registry.RegistryImpl
WARNING: System::setSecurityManager will be removed in a future release


and using the property gives this:


WARNING: A command line option has enabled the Security Manager
WARNING: The Security Manager is deprecated and will be removed in a future release


Using the property gives a shorter warning and one that is less misleading (!) than the one from use of the API. (I mean, it's kind of ridiculous for the `rmiregistry` command to emit a message suggesting that something be reported to the maintainers of `RegistryImpl`. In some sense it would be good if there were a way to disable the warning, but I rate the likelihood of that occurring as low.)

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

PR: https://git.openjdk.java.net/jdk18/pull/45


From dholmes at openjdk.java.net  Sun Dec 19 05:56:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 19 Dec 2021 05:56:30 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <BY9i_NIEEFszX9L3TcQZn2IcP1mH8N_HD5soTwruV5g=.38b6091e-e954-4899-be6f-ca2b87bd4e76@github.com>

On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Enable the security manager in rmiregistry's launcher arguments.

My concern is that having the SM installed during part of VM initialization could lead to different behaviour compared to installing the SM after that. This may be a small risk but it is a risk, and not something we are likely to observe in our own testing.

If there is no way to hide those warning messages (@SuppressWarnings in the code?) then we have a serious flaw in our warning system. As you say these warnings are for the developer not the end user!

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

PR: https://git.openjdk.java.net/jdk18/pull/45


From alanb at openjdk.java.net  Sun Dec 19 07:40:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 19 Dec 2021 07:40:29 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <XCbGplub5NvbUblllEMQxytUHkXupGhgFKHw5yW8jmQ=.e33a3f0a-94cb-45ac-b2ef-b023da85a175@github.com>

On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Enable the security manager in rmiregistry's launcher arguments.

As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry -J-Djava.security.manager=allow` are equivalent because rmiregistry sets the default SM. Some difference may be observed if someone is running rmiregistry with a custom system class loader set, or custom file system provider, or running it with a JVM TI agent that is looking at events between VMStart and VMInit but these seem somewhat obscure scenarios for a command line program If rmiregstry worked with ToolProvider then I think there would be more to discuss. If the final patch is to have the launcher set the default security manager then we may want to change RegistryImpl.createRegistry to fail if not set.

The warning that is emitted for both cases is expected. JEP 411 is very clear that it there is no mechanism to suppress it. We may need to add a release note to document that rmiregistry will emit a warning a startup, that will at least be something to point at in the event that anyone asks or reports an issue.

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

PR: https://git.openjdk.java.net/jdk18/pull/45


From smarks at openjdk.java.net  Mon Dec 20 22:35:34 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 20 Dec 2021 22:35:34 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <oE3n-Qm346QGuezStReumP2mNEKVFlbLEussXV_C6kc=.5bc857bc-fd94-40e3-8513-1db06f320f6d@github.com>

On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Enable the security manager in rmiregistry's launcher arguments.

I think there's little to worry about with custom configurations of the `rmiregistry` tool. What somebody might do is to enable a customized security manager using properties... of course they'd also have to ensure that the customized SM is somewhere in the classpath as well, by adding more command line options. That seems fairly unlikely to me. Anyone who wants to run an RMI registry service in some specialized configuration would probably just set things up themselves and then use the `LocateRegistry.createRegistry` API instead of trying to tinker with the `rmiregistry` command.

If `rmiregistry` enables the SM using properties, then yes we can probably change the code to assert that the SM is running instead of conditionally enabling it like it does now.

Next headache is that `tools/launcher/VersionCheck.jtr` fails because it sees the warning messages instead of the version string. (Argh!) Interestingly this test passes even though `rmiregistry` currently fails to operate normally, because it runs well enough to print its version string, but not well enough to start up a registry service. (Double argh!)

The warnings policy is a separate issue being discussed elsewhere.

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

PR: https://git.openjdk.java.net/jdk18/pull/45


From dholmes at openjdk.java.net  Tue Dec 21 21:45:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Dec 2021 21:45:14 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <XCbGplub5NvbUblllEMQxytUHkXupGhgFKHw5yW8jmQ=.e33a3f0a-94cb-45ac-b2ef-b023da85a175@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
 <XCbGplub5NvbUblllEMQxytUHkXupGhgFKHw5yW8jmQ=.e33a3f0a-94cb-45ac-b2ef-b023da85a175@github.com>
Message-ID: <lOWbt6DA6Y3Po8N2D8gFQm1BRhbeEC9N6Wnql2u4c_k=.44a8986c-38db-489e-bd78-02c4c2f0a7dd@github.com>

On Sun, 19 Dec 2021 07:37:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Enable the security manager in rmiregistry's launcher arguments.
>
> As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry -J-Djava.security.manager=allow` are equivalent because rmiregistry sets the default SM. Some difference may be observed if someone is running rmiregistry with a custom system class loader set, or custom file system provider, or running it with a JVM TI agent that is looking at events between VMStart and VMInit but these seem somewhat obscure scenarios for a command line program If rmiregstry worked with ToolProvider then I think there would be more to discuss. If the final patch is to have the launcher set the default security manager then we may want to change RegistryImpl.createRegistry to fail if not set.
> 
> The warning that is emitted for both cases is expected. JEP 411 is very clear that it there is no mechanism to suppress it. We may need to add a release note to document that rmiregistry will emit a warning a startup, that will at least be something to point at in the event that anyone asks or reports an issue.

In the same kind of PR (https://github.com/openjdk/jdk18/pull/53) for `jstatd` @AlanBateman writes:
> This looks okay in that it is now worked exactly as it did in JDK 17.

And that PR uses `allow` as I have suggested here (to preserve existing behaviour). All the affected launchers should be fixed in the same consistent way.

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

PR: https://git.openjdk.java.net/jdk18/pull/45


From smarks at openjdk.java.net  Wed Dec 22 01:18:58 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 22 Dec 2021 01:18:58 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled [v2]
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>

> Enable the security manager in rmiregistry's launcher arguments.

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

  Change java.security.manager to "allow"; filter warning lines from VersionCheck

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/45/files
  - new: https://git.openjdk.java.net/jdk18/pull/45/files/e899bd2d..f713e731

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

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

PR: https://git.openjdk.java.net/jdk18/pull/45


From smarks at openjdk.java.net  Wed Dec 22 01:30:15 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 22 Dec 2021 01:30:15 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled [v2]
In-Reply-To: <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
 <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
Message-ID: <j9NA-OXmsxCzk4qdqOD2zt8y8hTAQS35ShajqVh0t0I=.39eee2a3-eccd-4f61-a938-18d71d9560c0@github.com>

On Wed, 22 Dec 2021 01:18:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Enable the security manager in rmiregistry's launcher arguments.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change java.security.manager to "allow"; filter warning lines from VersionCheck

Enabling the security manager using a property, versus setting the property to `allow` and enabling it in code, is mostly a distinction without a difference. I don't think there is really a need to have the different tools be consistent. Local tool considerations probably swamp the need for any cross-tool consistency.

In this case some of the RMI registry tests set the property to `allow` on the command line and then rely on the code to enable the security manager using the API, so it's much easier to switch the `rmiregistry` launcher to use the `allow` technique instead. This is sort-of the tail (the tests) wagging the doc (the tool) but there doesn't seem to any benefit to be gained from fiddling around with the tests and the RMI test library.

I've also updated VersionCheck.java to filter out the security manager warning messages.

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

PR: https://git.openjdk.java.net/jdk18/pull/45


From duke at openjdk.java.net  Wed Dec 22 02:49:45 2021
From: duke at openjdk.java.net (Tyler)
Date: Wed, 22 Dec 2021 02:49:45 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712 (Flight
 Recorder)
Message-ID: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>

Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ?

### Implementation notes and alternatives considered

After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.

### Testing

Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).

### More notes

I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

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

Commit messages:
 - 8203290: Implements Java Flight Recorder on AIX

Changes: https://git.openjdk.java.net/jdk/pull/6885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8203290
  Stats: 1090 lines in 7 files changed: 425 ins; 500 del; 165 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

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


From egahlin at openjdk.java.net  Wed Dec 22 03:03:16 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 22 Dec 2021 03:03:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder)
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>

On Fri, 17 Dec 2021 19:07:54 GMT, Tyler <duke at openjdk.java.net> wrote:

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ?
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

I don't have access to AIX, but there are 500+ tests in test/jdk/jdk/jfr you might want to try out.

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

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


From dholmes at openjdk.java.net  Wed Dec 22 04:20:19 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 22 Dec 2021 04:20:19 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder)
In-Reply-To: <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>
Message-ID: <fb3uQAhT9A0eUXpBqOWPfzfOGmAJDs1nQRUz4wkfc_M=.95066e8a-e6a9-4ecf-ae36-c9e6fc7615a2@github.com>

On Wed, 22 Dec 2021 02:59:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ?
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> I don't have access to AIX, but there are 500+ tests in test/jdk/jdk/jfr you might want to try out.

@egahlin  beat me to it - yes the JFR testing is primarily under jdk not hotspot, so we don't really need the new sanity tests.

Also are you aware that we have `src/hotspot/os/aix/libperfstat_aix.*` ?

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

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


From sgehwolf at redhat.com  Wed Dec 22 10:14:39 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 22 Dec 2021 11:14:39 +0100
Subject: [Ping?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
Message-ID: <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>

On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote:
> Hi,
> 
> Please review this adaptation of the corresponding JDK 11 patch. The
> JDK 11u patch didn't apply because the build system is widely different
> between these two releases.
> 
> The main difference is make/common/MakeBase.gmk (JDK 8) vs
> make/SourceRevision.gmk (JDK 11). I've basically rewritten those parts
> of the patch. All the SCM handling in JDK 8 is in MakeBase.
> FindAllReposAbs isn't present in JDK 8u.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210283
> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/01/webrev/
> 
> Testing: "make --trace source-tips" on mercurial tree as well as
> ???????? the git mirror. $IMAGE_DIR/release file contains the SHA of
> ???????? the sources it was built from with 'git:' or 'hg:' prefixes.
> 
> Thoughts?

Anyone? When building from the git read-only mirror the "release" file
no longer includes the git sha it was built from without this fix.

Thanks,
Severin



From alanb at openjdk.java.net  Wed Dec 22 10:38:27 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 22 Dec 2021 10:38:27 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled [v2]
In-Reply-To: <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
 <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
Message-ID: <e0AhmU1AsthfpxKX-ewDJSp-UfO6V7z-8WA_NxnF6mk=.e3ceb171-14e6-4bcd-b4d5-4476fc6bb4ad@github.com>

On Wed, 22 Dec 2021 01:18:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Enable the security manager in rmiregistry's launcher arguments.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change java.security.manager to "allow"; filter warning lines from VersionCheck

This version looks okay, avoids having an attempt to set the SM in createRegistry always be skipped.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/45


From aleonard at openjdk.java.net  Wed Dec 22 13:06:00 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 13:06:00 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v2]
In-Reply-To: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
Message-ID: <Lhhmy2t8SUgN7sijUjpSh899JJa3mtnXc-TiaWLGY2k=.43e39ec1-8bd6-4988-82f9-60c199633fef@github.com>

> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
> Validating the boot jdk supports --date for the building of the jars.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

 - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6878/files
  - new: https://git.openjdk.java.net/jdk/pull/6878/files/b89ff538..e0fe5b75

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

  Stats: 35 lines in 6 files changed: 12 ins; 14 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6878.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6878/head:pull/6878

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


From aleonard at openjdk.java.net  Wed Dec 22 13:21:52 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 13:21:52 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v3]
In-Reply-To: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
Message-ID: <XrT6lEO6W2f3yh33dNay9qG5c5KaIpl9t5WVmHrkDls=.fed89665-4d71-42be-8d6f-577cac68a466@github.com>

> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
> Validating the boot jdk supports --date for the building of the jars.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6878/files
  - new: https://git.openjdk.java.net/jdk/pull/6878/files/e0fe5b75..75c9d692

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

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

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


From erikj at openjdk.java.net  Wed Dec 22 13:40:12 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 22 Dec 2021 13:40:12 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled [v2]
In-Reply-To: <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
 <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
Message-ID: <kdpb7afCAOo48qmkWEhACRErDBfXKhyq_kjt7exSgZE=.f01d9fab-4fbd-49ea-8610-97fd7f7e9d49@github.com>

On Wed, 22 Dec 2021 01:18:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Enable the security manager in rmiregistry's launcher arguments.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change java.security.manager to "allow"; filter warning lines from VersionCheck

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/45


From erikj at openjdk.java.net  Wed Dec 22 13:45:18 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 22 Dec 2021 13:45:18 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v3]
In-Reply-To: <XrT6lEO6W2f3yh33dNay9qG5c5KaIpl9t5WVmHrkDls=.fed89665-4d71-42be-8d6f-577cac68a466@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <XrT6lEO6W2f3yh33dNay9qG5c5KaIpl9t5WVmHrkDls=.fed89665-4d71-42be-8d6f-577cac68a466@github.com>
Message-ID: <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>

On Wed, 22 Dec 2021 13:21:52 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
>> Validating the boot jdk supports --date for the building of the jars.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

make/InitSupport.gmk line 317:

> 315:     export SOURCE_DATE_EPOCH := $$(SOURCE_DATE)
> 316:     ifeq ($$(IS_GNU_DATE), yes)
> 317:       SOURCE_DATE_ISO_8601 := $(shell $(DATE) --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)

Are you getting this to work without `export`? I would have expected that to be needed.

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

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


From aleonard at openjdk.java.net  Wed Dec 22 13:56:19 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 13:56:19 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v3]
In-Reply-To: <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <XrT6lEO6W2f3yh33dNay9qG5c5KaIpl9t5WVmHrkDls=.fed89665-4d71-42be-8d6f-577cac68a466@github.com>
 <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>
Message-ID: <nFZAc4rLlrjz_OhXO53wKA_977Ayg3xumETKDTcLBlw=.6a8b84f4-eb74-4186-b20f-aa6d48de297e@github.com>

On Wed, 22 Dec 2021 13:41:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/InitSupport.gmk line 317:
> 
>> 315:     export SOURCE_DATE_EPOCH := $$(SOURCE_DATE)
>> 316:     ifeq ($$(IS_GNU_DATE), yes)
>> 317:       SOURCE_DATE_ISO_8601 := $(shell $(DATE) --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
> 
> Are you getting this to work without `export`? I would have expected that to be needed.

just checking log now

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

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


From aleonard at openjdk.java.net  Wed Dec 22 13:56:19 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 13:56:19 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v3]
In-Reply-To: <nFZAc4rLlrjz_OhXO53wKA_977Ayg3xumETKDTcLBlw=.6a8b84f4-eb74-4186-b20f-aa6d48de297e@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <XrT6lEO6W2f3yh33dNay9qG5c5KaIpl9t5WVmHrkDls=.fed89665-4d71-42be-8d6f-577cac68a466@github.com>
 <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>
 <nFZAc4rLlrjz_OhXO53wKA_977Ayg3xumETKDTcLBlw=.6a8b84f4-eb74-4186-b20f-aa6d48de297e@github.com>
Message-ID: <dTMpX2jo5lvjzPlFOG2vqZ7jI-nbW_FKcjYoastBNGg=.5c12feff-20b8-4b41-93e5-0f67f5b70e2e@github.com>

On Wed, 22 Dec 2021 13:50:32 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> make/InitSupport.gmk line 317:
>> 
>>> 315:     export SOURCE_DATE_EPOCH := $$(SOURCE_DATE)
>>> 316:     ifeq ($$(IS_GNU_DATE), yes)
>>> 317:       SOURCE_DATE_ISO_8601 := $(shell $(DATE) --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
>> 
>> Are you getting this to work without `export`? I would have expected that to be needed.
>
> just checking log now

you're right !

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

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


From aleonard at openjdk.java.net  Wed Dec 22 14:55:27 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 14:55:27 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v3]
In-Reply-To: <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <XrT6lEO6W2f3yh33dNay9qG5c5KaIpl9t5WVmHrkDls=.fed89665-4d71-42be-8d6f-577cac68a466@github.com>
 <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>
Message-ID: <nq08PZxuNe_KCU2EXM56altBTQr4S_Xbw-0Z78AESZM=.7e6b58ce-6893-43b3-bc74-abdd36b0dea1@github.com>

On Wed, 22 Dec 2021 13:41:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/InitSupport.gmk line 317:
> 
>> 315:     export SOURCE_DATE_EPOCH := $$(SOURCE_DATE)
>> 316:     ifeq ($$(IS_GNU_DATE), yes)
>> 317:       SOURCE_DATE_ISO_8601 := $(shell $(DATE) --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
> 
> Are you getting this to work without `export`? I would have expected that to be needed.

@erikj79 right, so I was using the wrong configuration and reproducible-build was not set, now I am, I can see I am where I was before in that SOURCE_DATE_ISO_8601 being set in InitSupport.gmk is not visible in JarArchive.gmk, i've tried both with and without the export...?

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

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


From aleonard at openjdk.java.net  Wed Dec 22 15:32:13 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 15:32:13 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v3]
In-Reply-To: <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <XrT6lEO6W2f3yh33dNay9qG5c5KaIpl9t5WVmHrkDls=.fed89665-4d71-42be-8d6f-577cac68a466@github.com>
 <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>
Message-ID: <At7g3ZVgbpBKs0TQ7bOs2nUYzwwxsuPwMSURbX8KCVw=.b87d3621-e5da-4df6-a5f4-829e0785fd5b@github.com>

On Wed, 22 Dec 2021 13:41:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/InitSupport.gmk line 317:
> 
>> 315:     export SOURCE_DATE_EPOCH := $$(SOURCE_DATE)
>> 316:     ifeq ($$(IS_GNU_DATE), yes)
>> 317:       SOURCE_DATE_ISO_8601 := $(shell $(DATE) --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
> 
> Are you getting this to work without `export`? I would have expected that to be needed.

@erikj79 fixed it I think, problems is above not enough $'s !! for $(shell.......

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

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


From aleonard at openjdk.java.net  Wed Dec 22 15:44:47 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 15:44:47 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v4]
In-Reply-To: <9iDC1w4QBf7cAVBk6ofKHhpanhZF-8I0YeU9ZgxOLs0=.7ecaf76d-62ac-4e78-bbfc-766add0630a2@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <qr0gnjSoRmYeVGMNfl4Tx6I8cicyGg4ALP8YcV7tNak=.703496b7-c987-40ac-9934-ac66739091ab@github.com>
 <cQk-XSFq2LgdwfIpSAGFvLx1I0aNm6bUGhyMV34baIk=.1ace5924-d42e-48db-b260-bfdfcab942b8@github.com>
 <ci9J5BoqDgZudO4FAu8-DtA6uXcgHuAFi2p0C-3VWZA=.19aac980-5df7-436a-a4e8-a6695f77b7f5@github.com>
 <90OeqZiTLSgTZJcd4iyu6LI8xb-8HKZlduABiVcTP4g=.10beb9dd-8106-4b86-a8c5-4f08b4614924@github.com>
 <9iDC1w4QBf7cAVBk6ofKHhpanhZF-8I0YeU9ZgxOLs0=.7ecaf76d-62ac-4e78-bbfc-766add0630a2@github.com>
Message-ID: <37ZclwgoG50iGKkGzYM95TrAgoy-IZqEyi3Jsn7sunQ=.18fa823f-5ffa-49e8-9f51-e52c358493c5@github.com>

On Fri, 17 Dec 2021 20:08:43 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> But I think the code in InitSupport will be executed always; Init.gmk is our "bootstrapper" / "trampoline" which wraps all calls to make (and InitSupport.gmk contains gory implementation details of Init.gmk).
>
> @magicus don't worry, enjoy your holiday, I think @erik has pointed out it should work, so I probably made a mistake when I tried it...

Moved export SOURCE_DATE_ISO_8601 to InitSupport as suggested, found the problem as to why it didn't work for me, I was missing a "$" !

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

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


From aleonard at openjdk.java.net  Wed Dec 22 15:44:50 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 15:44:50 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v4]
In-Reply-To: <nPbPLbiQjmmKjnwOm2t3iNbOnFI0-NMUWRQLqvd-pkk=.783bab63-c2a2-4f7a-9b05-a7415db213b9@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <oeTN3EAyeJ3cnZAH76K3WwHQLcTqRTngywm6gjhn2A0=.6bca8025-3e49-41ed-b4c1-d824975a113c@github.com>
 <nPbPLbiQjmmKjnwOm2t3iNbOnFI0-NMUWRQLqvd-pkk=.783bab63-c2a2-4f7a-9b05-a7415db213b9@github.com>
Message-ID: <an05q7-5bsuTlnBuvsd4yyVsNR4tAqCRzn6skOJJ92A=.a0fb125b-246b-4b83-90fd-77735532df5b@github.com>

On Fri, 17 Dec 2021 20:04:20 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> make/common/MakeBase.gmk line 148:
>> 
>>> 146:   ifeq ($(SOURCE_DATE_ISO_8601), )
>>> 147:     # GNU date format did not work, try BSD date options
>>> 148:     SOURCE_DATE_ISO_8601 := $(shell $(DATE) -u -j -f "%s" "$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
>> 
>> Could we maybe figure out the date command line to use in configure instead to avoid the trial and error at build time?
>
> I based this trial and error based on util.m4 code and copied the method, so yes I can store the result from then...

Added IS_GNU_DATE variable

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

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


From aleonard at openjdk.java.net  Wed Dec 22 15:44:39 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 15:44:39 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v4]
In-Reply-To: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
Message-ID: <HwYKxtjLYg93rrKDN822OXelHseazPo5zgavEMMUOvA=.267c9059-f63b-49d9-b8d5-0c057168cae6@github.com>

> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
> Validating the boot jdk supports --date for the building of the jars.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

 - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6878/files
  - new: https://git.openjdk.java.net/jdk/pull/6878/files/75c9d692..5fb4676b

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

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

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


From aleonard at openjdk.java.net  Wed Dec 22 15:44:45 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 15:44:45 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v4]
In-Reply-To: <oeTN3EAyeJ3cnZAH76K3WwHQLcTqRTngywm6gjhn2A0=.6bca8025-3e49-41ed-b4c1-d824975a113c@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <oeTN3EAyeJ3cnZAH76K3WwHQLcTqRTngywm6gjhn2A0=.6bca8025-3e49-41ed-b4c1-d824975a113c@github.com>
Message-ID: <z3Xm8nma_ZNOKhLLFXHo6XvMpjVw0LdpQ8F9PFj340Y=.b658d71c-88c5-4f8c-9a7d-c4cce1fa09c7@github.com>

On Fri, 17 Dec 2021 17:47:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/common/JarArchive.gmk line 234:
> 
>> 232:     endif
>> 233:   else
>> 234:     $1_JAR_OPTIONS := $$($1_JAR_SOURCE_DATE)
> 
> Instead of adding $$($1_JAR_SOURCE_DATE) to every branch of this conditional, you can use += to build the $1_JAR_OPTIONS variable one step at a time. I don't think we need a separate variable JAR_SOURCE_DATE.

reduced as stated

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

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


From aleonard at openjdk.java.net  Wed Dec 22 15:44:41 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 15:44:41 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v3]
In-Reply-To: <At7g3ZVgbpBKs0TQ7bOs2nUYzwwxsuPwMSURbX8KCVw=.b87d3621-e5da-4df6-a5f4-829e0785fd5b@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <XrT6lEO6W2f3yh33dNay9qG5c5KaIpl9t5WVmHrkDls=.fed89665-4d71-42be-8d6f-577cac68a466@github.com>
 <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>
 <At7g3ZVgbpBKs0TQ7bOs2nUYzwwxsuPwMSURbX8KCVw=.b87d3621-e5da-4df6-a5f4-829e0785fd5b@github.com>
Message-ID: <DYTExu5hZuYtms5ABuCCY-KEsE_oXn-vtEqF-E0Ug6I=.8989575d-51f7-4d85-8930-070183665fae@github.com>

On Wed, 22 Dec 2021 15:28:52 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> make/InitSupport.gmk line 317:
>> 
>>> 315:     export SOURCE_DATE_EPOCH := $$(SOURCE_DATE)
>>> 316:     ifeq ($$(IS_GNU_DATE), yes)
>>> 317:       SOURCE_DATE_ISO_8601 := $(shell $(DATE) --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
>> 
>> Are you getting this to work without `export`? I would have expected that to be needed.
>
> @erikj79 fixed it I think, problems is above not enough $'s !! for $(shell.......

resolved, thanks

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

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


From jwilhelm at openjdk.java.net  Wed Dec 22 16:12:51 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 22 Dec 2021 16:12:51 GMT
Subject: RFR: Merge jdk18
Message-ID: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8274315: JFR: One closed state per file or stream
 - 8271447: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters
 - 8278987: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in __write_sample_info__
 - 8279007: jstatd fails to start because SecurityManager is disabled
 - 8278508: Enable X86 maskAll instruction pattern for 32 bit JVM.
 - 8279045: Intrinsics missing vzeroupper instruction

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6918&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6918&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/6918/files
  Stats: 260 lines in 21 files changed: 170 ins; 55 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6918.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6918/head:pull/6918

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


From jwilhelm at openjdk.java.net  Wed Dec 22 16:51:03 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 22 Dec 2021 16:51:03 GMT
Subject: RFR: Merge jdk18 [v2]
In-Reply-To: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>
References: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>
Message-ID: <F4hx0Py0VaieiF4QlekcSe5e5ApHCSYgKX-jdlEOULY=.0942e438-8ba7-4460-89f7-62a7dcfe66de@github.com>

> Forwardport JDK 18 -> JDK 19

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 104 commits:

 - Merge
 - 8279063: Consolidate push and push_if_necessary in PreservedMarks
   
   Reviewed-by: rkennke, mli, tschatzl
 - 8279024: Remove javascript references from clhsdb.html
   
   Reviewed-by: kevinw, sspitsyn
 - Merge
 - 8244670: convert clhsdb "whatis" command from javascript to java
   
   Reviewed-by: sspitsyn, kevinw
 - 8279066: entries.remove(entry) is useless in PKCS12KeyStore
   
   Reviewed-by: mullan
 - Merge
 - 8279060: Parallel: Remove unused PSVirtualSpace constructors
   
   Reviewed-by: mli, sjohanss, tschatzl
 - 8278396: G1: Initialize the BOT threshold to be region bottom
   
   Reviewed-by: tschatzl, sjohanss
 - 8279043: Some Security Exception Messages Miss Spaces
   
   Reviewed-by: weijun
 - ... and 94 more: https://git.openjdk.java.net/jdk/compare/dfb15c3e...70630b7b

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

Changes: https://git.openjdk.java.net/jdk/pull/6918/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6918&range=01
  Stats: 18775 lines in 519 files changed: 14457 ins; 3098 del; 1220 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6918.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6918/head:pull/6918

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


From jwilhelm at openjdk.java.net  Wed Dec 22 16:51:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 22 Dec 2021 16:51:06 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>
References: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>
Message-ID: <gwBOG6dixu-scUaTjURYxwudcIN4f5wf1jav_dJINCE=.9cc3f162-bc51-46bd-a309-1254000d862f@github.com>

On Wed, 22 Dec 2021 16:03:43 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: f1fbba23
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1fbba23ebdb28a32977241f8e85b60e10878cbc
Stats:     260 lines in 21 files changed: 170 ins; 55 del; 35 mod

Merge

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

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


From duke at openjdk.java.net  Wed Dec 22 17:10:15 2021
From: duke at openjdk.java.net (Tyler)
Date: Wed, 22 Dec 2021 17:10:15 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder)
In-Reply-To: <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>
Message-ID: <x-O_NAiGxSl5YQByRytVg01TXp-FNd2u2dMbC0sbAt4=.b590e2e0-b355-49e1-87bf-1539eda9566a@github.com>

On Wed, 22 Dec 2021 02:59:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ?
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> I don't have access to AIX, but there are 500+ tests in test/jdk/jdk/jfr you might want to try out.

Thanks @egahlin and @dholmes-ora. Responses to your comments below:


> I don't have access to AIX, but there are 500+ tests in test/jdk/jdk/jfr you might want to try out.


I definitely missed these! I ran them on my AIX testing machine and found a few failures. I'll look into them. 



> Also are you aware that we have `src/hotspot/os/aix/libperfstat_aix.*` ?


Thanks for pointing me to this, I was not aware of it. I will spend some time to assess whether I can make use of it.

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

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


From erikj at openjdk.java.net  Wed Dec 22 17:34:17 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 22 Dec 2021 17:34:17 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v3]
In-Reply-To: <DYTExu5hZuYtms5ABuCCY-KEsE_oXn-vtEqF-E0Ug6I=.8989575d-51f7-4d85-8930-070183665fae@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <XrT6lEO6W2f3yh33dNay9qG5c5KaIpl9t5WVmHrkDls=.fed89665-4d71-42be-8d6f-577cac68a466@github.com>
 <kPeZGSaOcWLAcQ_CHau7Br5OfN6MjcDpD6GP-G5_77k=.61186184-eb8c-4348-a24c-953f4ee5c500@github.com>
 <At7g3ZVgbpBKs0TQ7bOs2nUYzwwxsuPwMSURbX8KCVw=.b87d3621-e5da-4df6-a5f4-829e0785fd5b@github.com>
 <DYTExu5hZuYtms5ABuCCY-KEsE_oXn-vtEqF-E0Ug6I=.8989575d-51f7-4d85-8930-070183665fae@github.com>
Message-ID: <DrvP9-1xRWZG2awd1aR4pjc8j4fND6xN09ZFPsA_ZHk=.c57c68ac-a3e2-4111-a3bf-3d6b275e0bf0@github.com>

On Wed, 22 Dec 2021 15:34:23 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> @erikj79 fixed it I think, problems is above not enough $'s !! for $(shell.......
>
> resolved, thanks

Ah, the default diff view didn't show me enough context. This is part of a macro body, then yes, you need to double all the $ to get it evaluated at the correct time.

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

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


From erikj at openjdk.java.net  Wed Dec 22 17:34:19 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 22 Dec 2021 17:34:19 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v4]
In-Reply-To: <HwYKxtjLYg93rrKDN822OXelHseazPo5zgavEMMUOvA=.267c9059-f63b-49d9-b8d5-0c057168cae6@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <HwYKxtjLYg93rrKDN822OXelHseazPo5zgavEMMUOvA=.267c9059-f63b-49d9-b8d5-0c057168cae6@github.com>
Message-ID: <tPyw-Yto5L1QqkwwOpASCz5247K7fDyY_Rork8r7OOQ=.02859b70-15d6-42b5-ae43-df3f142e0c3f@github.com>

On Wed, 22 Dec 2021 15:44:39 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
>> Validating the boot jdk supports --date for the building of the jars.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

make/InitSupport.gmk line 320:

> 318:     else
> 319:       export SOURCE_DATE_ISO_8601 := $$(shell $$(DATE) -u -j -f "%s" "$$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
> 320:     endif

This is starting to look pretty good, but I would ask you to try to break these long lines. We try to keep the makefiles reasonably narrow for easier future 3-way merges and diff viewing.

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

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


From smarks at openjdk.java.net  Wed Dec 22 19:00:22 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 22 Dec 2021 19:00:22 GMT
Subject: [jdk18] Integrated: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <gysG0Nmb72FD1H__mYsvemMT2k220M3Pd2qvQpPZ_0k=.46182bd6-4427-424a-bdbc-566c50808b8f@github.com>

On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Enable the security manager in rmiregistry's launcher arguments.

This pull request has now been integrated.

Changeset: 04ee9211
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/04ee9211fcc59178b3bfdfdda5e0def9b0f29ada
Stats:     7 lines in 2 files changed: 4 ins; 0 del; 3 mod

8278967: rmiregistry fails to start because SecurityManager is disabled

Reviewed-by: alanb, erikj

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

PR: https://git.openjdk.java.net/jdk18/pull/45


From aleonard at openjdk.java.net  Wed Dec 22 19:34:48 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 19:34:48 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v5]
In-Reply-To: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
Message-ID: <Z9CAVUi79JBgI_BSbGa6ARmUXXcxcioC5R-brxaywrY=.9045eaed-9ab6-49ef-8561-49ae0393918d@github.com>

> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
> Validating the boot jdk supports --date for the building of the jars.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6878/files
  - new: https://git.openjdk.java.net/jdk/pull/6878/files/5fb4676b..add720cf

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

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

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


From aleonard at openjdk.java.net  Wed Dec 22 19:34:54 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 22 Dec 2021 19:34:54 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v4]
In-Reply-To: <tPyw-Yto5L1QqkwwOpASCz5247K7fDyY_Rork8r7OOQ=.02859b70-15d6-42b5-ae43-df3f142e0c3f@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <HwYKxtjLYg93rrKDN822OXelHseazPo5zgavEMMUOvA=.267c9059-f63b-49d9-b8d5-0c057168cae6@github.com>
 <tPyw-Yto5L1QqkwwOpASCz5247K7fDyY_Rork8r7OOQ=.02859b70-15d6-42b5-ae43-df3f142e0c3f@github.com>
Message-ID: <3PIWAaiM6Hihxt9hmyz7a6LV5xIWao36MTXLm9LogNQ=.9fdb4a2e-61dd-47b0-9a76-1fba1178b224@github.com>

On Wed, 22 Dec 2021 17:30:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/InitSupport.gmk line 320:
> 
>> 318:     else
>> 319:       export SOURCE_DATE_ISO_8601 := $$(shell $$(DATE) -u -j -f "%s" "$$(SOURCE_DATE_EPOCH)" +"%Y-%m-%dT%H:%M:%SZ" 2> /dev/null)
>> 320:     endif
> 
> This is starting to look pretty good, but I would ask you to try to break these long lines. We try to keep the makefiles reasonably narrow for easier future 3-way merges and diff viewing.

ah yes, fixed

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

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


From erikj at openjdk.java.net  Wed Dec 22 19:58:13 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 22 Dec 2021 19:58:13 GMT
Subject: RFR: 8278766: Enable OpenJDK build support for reproducible jars
 and jmods using --date [v5]
In-Reply-To: <Z9CAVUi79JBgI_BSbGa6ARmUXXcxcioC5R-brxaywrY=.9045eaed-9ab6-49ef-8561-49ae0393918d@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
 <Z9CAVUi79JBgI_BSbGa6ARmUXXcxcioC5R-brxaywrY=.9045eaed-9ab6-49ef-8561-49ae0393918d@github.com>
Message-ID: <C8PpC0KNTWfOtYkpNtsDnV9S1jeQZHWFwZRPjEhfP6g=.3bd4d424-44ad-4896-aeba-9eba2062d987@github.com>

On Wed, 22 Dec 2021 19:34:48 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
>> Validating the boot jdk supports --date for the building of the jars.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Marked as reviewed by erikj (Reviewer).

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

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


From aleonard at openjdk.java.net  Thu Dec 23 09:47:38 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 23 Dec 2021 09:47:38 GMT
Subject: RFR: 8279182: MakeZipReproducible ZipEntry timestamps not localized to
 UTC
Message-ID: <BH8VrNErXKWMzsgETsHsxPWlE5avUXgTRidKNpEwq9E=.83e27f00-5b90-49bb-b0c9-f46aef27f9e8@github.com>

MakeZipReproducible was added to enable reproducible building of src.zip. However, as ZipEntry timestamps are a "localized" date with no zone, the specified epoch instant was getting localized in whatever the building timezone was, hence src.zip built from the same source in different zones would differ.
The timestamp should be localized to UTC (like for jar, jmod entries), this PR ensures this.

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

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

Commit messages:
 - 8279182: MakeZipReproducible ZipEntry timestamps not localized to UTC

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

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


From aleonard at openjdk.java.net  Thu Dec 23 11:05:20 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 23 Dec 2021 11:05:20 GMT
Subject: Integrated: 8278766: Enable OpenJDK build support for reproducible
 jars and jmods using --date
In-Reply-To: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
References: <UZ7xN2Wgyy8uMQJ6v1WvBgYyj_pHTSQibXQjL__5J0Y=.25a87c46-ba5d-4e45-b320-7cdcc9fb7241@github.com>
Message-ID: <ZJXGgL40UkePVAwKeMLtAc0kj2rDrlbqUIy_mYgSPII=.dc13dd2a-0326-4aae-94e2-622b20e4aefa@github.com>

On Fri, 17 Dec 2021 09:18:03 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> If "reproducible build" is enabled, then utilize the new --date option in the building of jar's and jmods.
> Validating the boot jdk supports --date for the building of the jars.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: 214f98f6
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/214f98f6b07e312e6f4ded5364a94277114784e7
Stats:     65 lines in 7 files changed: 45 ins; 6 del; 14 mod

8278766: Enable OpenJDK build support for reproducible jars and jmods using --date

Reviewed-by: erikj

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

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


From erikj at openjdk.java.net  Thu Dec 23 13:42:21 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 23 Dec 2021 13:42:21 GMT
Subject: RFR: 8279182: MakeZipReproducible ZipEntry timestamps not
 localized to UTC
In-Reply-To: <BH8VrNErXKWMzsgETsHsxPWlE5avUXgTRidKNpEwq9E=.83e27f00-5b90-49bb-b0c9-f46aef27f9e8@github.com>
References: <BH8VrNErXKWMzsgETsHsxPWlE5avUXgTRidKNpEwq9E=.83e27f00-5b90-49bb-b0c9-f46aef27f9e8@github.com>
Message-ID: <s2HhMQ3L4BR7mVi-mP9I0_qwsk9aGV6ZRzoVIOUkKBE=.a0cf8cb4-9fa2-4ed2-b0ff-b730aaa4a005@github.com>

On Thu, 23 Dec 2021 09:39:19 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> MakeZipReproducible was added to enable reproducible building of src.zip. However, as ZipEntry timestamps are a "localized" date with no zone, the specified epoch instant was getting localized in whatever the building timezone was, hence src.zip built from the same source in different zones would differ.
> The timestamp should be localized to UTC (like for jar, jmod entries), this PR ensures this.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.java.net  Thu Dec 23 14:25:38 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 23 Dec 2021 14:25:38 GMT
Subject: RFR: 8279223: Define version in .jcheck/conf
Message-ID: <3rCTBYIOJDfd_Y7KB1PaGA6y380j004trul0JQLRiwg=.dfd7f5b5-d407-4199-a788-a2a68e2a5031@github.com>

This patch adds the version field to .jcheck/conf. By doing this we can remove the corresponding configuration from the Skara bots, which in turn reduces the need for timing and general complexity of starting a new JDK release.

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

Commit messages:
 - JDK-8279223

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

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


From alanb at openjdk.java.net  Thu Dec 23 14:32:16 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 23 Dec 2021 14:32:16 GMT
Subject: RFR: 8279223: Define version in .jcheck/conf
In-Reply-To: <3rCTBYIOJDfd_Y7KB1PaGA6y380j004trul0JQLRiwg=.dfd7f5b5-d407-4199-a788-a2a68e2a5031@github.com>
References: <3rCTBYIOJDfd_Y7KB1PaGA6y380j004trul0JQLRiwg=.dfd7f5b5-d407-4199-a788-a2a68e2a5031@github.com>
Message-ID: <3ObaqAZWSqf5IS3zlmf5oH_8HT0GYqavfMsl_W9kIW4=.bceec971-817a-4e06-beed-3de0d149c3c1@github.com>

On Thu, 23 Dec 2021 14:16:37 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch adds the version field to .jcheck/conf. By doing this we can remove the corresponding configuration from the Skara bots, which in turn reduces the need for timing and general complexity of starting a new JDK release.

Marked as reviewed by alanb (Reviewer).

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

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


From jwilhelm at openjdk.java.net  Thu Dec 23 17:19:53 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 23 Dec 2021 17:19:53 GMT
Subject: RFR: Merge jdk18
Message-ID: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8279204: [BACKOUT] JDK-8278413: C2 crash when allocating array of size too large
 - 8268297: jdk/jfr/api/consumer/streaming/TestLatestEvent.java times out
 - 8279076: C2: Bad AD file when matching SqrtF with UseSSE=0
 - 8278967: rmiregistry fails to start because SecurityManager is disabled
 - 8278239: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine failed with EXCEPTION_ACCESS_VIOLATION at 0x000000000000000d

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6931&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6931&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/6931/files
  Stats: 299 lines in 17 files changed: 141 ins; 126 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6931.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6931/head:pull/6931

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


From aleonard at openjdk.java.net  Thu Dec 23 18:06:17 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 23 Dec 2021 18:06:17 GMT
Subject: Integrated: 8279182: MakeZipReproducible ZipEntry timestamps not
 localized to UTC
In-Reply-To: <BH8VrNErXKWMzsgETsHsxPWlE5avUXgTRidKNpEwq9E=.83e27f00-5b90-49bb-b0c9-f46aef27f9e8@github.com>
References: <BH8VrNErXKWMzsgETsHsxPWlE5avUXgTRidKNpEwq9E=.83e27f00-5b90-49bb-b0c9-f46aef27f9e8@github.com>
Message-ID: <fmU8b9fwKLkwatp1SxH6439zVvYxoEoqxPfjSgJJU8I=.fb2392bb-68b4-4de7-b37f-fff04e77f95b@github.com>

On Thu, 23 Dec 2021 09:39:19 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> MakeZipReproducible was added to enable reproducible building of src.zip. However, as ZipEntry timestamps are a "localized" date with no zone, the specified epoch instant was getting localized in whatever the building timezone was, hence src.zip built from the same source in different zones would differ.
> The timestamp should be localized to UTC (like for jar, jmod entries), this PR ensures this.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: bc0466c7
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bc0466c7ca57f14b1e6285e2a39755d57c8de376
Stats:     11 lines in 1 file changed: 6 ins; 0 del; 5 mod

8279182: MakeZipReproducible ZipEntry timestamps not localized to UTC

Reviewed-by: erikj

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

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


From iris at openjdk.java.net  Thu Dec 23 18:46:17 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 23 Dec 2021 18:46:17 GMT
Subject: RFR: 8279223: Define version in .jcheck/conf
In-Reply-To: <3rCTBYIOJDfd_Y7KB1PaGA6y380j004trul0JQLRiwg=.dfd7f5b5-d407-4199-a788-a2a68e2a5031@github.com>
References: <3rCTBYIOJDfd_Y7KB1PaGA6y380j004trul0JQLRiwg=.dfd7f5b5-d407-4199-a788-a2a68e2a5031@github.com>
Message-ID: <Pn1qAuUc3OAbqzU6OtfQBAfVAtPpSYcKP80ytz5MAlY=.e018fb17-61d1-434f-85eb-cce3f341d547@github.com>

On Thu, 23 Dec 2021 14:16:37 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch adds the version field to .jcheck/conf. By doing this we can remove the corresponding configuration from the Skara bots, which in turn reduces the need for timing and general complexity of starting a new JDK release.

Marked as reviewed by iris (Reviewer).

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

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


From jwilhelm at openjdk.java.net  Thu Dec 23 21:22:01 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 23 Dec 2021 21:22:01 GMT
Subject: RFR: Merge jdk18 [v2]
In-Reply-To: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>
References: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>
Message-ID: <U55hVLEFuwsZjYsuXiVBXYDFfsCJf4VpKIaj62sWdos=.e9efafae-50cc-42bb-ba02-c177ded59d08@github.com>

> Forwardport JDK 18 -> JDK 19

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:

 - Merge
 - 8279115: Fix internal doc comment errors.
   
   Reviewed-by: mli
 - 8276302: Locale.filterTags methods ignore actual weight when matching "*" (as if it is 1)
   
   Reviewed-by: naoto
 - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
   
   Reviewed-by: erikj
 - 8278125: Some preallocated OOMEs are missing stack trace
   
   Co-authored-by: dongyun.tdy <dongyun.tdy at alibaba-inc.com>
   Reviewed-by: dholmes, coleenp
 - 8244669: convert clhsdb "mem" command from javascript to java
   
   Reviewed-by: sspitsyn, kevinw, poonam
 - 8209398: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed with "PKCS11Exception: CKR_ATTRIBUTE_SENSITIVE"
   
   Reviewed-by: hchao, weijun
 - Merge
 - 8279022: JCmdTestFileSafety.java should check file time stamp for test result
   
   Reviewed-by: ccheung
 - 8279018: CRC calculation in CDS should not include _version and _head_size
   
   Reviewed-by: iklam, ccheung
 - ... and 103 more: https://git.openjdk.java.net/jdk/compare/04ad6689...a3fcfa2b

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

Changes: https://git.openjdk.java.net/jdk/pull/6931/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6931&range=01
  Stats: 19323 lines in 545 files changed: 14840 ins; 3205 del; 1278 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6931.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6931/head:pull/6931

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


From jwilhelm at openjdk.java.net  Thu Dec 23 21:22:04 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 23 Dec 2021 21:22:04 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>
References: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>
Message-ID: <IDIFsv5ilpyholvzSNEyosRm8Ufm5r2cUvejdFAcLH0=.4431daf0-9246-4e36-9bcc-68181165b256@github.com>

On Thu, 23 Dec 2021 17:11:15 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: a3b1c6b0
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a3b1c6b03600da21b00a1f37ea4712096d636b14
Stats:     299 lines in 17 files changed: 141 ins; 126 del; 32 mod

Merge

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

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


From duke at openjdk.java.net  Wed Dec 29 19:41:55 2021
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 29 Dec 2021 19:41:55 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v2]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <g45JuCIr318VPitnrt3XOBzbhlNK0ozzpTsN4Y7RA0c=.ab437454-8c8f-40bc-8938-cd97f8bfa569@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ?
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

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

 - fix unsupported os in TestNativeLibrariesEvent.java
 - Removes unnecessary JFR sanity tests
 - Merge branch 'JDK-8203290' of github.com:backwaterred/jdk into JDK-8203290
 - 8203290: Implements Java Flight Recorder on AIX
   
    - changes build system to allow jfr feature on aix
    - implements NetworkPerformance, CPUPerformance, and SystemProcess
    interfaces from os_perf.hpp
    - implements jfr sanity tests
 - 8203290: Implements Java Flight Recorder on AIX
   
    - changes build system to allow jfr feature on aix
    - implements NetworkPerformance, CPUPerformance, and SystemProcess
    interfaces from os_perf.hpp
    - implements jfr sanity tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/a105951a..1fe36f65

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

  Stats: 59306 lines in 1564 files changed: 37906 ins; 12535 del; 8865 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

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


From duke at openjdk.java.net  Wed Dec 29 20:50:37 2021
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 29 Dec 2021 20:50:37 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v3]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <MNHfWLDDpaf90uWspzGCCKap56Nn3ZuiEWZTw0_XvaA=.068cb094-2dc7-48cf-9000-670efcc03ada@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ?
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

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

  Add misssing lib to jfr gtest

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/1fe36f65..7965898a

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

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

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


From duke at openjdk.java.net  Wed Dec 29 22:42:50 2021
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 29 Dec 2021 22:42:50 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v4]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <XHfPQldHkfXzD7GJHdkUcZUbIAb5-YuIOSt2HfGmpJI=.3c123d7b-f0fc-468c-a411-b9ece8e5cd2a@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ?
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

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

  Addresses possible memory leak in network_utilization Class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/7965898a..4c0b1877

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

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

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


From duke at openjdk.java.net  Wed Dec 29 23:14:52 2021
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 29 Dec 2021 23:14:52 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v5]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <lAuFaBmN9Mcnni-Hv9E24P9J2JAXqEuVSqt93VNuBZg=.8545060c-1afc-466d-b74b-809396e385b2@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ?
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

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

  Fix issue where network_interface pointer is not updated to newly created list

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/4c0b1877..a286c9a4

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

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

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


From benjamin.cook at bt.com  Fri Dec 17 17:15:49 2021
From: benjamin.cook at bt.com (benjamin.cook at bt.com)
Date: Fri, 17 Dec 2021 17:15:49 -0000
Subject: Struggling to build OpenJDK on Solaris 10
Message-ID: <LO2P123MB38709F63D9CB8D64B7E91ABD8D789@LO2P123MB3870.GBRP123.PROD.OUTLOOK.COM>

Hello,

I have successfully run the configure procedure for OpenJDK. I am now trying to run gmake but am getting the following error:

## Starting langtools
wc: cannot open /javabuild/jdk8u-777c3a63d228/build/solaris-sparc-normal-server-release/langtools/btclasses/_the.BUILD_TOOLS_batch.tmp
Compiling files for BUILD_TOOLS
javac: file not found: /javabuild/jdk8u-777c3a63d228/build/solaris-sparc-normal-server-release/langtools/btclasses/_the.BUILD_TOOLS_batch.tmp (No such file or directory)
gmake[1]: *** No rule to make target `all', needed by `default'.  Stop.
gmake: *** [langtools-only] Error 2


Any advise?


Kind Regards,

Benjamin Cook
Solution Design Specialist, Secure Platforms
Digital, Technology

T: +44 33 1621 2032



[EmailSigLogo]






This email contains information from BT that might be privileged or confidential. And it's only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks.
We monitor our email systems and may record all our emails.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000