From shade at openjdk.java.net  Mon Jan  3 11:41:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 3 Jan 2022 11:41:32 GMT
Subject: [jdk18] RFR: 8279379: GHA: Print tests that are in error
Message-ID: <MiXxnvrhl6EJgiQQzEbnzMMEM2HI5NAVGaA9CUczmow=.e3f97228-b5e6-428a-94ea-0417cc159eaa@github.com>

Current GHA workflow only prints `newfailures.txt` when tests fail. But the tests can also "ERROR" out. In which case, we want to print `other_errors.txt` as well. In current mainline GHA, we have a x86_32 langtools_tier1 failure like this:


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/langtools:tier1                         4282  4281     0     1 <<
==============================
TEST FAILURE

# newfailures.txt
<empty>

# other_errors.txt
jdk/javadoc/doclet/testLinkPlatform/TestLinkPlatform.java


I would like to get it in JDK 18 as well, to make GHA better during stabilization.

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk18/pull/75


From erikj at openjdk.java.net  Mon Jan  3 13:58:22 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 3 Jan 2022 13:58:22 GMT
Subject: [jdk18] RFR: 8279379: GHA: Print tests that are in error
In-Reply-To: <MiXxnvrhl6EJgiQQzEbnzMMEM2HI5NAVGaA9CUczmow=.e3f97228-b5e6-428a-94ea-0417cc159eaa@github.com>
References: <MiXxnvrhl6EJgiQQzEbnzMMEM2HI5NAVGaA9CUczmow=.e3f97228-b5e6-428a-94ea-0417cc159eaa@github.com>
Message-ID: <NC0SYEQTP_fDFWtbSBxkcWymoUqaKhCd1F7YkliRLEw=.5c033dfc-0634-454f-922d-a2510ea74a79@github.com>

On Mon, 3 Jan 2022 11:34:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current GHA workflow only prints `newfailures.txt` when tests fail. But the tests can also "ERROR" out. In which case, we want to print `other_errors.txt` as well. In current mainline GHA, we have a x86_32 langtools_tier1 failure like this:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/langtools:tier1                         4282  4281     0     1 <<
> ==============================
> TEST FAILURE
> 
> # newfailures.txt
> <empty>
> 
> # other_errors.txt
> jdk/javadoc/doclet/testLinkPlatform/TestLinkPlatform.java
> 
> 
> I would like to get it in JDK 18 as well, to make GHA better during stabilization.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/75


From erikj at openjdk.java.net  Mon Jan  3 14:01:12 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 3 Jan 2022 14:01:12 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v5]
In-Reply-To: <lAuFaBmN9Mcnni-Hv9E24P9J2JAXqEuVSqt93VNuBZg=.8545060c-1afc-466d-b74b-809396e385b2@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lAuFaBmN9Mcnni-Hv9E24P9J2JAXqEuVSqt93VNuBZg=.8545060c-1afc-466d-b74b-809396e385b2@github.com>
Message-ID: <ZZLlRDEvHLgSyOnTLqv817Et4LETQkrysduZy8S9f40=.95078892-71f5-4720-b15d-5882ee6bc485@github.com>

On Wed, 29 Dec 2021 23:14:52 GMT, Tyler Steele <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.
>
> 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

Build changes look ok. You will also need ok from someone in the component team.

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

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


From kcr at openjdk.java.net  Mon Jan  3 18:21:11 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 3 Jan 2022 18:21:11 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: <9XESKjSJ8po2-ZX49fJf-Fo8bek4s19SAoHo0UUESEU=.21b46b39-3c2c-4196-a996-60fad7897a0c@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 kcr (Author).

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

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


From darcy at openjdk.java.net  Mon Jan  3 18:33:35 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 3 Jan 2022 18:33:35 GMT
Subject: RFR: JDK-8277515: Update --release 18 symbol information for JDK 18
 build 29
Message-ID: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>

Usual update to the JDK 19 symbol files for changes in JDK 18; this time JDK-8276660 in JDK 18 build 28.

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

Commit messages:
 - JDK-8277515: Update --release 18 symbol information for JDK 18 build 29

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

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


From iris at openjdk.java.net  Mon Jan  3 19:16:20 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 3 Jan 2022 19:16:20 GMT
Subject: RFR: JDK-8277515: Update --release 18 symbol information for JDK
 18 build 29
In-Reply-To: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>
References: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>
Message-ID: <pNvm2NdUTa4azcWT-i9YXkoeSH7LkJypNbGGXy5x68Y=.ce7f18d5-d97b-4081-a3cc-cb6df437b2e1@github.com>

On Mon, 3 Jan 2022 18:26:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual update to the JDK 19 symbol files for changes in JDK 18; this time JDK-8276660 in JDK 18 build 28.

Marked as reviewed by iris (Reviewer).

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

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


From erikj at openjdk.java.net  Mon Jan  3 21:58:17 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 3 Jan 2022 21:58:17 GMT
Subject: Integrated: 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: <_P1P5TBdT6h4LeC4b9uS3MC6xd7INtY-_1uYqua96CI=.f553cbc0-89b8-4c8f-96f2-6f7dfa69ab3b@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.

This pull request has now been integrated.

Changeset: 6b906bba
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b906bbab1bdeceab9610cec8c6fd95128fddf32
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8279223: Define version in .jcheck/conf

Reviewed-by: alanb, iris, kcr

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

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


From clanger at openjdk.java.net  Tue Jan  4 09:31:15 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 4 Jan 2022 09:31:15 GMT
Subject: [jdk18] RFR: 8279379: GHA: Print tests that are in error
In-Reply-To: <MiXxnvrhl6EJgiQQzEbnzMMEM2HI5NAVGaA9CUczmow=.e3f97228-b5e6-428a-94ea-0417cc159eaa@github.com>
References: <MiXxnvrhl6EJgiQQzEbnzMMEM2HI5NAVGaA9CUczmow=.e3f97228-b5e6-428a-94ea-0417cc159eaa@github.com>
Message-ID: <UB2juq06ld7m2bUX4dvYA5gGdwIhXS911-zfCcgH2RE=.3564fee5-11bc-43e3-aaea-4e8e169a138c@github.com>

On Mon, 3 Jan 2022 11:34:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current GHA workflow only prints `newfailures.txt` when tests fail. But the tests can also "ERROR" out. In which case, we want to print `other_errors.txt` as well. In current mainline GHA, we have a x86_32 langtools_tier1 failure like this:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/langtools:tier1                         4282  4281     0     1 <<
> ==============================
> TEST FAILURE
> 
> # newfailures.txt
> <empty>
> 
> # other_errors.txt
> jdk/javadoc/doclet/testLinkPlatform/TestLinkPlatform.java
> 
> 
> I would like to get it in JDK 18 as well, to make GHA better during stabilization.

Marked as reviewed by clanger (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/75


From shade at openjdk.java.net  Tue Jan  4 11:16:17 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 4 Jan 2022 11:16:17 GMT
Subject: [jdk18] RFR: 8279379: GHA: Print tests that are in error
In-Reply-To: <MiXxnvrhl6EJgiQQzEbnzMMEM2HI5NAVGaA9CUczmow=.e3f97228-b5e6-428a-94ea-0417cc159eaa@github.com>
References: <MiXxnvrhl6EJgiQQzEbnzMMEM2HI5NAVGaA9CUczmow=.e3f97228-b5e6-428a-94ea-0417cc159eaa@github.com>
Message-ID: <BeIukTD5OZgeOIfm9CLArM263x1H42Wnh5diViJajLk=.ca576e38-2d63-452c-963f-6a6e8e88ca53@github.com>

On Mon, 3 Jan 2022 11:34:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current GHA workflow only prints `newfailures.txt` when tests fail. But the tests can also "ERROR" out. In which case, we want to print `other_errors.txt` as well. In current mainline GHA, we have a x86_32 langtools_tier1 failure like this:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/langtools:tier1                         4282  4281     0     1 <<
> ==============================
> TEST FAILURE
> 
> # newfailures.txt
> <empty>
> 
> # other_errors.txt
> jdk/javadoc/doclet/testLinkPlatform/TestLinkPlatform.java
> 
> 
> I would like to get it in JDK 18 as well, to make GHA better during stabilization.

Thanks for reviews, folks!

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

PR: https://git.openjdk.java.net/jdk18/pull/75


From shade at openjdk.java.net  Tue Jan  4 11:16:18 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 4 Jan 2022 11:16:18 GMT
Subject: [jdk18] Integrated: 8279379: GHA: Print tests that are in error
In-Reply-To: <MiXxnvrhl6EJgiQQzEbnzMMEM2HI5NAVGaA9CUczmow=.e3f97228-b5e6-428a-94ea-0417cc159eaa@github.com>
References: <MiXxnvrhl6EJgiQQzEbnzMMEM2HI5NAVGaA9CUczmow=.e3f97228-b5e6-428a-94ea-0417cc159eaa@github.com>
Message-ID: <V5rTpUjExnU7zhBsw8dq1SoU15SxFKPgQqXP19mYvDo=.834a1998-b705-4976-8a4f-816e6d8d8473@github.com>

On Mon, 3 Jan 2022 11:34:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current GHA workflow only prints `newfailures.txt` when tests fail. But the tests can also "ERROR" out. In which case, we want to print `other_errors.txt` as well. In current mainline GHA, we have a x86_32 langtools_tier1 failure like this:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/langtools:tier1                         4282  4281     0     1 <<
> ==============================
> TEST FAILURE
> 
> # newfailures.txt
> <empty>
> 
> # other_errors.txt
> jdk/javadoc/doclet/testLinkPlatform/TestLinkPlatform.java
> 
> 
> I would like to get it in JDK 18 as well, to make GHA better during stabilization.

This pull request has now been integrated.

Changeset: 06f37132
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/06f3713271f7827b376a3a9cfbfd3d91bc77f7de
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8279379: GHA: Print tests that are in error

Reviewed-by: erikj, clanger

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

PR: https://git.openjdk.java.net/jdk18/pull/75


From shade at openjdk.java.net  Tue Jan  4 12:22:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 4 Jan 2022 12:22:33 GMT
Subject: RFR: 8279445: Update JMH devkit to 1.34
Message-ID: <htlBXNRITJo-0Iaiika_qAnuItkKzIkerxCdaNfMWlI=.79b85167-cebe-4bb1-8180-5d99fb1048a2@github.com>

Brings lots of goodies, including automatic enablement of Compiler Blackholes: https://mail.openjdk.java.net/pipermail/jmh-dev/2021-December/003406.html 

Additional testing:
 - [x] Devkit creation works
 - [x] Sample benchmarks runs with new devkit

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

Commit messages:
 - Fix

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

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


From aph at openjdk.java.net  Tue Jan  4 13:17:11 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 4 Jan 2022 13:17:11 GMT
Subject: RFR: 8279445: Update JMH devkit to 1.34
In-Reply-To: <htlBXNRITJo-0Iaiika_qAnuItkKzIkerxCdaNfMWlI=.79b85167-cebe-4bb1-8180-5d99fb1048a2@github.com>
References: <htlBXNRITJo-0Iaiika_qAnuItkKzIkerxCdaNfMWlI=.79b85167-cebe-4bb1-8180-5d99fb1048a2@github.com>
Message-ID: <aGNf81QLgUPUUfBVFuh-rzkTb-3qX0GpQfmoMIFAaKY=.d7e3ef17-6e04-4fd4-aa85-734c7d7c08d6@github.com>

On Tue, 4 Jan 2022 12:15:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Brings lots of goodies, including automatic enablement of Compiler Blackholes: https://mail.openjdk.java.net/pipermail/jmh-dev/2021-December/003406.html 
> 
> Additional testing:
>  - [x] Devkit creation works
>  - [x] Sample benchmarks runs with new devkit

Marked as reviewed by aph (Reviewer).

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

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


From erikj at openjdk.java.net  Tue Jan  4 14:03:16 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 4 Jan 2022 14:03:16 GMT
Subject: RFR: 8279445: Update JMH devkit to 1.34
In-Reply-To: <htlBXNRITJo-0Iaiika_qAnuItkKzIkerxCdaNfMWlI=.79b85167-cebe-4bb1-8180-5d99fb1048a2@github.com>
References: <htlBXNRITJo-0Iaiika_qAnuItkKzIkerxCdaNfMWlI=.79b85167-cebe-4bb1-8180-5d99fb1048a2@github.com>
Message-ID: <ygt138hsJpiL-U6ImefgnuXiOI9y58VTJg8Ff1_ys8Y=.7931bd70-d5b5-460a-a6a7-175231eec9ff@github.com>

On Tue, 4 Jan 2022 12:15:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Brings lots of goodies, including automatic enablement of Compiler Blackholes: https://mail.openjdk.java.net/pipermail/jmh-dev/2021-December/003406.html 
> 
> Additional testing:
>  - [x] Devkit creation works
>  - [x] Sample benchmarks runs with new devkit

Marked as reviewed by erikj (Reviewer).

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

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


From jwilhelm at openjdk.java.net  Tue Jan  4 18:46:48 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 4 Jan 2022 18:46:48 GMT
Subject: RFR: Merge jdk18
Message-ID: <fDR8P9O2EsQla4YkjHJD0-BeJr63PiezGeylWoK-JoI=.18acd67a-9e06-482a-a758-418df5713273@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18
 - 8275830: C2: Receiver downcast is missing when inlining through method handle linkers
 - 8265317: [vector] assert(payload->is_object()) failed: expected 'object' value for scalar-replaced boxed vector but got: NULL
 - 8279379: GHA: Print tests that are in error
 - 8278966: two microbenchmarks tests fail "assert(!jvms->method()->has_exception_handlers()) failed: no exception handler expected" after JDK-8275638
 - 8278824: Uneven work distribution when scanning heap roots in G1

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6959&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6959&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/6959/files
  Stats: 161 lines in 9 files changed: 125 ins; 11 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6959/head:pull/6959

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


From jwilhelm at openjdk.java.net  Tue Jan  4 19:35:28 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 4 Jan 2022 19:35:28 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <fDR8P9O2EsQla4YkjHJD0-BeJr63PiezGeylWoK-JoI=.18acd67a-9e06-482a-a758-418df5713273@github.com>
References: <fDR8P9O2EsQla4YkjHJD0-BeJr63PiezGeylWoK-JoI=.18acd67a-9e06-482a-a758-418df5713273@github.com>
Message-ID: <feUX7qrqd7AmS-bXRomxklm_eLGFa91rUAEFg2RQ6Yw=.38fb99c9-2775-4007-9b77-9fd8899ce7b4@github.com>

On Tue, 4 Jan 2022 18:37:53 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 191f7307
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/191f7307bb2f2e2ce93480b4fc5fbbef216ff7cd
Stats:     161 lines in 9 files changed: 125 ins; 11 del; 25 mod

Merge

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

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


From serb at openjdk.java.net  Tue Jan  4 23:43:14 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 4 Jan 2022 23:43:14 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: <GnPt05V873fHYXJ9scilWQN-L17JlW_MjwyUtnrQBuY=.fd5752c8-5332-4d14-a5f2-83c46f060ab2@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

doc/testing.html line 198:

> 196: <p>Retry failed tests up to a set number of times. Defaults to 0.</p>
> 197: <h4 id="repeat_count">REPEAT_COUNT</h4>
> 198: <p>Repeat the tests for a set number of times. Defaults to 0.</p>

Don't we need to mention that the goal of the repeat_count is to run a test until it fails first (to reproduce intermittent issues)?

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

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


From shade at openjdk.java.net  Wed Jan  5 08:36:20 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 08:36:20 GMT
Subject: RFR: 8244602: Add JTREG_REPEAT_COUNT to repeat execution of a test
In-Reply-To: <GnPt05V873fHYXJ9scilWQN-L17JlW_MjwyUtnrQBuY=.fd5752c8-5332-4d14-a5f2-83c46f060ab2@github.com>
References: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
 <GnPt05V873fHYXJ9scilWQN-L17JlW_MjwyUtnrQBuY=.fd5752c8-5332-4d14-a5f2-83c46f060ab2@github.com>
Message-ID: <h9a18ztJ6ybGC3yEs4auIeAZhan8b39qyRrXd1ad_fw=.30618111-b69f-462e-b412-f1ab49ed9126@github.com>

On Tue, 4 Jan 2022 23:39:45 GMT, Sergey Bylokhov <serb 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
>
> doc/testing.html line 198:
> 
>> 196: <p>Retry failed tests up to a set number of times. Defaults to 0.</p>
>> 197: <h4 id="repeat_count">REPEAT_COUNT</h4>
>> 198: <p>Repeat the tests for a set number of times. Defaults to 0.</p>
> 
> Don't we need to mention that the goal of the repeat_count is to run a test until it fails first (to reproduce intermittent issues)?

We can. Current docs copy-pasted the form of `RETRY_COUNT` above. Both should be updated with some mention for use cases. Let me do that...

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

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


From shade at openjdk.java.net  Wed Jan  5 08:47:17 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 08:47:17 GMT
Subject: RFR: 8244602: Add JTREG_REPEAT_COUNT to repeat execution of a test
In-Reply-To: <h9a18ztJ6ybGC3yEs4auIeAZhan8b39qyRrXd1ad_fw=.30618111-b69f-462e-b412-f1ab49ed9126@github.com>
References: <n9UwDszUGSvrXICxM9chkfBj8JYtpgPngyBIHiKrOe4=.7c671011-8e90-44b8-8399-0e713a95f14b@github.com>
 <GnPt05V873fHYXJ9scilWQN-L17JlW_MjwyUtnrQBuY=.fd5752c8-5332-4d14-a5f2-83c46f060ab2@github.com>
 <h9a18ztJ6ybGC3yEs4auIeAZhan8b39qyRrXd1ad_fw=.30618111-b69f-462e-b412-f1ab49ed9126@github.com>
Message-ID: <cWxyYFKE-WHZ_48l_egwgDm5ggNoP5NxHjVrIDz8PJ4=.19f1eea4-9dc4-413d-9034-eb2f14584e6b@github.com>

On Wed, 5 Jan 2022 08:31:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> doc/testing.html line 198:
>> 
>>> 196: <p>Retry failed tests up to a set number of times. Defaults to 0.</p>
>>> 197: <h4 id="repeat_count">REPEAT_COUNT</h4>
>>> 198: <p>Repeat the tests for a set number of times. Defaults to 0.</p>
>> 
>> Don't we need to mention that the goal of the repeat_count is to run a test until it fails first (to reproduce intermittent issues)?
>
> We can. Current docs copy-pasted the form of `RETRY_COUNT` above. Both should be updated with some mention for use cases. Let me do that...

See #6964.

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

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


From shade at openjdk.java.net  Wed Jan  5 08:50:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 08:50:47 GMT
Subject: RFR: 8279505: Update documentation for RETRY_COUNT and REPEAT_COUNT
Message-ID: <bDrkUttTwxdm4Ha42mk48PpRNlv41THA0W4Zd4rTGQQ=.13ced41e-4aef-4d9c-a347-00cbd66b73f8@github.com>

Following up on suggestion here: 
 https://github.com/openjdk/jdk/pull/6720#discussion_r778457819

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

Commit messages:
 - Fix

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

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


From shade at openjdk.java.net  Wed Jan  5 12:07:16 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 12:07:16 GMT
Subject: RFR: 8279445: Update JMH devkit to 1.34
In-Reply-To: <htlBXNRITJo-0Iaiika_qAnuItkKzIkerxCdaNfMWlI=.79b85167-cebe-4bb1-8180-5d99fb1048a2@github.com>
References: <htlBXNRITJo-0Iaiika_qAnuItkKzIkerxCdaNfMWlI=.79b85167-cebe-4bb1-8180-5d99fb1048a2@github.com>
Message-ID: <sXkwPNMjH2I8oqlm2WZR6YjlFTijFsHhRP87fSRyTGk=.0c80982c-6d71-4c4c-a899-5cf8815aa1ab@github.com>

On Tue, 4 Jan 2022 12:15:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Brings lots of goodies, including automatic enablement of Compiler Blackholes: https://mail.openjdk.java.net/pipermail/jmh-dev/2021-December/003406.html 
> 
> Additional testing:
>  - [x] Devkit creation works
>  - [x] Sample benchmarks runs with new devkit

Thanks for reviews!

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

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


From shade at openjdk.java.net  Wed Jan  5 12:07:17 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 12:07:17 GMT
Subject: Integrated: 8279445: Update JMH devkit to 1.34
In-Reply-To: <htlBXNRITJo-0Iaiika_qAnuItkKzIkerxCdaNfMWlI=.79b85167-cebe-4bb1-8180-5d99fb1048a2@github.com>
References: <htlBXNRITJo-0Iaiika_qAnuItkKzIkerxCdaNfMWlI=.79b85167-cebe-4bb1-8180-5d99fb1048a2@github.com>
Message-ID: <mKqDXJgszIB8joopmykWXubdbys82us7iMY1MMA090Q=.28b637d7-6f82-4d3e-b7fd-392a62ed95b0@github.com>

On Tue, 4 Jan 2022 12:15:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Brings lots of goodies, including automatic enablement of Compiler Blackholes: https://mail.openjdk.java.net/pipermail/jmh-dev/2021-December/003406.html 
> 
> Additional testing:
>  - [x] Devkit creation works
>  - [x] Sample benchmarks runs with new devkit

This pull request has now been integrated.

Changeset: 0f98efbf
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0f98efbf2f0e47bb398fe7ca5235853e1d98df3a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8279445: Update JMH devkit to 1.34

Reviewed-by: aph, erikj

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

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


From erikj at openjdk.java.net  Wed Jan  5 13:37:15 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 5 Jan 2022 13:37:15 GMT
Subject: RFR: 8279505: Update documentation for RETRY_COUNT and
 REPEAT_COUNT
In-Reply-To: <bDrkUttTwxdm4Ha42mk48PpRNlv41THA0W4Zd4rTGQQ=.13ced41e-4aef-4d9c-a347-00cbd66b73f8@github.com>
References: <bDrkUttTwxdm4Ha42mk48PpRNlv41THA0W4Zd4rTGQQ=.13ced41e-4aef-4d9c-a347-00cbd66b73f8@github.com>
Message-ID: <o_XUR2A2XJjvma5Xqf05zpTq7Hlr-ujbPSG1i28lNhk=.835bdb92-8e75-421d-99f1-cb864feb1e81@github.com>

On Wed, 5 Jan 2022 08:42:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Following up on suggestion here: 
>  https://github.com/openjdk/jdk/pull/6720#discussion_r778457819

Marked as reviewed by erikj (Reviewer).

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

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


From darcy at openjdk.java.net  Wed Jan  5 18:59:16 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 Jan 2022 18:59:16 GMT
Subject: Integrated: JDK-8277515: Update --release 18 symbol information for
 JDK 18 build 29
In-Reply-To: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>
References: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>
Message-ID: <BnQmjkOjkHHzWJlWkhYV6tTtKQ49659A9036Uq_yFco=.354f2114-928f-4cdb-a704-bf11011baf54@github.com>

On Mon, 3 Jan 2022 18:26:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual update to the JDK 19 symbol files for changes in JDK 18; this time JDK-8276660 in JDK 18 build 28.

This pull request has now been integrated.

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

8277515: Update --release 18 symbol information for JDK 18 build 29

Reviewed-by: iris

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

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


From naoto at openjdk.java.net  Wed Jan  5 22:51:48 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 5 Jan 2022 22:51:48 GMT
Subject: RFR: 8268081: Support for Unicode 14
Message-ID: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>

Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.

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

Commit messages:
 - Amend unicode.md and icu.md files
 - Minor fixup
 - Merge branch 'master' into unicode
 - Copyright year to 2022
 - ICU4J 70.1
 - 18 -> 19
 - Merge branch 'master' into unicode
 - Unicode 14.0.0 (final)
 - UCD ver. 14.0 (beta) / Unicode Text Segmentation rev. 38 (draft)
 - ICU4J 69.1

Changes: https://git.openjdk.java.net/jdk/pull/6974/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6974&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268081
  Stats: 3443 lines in 41 files changed: 2353 ins; 101 del; 989 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6974/head:pull/6974

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


From joehw at openjdk.java.net  Thu Jan  6 01:49:12 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 6 Jan 2022 01:49:12 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
References: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
Message-ID: <SuLo6G1MZNVqo7y_wjGeed1AzDy1CpXd3SpqwyHWEeQ=.a902f32e-fddf-47ad-b764-84df8f87fdfc@github.com>

On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.

Marked as reviewed by joehw (Reviewer).

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

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


From joehw at openjdk.java.net  Thu Jan  6 01:52:12 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 6 Jan 2022 01:52:12 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
References: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
Message-ID: <O0KroRtaLqhQ--DAaQNO3dINb0ZU4r2R4zQwpbMEHAg=.eac51836-c2a8-43be-851a-ea19736c4dbc@github.com>

On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.

I like how they changed dizzy face to face with crossed-out eyes. Pistol to water pistol, that's even better, just to avoid any confusion  ;-)

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

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


From iris at openjdk.java.net  Thu Jan  6 05:24:14 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 6 Jan 2022 05:24:14 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
References: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
Message-ID: <TxlmHhondpDoxXY1TbvtuGWV5MwNaGBtaFmrNchz5R0=.f446055a-b921-4c25-a920-7aa5e1eeb236@github.com>

On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.

Marked as reviewed by iris (Reviewer).

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

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


From serb at openjdk.java.net  Thu Jan  6 06:02:15 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 6 Jan 2022 06:02:15 GMT
Subject: RFR: 8279505: Update documentation for RETRY_COUNT and
 REPEAT_COUNT
In-Reply-To: <bDrkUttTwxdm4Ha42mk48PpRNlv41THA0W4Zd4rTGQQ=.13ced41e-4aef-4d9c-a347-00cbd66b73f8@github.com>
References: <bDrkUttTwxdm4Ha42mk48PpRNlv41THA0W4Zd4rTGQQ=.13ced41e-4aef-4d9c-a347-00cbd66b73f8@github.com>
Message-ID: <USWj30w0fnZxDI_hNhL8HFkRytP49atNDtgFSSeAOYY=.d8d69482-a8aa-4a3e-8cfc-9f7c5ad01ad0@github.com>

On Wed, 5 Jan 2022 08:42:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Following up on suggestion here: 
>  https://github.com/openjdk/jdk/pull/6720#discussion_r778457819

Thank you!

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

Marked as reviewed by serb (Reviewer).

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


From shade at openjdk.java.net  Thu Jan  6 08:31:20 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 6 Jan 2022 08:31:20 GMT
Subject: Integrated: 8279505: Update documentation for RETRY_COUNT and
 REPEAT_COUNT
In-Reply-To: <bDrkUttTwxdm4Ha42mk48PpRNlv41THA0W4Zd4rTGQQ=.13ced41e-4aef-4d9c-a347-00cbd66b73f8@github.com>
References: <bDrkUttTwxdm4Ha42mk48PpRNlv41THA0W4Zd4rTGQQ=.13ced41e-4aef-4d9c-a347-00cbd66b73f8@github.com>
Message-ID: <z9JpUWV1zpFiNIop-a6kjFpK1yqbDy0-xubkxjk1idQ=.1f3eb832-ca47-44d2-9fe1-1b42423b8380@github.com>

On Wed, 5 Jan 2022 08:42:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Following up on suggestion here: 
>  https://github.com/openjdk/jdk/pull/6720#discussion_r778457819

This pull request has now been integrated.

Changeset: bc123811
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bc12381105ef5ba14f99304a220817e97c9a99b5
Stats:     8 lines in 2 files changed: 4 ins; 0 del; 4 mod

8279505: Update documentation for RETRY_COUNT and REPEAT_COUNT

Reviewed-by: erikj, serb

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

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


From lancea at openjdk.java.net  Thu Jan  6 17:58:16 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 6 Jan 2022 17:58:16 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
References: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
Message-ID: <fa3n0BGQpzq3P4sGTmnd67Nkyho5rTQE-UF1ThiEY-g=.435514c7-c59d-49fb-bb27-64c621c52c27@github.com>

On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.

Marked as reviewed by lancea (Reviewer).

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

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


From tim.bell at oracle.com  Thu Jan  6 19:21:25 2022
From: tim.bell at oracle.com (tim.bell at oracle.com)
Date: Thu, 6 Jan 2022 11:21:25 -0800
Subject: Need OpenJDK to be used on PowerPC for our products.
In-Reply-To: <MW4PR17MB47955D139CA293A0A18DD690914C9@MW4PR17MB4795.namprd17.prod.outlook.com>
References: <MW4PR17MB47955D139CA293A0A18DD690914C9@MW4PR17MB4795.namprd17.prod.outlook.com>
Message-ID: <09a0042e-b0c0-df7b-062a-985e78422806@oracle.com>

-------- Forwarded Message --------
Subject: 	RE: Need OpenJDK to be used on PowerPC for our products.
Date: 	Thu, 6 Jan 2022 19:16:10 +0000
From: 	Dipendu Ghosh <dipendu.ghosh at keysight.com>
To: 	mailman-owner



Hi,

I am an Engineer from Keysight Technologies. In Keysight, we have a few 
products where we use Java. At present we are using Java distribution 
from Oracle. Since there is some licensing issue raised by Oracle we 
need to move to OpenJDK distributions.

We have a requirement where we need to deploy Java 8 on the PowerPC 
processor and Java is not readily available on this particular platform. 
Will it be possible if you can provide us with Open JDK which can be 
used on the PowerPC processor?

I am trying to follow the steps to compile OpenJDK for PPC following the 
link https://openjdk.java.net/groups/build/doc/building.html but I am 
stuck at cross compilation. Any help in this regard will be highly 
appreciated.

Will be eagerly waiting to hear back from you on a positive note.

Thanks & Regards,

Dipendu Ghosh

Senior Software Engineer II,

Keysight Technologies

dipendu.ghosh at keysight.com



From dipendu.ghosh at keysight.com  Thu Jan  6 20:28:28 2022
From: dipendu.ghosh at keysight.com (Dipendu Ghosh)
Date: Thu, 6 Jan 2022 20:28:28 +0000
Subject: Unable to build OpenJDK for cross platform.
Message-ID: <MW4PR17MB47952FE1B3699702AB7D94D1914C9@MW4PR17MB4795.namprd17.prod.outlook.com>

Hi,

I was following the steps to cross compile OpenJDK from https://openjdk.java.net/groups/build/doc/building.html.

But, the cross compilation fails at the below step.

Failure step:-
sh ./configure \
  --openjdk-target=aarch64-linux-gnu \
  --with-sysroot=~/sysroot-arm64

Error is as below:-
"configure: error: Could not find X11 libraries. You might be able to fix this by running 'sudo apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev'. configure exiting with result code 1"
The fix provided after the error is not solving the problem since the packages are already installed but somehow they are not being included in the sysroot.

Prior to the failure step I have executed the below command:-
sudo qemu-debootstrap \
--arch=arm64 \
--verbose \
--include=autoconf,fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libxss-dev,libxxf86vm-dev,libxkbfile-dev,libxv-dev,libxinerama-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libjpeg-dev,libpng-dev,libffi-dev,jtreg
--resolve-deps \
buster \
~/sysroot-arm64 \
http://httpredir.debian.org/debian/

Please help me resolving this error.

Thanks & Regards,
Dipendu Ghosh
Senior Software Engineer II,
Keysight Technologies
dipendu.ghosh at keysight.com<mailto:dipendu.ghosh at keysight.com>


From david.holmes at oracle.com  Fri Jan  7 00:05:05 2022
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 7 Jan 2022 10:05:05 +1000
Subject: Need OpenJDK to be used on PowerPC for our products.
In-Reply-To: <09a0042e-b0c0-df7b-062a-985e78422806@oracle.com>
References: <MW4PR17MB47955D139CA293A0A18DD690914C9@MW4PR17MB4795.namprd17.prod.outlook.com>
 <09a0042e-b0c0-df7b-062a-985e78422806@oracle.com>
Message-ID: <8fc6c530-2518-7c8a-6ac7-bce33b0c2be0@oracle.com>

On 7/01/2022 5:21 am, tim.bell at oracle.com wrote:
> -------- Forwarded Message --------
> Subject:???? RE: Need OpenJDK to be used on PowerPC for our products.
> Date:???? Thu, 6 Jan 2022 19:16:10 +0000
> From:???? Dipendu Ghosh <dipendu.ghosh at keysight.com>
> To:???? mailman-owner
> 
> 
> 
> Hi,
> 
> I am an Engineer from Keysight Technologies. In Keysight, we have a few 
> products where we use Java. At present we are using Java distribution 
> from Oracle. Since there is some licensing issue raised by Oracle we 
> need to move to OpenJDK distributions.
> 
> We have a requirement where we need to deploy Java 8 on the PowerPC 
> processor and Java is not readily available on this particular platform. 
> Will it be possible if you can provide us with Open JDK which can be 
> used on the PowerPC processor?

The AdoptOpenJDK project provides such builds:

https://adoptium.net/releases.html?variant=openjdk8

Cheers,
David
-----

> I am trying to follow the steps to compile OpenJDK for PPC following the 
> link https://openjdk.java.net/groups/build/doc/building.html but I am 
> stuck at cross compilation. Any help in this regard will be highly 
> appreciated.
> 
> Will be eagerly waiting to hear back from you on a positive note.
> 
> Thanks & Regards,
> 
> Dipendu Ghosh
> 
> Senior Software Engineer II,
> 
> Keysight Technologies
> 
> dipendu.ghosh at keysight.com
> 


From dipendu.ghosh at keysight.com  Fri Jan  7 08:38:34 2022
From: dipendu.ghosh at keysight.com (Dipendu Ghosh)
Date: Fri, 7 Jan 2022 08:38:34 +0000
Subject: Need OpenJDK to be used on PowerPC for our products.
In-Reply-To: <8fc6c530-2518-7c8a-6ac7-bce33b0c2be0@oracle.com>
References: <MW4PR17MB47955D139CA293A0A18DD690914C9@MW4PR17MB4795.namprd17.prod.outlook.com>
 <09a0042e-b0c0-df7b-062a-985e78422806@oracle.com>
 <8fc6c530-2518-7c8a-6ac7-bce33b0c2be0@oracle.com>
Message-ID: <MW4PR17MB47951066857017949123F62E914D9@MW4PR17MB4795.namprd17.prod.outlook.com>

Thank You David for the link. But that does not provide builds for Linux/PPC32 (single core e500v2).



I am trying to build the code locally following the steps available at https://openjdk.java.net/groups/build/doc/building.htmlbut but I am facing the below error while trying to cross compile.



Failure step:-

sh ./configure \

  --openjdk-target=aarch64-linux-gnu \

  --with-sysroot=~/sysroot-arm64



Error is as below:-

?configure: error: Could not find X11 libraries. You might be able to fix this by running 'sudo apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev'. configure exiting with result code 1?

The fix provided after the error is not solving the problem since the packages are already installed but somehow they are not being included in the sysroot.



Prior to the failure step I have executed the below command:-

sudo qemu-debootstrap \

--arch=arm64 \

--verbose \

--include=autoconf,fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libxss-dev,libxxf86vm-dev,libxkbfile-dev,libxv-dev,libxinerama-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libjpeg-dev,libpng-dev,libffi-dev,jtreg

--resolve-deps \

buster \

~/sysroot-arm64 \

http://httpredir.debian.org/debian/


Thanks & Regards,
Dipendu Ghosh
Senior Software Engineer II,
Keysight Technologies
dipendu.ghosh at keysight.com<mailto:dipendu.ghosh at keysight.com>



-----Original Message-----
From: David Holmes <david.holmes at oracle.com>
Sent: 07 January 2022 05:35
To: build-dev at openjdk.java.net; Dipendu Ghosh <dipendu.ghosh at keysight.com>
Subject: Re: Need OpenJDK to be used on PowerPC for our products.



CAUTION: This message originates from an external sender.



On 7/01/2022 5:21 am, tim.bell at oracle.com<mailto:tim.bell at oracle.com> wrote:

> -------- Forwarded Message --------

> Subject:     RE: Need OpenJDK to be used on PowerPC for our products.

> Date:     Thu, 6 Jan 2022 19:16:10 +0000

> From:     Dipendu Ghosh <dipendu.ghosh at keysight.com<mailto:dipendu.ghosh at keysight.com>>

> To:     mailman-owner

>

>

>

> Hi,

>

> I am an Engineer from Keysight Technologies. In Keysight, we have a

> few products where we use Java. At present we are using Java

> distribution from Oracle. Since there is some licensing issue raised

> by Oracle we need to move to OpenJDK distributions.

>

> We have a requirement where we need to deploy Java 8 on the PowerPC

> processor and Java is not readily available on this particular platform.

> Will it be possible if you can provide us with Open JDK which can be

> used on the PowerPC processor?



The AdoptOpenJDK project provides such builds:



https://urldefense.com/v3/__https://adoptium.net/releases.html?variant=openjdk8__;!!I5pVk4LIGAfnvw!2qVvABDs0nwUByHueQTSm_CA8UOpab4k2I0PMVXyThTTTTvyOv-Spbt-nmkDLSK_jkMQiQ$<https://urldefense.com/v3/__https:/adoptium.net/releases.html?variant=openjdk8__;!!I5pVk4LIGAfnvw!2qVvABDs0nwUByHueQTSm_CA8UOpab4k2I0PMVXyThTTTTvyOv-Spbt-nmkDLSK_jkMQiQ$>



Cheers,

David

-----



> I am trying to follow the steps to compile OpenJDK for PPC following

> the link

> https://urldefense.com/v3/__https://openjdk.java.net/groups/build/doc/<https://urldefense.com/v3/__https:/openjdk.java.net/groups/build/doc/>

> building.html__;!!I5pVk4LIGAfnvw!2qVvABDs0nwUByHueQTSm_CA8UOpab4k2I0PMVXyThTTTTvyOv-Spbt-nmkDLSIe0_6ZXA$  but I am stuck at cross compilation. Any help in this regard will be highly appreciated.

>

> Will be eagerly waiting to hear back from you on a positive note.

>

> Thanks & Regards,

>

> Dipendu Ghosh

>

> Senior Software Engineer II,

>

> Keysight Technologies

>

> dipendu.ghosh at keysight.com<mailto:dipendu.ghosh at keysight.com>

>

From shade at redhat.com  Fri Jan  7 09:07:44 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 7 Jan 2022 10:07:44 +0100
Subject: Need OpenJDK to be used on PowerPC for our products.
In-Reply-To: <MW4PR17MB47951066857017949123F62E914D9@MW4PR17MB4795.namprd17.prod.outlook.com>
References: <MW4PR17MB47955D139CA293A0A18DD690914C9@MW4PR17MB4795.namprd17.prod.outlook.com>
 <09a0042e-b0c0-df7b-062a-985e78422806@oracle.com>
 <8fc6c530-2518-7c8a-6ac7-bce33b0c2be0@oracle.com>
 <MW4PR17MB47951066857017949123F62E914D9@MW4PR17MB4795.namprd17.prod.outlook.com>
Message-ID: <30d354f0-693b-412c-d715-02fdb3965012@redhat.com>

On 1/7/22 9:38 AM, Dipendu Ghosh wrote:
> Thank You David for the link. But that does not provide builds for Linux/PPC32 (single core e500v2).

PPC32 is not a supported platform, so you would not be be able to compile "Server" (C1/C2 compilers) 
for it. You would be able to compile "Zero" (pure C++ interpreter), but that would produce 20..50x 
slower binary.

Evidence that current mainline (JDK 19+) can be configured and built for Linux/PPC32/Zero:
 
https://builds.shipilev.net/openjdk-jdk/configure-logs/configure-openjdk-jdk-linux-ppc-zero-release-gcc10-glibc2.31.log
 
https://builds.shipilev.net/openjdk-jdk/build-logs/build-openjdk-jdk-linux-ppc-zero-release-gcc10-glibc2.31.log
   https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-linux-ppc-zero-release-gcc10-glibc2.31.tar.xz

Generally, I would warn that getting PPC32 (old hardware) to work reasonably well on JDK 8 (old 
release) would be much harder than just cross-compiling it. Unless you can find a vendor that does 
that for you, be prepared to do *a lot* of work.

Please read the previous paragraph again.

> Failure step:-
> 
> sh ./configure \
>    --openjdk-target=aarch64-linux-gnu \
>    --with-sysroot=~/sysroot-arm64
> 
> Error is as below:-
> 
> ?configure: error: Could not find X11 libraries. You might be able to fix this by running 'sudo apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev'. configure exiting with result code 1?
> 
> The fix provided after the error is not solving the problem since the packages are already installed but somehow they are not being included in the sysroot.

Several problems here.

First, you are trying to build arm64 binaries, not ppc32.

Second, the default search paths work well for JDK 11 and 17, but on JDK 8, you sometimes have to 
point to library locations by hand, e.g see "using configure arguments" line here: 
https://builds.shipilev.net/openjdk-jdk8/configure-logs/configure-linux-aarch64-server-fastdebug.log

Third, I think PPC32 would still not compile on JDK 8, because some massaging would be required to 
accept a new architecture in the build. I might be wrong about that part, though. I cannot remember 
what was the reason why my CIs are only building PPC64 Zero for JDK 8...

-- 
Thanks,
-Aleksey



From dipendu.ghosh at keysight.com  Fri Jan  7 10:06:05 2022
From: dipendu.ghosh at keysight.com (Dipendu Ghosh)
Date: Fri, 7 Jan 2022 10:06:05 +0000
Subject: Need OpenJDK to be used on PowerPC for our products.
In-Reply-To: <30d354f0-693b-412c-d715-02fdb3965012@redhat.com>
References: <MW4PR17MB47955D139CA293A0A18DD690914C9@MW4PR17MB4795.namprd17.prod.outlook.com>
 <09a0042e-b0c0-df7b-062a-985e78422806@oracle.com>
 <8fc6c530-2518-7c8a-6ac7-bce33b0c2be0@oracle.com>
 <MW4PR17MB47951066857017949123F62E914D9@MW4PR17MB4795.namprd17.prod.outlook.com>
 <30d354f0-693b-412c-d715-02fdb3965012@redhat.com>
Message-ID: <MW4PR17MB47950A43F42E9607A870A702914D9@MW4PR17MB4795.namprd17.prod.outlook.com>

Thank You Aleksey for the clarification.

It was my mistake that I mentioned about PPC32 and my commands were trying to build for another platform.
At present I am trying to setup the build environment for OpenJDK. So I followed the steps present at https://openjdk.java.net/groups/build/doc/building.html.
The default build steps ran fine and the output was generated for linux-x86_64-server-release. Now I am trying to execute the cross compilation which is for aarch64-linux-gnu.
All these which I am trying are being executed on the latest code from https://git.openjdk.java.net/jdk/ so I am not working on OpenJDK 8 at present.

Thanks & Regards,
Dipendu

-----Original Message-----
From: Aleksey Shipilev <shade at redhat.com> 
Sent: 07 January 2022 14:38
To: Dipendu Ghosh <dipendu.ghosh at keysight.com>; David Holmes <david.holmes at oracle.com>; build-dev at openjdk.java.net
Subject: Re: Need OpenJDK to be used on PowerPC for our products.

CAUTION: This message originates from an external sender.

On 1/7/22 9:38 AM, Dipendu Ghosh wrote:
> Thank You David for the link. But that does not provide builds for Linux/PPC32 (single core e500v2).

PPC32 is not a supported platform, so you would not be be able to compile "Server" (C1/C2 compilers) for it. You would be able to compile "Zero" (pure C++ interpreter), but that would produce 20..50x slower binary.

Evidence that current mainline (JDK 19+) can be configured and built for Linux/PPC32/Zero:

https://urldefense.com/v3/__https://builds.shipilev.net/openjdk-jdk/configure-logs/configure-openjdk-jdk-linux-ppc-zero-release-gcc10-glibc2.31.log__;!!I5pVk4LIGAfnvw!x3Rv0V9KaXy7JXJNfVgwddCv5m9J5jH0v0SOg2QU4HAa6aGLJd73duL6EoyDQzPos1dGaA$

https://urldefense.com/v3/__https://builds.shipilev.net/openjdk-jdk/build-logs/build-openjdk-jdk-linux-ppc-zero-release-gcc10-glibc2.31.log__;!!I5pVk4LIGAfnvw!x3Rv0V9KaXy7JXJNfVgwddCv5m9J5jH0v0SOg2QU4HAa6aGLJd73duL6EoyDQzN64vQZjw$
   https://urldefense.com/v3/__https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-linux-ppc-zero-release-gcc10-glibc2.31.tar.xz__;!!I5pVk4LIGAfnvw!x3Rv0V9KaXy7JXJNfVgwddCv5m9J5jH0v0SOg2QU4HAa6aGLJd73duL6EoyDQzNMbl5hNQ$

Generally, I would warn that getting PPC32 (old hardware) to work reasonably well on JDK 8 (old
release) would be much harder than just cross-compiling it. Unless you can find a vendor that does that for you, be prepared to do *a lot* of work.

Please read the previous paragraph again.

> Failure step:-
>
> sh ./configure \
>    --openjdk-target=aarch64-linux-gnu \
>    --with-sysroot=~/sysroot-arm64
>
> Error is as below:-
>
> ?configure: error: Could not find X11 libraries. You might be able to fix this by running 'sudo apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev'. configure exiting with result code 1?
>
> The fix provided after the error is not solving the problem since the packages are already installed but somehow they are not being included in the sysroot.

Several problems here.

First, you are trying to build arm64 binaries, not ppc32.

Second, the default search paths work well for JDK 11 and 17, but on JDK 8, you sometimes have to point to library locations by hand, e.g see "using configure arguments" line here:
https://urldefense.com/v3/__https://builds.shipilev.net/openjdk-jdk8/configure-logs/configure-linux-aarch64-server-fastdebug.log__;!!I5pVk4LIGAfnvw!x3Rv0V9KaXy7JXJNfVgwddCv5m9J5jH0v0SOg2QU4HAa6aGLJd73duL6EoyDQzN4XXiMhQ$

Third, I think PPC32 would still not compile on JDK 8, because some massaging would be required to accept a new architecture in the build. I might be wrong about that part, though. I cannot remember what was the reason why my CIs are only building PPC64 Zero for JDK 8...

--
Thanks,
-Aleksey


From aph-open at littlepinkcloud.com  Fri Jan  7 10:12:56 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 7 Jan 2022 10:12:56 +0000
Subject: Need OpenJDK to be used on PowerPC for our products.
In-Reply-To: <MW4PR17MB47951066857017949123F62E914D9@MW4PR17MB4795.namprd17.prod.outlook.com>
References: <MW4PR17MB47955D139CA293A0A18DD690914C9@MW4PR17MB4795.namprd17.prod.outlook.com>
 <09a0042e-b0c0-df7b-062a-985e78422806@oracle.com>
 <8fc6c530-2518-7c8a-6ac7-bce33b0c2be0@oracle.com>
 <MW4PR17MB47951066857017949123F62E914D9@MW4PR17MB4795.namprd17.prod.outlook.com>
Message-ID: <bbdce900-f500-e6ce-99cc-86edf2604612@littlepinkcloud.com>

On 1/7/22 08:38, Dipendu Ghosh wrote:
> ?configure: error: Could not find X11 libraries. You might be able to fix this by running 'sudo apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev'. configure exiting with result code 1?
> 
> The fix provided after the error is not solving the problem since the packages are already installed but somehow they are not being included in the sysroot.

It is your job to copy target versions of the packages into the sysroot.
The easiest way to do this is to install the packages into the root
filesystem of your target and then copy that filesystem into your
sysroot.

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


From shade at redhat.com  Fri Jan  7 10:23:33 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 7 Jan 2022 11:23:33 +0100
Subject: Need OpenJDK to be used on PowerPC for our products.
In-Reply-To: <MW4PR17MB47950A43F42E9607A870A702914D9@MW4PR17MB4795.namprd17.prod.outlook.com>
References: <MW4PR17MB47955D139CA293A0A18DD690914C9@MW4PR17MB4795.namprd17.prod.outlook.com>
 <09a0042e-b0c0-df7b-062a-985e78422806@oracle.com>
 <8fc6c530-2518-7c8a-6ac7-bce33b0c2be0@oracle.com>
 <MW4PR17MB47951066857017949123F62E914D9@MW4PR17MB4795.namprd17.prod.outlook.com>
 <30d354f0-693b-412c-d715-02fdb3965012@redhat.com>
 <MW4PR17MB47950A43F42E9607A870A702914D9@MW4PR17MB4795.namprd17.prod.outlook.com>
Message-ID: <5a4e060e-7050-9bb6-b554-e960a2c7be6b@redhat.com>


On 1/7/22 11:06 AM, Dipendu Ghosh wrote:
> At present I am trying to setup the build environment for OpenJDK. So I followed the steps 
> present at https://openjdk.java.net/groups/build/doc/building.html. 

I think that's a mirror of in-tree docs:
   https://github.com/openjdk/jdk/blob/master/doc/building.md#cross-compiling-with-debian-sysroots

I'd go for in-tree docs, as those are supposed to be most up to date.

> The default build steps ran fine and the output was generated for linux-x86_64-server-release.
> Now I am trying to execute the cross compilation which is for aarch64-linux-gnu.
Okay. We know that should work, because GHA routinely cross-compile x86_64 -> aarch64:
 
https://github.com/openjdk/jdk/blob/62d03c283667c4122130ec9bbeec623e6a2840e5/.github/workflows/submit.yml#L513-L558

-- 
Thanks,
-Aleksey



From ysuenaga at openjdk.java.net  Sat Jan  8 02:07:52 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 8 Jan 2022 02:07:52 GMT
Subject: RFR: 8279644: hsdis may not work when it was built with
 --with-binutils=system
Message-ID: <xbelK9-BSS57a_C95MQWpWeDMxBDbM5dgUZs9RI5c0o=.07fe4bb0-cf58-47a5-8c0f-9310631f6eb8@github.com>

[JDK-8277089](https://bugs.openjdk.java.net/browse/JDK-8277089) (PR #6378 ) introduced the feature to build hsdis with binutils which is provided by the system, however it may not work when it was build with --with-binutils=system.

We can see the following message when the problem happens. I saw it on Ubuntu 20.04.


hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform


The cause is `-DLIBARCH_$OPENJDK_TARGET_CPU_LEGACY_LIB` is not set in `HSDIS_CFLAGS`. For example, it will be set `LIBARCH_amd64` on AMD64. We should set `LIBARCH_$OPENJDK_TARGET_CPU_LEGACY_LIB` to `HSDIS_CFLAGS` even if the builder uses system binutils.

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

Commit messages:
 - 8279644: hsdis may not work when it was built with --with-binutils=system

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

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


From erikj at openjdk.java.net  Mon Jan 10 13:34:41 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 10 Jan 2022 13:34:41 GMT
Subject: RFR: 8279644: hsdis may not work when it was built with
 --with-binutils=system
In-Reply-To: <xbelK9-BSS57a_C95MQWpWeDMxBDbM5dgUZs9RI5c0o=.07fe4bb0-cf58-47a5-8c0f-9310631f6eb8@github.com>
References: <xbelK9-BSS57a_C95MQWpWeDMxBDbM5dgUZs9RI5c0o=.07fe4bb0-cf58-47a5-8c0f-9310631f6eb8@github.com>
Message-ID: <7FokvFB1tJlD2TQ12l2q5HIqXGIFlaV1LpPdekls-Po=.8d1c9bba-b71e-4ab1-98d6-c041fb3cfa33@github.com>

On Sat, 8 Jan 2022 02:00:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> [JDK-8277089](https://bugs.openjdk.java.net/browse/JDK-8277089) (PR #6378 ) introduced the feature to build hsdis with binutils which is provided by the system, however it may not work when it was build with --with-binutils=system.
> 
> We can see the following message when the problem happens. I saw it on Ubuntu 20.04.
> 
> 
> hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform
> 
> 
> The cause is `-DLIBARCH_$OPENJDK_TARGET_CPU_LEGACY_LIB` is not set in `HSDIS_CFLAGS`. For example, it will be set `LIBARCH_amd64` on AMD64. We should set `LIBARCH_$OPENJDK_TARGET_CPU_LEGACY_LIB` to `HSDIS_CFLAGS` even if the builder uses system binutils.

Marked as reviewed by erikj (Reviewer).

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

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


From duke at openjdk.java.net  Tue Jan 11 00:11:04 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 11 Jan 2022 00:11:04 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v6]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <e4QhcfSW9QqAu0H9T2VdfvFpRNZaejtedRMJXREnViw=.a9eb98c7-1b45-4255-b116-2df3260aa7ac@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 six additional commits since the last revision:

 - Merge branch 'JDK-8203290' into JDK-8203290-testing
 - Review changes, fix failing tests
 - Remove issue preventing TestNativeLibrariesEvent.java from building
   
   - Test should now fail
 - Fix issue where network_interface pointer is not updated to newly created list
 - Addresses possible memory leak in network_utilization Class
 - 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/a286c9a4..79bfca43

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

  Stats: 337 lines in 4 files changed: 78 ins; 160 del; 99 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 ysuenaga at openjdk.java.net  Tue Jan 11 00:24:29 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 11 Jan 2022 00:24:29 GMT
Subject: Integrated: 8279644: hsdis may not work when it was built with
 --with-binutils=system
In-Reply-To: <xbelK9-BSS57a_C95MQWpWeDMxBDbM5dgUZs9RI5c0o=.07fe4bb0-cf58-47a5-8c0f-9310631f6eb8@github.com>
References: <xbelK9-BSS57a_C95MQWpWeDMxBDbM5dgUZs9RI5c0o=.07fe4bb0-cf58-47a5-8c0f-9310631f6eb8@github.com>
Message-ID: <gSCNJirPnQoSTaK0wdkQ6z02P2MgEJuMjkLuro7hjvY=.69efd35b-1a64-4a87-ba6f-9f8bd7e62779@github.com>

On Sat, 8 Jan 2022 02:00:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> [JDK-8277089](https://bugs.openjdk.java.net/browse/JDK-8277089) (PR #6378 ) introduced the feature to build hsdis with binutils which is provided by the system, however it may not work when it was build with --with-binutils=system.
> 
> We can see the following message when the problem happens. I saw it on Ubuntu 20.04.
> 
> 
> hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform
> 
> 
> The cause is `-DLIBARCH_$OPENJDK_TARGET_CPU_LEGACY_LIB` is not set in `HSDIS_CFLAGS`. For example, it will be set `LIBARCH_amd64` on AMD64. We should set `LIBARCH_$OPENJDK_TARGET_CPU_LEGACY_LIB` to `HSDIS_CFLAGS` even if the builder uses system binutils.

This pull request has now been integrated.

Changeset: 2f7665b8
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2f7665b8292cc09574d62fecc3e9619c488ac137
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8279644: hsdis may not work when it was built with --with-binutils=system

Reviewed-by: erikj

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

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


From aleonard at openjdk.java.net  Tue Jan 11 10:31:51 2022
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 11 Jan 2022 10:31:51 GMT
Subject: RFR: 8279834: Alpine Linux fails to build when --with-source-date
 enabled
Message-ID: <CHjlZccSjA00N4f8-UUXnwrI00ayUeMmaa2N3AB_49E=.1e43b68b-3e30-495e-9c80-44389c4dc5b4@github.com>

The new reproducible build jar & jmod feature exposed a problem on Alpline linux whereby when --with-source-date is specified the IS_GNU_DATE setting was actually wrong. It was assuming the BusyBox "date" tool on Alpine linux was BSD compatible, but it is actually GNU syntax compatible.

This PR additionally checks for BusyBox when determining the date tool version compatibility.

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

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

Commit messages:
 - 8279834: Alpine Linux fails to build when --with-source-date enabled

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

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


From erikj at openjdk.java.net  Tue Jan 11 13:57:23 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 11 Jan 2022 13:57:23 GMT
Subject: RFR: 8279834: Alpine Linux fails to build when --with-source-date
 enabled
In-Reply-To: <CHjlZccSjA00N4f8-UUXnwrI00ayUeMmaa2N3AB_49E=.1e43b68b-3e30-495e-9c80-44389c4dc5b4@github.com>
References: <CHjlZccSjA00N4f8-UUXnwrI00ayUeMmaa2N3AB_49E=.1e43b68b-3e30-495e-9c80-44389c4dc5b4@github.com>
Message-ID: <QOlyU0bOTBXOpW2k1fNTFq8LQ9trzNy11WFdT-cs0D0=.d97b629e-8ca5-469f-97e2-58455ba69b3f@github.com>

On Tue, 11 Jan 2022 10:25:31 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> The new reproducible build jar & jmod feature exposed a problem on Alpline linux whereby when --with-source-date is specified the IS_GNU_DATE setting was actually wrong. It was assuming the BusyBox "date" tool on Alpine linux was BSD compatible, but it is actually GNU syntax compatible.
> 
> This PR additionally checks for BusyBox when determining the date tool version compatibility.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Marked as reviewed by erikj (Reviewer).

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

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


From aleonard at openjdk.java.net  Tue Jan 11 14:08:28 2022
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 11 Jan 2022 14:08:28 GMT
Subject: RFR: 8279834: Alpine Linux fails to build when --with-source-date
 enabled
In-Reply-To: <QOlyU0bOTBXOpW2k1fNTFq8LQ9trzNy11WFdT-cs0D0=.d97b629e-8ca5-469f-97e2-58455ba69b3f@github.com>
References: <CHjlZccSjA00N4f8-UUXnwrI00ayUeMmaa2N3AB_49E=.1e43b68b-3e30-495e-9c80-44389c4dc5b4@github.com>
 <QOlyU0bOTBXOpW2k1fNTFq8LQ9trzNy11WFdT-cs0D0=.d97b629e-8ca5-469f-97e2-58455ba69b3f@github.com>
Message-ID: <NnG9T8Y4nZiqDMYP16FQJvZmPSvvAEcPD2cclenJZNQ=.fc60c767-29d3-48af-9e05-9e8313bdf878@github.com>

On Tue, 11 Jan 2022 13:53:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The new reproducible build jar & jmod feature exposed a problem on Alpline linux whereby when --with-source-date is specified the IS_GNU_DATE setting was actually wrong. It was assuming the BusyBox "date" tool on Alpine linux was BSD compatible, but it is actually GNU syntax compatible.
>> 
>> This PR additionally checks for BusyBox when determining the date tool version compatibility.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Marked as reviewed by erikj (Reviewer).

thank you @erikj79

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

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


From aleonard at openjdk.java.net  Tue Jan 11 14:25:29 2022
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 11 Jan 2022 14:25:29 GMT
Subject: Integrated: 8279834: Alpine Linux fails to build when
 --with-source-date enabled
In-Reply-To: <CHjlZccSjA00N4f8-UUXnwrI00ayUeMmaa2N3AB_49E=.1e43b68b-3e30-495e-9c80-44389c4dc5b4@github.com>
References: <CHjlZccSjA00N4f8-UUXnwrI00ayUeMmaa2N3AB_49E=.1e43b68b-3e30-495e-9c80-44389c4dc5b4@github.com>
Message-ID: <78pFqKF7_s0BmhaoGC6y2gK6ZmhoYfcqOqFNbCiF0-Q=.1ad62530-8f8d-400d-b453-ab21ba0990a0@github.com>

On Tue, 11 Jan 2022 10:25:31 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> The new reproducible build jar & jmod feature exposed a problem on Alpline linux whereby when --with-source-date is specified the IS_GNU_DATE setting was actually wrong. It was assuming the BusyBox "date" tool on Alpine linux was BSD compatible, but it is actually GNU syntax compatible.
> 
> This PR additionally checks for BusyBox when determining the date tool version compatibility.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: 9e024476
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9e0244762c0961b1bb3453d294531997b367e757
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8279834: Alpine Linux fails to build when --with-source-date enabled

Reviewed-by: erikj

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

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


From duke at openjdk.java.net  Tue Jan 11 16:53:08 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 11 Jan 2022 16:53:08 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v5]
In-Reply-To: <ZZLlRDEvHLgSyOnTLqv817Et4LETQkrysduZy8S9f40=.95078892-71f5-4720-b15d-5882ee6bc485@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lAuFaBmN9Mcnni-Hv9E24P9J2JAXqEuVSqt93VNuBZg=.8545060c-1afc-466d-b74b-809396e385b2@github.com>
 <ZZLlRDEvHLgSyOnTLqv817Et4LETQkrysduZy8S9f40=.95078892-71f5-4720-b15d-5882ee6bc485@github.com>
Message-ID: <W4fjkr9Ts8XtxQCBaPTGiQjKy1ZI1xNASI-bM5hNUYo=.ec9c16c5-ddc5-47dc-95d7-da9e1179bcfd@github.com>

On Mon, 3 Jan 2022 13:57:59 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> 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
>
> Build changes look ok. You will also need ok from someone in the component team.

@erikj79 
Regarding the TOC warning I mentioned above:

- I now believe the TOC warning has been present while building the master branch (so this PR probably isn't the root cause).
- I've also noticed that the addition of `-qpic=large` in [flags-cflags.m4](https://github.com/backwaterred/jdk/blob/79bfca43a729675da9c95a59fead373f76e9feac/make/autoconf/flags-cflags.m4#L429) hasn't removed the build warning about a TOC overflow.

Because of the above, I've removed `-qpic=large` from the line above.

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

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


From duke at openjdk.java.net  Tue Jan 11 16:53:05 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 11 Jan 2022 16:53:05 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v7]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <rPB9xl_uKW6-tMYEBbhupPnYQbcIWwQUWtkIyAH4xgE=.aacff5d8-7015-4368-b68c-9cc334982577@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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Clean up & testing
  
  - Run JFR tests in test/jdk/jdk/jfr
  - Fix issues found from above test suite
  - Remove unecessary jtreg & gtest tests
  - Remove ineffective `qpic=large`
  - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/79bfca43..cc04740a

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

  Stats: 1 line in 1 file changed: 0 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  Tue Jan 11 16:59:29 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 11 Jan 2022 16:59:29 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v7]
In-Reply-To: <rPB9xl_uKW6-tMYEBbhupPnYQbcIWwQUWtkIyAH4xgE=.aacff5d8-7015-4368-b68c-9cc334982577@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <rPB9xl_uKW6-tMYEBbhupPnYQbcIWwQUWtkIyAH4xgE=.aacff5d8-7015-4368-b68c-9cc334982577@github.com>
Message-ID: <zMOlwI7UHzpf_8ZazjM55yUPAV2Wg76-_ANAwxkr4VA=.f51a5d98-2122-411b-bf9a-48255135c96e@github.com>

On Tue, 11 Jan 2022 16:53:05 GMT, Tyler Steele <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.
>
> Tyler Steele has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Clean up & testing
>   
>   - Run JFR tests in test/jdk/jdk/jfr
>   - Fix issues found from above test suite
>   - Remove unecessary jtreg & gtest tests
>   - Remove ineffective `qpic=large`
>   - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java

After running the test suite mentioned above, I found and fixed several issues with the PR. Only one failing test remains, and I am seeking some help with it.

I'm looking for some clarification on the purpose TestNativeLibrariesEvent.java. Currently it fails with "Missing libraries:libjvm.so, libjava.so, libzip.so: expected true, was false". I find those libs in my build directory, and everything else seems to work. Can anyone provide an idea why this test is failing (or what the failure means)?

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

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


From erikj at openjdk.java.net  Tue Jan 11 17:13:30 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 11 Jan 2022 17:13:30 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v5]
In-Reply-To: <ZZLlRDEvHLgSyOnTLqv817Et4LETQkrysduZy8S9f40=.95078892-71f5-4720-b15d-5882ee6bc485@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lAuFaBmN9Mcnni-Hv9E24P9J2JAXqEuVSqt93VNuBZg=.8545060c-1afc-466d-b74b-809396e385b2@github.com>
 <ZZLlRDEvHLgSyOnTLqv817Et4LETQkrysduZy8S9f40=.95078892-71f5-4720-b15d-5882ee6bc485@github.com>
Message-ID: <FdQGTUC9bDNrKq1rd87uJyVuvq3Ss6a3FbPLx96liMg=.e980120b-6e48-43df-911a-c0ccdeee7841@github.com>

On Mon, 3 Jan 2022 13:57:59 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Tyler Steele has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> Build changes look ok. You will also need ok from someone in the component team.

> @erikj79 Regarding the TOC warning I mentioned above:
> 
> * I now believe the TOC warning has been present while building the master branch (so this PR probably isn't the root cause).
> * I've also noticed that the addition of `-qpic=large` in [flags-cflags.m4](https://github.com/backwaterred/jdk/blob/79bfca43a729675da9c95a59fead373f76e9feac/make/autoconf/flags-cflags.m4#L429) hasn't removed the build warning about a TOC overflow.
> 
> For the above reasons, I've removed `-qpic=large` from the line linked above.

I can't really comment on any AIX specific compiler flags as I'm not familiar with AIX and not representing a company that supports it. All I can say is that the build changes look sane from a structural point of view. I don't know if anyone here is able to judge the choice of AIX specific flags better than yourself.

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

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


From duke at openjdk.java.net  Tue Jan 11 17:44:26 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 11 Jan 2022 17:44:26 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v5]
In-Reply-To: <FdQGTUC9bDNrKq1rd87uJyVuvq3Ss6a3FbPLx96liMg=.e980120b-6e48-43df-911a-c0ccdeee7841@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lAuFaBmN9Mcnni-Hv9E24P9J2JAXqEuVSqt93VNuBZg=.8545060c-1afc-466d-b74b-809396e385b2@github.com>
 <ZZLlRDEvHLgSyOnTLqv817Et4LETQkrysduZy8S9f40=.95078892-71f5-4720-b15d-5882ee6bc485@github.com>
 <FdQGTUC9bDNrKq1rd87uJyVuvq3Ss6a3FbPLx96liMg=.e980120b-6e48-43df-911a-c0ccdeee7841@github.com>
Message-ID: <lUG_prrKUBbman91lQGJZk_WWwzu1Z9UEGlVNgq9dTk=.0c726c09-25eb-4df2-a2c9-9114bacf5bc1@github.com>

On Tue, 11 Jan 2022 17:10:13 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I can't really comment on any AIX specific compiler flags as I'm not familiar with AIX and not representing a company that supports it. All I can say is that the build changes look sane from a structural point of view. I don't know if anyone here is able to judge the choice of AIX specific flags better than yourself.

Good to know. Thanks for clarifying.

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

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


From duke at openjdk.java.net  Tue Jan 11 17:51:32 2022
From: duke at openjdk.java.net (Saint Wesonga)
Date: Tue, 11 Jan 2022 17:51:32 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <RTjg8mAEZjmQ3LiTuk6f4AtEg2_FwKtfAw9hPsYz6v8=.4196f853-5291-427e-bec7-57067fdb58b0@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
 <RTjg8mAEZjmQ3LiTuk6f4AtEg2_FwKtfAw9hPsYz6v8=.4196f853-5291-427e-bec7-57067fdb58b0@github.com>
Message-ID: <DC0shIlkPGNT1VVyoY3o2sgnxTdIZKy0q_qpn5EDiV8=.4448968d-4395-401f-b0ce-4f56788f3d0f@github.com>

On Wed, 17 Nov 2021 13:17:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch expands the newly added system for hsdis backends to include LLVM.
>> 
>> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
>> 
>> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
>> 
>> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.
>
> Yeah bot, I'm still working on it.

@magicus @JornVernee Thank you for starting this PR and for the notes on the Windows changes. I'm trying them out on macOS and Windows.

@theRealAph I'm not as familiar with the mac platform. Did you need to do anything special to address these errors? I was adding -L/opt/homebrew/opt/llvm/lib to the HSDIS_LDFLAGS.

```Undefined symbols for architecture arm64:
  "_LLVMCreateDisasm", referenced from:
      hsdis_backend::hsdis_backend(unsigned long, unsigned long, unsigned char*, unsigned long, void* (*)(void*, char const*, void*), void*, int (*)(void*, char const*, ...), void*, char const*, int) in hsdis-llvm.o
  "_LLVMDisasmDispose", referenced from:
      hsdis_backend::~hsdis_backend() in hsdis-llvm.o
...
ld: symbol(s) not found for architecture arm64
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

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

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


From mikael at openjdk.java.net  Tue Jan 11 21:12:44 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Tue, 11 Jan 2022 21:12:44 GMT
Subject: RFR: 8279884: Use better file for cygwin source permission check
Message-ID: <R1UsHdnZUoUJa9ZxYUvAJVjPG-f3UvExg8B5tVeoAh8=.866eb1ac-f97d-4bcd-ae4b-14971c4f9d81@github.com>

For sanity, configure tries to verify that source files have the right permissions by checking the LICENSE file in TOPDIR. That file may not always be available, and for builds where it isn't configure will generate a (harmless) error along the lines of:

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

Commit messages:
 - 8279884: Use better file for cygwin source permission check

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

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


From erikj at openjdk.java.net  Tue Jan 11 21:20:21 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 11 Jan 2022 21:20:21 GMT
Subject: RFR: 8279884: Use better file for cygwin source permission check
In-Reply-To: <R1UsHdnZUoUJa9ZxYUvAJVjPG-f3UvExg8B5tVeoAh8=.866eb1ac-f97d-4bcd-ae4b-14971c4f9d81@github.com>
References: <R1UsHdnZUoUJa9ZxYUvAJVjPG-f3UvExg8B5tVeoAh8=.866eb1ac-f97d-4bcd-ae4b-14971c4f9d81@github.com>
Message-ID: <oIwDHh-WAiuC00bzS9Knis7e5mffz8ByV-5LqqrE2cQ=.05b4246a-ef02-4c50-bd17-c6e29e276919@github.com>

On Tue, 11 Jan 2022 21:07:17 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> For sanity, configure tries to verify that source files have the right permissions by checking the LICENSE file in TOPDIR. That file may not always be available, and for builds where it isn't configure will generate a (harmless) error along the lines of:

Marked as reviewed by erikj (Reviewer).

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

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


From mikael at openjdk.java.net  Tue Jan 11 22:37:31 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Tue, 11 Jan 2022 22:37:31 GMT
Subject: Integrated: 8279884: Use better file for cygwin source permission
 check
In-Reply-To: <R1UsHdnZUoUJa9ZxYUvAJVjPG-f3UvExg8B5tVeoAh8=.866eb1ac-f97d-4bcd-ae4b-14971c4f9d81@github.com>
References: <R1UsHdnZUoUJa9ZxYUvAJVjPG-f3UvExg8B5tVeoAh8=.866eb1ac-f97d-4bcd-ae4b-14971c4f9d81@github.com>
Message-ID: <obJqyolHB3cfSPbM49pFWfU0ANyZUExzNnxsZfblHE4=.a566a361-31ff-482a-a88a-e225eabd0136@github.com>

On Tue, 11 Jan 2022 21:07:17 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> For sanity, configure tries to verify that source files have the right permissions by checking the LICENSE file in TOPDIR. That file may not always be available, and for builds where it isn't configure will generate a (harmless) error along the lines of:

This pull request has now been integrated.

Changeset: 36f41cbe
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/36f41cbe1126c6d9a00b21a1a68cf5f44e2f443f
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8279884: Use better file for cygwin source permission check

Reviewed-by: erikj

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

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


From duke at openjdk.java.net  Wed Jan 12 07:35:45 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Wed, 12 Jan 2022 07:35:45 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md
Message-ID: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>

Currently the information about using IDEA can only be found on mailing lists.

Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.

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

Commit messages:
 - Update IDEA and VS documentation

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

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


From mdoerr at openjdk.java.net  Wed Jan 12 11:47:24 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 12 Jan 2022 11:47:24 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v7]
In-Reply-To: <rPB9xl_uKW6-tMYEBbhupPnYQbcIWwQUWtkIyAH4xgE=.aacff5d8-7015-4368-b68c-9cc334982577@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <rPB9xl_uKW6-tMYEBbhupPnYQbcIWwQUWtkIyAH4xgE=.aacff5d8-7015-4368-b68c-9cc334982577@github.com>
Message-ID: <Ri4iVBtDjmp26Z6--YpHDHAZkN1iqCX19jbNbw0UNU0=.9febd3eb-3c3c-483b-8739-e2b015d88884@github.com>

On Tue, 11 Jan 2022 16:53:05 GMT, Tyler Steele <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.
>
> Tyler Steele has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Clean up & testing
>   
>   - Run JFR tests in test/jdk/jdk/jfr
>   - Fix issues found from above test suite
>   - Remove unecessary jtreg & gtest tests
>   - Remove ineffective `qpic=large`
>   - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java

The change looks good to me. I only had a quick look at the new os_perf_aix implementation, so someone else should serve as 2nd reviewer (no Reviewer status required). The old code was a copy from linux as a placeholder. Note that we don't build and test on AIX anymore.

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

Marked as reviewed by mdoerr (Reviewer).

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


From lancea at openjdk.java.net  Wed Jan 12 11:58:22 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 12 Jan 2022 11:58:22 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md
In-Reply-To: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
Message-ID: <IeGtsbtgjBjR7DdLzm2z7DkwRG9zjV-VSt2JFD6qbPQ=.d5da3454-671a-4f9b-91d5-b02f25f46148@github.com>

On Wed, 12 Jan 2022 07:29:33 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

> Currently the information about using IDEA can only be found on mailing lists.
> 
> Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.

Thank you for taking a stab at this.  As far as I am aware, the ide.html should be generated from the ide.md so you should only need to modify ide.md

doc/ide.md line 88:

> 86: ```
> 87: 
> 88: This creates a subfolder called `.idea` in the current folder. To use it,

I might consider rewording this.  Typically this is run at the top of the your openjdk fork/clone.

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

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


From duke at openjdk.java.net  Wed Jan 12 12:14:26 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Wed, 12 Jan 2022 12:14:26 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md
In-Reply-To: <IeGtsbtgjBjR7DdLzm2z7DkwRG9zjV-VSt2JFD6qbPQ=.d5da3454-671a-4f9b-91d5-b02f25f46148@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
 <IeGtsbtgjBjR7DdLzm2z7DkwRG9zjV-VSt2JFD6qbPQ=.d5da3454-671a-4f9b-91d5-b02f25f46148@github.com>
Message-ID: <3ngmr1VcMpP63weXr4M625KXiEsvJkiz5-TYPaUsYCM=.21243e97-7fb4-40c3-9d6e-976a7d877b8a@github.com>

On Wed, 12 Jan 2022 11:55:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> (...) As far as I am aware, the ide.html should be generated from the ide.md so you should only need to modify ide.md

Are you sure about this? The discussion on #5676 suggests that the HTML files need to be modified.

I wouldn't mind not having to edit htmls; `make update-build-docs` is broken on Cygwin, and I had to fix paths in compile commands manually.

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

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


From lancea at openjdk.java.net  Wed Jan 12 12:20:20 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 12 Jan 2022 12:20:20 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md
In-Reply-To: <3ngmr1VcMpP63weXr4M625KXiEsvJkiz5-TYPaUsYCM=.21243e97-7fb4-40c3-9d6e-976a7d877b8a@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
 <IeGtsbtgjBjR7DdLzm2z7DkwRG9zjV-VSt2JFD6qbPQ=.d5da3454-671a-4f9b-91d5-b02f25f46148@github.com>
 <3ngmr1VcMpP63weXr4M625KXiEsvJkiz5-TYPaUsYCM=.21243e97-7fb4-40c3-9d6e-976a7d877b8a@github.com>
Message-ID: <PSqAOdsOh3hUs4fHf9UDcRc12xcPqKduPgW2CiDNnhU=.73c432d2-cf2d-4556-92d8-cc94a22c905f@github.com>

On Wed, 12 Jan 2022 12:10:50 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

> > (...) As far as I am aware, the ide.html should be generated from the ide.md so you should only need to modify ide.md
> 
> Are you sure about this? The discussion on #5676 suggests that the HTML files need to be modified.
> 
> I wouldn't mind not having to edit htmls; `make update-build-docs` is broken on Cygwin, and I had to fix paths in compile commands manually.

Yes pandoc as far as I am aware should be generating the html so lets wait for Erik to comment as it seems strange to have to do both and would be better to address the issue so only one file needs updated if there is indeed an issue.

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

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


From erikj at openjdk.java.net  Wed Jan 12 14:04:23 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 12 Jan 2022 14:04:23 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md
In-Reply-To: <PSqAOdsOh3hUs4fHf9UDcRc12xcPqKduPgW2CiDNnhU=.73c432d2-cf2d-4556-92d8-cc94a22c905f@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
 <IeGtsbtgjBjR7DdLzm2z7DkwRG9zjV-VSt2JFD6qbPQ=.d5da3454-671a-4f9b-91d5-b02f25f46148@github.com>
 <3ngmr1VcMpP63weXr4M625KXiEsvJkiz5-TYPaUsYCM=.21243e97-7fb4-40c3-9d6e-976a7d877b8a@github.com>
 <PSqAOdsOh3hUs4fHf9UDcRc12xcPqKduPgW2CiDNnhU=.73c432d2-cf2d-4556-92d8-cc94a22c905f@github.com>
Message-ID: <M0XTReeLqLuyUSLrm9ZLNwrriz7LkUAFJfPF834RylU=.62dfa4ff-8e63-47fb-a139-808638d8b9c5@github.com>

On Wed, 12 Jan 2022 12:17:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > > (...) As far as I am aware, the ide.html should be generated from the ide.md so you should only need to modify ide.md
> > 
> > 
> > Are you sure about this? The discussion on #5676 suggests that the HTML files need to be modified.
> > I wouldn't mind not having to edit htmls; `make update-build-docs` is broken on Cygwin, and I had to fix paths in compile commands manually.
> 
> Yes pandoc as far as I am aware should be generating the html so lets wait for Erik to comment as it seems strange to have to do both and would be better to address the issue so only one file needs updated if there is indeed an issue.

You should only manually edit the .md files and then let pandoc generate .html files using `make update-build-docs`. Both types of files should then be included in the commit. If you have trouble generating .html files this way, you will need help from someone who can. Let me know when the textual content of this patch is considered final, then I can do it for you if you like.

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

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


From erikj at openjdk.java.net  Wed Jan 12 14:13:21 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 12 Jan 2022 14:13:21 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md
In-Reply-To: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
Message-ID: <mffOyJxgeuMqotVaJD618v8mThJXfiu9zKtLWazZxI4=.d6d4f901-c084-482c-92bf-fbf91312de06@github.com>

On Wed, 12 Jan 2022 07:29:33 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

> Currently the information about using IDEA can only be found on mailing lists.
> 
> Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.

Added some suggestions on language.

doc/ide.md line 49:

> 47: 
> 48: The make system can generate a Visual Studio project for a limited subset
> 49: of native sources. After configuring, the project can be generated using:

The limited subset is hotspot, which is a pretty clear separation. 
Suggestion:

The make system can generate a Visual Studio project for the Hotspot 
native source. After configuring, the project is be generated using:

doc/ide.md line 81:

> 79: 
> 80: The JDK project has a script that can be used for indexing the project
> 81: with IntelliJ. After configuring and building the JDK, IntelliJ workspace

Suggestion:

with IntelliJ. After configuring and building the JDK, an IntelliJ workspace

doc/ide.md line 89:

> 87: 
> 88: This creates a subfolder called `.idea` in the current folder. To use it,
> 89: choose `File -> Open...` in IntelliJ and select the folder where you run

Suggestion:

choose `File -> Open...` in IntelliJ and select the folder where you ran

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

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


From duke at openjdk.java.net  Wed Jan 12 14:46:54 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Wed, 12 Jan 2022 14:46:54 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md [v2]
In-Reply-To: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
Message-ID: <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>

> Currently the information about using IDEA can only be found on mailing lists.
> 
> Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.

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

  Improved wording

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7044/files
  - new: https://git.openjdk.java.net/jdk/pull/7044/files/1f4e99ca..b6d81300

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

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

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


From duke at openjdk.java.net  Wed Jan 12 14:49:25 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Wed, 12 Jan 2022 14:49:25 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md
In-Reply-To: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
Message-ID: <zHqRPqPKqcjmNO7ei7BEcRdgZ36XtznO7VVHtVuC2s4=.c04b9057-36cb-4a2a-846e-a749e1717ff7@github.com>

On Wed, 12 Jan 2022 07:29:33 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

> Currently the information about using IDEA can only be found on mailing lists.
> 
> Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.

Thanks for all your suggestions. Let me know if the current version is acceptable.

Re pandoc, it looks like the Windows version is generating similar output to the Linux one, so I think I can handle this. Thanks for the offer.

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

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


From duke at openjdk.java.net  Wed Jan 12 15:18:46 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 12 Jan 2022 15:18:46 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v8]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@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 pull request now contains five commits:

 - Merge branch 'master' into JDK-8203290
 - Clean up & testing
   
   - Run JFR tests in test/jdk/jdk/jfr
   - Fix issues found from above test suite
   - Remove unecessary jtreg & gtest tests
   - Remove ineffective `qpic=large`
   - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java
 - 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: https://git.openjdk.java.net/jdk/pull/6885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=07
  Stats: 831 lines in 5 files changed: 151 ins; 514 del; 166 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 erikj at openjdk.java.net  Wed Jan 12 15:46:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 12 Jan 2022 15:46:35 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md [v2]
In-Reply-To: <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
 <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>
Message-ID: <QEt5p31rabu7UycHqEX78irnp6OYb8BCGFitbwFyBTc=.3d565bbc-f631-4e32-88ba-a34f19315c13@github.com>

On Wed, 12 Jan 2022 14:46:54 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

>> Currently the information about using IDEA can only be found on mailing lists.
>> 
>> Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.
>
> Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved wording

Contents of ide.md looks good. As long as ide.html is generated correctly using pandoc I'm good with this.

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

Marked as reviewed by erikj (Reviewer).

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


From duke at openjdk.java.net  Wed Jan 12 17:11:37 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Wed, 12 Jan 2022 17:11:37 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: <BbJRPOB6NKZ9An0q6BWvd0dxIFj_qXe6rxDY86B8ZVU=.b522a311-e67e-49ad-9cb7-040e05b87a2a@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

Coming back to this work for 2021....

I've just done a complete run of all the jtreg tests on this patch with both PAC on and PAC off on a PAC enabled machine.
With PAC off I saw no regressions. With PAC on I saw ~250 regressions - mostly Shenendoah tests, but with a few ZGC and serviceability tests too. Is it worth holding this patch up for those fixes?

In addition the CSR still needs a review: https://bugs.openjdk.java.net/browse/JDK-8277543

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

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


From adinn at openjdk.java.net  Wed Jan 12 17:21:30 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Wed, 12 Jan 2022 17:21:30 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v11]
In-Reply-To: <BbJRPOB6NKZ9An0q6BWvd0dxIFj_qXe6rxDY86B8ZVU=.b522a311-e67e-49ad-9cb7-040e05b87a2a@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <imt57f8ms-TPW030GNf47ixU_zxpIH785uty3hM7G9s=.0d6c08c0-3b2f-440b-add2-1614698078b8@github.com>
 <BbJRPOB6NKZ9An0q6BWvd0dxIFj_qXe6rxDY86B8ZVU=.b522a311-e67e-49ad-9cb7-040e05b87a2a@github.com>
Message-ID: <eA6NyC-Tyqs-rOqOZFWnq-DAq3RjlW3KMk0o5KR0oQw=.57a97ade-54e8-4e5f-a3f5-8ae878c985b2@github.com>

On Wed, 12 Jan 2022 17:08:34 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> Is it worth holding this patch up for those fixes?

Probably. It depends on exactly what is failing. Can you provide more info?

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

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


From lancea at openjdk.java.net  Wed Jan 12 18:12:22 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 12 Jan 2022 18:12:22 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md [v2]
In-Reply-To: <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
 <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>
Message-ID: <L-TK2fZT7hAmSrkcXNXKypZLkxvmHWhrO2poruOKnCg=.9705f93f-2698-4195-a815-027a4f33578d@github.com>

On Wed, 12 Jan 2022 14:46:54 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

>> Currently the information about using IDEA can only be found on mailing lists.
>> 
>> Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.
>
> Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved wording

I think you are good to go with your latest set of changes.

Not sure if you want to refer to the idea.sh -h for additional options (though that does not seem to give you any detail regarding the options)

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

Marked as reviewed by lancea (Reviewer).

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


From duke at openjdk.java.net  Wed Jan 12 18:32:29 2022
From: duke at openjdk.java.net (Saint Wesonga)
Date: Wed, 12 Jan 2022 18:32:29 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <RTjg8mAEZjmQ3LiTuk6f4AtEg2_FwKtfAw9hPsYz6v8=.4196f853-5291-427e-bec7-57067fdb58b0@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
 <RTjg8mAEZjmQ3LiTuk6f4AtEg2_FwKtfAw9hPsYz6v8=.4196f853-5291-427e-bec7-57067fdb58b0@github.com>
Message-ID: <yDxFAXLDq5iJDjyDVgmzG5C-7fkD0oiWoeWJXoqh_qU=.8603d7d6-3fbb-423c-a31a-2a5706a1e8b4@github.com>

On Wed, 17 Nov 2021 13:17:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch expands the newly added system for hsdis backends to include LLVM.
>> 
>> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
>> 
>> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
>> 
>> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.
>
> Yeah bot, I'm still working on it.

> @magicus @JornVernee Thank you for starting this PR and for the notes on the Windows changes. I'm trying them out on macOS and Windows.
> 
> @theRealAph I'm not as familiar with the mac platform. Did you need to do anything special to address these errors? I was adding -L/opt/homebrew/opt/llvm/lib to the HSDIS_LDFLAGS.
> 
> ```
>   "_LLVMCreateDisasm", referenced from:
>       hsdis_backend::hsdis_backend(unsigned long, unsigned long, unsigned char*, unsigned long, void* (*)(void*, char const*, void*), void*, int (*)(void*, char const*, ...), void*, char const*, int) in hsdis-llvm.o
>   "_LLVMDisasmDispose", referenced from:
>       hsdis_backend::~hsdis_backend() in hsdis-llvm.o
> ...
> ld: symbol(s) not found for architecture arm64
> clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
> ```

Turns out I just needed to add /opt/homebrew/opt/llvm/bin to my PATH. I can now use --with-hsdis=llvm.

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

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


From kcr at openjdk.java.net  Wed Jan 12 19:05:29 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 12 Jan 2022 19:05:29 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
References: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
Message-ID: <VYosmCusXebdGcHl9yyTzR_a5xjBVT6lP9ZZw6YPKUY=.1bf44bb5-95a0-41d9-ad69-7f38c23b0b5e@github.com>

On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.

The CSR is now approved. This comment should be sufficient to wake up the bot.

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

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


From duke at openjdk.java.net  Wed Jan 12 19:17:29 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Wed, 12 Jan 2022 19:17:29 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md [v2]
In-Reply-To: <L-TK2fZT7hAmSrkcXNXKypZLkxvmHWhrO2poruOKnCg=.9705f93f-2698-4195-a815-027a4f33578d@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
 <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>
 <L-TK2fZT7hAmSrkcXNXKypZLkxvmHWhrO2poruOKnCg=.9705f93f-2698-4195-a815-027a4f33578d@github.com>
Message-ID: <LTHUgOrk5EYRorMObViBujZOm4aefnpe7G8QLqkNmtE=.06669280-9ea2-45f7-a26a-d7375a942587@github.com>

On Wed, 12 Jan 2022 18:08:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Not sure if you want to refer to the idea.sh -h for additional options

I'm not sure about that either. These options are usually not required, and the -h output leaves something to be desired. I'd rather keep the current version, and only expand if users start asking.

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

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


From naoto at openjdk.java.net  Wed Jan 12 19:21:32 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 12 Jan 2022 19:21:32 GMT
Subject: Integrated: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
References: <HB9u-9KyuLgcrFwHxPFq9kGmUkTVQeKLNGt9tqjRlV0=.810ad7f5-d58a-4844-846e-97c800091ff2@github.com>
Message-ID: <Ifb3CtF69D6Et3Ekpoa1kKa_FQ7Zlq4hjji8PeuVivs=.9fdd0f4e-e143-48b1-9225-b5706b087f57@github.com>

On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 0a094d7c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a094d7c286ed0b5a35c517391e48c603cb43a68
Stats:     3443 lines in 41 files changed: 2353 ins; 101 del; 989 mod

8268081: Upgrade Unicode Data Files to 14.0.0

Reviewed-by: joehw, iris, lancea

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

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


From lancea at openjdk.java.net  Wed Jan 12 19:26:28 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 12 Jan 2022 19:26:28 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md [v2]
In-Reply-To: <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
 <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>
Message-ID: <qNS9ypdpHrmAmiKNC1FnA2SymK0s8Hzgb4WcJNypr28=.369f7a26-9f0f-4a50-8539-52136eba1dba@github.com>

On Wed, 12 Jan 2022 14:46:54 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

>> Currently the information about using IDEA can only be found on mailing lists.
>> 
>> Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.
>
> Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved wording

> I think you are good to go with your latest set of changes.
> 
> Not sure if you want to refer to the idea.sh -h for additional options (though that does not seem to give you any detail regarding the options)



> > Not sure if you want to refer to the idea.sh -h for additional options
> 
> I'm not sure about that either. These options are usually not required, and the -h output leaves something to be desired. I'd rather keep the current version, and only expand if users start asking.
> 
> /integrate

Works for me.

BTW typically we do the /integrate in a separate comment but it seems to have worked her

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

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


From mgronlun at openjdk.java.net  Wed Jan 12 19:32:30 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 12 Jan 2022 19:32:30 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v8]
In-Reply-To: <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
Message-ID: <9sr1FosT8HqElw0IZzUJfY9noHxT6rSfgZ9unRu9ijs=.5a3dab44-9e87-40b7-a174-a80c634299e4@github.com>

On Wed, 12 Jan 2022 15:18:46 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Clean up & testing
>    
>    - Run JFR tests in test/jdk/jdk/jfr
>    - Fix issues found from above test suite
>    - Remove unecessary jtreg & gtest tests
>    - Remove ineffective `qpic=large`
>    - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java
>  - 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

Hi Tyler,

Good work in getting JFR ported - thank you. Most of the work revolved around implementing the platform-specific os_perf* functionality. I had assumed you would need more work concerning the thread sampler, i.e. JFR method sampling, but it seems that os/posix/signals_posix.cpp can be used as-is (for suspend / resume) and that  pd_get_top_frame_for_profiling() already have implementations - that's good in that case.
Speaking of the thread sampler, to ensure stability, you also need a working implementation of os::ThreadCrashProtection. I can see there is the one in os_posix.cpp, and maybe that is the one already in use? Or does there need to be a specialization in os_aix.cpp? Please see https://bugs.openjdk.java.net/browse/JDK-8279077 for more details about crash protection.

I can't comment on the os_perf_aix.cpp changes from a ppc/aix viewpoint - I think Martin has taken care of that already.

I am ok with this from a JFR standpoint.

Thanks again
Markus

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

Marked as reviewed by mgronlun (Reviewer).

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


From duke at openjdk.java.net  Wed Jan 12 23:59:43 2022
From: duke at openjdk.java.net (Dmitry Kulikov)
Date: Wed, 12 Jan 2022 23:59:43 GMT
Subject: RFR: 8279315: Add Git support to update_copyright_year.sh script
Message-ID: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>

Modified the `make/scripts/update_copyright_year.sh` script to support Git as well as Mercurial, as per [JDK-8279315](https://bugs.openjdk.java.net/browse/JDK-8279315). Also added the ability to specify company name as a command line argument instead of being hard-coded into the script.

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

Commit messages:
 - 8279315: Add Git support to update_copyright_year.sh script

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

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


From duke at openjdk.java.net  Thu Jan 13 00:30:51 2022
From: duke at openjdk.java.net (aamarsh)
Date: Thu, 13 Jan 2022 00:30:51 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
Message-ID: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>

Please review this small change to revert a previous workaround that avoided an MSVC issue. 

This issue has now been fixed in VS 16.8 and higher. 

I also updated some documentation to reflect this change.

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

Commit messages:
 - reverted windows/aarch64 workaround and added to documentation

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

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


From archon358 at yahoo.com  Wed Jan 12 23:52:27 2022
From: archon358 at yahoo.com (Ken Taylor)
Date: Wed, 12 Jan 2022 23:52:27 +0000 (UTC)
Subject: Configuration Error in JDK Build Java 8 (JDK8u) for VS
References: <503545103.115891.1642031547119.ref@mail.yahoo.com>
Message-ID: <503545103.115891.1642031547119@mail.yahoo.com>

I am trying to build JDK 8 from the jdk8u repo, master branch.Project was forked and cloned into a Windows 10 VM.Building in Cygwin.
It appears that the change to support VS 2019 has not been checked in.

=======================================================

JDK Build Instructions:
Microsoft Visual Studio

The minimum accepted version of Visual Studio is 2017. Older versions will not be accepted by configure and will not work. 
The maximum accepted version of Visual Studio is 2019.

If you have multiple versions of Visual Studio installed, configure will by default pick the latest. 

You can request a specific version to be used by setting 
?? ?--with-toolchain-version, e.g. --with-toolchain-version=2017.

=======================================================

Our Command:

./configure 
?? ?--with-boot-jdk=/cygdrive/c/Programs/Java/jdk1.8.0_301 
?? ?--with-tools-dir='/cygdrive/c/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Auxiliary' 
?? ?--with-toolchain-version=2019

=======================================================

Error:

configure: Using default toolchain microsoft (Microsoft Visual Studio)
checking for link... /usr/bin/link
checking if the first found link.exe is actually the Cygwin link tool... yes
configure: Visual Studio version 2019 is not valid.
configure: Valid Visual Studio versions: 2010 2012 2013 2015 2017.

=======================================================

Was this something that got missed and is there a work-around, or should I install VS 2017?? BTW, VS 2022 also does not work.

Thanks for any help you can provide.
Ken Taylor




From duke at openjdk.java.net  Thu Jan 13 11:56:32 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 13 Jan 2022 11:56:32 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v11]
In-Reply-To: <eA6NyC-Tyqs-rOqOZFWnq-DAq3RjlW3KMk0o5KR0oQw=.57a97ade-54e8-4e5f-a3f5-8ae878c985b2@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <imt57f8ms-TPW030GNf47ixU_zxpIH785uty3hM7G9s=.0d6c08c0-3b2f-440b-add2-1614698078b8@github.com>
 <BbJRPOB6NKZ9An0q6BWvd0dxIFj_qXe6rxDY86B8ZVU=.b522a311-e67e-49ad-9cb7-040e05b87a2a@github.com>
 <eA6NyC-Tyqs-rOqOZFWnq-DAq3RjlW3KMk0o5KR0oQw=.57a97ade-54e8-4e5f-a3f5-8ae878c985b2@github.com>
Message-ID: <yqziBnLuMTiwTKbKG0BDMn_DBw9KMvVJqZXK8-_1wcc=.478008c6-02b6-4e9f-89a0-1b7bc8691ef9@github.com>

On Wed, 12 Jan 2022 17:18:16 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>Probably. It depends on exactly what is failing. Can you provide more info?

Looks like they are all segfaults, which is exactly what I'd expect if a frame was missing a sign or auth. I'm fairly confident it's the same handful of issues over and over. I'll get onto debugging them a little more.

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

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


From shade at openjdk.java.net  Thu Jan 13 12:09:50 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 13 Jan 2022 12:09:50 GMT
Subject: RFR: 8279958: Provide configure hints for Alpine/apk package managers
Message-ID: <MjROlusJUNBUokH1qA8vRFRfNsZdCOhzMolxUUztjPI=.213098ff-b63b-4483-8a3d-7104e5157a2e@github.com>

Our build system provides helpful hints about the packages to install to resolve the build-time dependencies. It can be amended to include Alpine/apk package managers. Noticed this when trying to build mainline OpenJDK on Alpine 3. 

Additional testing:
 - [x] Was able to build on clean Alpine 3 with these hints

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

Commit messages:
 - Fix

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

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


From adinn at openjdk.java.net  Thu Jan 13 12:51:34 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 13 Jan 2022 12:51:34 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v11]
In-Reply-To: <yqziBnLuMTiwTKbKG0BDMn_DBw9KMvVJqZXK8-_1wcc=.478008c6-02b6-4e9f-89a0-1b7bc8691ef9@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <imt57f8ms-TPW030GNf47ixU_zxpIH785uty3hM7G9s=.0d6c08c0-3b2f-440b-add2-1614698078b8@github.com>
 <BbJRPOB6NKZ9An0q6BWvd0dxIFj_qXe6rxDY86B8ZVU=.b522a311-e67e-49ad-9cb7-040e05b87a2a@github.com>
 <eA6NyC-Tyqs-rOqOZFWnq-DAq3RjlW3KMk0o5KR0oQw=.57a97ade-54e8-4e5f-a3f5-8ae878c985b2@github.com>
 <yqziBnLuMTiwTKbKG0BDMn_DBw9KMvVJqZXK8-_1wcc=.478008c6-02b6-4e9f-89a0-1b7bc8691ef9@github.com>
Message-ID: <EEtBB9wMXYCk5--JuETCsTIhT-LOgsr1MajOTEsmkpY=.d3076a89-96fe-41dd-9677-833fc96734dc@github.com>

On Thu, 13 Jan 2022 11:53:47 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> Looks like they are all segfaults, which is exactly what I'd expect if a frame was missing a sign or auth. I'm fairly confident it's the same handful of issues over and over. I'll get onto debugging them a little more.

I was hoping you were going to say that ... :-) Let's see how it looks in the debugger.

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

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


From erikj at openjdk.java.net  Thu Jan 13 14:10:28 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 13 Jan 2022 14:10:28 GMT
Subject: RFR: 8279315: Add Git support to update_copyright_year.sh script
In-Reply-To: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
References: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
Message-ID: <8d4kS1vAVfKpedjAaQSj4vCchb6PJ1_00fjdu10Qbfs=.38e63d92-67fa-4be0-a87b-71f483db6b7f@github.com>

On Tue, 11 Jan 2022 13:10:38 GMT, Dmitry Kulikov <duke at openjdk.java.net> wrote:

> Modified the `make/scripts/update_copyright_year.sh` script to support Git as well as Mercurial, as per [JDK-8279315](https://bugs.openjdk.java.net/browse/JDK-8279315). Also added the ability to specify company name as a command line argument instead of being hard-coded into the script.

Looks good. 

Did you consider automatically inferring the VCS by looking for `${this_script_dir}/../../{.git,.hg}`? To resolve `this_script_dir`, you can use the same snippet we have in e.g. top level configure:


# Get an absolute path to this script, since that determines the top-level directory.
this_script_dir=`dirname $0`
this_script_dir=`cd $this_script_dir > /dev/null && pwd`

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

Marked as reviewed by erikj (Reviewer).

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


From erikj at openjdk.java.net  Thu Jan 13 14:13:26 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 13 Jan 2022 14:13:26 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <k8aVa43-O1advLWV3TpXYKYH3Q1CIEcegKgNIt3fBmg=.4e26dd0c-9315-462a-8c86-b7434a739950@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

Marked as reviewed by erikj (Reviewer).

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

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


From duke at openjdk.java.net  Thu Jan 13 14:14:32 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Thu, 13 Jan 2022 14:14:32 GMT
Subject: RFR: 8279877: Document IDEA IDE setup in docs/ide.md [v2]
In-Reply-To: <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
 <Kw4EiA68gtbXf3-OFAvClMWrVmf4EnyOWFTGpRMtfJ4=.dc173b5d-d726-4a1d-b027-fe2f485a0c1e@github.com>
Message-ID: <Pc--rmfObLHqu-3b8jsRk_jLNmb_5XW7CV-6P9_1gbs=.924b6956-332d-449d-a0b1-87ca1c97b382@github.com>

On Wed, 12 Jan 2022 14:46:54 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

>> Currently the information about using IDEA can only be found on mailing lists.
>> 
>> Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.
>
> Daniel Jelinski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved wording

Thanks. Could you sponsor this change?

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

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


From erikj at openjdk.java.net  Thu Jan 13 14:14:30 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 13 Jan 2022 14:14:30 GMT
Subject: RFR: 8279958: Provide configure hints for Alpine/apk package
 managers
In-Reply-To: <MjROlusJUNBUokH1qA8vRFRfNsZdCOhzMolxUUztjPI=.213098ff-b63b-4483-8a3d-7104e5157a2e@github.com>
References: <MjROlusJUNBUokH1qA8vRFRfNsZdCOhzMolxUUztjPI=.213098ff-b63b-4483-8a3d-7104e5157a2e@github.com>
Message-ID: <-VipwX6uiAcLcjq72bYprTT6gIhEDrnprSd5n1TKMe0=.955c07d3-5d34-4c8f-a0db-da1941f03a7c@github.com>

On Thu, 13 Jan 2022 12:02:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Our build system provides helpful hints about the packages to install to resolve the build-time dependencies. It can be amended to include Alpine/apk package managers. Noticed this when trying to build mainline OpenJDK on Alpine 3. 
> 
> Additional testing:
>  - [x] Was able to build on clean Alpine 3 with these hints

Marked as reviewed by erikj (Reviewer).

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

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


From kiriyama.takuya at fujitsu.com  Thu Jan 13 06:30:15 2022
From: kiriyama.takuya at fujitsu.com (kiriyama.takuya at fujitsu.com)
Date: Thu, 13 Jan 2022 06:30:15 +0000
Subject: 8278138: OpenJDK8 fails to start on Windows 8.1 after upgrading
 compiler to VS2017
Message-ID: <TYCPR01MB883400EA5D46902259F1A870E7539@TYCPR01MB8834.jpnprd01.prod.outlook.com>

I thought about this issue, but unfortunately I found no way to fix.
Does anyone have good idea to fix this bug?  
https://bugs.openjdk.java.net/browse/JDK-8278138

Thanks for any help you can provide.

Regards,
KIRIYAMA Takuya






From duke at openjdk.java.net  Thu Jan 13 16:21:31 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Thu, 13 Jan 2022 16:21:31 GMT
Subject: Integrated: 8279877: Document IDEA IDE setup in docs/ide.md
In-Reply-To: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
References: <X-_ksg4oOGRQYCmCdkCNuJa8h17-nT95Lpu51kntZC0=.12c9311a-320c-4690-853b-b4a553fcad18@github.com>
Message-ID: <ClBfBT64iVG5wAE-Z7XkUlCPcWPHS9ScCiogDjZNlZo=.529f49f0-b98e-4e63-82a4-b43db0c8bb49@github.com>

On Wed, 12 Jan 2022 07:29:33 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

> Currently the information about using IDEA can only be found on mailing lists.
> 
> Additionally fixed the documentation for Visual Studio; the target `ide-project` does not exist.

This pull request has now been integrated.

Changeset: 9209e6d6
Author:    Daniel Jelinski <daniel.jelinski at oracle.com>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9209e6d6aeee002c5de3b29cfed1e91c61c37868
Stats:     37 lines in 2 files changed: 31 ins; 0 del; 6 mod

8279877: Document IDEA IDE setup in docs/ide.md

Reviewed-by: lancea, erikj

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

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


From tschatzl at openjdk.java.net  Thu Jan 13 17:24:40 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 13 Jan 2022 17:24:40 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <s4cHNM85u-0zpCbevYdM_wsyQvOXbRS-GyLci3i96Dw=.ceedaac2-fc2a-44d2-bc83-f1949a999db5@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

GC changes look good.

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

Marked as reviewed by tschatzl (Reviewer).

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


From mli at openjdk.java.net  Fri Jan 14 01:51:21 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 14 Jan 2022 01:51:21 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <_nHW8kORImeQlf40ntU2l73jfaEQvUwsAQhBpD3LznI=.a16be953-1f13-46e0-93ca-43de15465ec1@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

looks good

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

Marked as reviewed by mli (Reviewer).

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


From duke at openjdk.java.net  Fri Jan 14 02:28:39 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Fri, 14 Jan 2022 02:28:39 GMT
Subject: [jdk18] RFR: 8279702: [macosx] ignore xcodebuild warnings on M1
Message-ID: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>

Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in its title and description.

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

Commit messages:
 - Update copyright
 - Ignore the error output of xcodebuild when checking its version

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

PR: https://git.openjdk.java.net/jdk18/pull/95


From goetz at openjdk.java.net  Fri Jan 14 02:28:39 2022
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Fri, 14 Jan 2022 02:28:39 GMT
Subject: [jdk18] RFR: 8279702: [macosx] ignore xcodebuild warnings on M1
In-Reply-To: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
References: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
Message-ID: <qkg5tojVkI08tmpXfxu9yJb9Qgg-8s_1_4m3bJ0PxQ4=.413a6054-08a9-4e7b-b309-249aed5c1258@github.com>

On Wed, 12 Jan 2022 09:42:07 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in its title and description.

I confirm that Johannes Bechberger is in the SAP openJDK team and thus covered by the SAP OCA.

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

PR: https://git.openjdk.java.net/jdk18/pull/95


From egahlin at openjdk.java.net  Fri Jan 14 03:57:42 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 14 Jan 2022 03:57:42 GMT
Subject: RFR: 8279825: JFR: JFCModel should use SecuritySupport for predefined
 .jfc files
Message-ID: <NI28LN0nSTSpjt6-X88qXKRPC9XGCGSKaPox28YpXTw=.ab8ef066-6547-4f23-a52e-93d55d8bf271@github.com>

Hi,

Could I have review of a fix that allows the new parser, used by JFCModel, to read known configuration files in JAVA_HOME/lib/jfr without FilePermission, similar to the older parser.

Testing: jdk/jdkjfr

Thanks
Erik

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

Commit messages:
 - Merge branch 'openjdk:master' into smstart
 - Remove whitespace
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/7066/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7066&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279825
  Stats: 53 lines in 4 files changed: 31 ins; 13 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7066.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7066/head:pull/7066

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


From goetz at openjdk.java.net  Fri Jan 14 07:07:22 2022
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Fri, 14 Jan 2022 07:07:22 GMT
Subject: [jdk18] RFR: 8279702: [macosx] ignore xcodebuild warnings on M1
In-Reply-To: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
References: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
Message-ID: <8AHb_x4XIJfdHrnnXldhADFnBdtLU34_HpCL6Bc1I6M=.37c3423e-ce3f-4ad9-870e-4df59b8d2d44@github.com>

On Wed, 12 Jan 2022 09:42:07 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in its title and description.

Good point to write stderr to the output. This will simplify detecting future errors here.
LGTM

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

Marked as reviewed by goetz (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/95


From clanger at openjdk.java.net  Fri Jan 14 07:50:32 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 14 Jan 2022 07:50:32 GMT
Subject: [jdk18] RFR: 8279702: [macosx] ignore xcodebuild warnings on M1
In-Reply-To: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
References: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
Message-ID: <VvML1LibqnB0Qvp3jD2V0S_QZTUL5d4TVH6LYOGp98I=.f0d0662e-adbd-42c8-8d60-914ba9b042a4@github.com>

On Wed, 12 Jan 2022 09:42:07 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in its title and description.

You?re too quick. This needs a review from somebody in the build group.

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

PR: https://git.openjdk.java.net/jdk18/pull/95


From duke at openjdk.java.net  Fri Jan 14 08:19:24 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Fri, 14 Jan 2022 08:19:24 GMT
Subject: [jdk18] RFR: 8279702: [macosx] ignore xcodebuild warnings on M1
In-Reply-To: <VvML1LibqnB0Qvp3jD2V0S_QZTUL5d4TVH6LYOGp98I=.f0d0662e-adbd-42c8-8d60-914ba9b042a4@github.com>
References: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
 <VvML1LibqnB0Qvp3jD2V0S_QZTUL5d4TVH6LYOGp98I=.f0d0662e-adbd-42c8-8d60-914ba9b042a4@github.com>
Message-ID: <3lRBE2bx5keID_AJ9oWf6X5fcvvAJBRH4KhWcU9YlPA=.433c3dde-6925-4158-9451-96d45e61c1bf@github.com>

On Fri, 14 Jan 2022 07:47:19 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in its title and description.
>
> You?re too quick. This needs a review from somebody in the build group.

@RealCLanger thanks, I'm new to the process.

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

PR: https://git.openjdk.java.net/jdk18/pull/95


From aph at openjdk.java.net  Fri Jan 14 09:09:27 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 14 Jan 2022 09:09:27 GMT
Subject: [jdk18] RFR: 8279702: [macosx] ignore xcodebuild warnings on M1
In-Reply-To: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
References: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
Message-ID: <w-5vI3hqdpb-Z14xs_uw3ehwX2XQWcPvjT8m4RXnLM0=.edbabc13-5f3f-4eec-bc30-915d067e33b0@github.com>

On Wed, 12 Jan 2022 09:42:07 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in its title and description.

make/autoconf/toolchain.m4 line 237:

> 235:     if test -n "$XCODEBUILD"; then
> 236:       # On Mac OS X, default toolchain to clang after Xcode 5
> 237:       XCODE_VERSION_OUTPUT=`"$XCODEBUILD" -version 2>&1 | $HEAD -n 1`

What's the warning? If it is truly expected, shouldn't it go to /dev/null ?

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

PR: https://git.openjdk.java.net/jdk18/pull/95


From matthias.baesken at sap.com  Fri Jan 14 09:19:41 2022
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 14 Jan 2022 09:19:41 +0000
Subject: Heads up: planned Harfbuzz update in jdk11u-dev
Message-ID: <AM9PR02MB67703D2497B22F5C7F9CD54B93549@AM9PR02MB6770.eurprd02.prod.outlook.com>

For one of the next jdk11 updates, an update to a more recent harfbuzz version is planned.
This has been done already in jdk/jdk some time ago, and was backported recently to jdk13,
please see the harfbuzz 2.7.2 / 2.8.0 related changes done in jdk13 :

https://github.com/openjdk/jdk13u-dev/commit/e183f2d3650b6275a59d0cdd7303ca22f2ae088a
https://github.com/openjdk/jdk13u-dev/commit/64627b5061fdd15ed52e3858cb52bb6b3b2b020b
https://github.com/openjdk/jdk13u-dev/commit/c42c231e1dabd37ec09362291dc8141117ce0bbd

However the new harfbuzz 2.7.2 / 2.8.0 updates need C++11 support (they are built with option -std=c++11).
So please check that

a) your toolchain supports -std=c++11 or you have the option to update your toolchain to a more recent version


or as a workaround

b) check the -with-harfbuzz=system option to use another precompiled harfbuzz version from your system

Best regards, Matthias


From duke at openjdk.java.net  Fri Jan 14 09:21:33 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Fri, 14 Jan 2022 09:21:33 GMT
Subject: [jdk18] RFR: 8279702: [macosx] ignore xcodebuild warnings on M1
In-Reply-To: <w-5vI3hqdpb-Z14xs_uw3ehwX2XQWcPvjT8m4RXnLM0=.edbabc13-5f3f-4eec-bc30-915d067e33b0@github.com>
References: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
 <w-5vI3hqdpb-Z14xs_uw3ehwX2XQWcPvjT8m4RXnLM0=.edbabc13-5f3f-4eec-bc30-915d067e33b0@github.com>
Message-ID: <U8xWKFL2nHTDLrQdx6bUX6PxFEEMWqralozEeptTP44=.1a1b1bcc-1580-4fe6-8da8-1a4e9f85d7c8@github.com>

On Fri, 14 Jan 2022 09:06:47 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in its title and description.
>
> make/autoconf/toolchain.m4 line 237:
> 
>> 235:     if test -n "$XCODEBUILD"; then
>> 236:       # On Mac OS X, default toolchain to clang after Xcode 5
>> 237:       XCODE_VERSION_OUTPUT=`"$XCODEBUILD" -version 2>&1 | $HEAD -n 1`
> 
> What's the warning? If it is truly expected, shouldn't it go to /dev/null ?

The warning is

objc[3881]: Class AMSupportURLConnectionDelegate is implemented in both /usr/lib/libauthinstall.dylib (0x1e32b6b90) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1087e42c8). One of the two will be used. Which one is undefined.
objc[3881]: Class AMSupportURLSession is implemented in both /usr/lib/libauthinstall.dylib (0x1e32b6be0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1087e4318). One of the two will be used. Which one is undefined.

as noted in the issues referenced by my bug report and we can ignore it (as build scripts of other projects do).

The problem with fully discarding the output is that there are other errors that might cause the exit code to be non-zero and in this case displaying the warning should be helpful for debugging.
Of course one could either just remove the expected warning or only display the error output when the return code is non-zero, but these alternatives seemed to cumbersome for me (and the first alternative to error-prone).

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

PR: https://git.openjdk.java.net/jdk18/pull/95


From sgehwolf at redhat.com  Fri Jan 14 09:40:30 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 14 Jan 2022 10:40:30 +0100
Subject: Heads up: planned Harfbuzz update in jdk11u-dev
In-Reply-To: <AM9PR02MB67703D2497B22F5C7F9CD54B93549@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB67703D2497B22F5C7F9CD54B93549@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <ca8d84bbaca44a0646df03fa5b383e0a4fa8de60.camel@redhat.com>

On Fri, 2022-01-14 at 09:19 +0000, Baesken, Matthias wrote:
> For one of the next jdk11 updates, an update to a more recent harfbuzz version is planned.
> This has been done already in jdk/jdk some time ago, and was backported recently to jdk13,
> please see the harfbuzz 2.7.2 / 2.8.0 related changes done in jdk13 :
> 
> https://github.com/openjdk/jdk13u-dev/commit/e183f2d3650b6275a59d0cdd7303ca22f2ae088a
> https://github.com/openjdk/jdk13u-dev/commit/64627b5061fdd15ed52e3858cb52bb6b3b2b020b
> https://github.com/openjdk/jdk13u-dev/commit/c42c231e1dabd37ec09362291dc8141117ce0bbd
> 
> However the new harfbuzz 2.7.2 / 2.8.0 updates need C++11 support (they are built with option -std=c++11).
> So please check that
> 
> a) your toolchain supports -std=c++11 or you have the option to update your toolchain to a more recent version
> 
> 
> or as a workaround
> 
> b) check the -with-harfbuzz=system option to use another precompiled harfbuzz version from your system

Thanks for the heads-up. This will break the JDK 11u vanilla builds
which we still build on RHEL 6 which doesn't have a new enough system
compiler to support c++11. We'll look into a work-around for this.

Cheers,
Severin



From aph at openjdk.java.net  Fri Jan 14 10:22:39 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 14 Jan 2022 10:22:39 GMT
Subject: [jdk18] RFR: 8279702: [macosx] ignore xcodebuild warnings on M1
In-Reply-To: <U8xWKFL2nHTDLrQdx6bUX6PxFEEMWqralozEeptTP44=.1a1b1bcc-1580-4fe6-8da8-1a4e9f85d7c8@github.com>
References: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
 <w-5vI3hqdpb-Z14xs_uw3ehwX2XQWcPvjT8m4RXnLM0=.edbabc13-5f3f-4eec-bc30-915d067e33b0@github.com>
 <U8xWKFL2nHTDLrQdx6bUX6PxFEEMWqralozEeptTP44=.1a1b1bcc-1580-4fe6-8da8-1a4e9f85d7c8@github.com>
Message-ID: <_ZNYJjn79FBrNqzr5Mq-rJzbZ4Vw4nvpJOC0U04AVPc=.a675ceb9-da33-4b60-9a93-0f02213d26d2@github.com>

On Fri, 14 Jan 2022 09:18:43 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> make/autoconf/toolchain.m4 line 237:
>> 
>>> 235:     if test -n "$XCODEBUILD"; then
>>> 236:       # On Mac OS X, default toolchain to clang after Xcode 5
>>> 237:       XCODE_VERSION_OUTPUT=`"$XCODEBUILD" -version 2>&1 | $HEAD -n 1`
>> 
>> What's the warning? If it is truly expected, shouldn't it go to /dev/null ?
>
> The warning is
> 
> objc[3881]: Class AMSupportURLConnectionDelegate is implemented in both /usr/lib/libauthinstall.dylib (0x1e32b6b90) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1087e42c8). One of the two will be used. Which one is undefined.
> objc[3881]: Class AMSupportURLSession is implemented in both /usr/lib/libauthinstall.dylib (0x1e32b6be0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1087e4318). One of the two will be used. Which one is undefined.
> 
> as noted in the issues referenced by my bug report and we can ignore it (as build scripts of other projects do).
> 
> The problem with fully discarding the output is that there are other errors that might cause the exit code to be non-zero and in this case displaying the warning should be helpful for debugging.
> Of course one could either just remove the expected warning or only display the error output when the return code is non-zero, but these alternatives seemed to cumbersome for me (and the first alternative to error-prone).

OK. I've seen this a couple of times, and I hate warnings that can't be fixed. But it is what it is, thanks.

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

PR: https://git.openjdk.java.net/jdk18/pull/95


From erikj at openjdk.java.net  Fri Jan 14 13:35:39 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 14 Jan 2022 13:35:39 GMT
Subject: [jdk18] RFR: 8279702: [macosx] ignore xcodebuild warnings on M1
In-Reply-To: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
References: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
Message-ID: <ClP4wvXinMvO_QY7m28g0ks9pnMbbZn13hLpu4MdZOk=.aa03c639-1b44-4f97-8195-a71ea94bf2bd@github.com>

On Wed, 12 Jan 2022 09:42:07 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in its title and description.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/95


From duke at openjdk.java.net  Fri Jan 14 13:51:42 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Fri, 14 Jan 2022 13:51:42 GMT
Subject: RFR: 8258240: make vscode-project on Windows generates
 jdk.code-workspace file with unescaped '\' in paths
Message-ID: <JKIgt2erxvLcBh-uNE7QcBXaHc6HqZqYv6tc_1ufJHs=.1faf8863-5db6-4710-9243-29053018156a@github.com>

Backslashes in `sed` replacement string are interpreted by `sed`. In order to output the strings we want, the replacement text needs to be escaped again. See https://stackoverflow.com/a/2705678

Verified that with this patch VSCode is able to open the workspace, and all files are visible in "Explorer".

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

Commit messages:
 - Escape SED replacement string

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

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


From duke at openjdk.java.net  Fri Jan 14 13:57:25 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Fri, 14 Jan 2022 13:57:25 GMT
Subject: [jdk18] Integrated: 8279702: [macosx] ignore xcodebuild warnings on M1
In-Reply-To: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
References: <8tJJmlzzmp-FnQKoOy6-9hx2DZ8scPyR5ZqK0QywE5c=.d203f23d-49f0-4b67-993f-11d7d1be6488@github.com>
Message-ID: <U2Pq9m2u4H4ygmSSl0R4R6L5p7E_hjV7tozBlLSgdZA=.0ae10cca-94d3-4feb-86bd-c5f04b809b78@github.com>

On Wed, 12 Jan 2022 09:42:07 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in its title and description.

This pull request has now been integrated.

Changeset: 4b520f00
Author:    Johannes Bechberger <johannes.bechberger at sap.com>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/4b520f0001be5f33996d5ab7d9ad75773a847e54
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8279702: [macosx] ignore xcodebuild warnings on M1

Reviewed-by: goetz, erikj

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

PR: https://git.openjdk.java.net/jdk18/pull/95


From erikj at openjdk.java.net  Fri Jan 14 14:35:28 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 14 Jan 2022 14:35:28 GMT
Subject: RFR: 8258240: make vscode-project on Windows generates
 jdk.code-workspace file with unescaped '\' in paths
In-Reply-To: <JKIgt2erxvLcBh-uNE7QcBXaHc6HqZqYv6tc_1ufJHs=.1faf8863-5db6-4710-9243-29053018156a@github.com>
References: <JKIgt2erxvLcBh-uNE7QcBXaHc6HqZqYv6tc_1ufJHs=.1faf8863-5db6-4710-9243-29053018156a@github.com>
Message-ID: <_ChRC4LbPyh6n41HU6Wnz0oso7awQv-Iyh317MrOQ_I=.f418748d-b636-4186-b24e-7ab986496f07@github.com>

On Fri, 14 Jan 2022 13:45:51 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

> Backslashes in `sed` replacement string are interpreted by `sed`. In order to output the strings we want, the replacement text needs to be escaped again. See https://stackoverflow.com/a/2705678
> 
> Verified that with this patch VSCode is able to open the workspace, and all files are visible in "Explorer".

Looks good!

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

Marked as reviewed by erikj (Reviewer).

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


From duke at openjdk.java.net  Fri Jan 14 16:13:31 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 14 Jan 2022 16:13:31 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v8]
In-Reply-To: <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
Message-ID: <sJ_RH4kLOuXl5jdxEhOhkg0y7zsDWLzqpuyUWw5Yb50=.1280aa42-b622-4440-915e-80b13426b1f5@github.com>

On Wed, 12 Jan 2022 15:18:46 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Clean up & testing
>    
>    - Run JFR tests in test/jdk/jdk/jfr
>    - Fix issues found from above test suite
>    - Remove unecessary jtreg & gtest tests
>    - Remove ineffective `qpic=large`
>    - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java
>  - 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

To follow up on an item mentioned above so that it is documented here: I reviewed the functionality from `src/hotspot/os/aix/libperfstat_aix` and found it didn't fit well with the needs of this pr. If it were extended in the future to include the ability to call at least `libperfstat_process` and `libperfstat_cpu` (in addition to `libperfstat_cpu_total`), then using it here would be a reasonable choice. There may be some other functionality required, but those stand out to me as the big ones.

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

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


From duke at openjdk.java.net  Fri Jan 14 16:21:34 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 14 Jan 2022 16:21:34 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v7]
In-Reply-To: <zMOlwI7UHzpf_8ZazjM55yUPAV2Wg76-_ANAwxkr4VA=.f51a5d98-2122-411b-bf9a-48255135c96e@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <rPB9xl_uKW6-tMYEBbhupPnYQbcIWwQUWtkIyAH4xgE=.aacff5d8-7015-4368-b68c-9cc334982577@github.com>
 <zMOlwI7UHzpf_8ZazjM55yUPAV2Wg76-_ANAwxkr4VA=.f51a5d98-2122-411b-bf9a-48255135c96e@github.com>
Message-ID: <kP3vudLJzpdKNCjEOrE_YTtni1rwz91OXh0yjuYLOUk=.16c7026d-4d5a-416c-b6ed-0e7bc9664ffb@github.com>

On Tue, 11 Jan 2022 16:56:15 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> I'm looking for some clarification on the purpose TestNativeLibrariesEvent.java. Currently it fails with "Missing libraries:libjvm.so, libjava.so, libzip.so: expected true, was false". I find those libs in my build directory, and everything else seems to work. Can anyone provide an idea why this test is failing (or what the failure means)?

The only item keeping me from `/integrating` is the failing test referenced above. Can anyone provide some clarification? I find the 'missing' libs in a few places in the build directory including the paths below:


build/aix-ppc64-server-release/images/jdk/lib/libjava.so
build/aix-ppc64-server-release/images/jdk/lib/libzip.so
build/aix-ppc64-server-release/images/jdk/lib/server/libjvm.so

build/aix-ppc64-server-release/jdk/lib/libjava.so
build/aix-ppc64-server-release/jdk/lib/libzip.so
build/aix-ppc64-server-release/jdk/lib/server/libjvm.so


Another option is to simply add the test to a ProblemList.txt, but I'd prefer not to unless it's really warranted.

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

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


From egahlin at openjdk.java.net  Fri Jan 14 16:48:27 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 14 Jan 2022 16:48:27 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v7]
In-Reply-To: <kP3vudLJzpdKNCjEOrE_YTtni1rwz91OXh0yjuYLOUk=.16c7026d-4d5a-416c-b6ed-0e7bc9664ffb@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <rPB9xl_uKW6-tMYEBbhupPnYQbcIWwQUWtkIyAH4xgE=.aacff5d8-7015-4368-b68c-9cc334982577@github.com>
 <zMOlwI7UHzpf_8ZazjM55yUPAV2Wg76-_ANAwxkr4VA=.f51a5d98-2122-411b-bf9a-48255135c96e@github.com>
 <kP3vudLJzpdKNCjEOrE_YTtni1rwz91OXh0yjuYLOUk=.16c7026d-4d5a-416c-b6ed-0e7bc9664ffb@github.com>
Message-ID: <T-FPYl-nVQbzjqo_7GsVjPCgm9CbGfIld27B_gcBWBc=.219bf3a3-2a91-4208-98b0-753960ccaac3@github.com>

On Fri, 14 Jan 2022 16:18:37 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> > I'm looking for some clarification on the purpose TestNativeLibrariesEvent.java. Currently it fails with "Missing libraries:libjvm.so, libjava.so, libzip.so: expected true, was false". I find those libs in my build directory, and everything else seems to work. Can anyone provide an idea why this test is failing (or what the failure means)?
> 
> The only item keeping me from `/integrating` is the failing test referenced above. Can anyone provide some clarification? [Edit: The test is checking a (JFR) recording for the libs, not the path as I misunderstood earlier].
> 
> Another option is to simply add the test to a ProblemList.txt, but I'd prefer not to unless it's really warranted.

What is the output if you run the test on AIX? 

It should print all NativeLibrary events. If you don't get any, you may want to look at how data is gathered for EventNativeLibrary.  If you get events, you might want to add one library as a sanity test.

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

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


From duke at openjdk.java.net  Fri Jan 14 16:58:28 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 14 Jan 2022 16:58:28 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v8]
In-Reply-To: <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
Message-ID: <XuoxyKbZUNQMMN3eA0-I9XecIGWidjy435qS0Mk_Hck=.1f4098bf-152a-4df6-bd84-5404d596a8d2@github.com>

On Wed, 12 Jan 2022 15:18:46 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Clean up & testing
>    
>    - Run JFR tests in test/jdk/jdk/jfr
>    - Fix issues found from above test suite
>    - Remove unecessary jtreg & gtest tests
>    - Remove ineffective `qpic=large`
>    - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java
>  - 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

Thanks! That clarifies some things. The output for that test is currently empty, so it seems that the Native Libs are not being included in the recording.

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

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


From redestad at openjdk.java.net  Fri Jan 14 17:17:39 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 14 Jan 2022 17:17:39 GMT
Subject: RFR: 8280032: Update jib-profiles.js to use JMH 1.34 devkit
Message-ID: <QZLGRgg89KKoOEx9wyWcyk60subXpJUQG_9cArNWty0=.105600a9-9e3f-4c1b-9e08-8b42565e827a@github.com>

Change so that jib users pick up and use the latest JMH devkit.

Testing: verified locally

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

Commit messages:
 - Update jib-profile to use JMH 1.34

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

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


From erikj at openjdk.java.net  Fri Jan 14 17:17:39 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 14 Jan 2022 17:17:39 GMT
Subject: RFR: 8280032: Update jib-profiles.js to use JMH 1.34 devkit
In-Reply-To: <QZLGRgg89KKoOEx9wyWcyk60subXpJUQG_9cArNWty0=.105600a9-9e3f-4c1b-9e08-8b42565e827a@github.com>
References: <QZLGRgg89KKoOEx9wyWcyk60subXpJUQG_9cArNWty0=.105600a9-9e3f-4c1b-9e08-8b42565e827a@github.com>
Message-ID: <fX7e2Kyt0l48IYXcHOSQc5LhxBArmA7GGHbLEPzESO8=.f0ead0bd-9bc9-483e-b17c-62ce41e9ea0c@github.com>

On Fri, 14 Jan 2022 17:05:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Change so that jib users pick up and use the latest JMH devkit.
> 
> Testing: verified locally

Marked as reviewed by erikj (Reviewer).

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

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


From iris at openjdk.java.net  Fri Jan 14 18:10:30 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 14 Jan 2022 18:10:30 GMT
Subject: RFR: 8280032: Update jib-profiles.js to use JMH 1.34 devkit
In-Reply-To: <QZLGRgg89KKoOEx9wyWcyk60subXpJUQG_9cArNWty0=.105600a9-9e3f-4c1b-9e08-8b42565e827a@github.com>
References: <QZLGRgg89KKoOEx9wyWcyk60subXpJUQG_9cArNWty0=.105600a9-9e3f-4c1b-9e08-8b42565e827a@github.com>
Message-ID: <QGRonfzU5ZV5lOQawbnRs9JPxACsXkGBaAGT7ys6pjI=.9f716f7b-c806-4bc4-9e90-4e17346aacc0@github.com>

On Fri, 14 Jan 2022 17:05:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Change so that jib users pick up and use the latest JMH devkit.
> 
> Testing: verified locally

Marked as reviewed by iris (Reviewer).

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

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


From dev at kb6.ee  Sun Jan 16 05:12:46 2022
From: dev at kb6.ee (Abigail G)
Date: Sun, 16 Jan 2022 00:12:46 -0500
Subject: gtest test targets fail with "Unknown test selection: 'gtest'" on
 jdk15-17
Message-ID: <87b8679cb209e77b8ea87aff5b7df28adc0a7206.camel@kb6.ee>

Hello,

I am attempting to run tests for openjdk15 to 17 using the make target
test-hotspot-gtest, but after compiling the test files, it fails with
this message:

   Unknown test selection: 'gtest'
   See doc/testing.[md|html] for help
   RunTests.gmk:541: *** Cannot continue.  Stop.
   make[2]: *** [make/Main.gmk:601: exploded-test-gtest] Error 2
   
   ERROR: Build failed for target 'test-hotspot-gtest' in configuration
   'linux-x86_64-server-release' (exit code 2) 
   
   No indication of failed target found.
   Hint: Try searching the build log for '] Error'.
   Hint: See doc/building.html#troubleshooting for assistance.
   
   make[1]: *** [/builddir/jdk15u-jdk-15.0.3+3/make/Init.gmk:315: main]
   Error 2
   make: *** [/builddir/jdk15u-jdk-15.0.3+3/make/Init.gmk:186: test-
   hotspot-gtest] Error 2

I have been able to successfully compile and run the tests for
openjdk12 to 14 with the same test target, and, looking at the
makefiles, it appears there has been no change in the relevant code
between jdk14 and 15. What could be the issue here?

Thanks in advance,
Abigail G



From thomas.stuefe at gmail.com  Sun Jan 16 20:13:18 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 16 Jan 2022 21:13:18 +0100
Subject: gtest test targets fail with "Unknown test selection: 'gtest'" on
 jdk15-17
In-Reply-To: <87b8679cb209e77b8ea87aff5b7df28adc0a7206.camel@kb6.ee>
References: <87b8679cb209e77b8ea87aff5b7df28adc0a7206.camel@kb6.ee>
Message-ID: <CAA-vtUwmKpZWuTzZmEJz6xa+W0Q3yaN2r97Dquyye2yc3h0dCQ@mail.gmail.com>

Hi Abigail,

at some point (it may have been JDK 15, I am not sure atm) we stopped
including the google test framework in our repo and instead require the
builder to provide it externally. See configure option "--with-gtest". Must
point to a copy of the googletest framework (
https://github.com/google/googletest).

HTH, Cheers, Thomas

On Sun, Jan 16, 2022 at 9:01 PM Abigail G <dev at kb6.ee> wrote:

> Hello,
>
> I am attempting to run tests for openjdk15 to 17 using the make target
> test-hotspot-gtest, but after compiling the test files, it fails with
> this message:
>
>    Unknown test selection: 'gtest'
>    See doc/testing.[md|html] for help
>    RunTests.gmk:541: *** Cannot continue.  Stop.
>    make[2]: *** [make/Main.gmk:601: exploded-test-gtest] Error 2
>
>    ERROR: Build failed for target 'test-hotspot-gtest' in configuration
>    'linux-x86_64-server-release' (exit code 2)
>
>    No indication of failed target found.
>    Hint: Try searching the build log for '] Error'.
>    Hint: See doc/building.html#troubleshooting for assistance.
>
>    make[1]: *** [/builddir/jdk15u-jdk-15.0.3+3/make/Init.gmk:315: main]
>    Error 2
>    make: *** [/builddir/jdk15u-jdk-15.0.3+3/make/Init.gmk:186: test-
>    hotspot-gtest] Error 2
>
> I have been able to successfully compile and run the tests for
> openjdk12 to 14 with the same test target, and, looking at the
> makefiles, it appears there has been no change in the relevant code
> between jdk14 and 15. What could be the issue here?
>
> Thanks in advance,
> Abigail G
>
>


From gnu.andrew at redhat.com  Mon Jan 17 00:31:10 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 17 Jan 2022 00:31:10 +0000
Subject: Heads up: planned Harfbuzz update in jdk11u-dev
In-Reply-To: <AM9PR02MB67703D2497B22F5C7F9CD54B93549@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB67703D2497B22F5C7F9CD54B93549@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <YeS4zp+QZNQ/1F2v@hex.discworld.ac.uk>

On 09:19 Fri 14 Jan     , Baesken, Matthias wrote:
> For one of the next jdk11 updates, an update to a more recent harfbuzz version is planned.
> This has been done already in jdk/jdk some time ago, and was backported recently to jdk13,
> please see the harfbuzz 2.7.2 / 2.8.0 related changes done in jdk13 :
> 
> https://github.com/openjdk/jdk13u-dev/commit/e183f2d3650b6275a59d0cdd7303ca22f2ae088a
> https://github.com/openjdk/jdk13u-dev/commit/64627b5061fdd15ed52e3858cb52bb6b3b2b020b
> https://github.com/openjdk/jdk13u-dev/commit/c42c231e1dabd37ec09362291dc8141117ce0bbd
> 
> However the new harfbuzz 2.7.2 / 2.8.0 updates need C++11 support (they are built with option -std=c++11).
> So please check that
> 
> a) your toolchain supports -std=c++11 or you have the option to update your toolchain to a more recent version
> 
> 
> or as a workaround
> 
> b) check the -with-harfbuzz=system option to use another precompiled harfbuzz version from your system
> 
> Best regards, Matthias
> 

Why?

11u is a stable release. I don't think it is appropriate to break
existing build setups on a 3+ year old JDK.

If people want a newer HarfBuzz, they can use --with-harfbuzz=system
or upgrade to a newer JDK.
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From david.holmes at oracle.com  Mon Jan 17 04:35:39 2022
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 17 Jan 2022 14:35:39 +1000
Subject: Configuration Error in JDK Build Java 8 (JDK8u) for VS
In-Reply-To: <503545103.115891.1642031547119@mail.yahoo.com>
References: <503545103.115891.1642031547119.ref@mail.yahoo.com>
 <503545103.115891.1642031547119@mail.yahoo.com>
Message-ID: <fb47f7cf-fe70-9d13-c062-bc70b378d6f8@oracle.com>

Hi Ken,

On 13/01/2022 9:52 am, Ken Taylor wrote:
> I am trying to build JDK 8 from the jdk8u repo, master branch.Project was forked and cloned into a Windows 10 VM.Building in Cygwin.
> It appears that the change to support VS 2019 has not been checked in.
> 
> =======================================================
> 
> JDK Build Instructions:
> Microsoft Visual Studio
> 
> The minimum accepted version of Visual Studio is 2017. Older versions will not be accepted by configure and will not work.
> The maximum accepted version of Visual Studio is 2019.

What repo exactly and what file contains these build instructions?

Thanks,
David

> If you have multiple versions of Visual Studio installed, configure will by default pick the latest.
> 
> You can request a specific version to be used by setting
>  ?? ?--with-toolchain-version, e.g. --with-toolchain-version=2017.
> 
> =======================================================
> 
> Our Command:
> 
> ./configure
>  ?? ?--with-boot-jdk=/cygdrive/c/Programs/Java/jdk1.8.0_301
>  ?? ?--with-tools-dir='/cygdrive/c/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Auxiliary'
>  ?? ?--with-toolchain-version=2019
> 
> =======================================================
> 
> Error:
> 
> configure: Using default toolchain microsoft (Microsoft Visual Studio)
> checking for link... /usr/bin/link
> checking if the first found link.exe is actually the Cygwin link tool... yes
> configure: Visual Studio version 2019 is not valid.
> configure: Valid Visual Studio versions: 2010 2012 2013 2015 2017.
> 
> =======================================================
> 
> Was this something that got missed and is there a work-around, or should I install VS 2017?? BTW, VS 2022 also does not work.
> 
> Thanks for any help you can provide.
> Ken Taylor
> 
> 


From david.holmes at oracle.com  Mon Jan 17 04:48:22 2022
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 17 Jan 2022 14:48:22 +1000
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v8]
In-Reply-To: <sJ_RH4kLOuXl5jdxEhOhkg0y7zsDWLzqpuyUWw5Yb50=.1280aa42-b622-4440-915e-80b13426b1f5@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
 <sJ_RH4kLOuXl5jdxEhOhkg0y7zsDWLzqpuyUWw5Yb50=.1280aa42-b622-4440-915e-80b13426b1f5@github.com>
Message-ID: <ff822b59-7750-f554-439e-9f484412db79@oracle.com>

On 15/01/2022 2:13 am, Tyler Steele wrote:
> To follow up on an item mentioned above so that it is documented here: I reviewed the functionality from `src/hotspot/os/aix/libperfstat_aix` and found it didn't fit well with the needs of this pr. If it were extended in the future to include the ability to call at least `libperfstat_process` and `libperfstat_cpu` (in addition to `libperfstat_cpu_total`), then using it here would be a reasonable choice. There may be some other functionality required, but those stand out to me as the big ones.

Wouldn't adding the needed functionality to the existing libperfstat_aix 
be preferable here?

David

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


From duke at openjdk.java.net  Mon Jan 17 08:17:01 2022
From: duke at openjdk.java.net (Dmitry Kulikov)
Date: Mon, 17 Jan 2022 08:17:01 GMT
Subject: RFR: 8279315: Add Git support to update_copyright_year.sh script
 [v2]
In-Reply-To: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
References: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
Message-ID: <XGbyknpWeuwIy8kp2-FURU5X65QiZEd-_Ha0Quih-ek=.42fceb13-9fc5-4eac-8b21-bc3e1eeaee15@github.com>

> Modified the `make/scripts/update_copyright_year.sh` script to support Git as well as Mercurial, as per [JDK-8279315](https://bugs.openjdk.java.net/browse/JDK-8279315). Also added the ability to specify company name as a command line argument instead of being hard-coded into the script.

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

  Add VCS auto-detection

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7027/files
  - new: https://git.openjdk.java.net/jdk/pull/7027/files/17805219..670b50b2

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

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

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


From shade at openjdk.java.net  Mon Jan 17 08:22:28 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 17 Jan 2022 08:22:28 GMT
Subject: RFR: 8279958: Provide configure hints for Alpine/apk package
 managers
In-Reply-To: <MjROlusJUNBUokH1qA8vRFRfNsZdCOhzMolxUUztjPI=.213098ff-b63b-4483-8a3d-7104e5157a2e@github.com>
References: <MjROlusJUNBUokH1qA8vRFRfNsZdCOhzMolxUUztjPI=.213098ff-b63b-4483-8a3d-7104e5157a2e@github.com>
Message-ID: <QfOBKfJ80l628i6KU2ydsv1VTYxy_9OEH50JZuz7j-U=.86f20fc9-22fc-4b61-b173-633ccb62b371@github.com>

On Thu, 13 Jan 2022 12:02:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Our build system provides helpful hints about the packages to install to resolve the build-time dependencies. It can be amended to include Alpine/apk package managers. Noticed this when trying to build mainline OpenJDK on Alpine 3. 
> 
> Additional testing:
>  - [x] Was able to build on clean Alpine 3 with these hints

Since this is a simple change and at least one build system maintainer acked this, I am integrating.

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

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


From shade at openjdk.java.net  Mon Jan 17 08:22:28 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 17 Jan 2022 08:22:28 GMT
Subject: Integrated: 8279958: Provide configure hints for Alpine/apk package
 managers
In-Reply-To: <MjROlusJUNBUokH1qA8vRFRfNsZdCOhzMolxUUztjPI=.213098ff-b63b-4483-8a3d-7104e5157a2e@github.com>
References: <MjROlusJUNBUokH1qA8vRFRfNsZdCOhzMolxUUztjPI=.213098ff-b63b-4483-8a3d-7104e5157a2e@github.com>
Message-ID: <Y7C5G8pN6MJTIrrR5mhwipfcunDwkRYFKOg6KGzBkyM=.4bf701b1-3f38-4ba1-b6d1-51ac5e5ca750@github.com>

On Thu, 13 Jan 2022 12:02:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Our build system provides helpful hints about the packages to install to resolve the build-time dependencies. It can be amended to include Alpine/apk package managers. Noticed this when trying to build mainline OpenJDK on Alpine 3. 
> 
> Additional testing:
>  - [x] Was able to build on clean Alpine 3 with these hints

This pull request has now been integrated.

Changeset: a30aa52b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a30aa52b77931bcea38213cf3d243d18a37dc858
Stats:     25 lines in 1 file changed: 23 ins; 0 del; 2 mod

8279958: Provide configure hints for Alpine/apk package managers

Reviewed-by: erikj

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

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


From duke at openjdk.java.net  Mon Jan 17 08:23:24 2022
From: duke at openjdk.java.net (Dmitry Kulikov)
Date: Mon, 17 Jan 2022 08:23:24 GMT
Subject: RFR: 8279315: Add Git support to update_copyright_year.sh script
 [v2]
In-Reply-To: <8d4kS1vAVfKpedjAaQSj4vCchb6PJ1_00fjdu10Qbfs=.38e63d92-67fa-4be0-a87b-71f483db6b7f@github.com>
References: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
 <8d4kS1vAVfKpedjAaQSj4vCchb6PJ1_00fjdu10Qbfs=.38e63d92-67fa-4be0-a87b-71f483db6b7f@github.com>
Message-ID: <81VUU6qeAPA589aZ8Gv8gtwDl7j8Z3xGiIf5xcEmFps=.56b76cfb-2775-40e1-9507-c984d33a7431@github.com>

On Thu, 13 Jan 2022 14:06:52 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Looks good.
> 
> Did you consider automatically inferring the VCS by looking for `${this_script_dir}/../../{.git,.hg}`? To resolve `this_script_dir`, you can use the same snippet we have in e.g. top level configure:
> 
> ```
> # Get an absolute path to this script, since that determines the top-level directory.
> this_script_dir=`dirname $0`
> this_script_dir=`cd $this_script_dir > /dev/null && pwd`
> ```

Thank you for the review, and for the suggestion! I've implemented the VCS auto-detection logic now, could you please take another look?

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

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


From matthias.baesken at sap.com  Mon Jan 17 08:31:29 2022
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 17 Jan 2022 08:31:29 +0000
Subject: Heads up: planned Harfbuzz update in jdk11u-dev
In-Reply-To: <YeS4zp+QZNQ/1F2v@hex.discworld.ac.uk>
References: <AM9PR02MB67703D2497B22F5C7F9CD54B93549@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <YeS4zp+QZNQ/1F2v@hex.discworld.ac.uk>
Message-ID: <AM9PR02MB677074FEE2F6501D9B3552E393579@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hi Andrew , it would follow what Oracle did in 11.0.13-oracle  and what Azul did successfully in 13.0.10
 please see  https://bugs.openjdk.java.net/browse/JDK-8261169  , those are all  older / established releases .

>If people want a newer HarfBuzz, they can use --with-harfbuzz=system
> or upgrade to a newer JDK.

Unfortunately at least on the Linux distros I checked , the  system-installed harfbuzz would be older , not newer (at least on SLES where I checked).
Might be different on other distros however ...

Best regards, Matthias


-----Original Message-----
From: Andrew Hughes <gnu.andrew at redhat.com> 
Sent: Montag, 17. Januar 2022 01:31
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; Andrew Brygin <abrygin at azul.com>; Yuri Nesterenko <yan at azul.com>; Zeller, Arno <arno.zeller at sap.com>
Subject: Re: Heads up: planned Harfbuzz update in jdk11u-dev

* PGP Signed by an unknown key

On 09:19 Fri 14 Jan     , Baesken, Matthias wrote:
> For one of the next jdk11 updates, an update to a more recent harfbuzz version is planned.
> This has been done already in jdk/jdk some time ago, and was backported recently to jdk13,
> please see the harfbuzz 2.7.2 / 2.8.0 related changes done in jdk13 :
> 
> https://github.com/openjdk/jdk13u-dev/commit/e183f2d3650b6275a59d0cdd7303ca22f2ae088a
> https://github.com/openjdk/jdk13u-dev/commit/64627b5061fdd15ed52e3858cb52bb6b3b2b020b
> https://github.com/openjdk/jdk13u-dev/commit/c42c231e1dabd37ec09362291dc8141117ce0bbd
> 
> However the new harfbuzz 2.7.2 / 2.8.0 updates need C++11 support (they are built with option -std=c++11).
> So please check that
> 
> a) your toolchain supports -std=c++11 or you have the option to update your toolchain to a more recent version
> 
> 
> or as a workaround
> 
> b) check the -with-harfbuzz=system option to use another precompiled harfbuzz version from your system
> 
> Best regards, Matthias
> 

Why?

11u is a stable release. I don't think it is appropriate to break
existing build setups on a 3+ year old JDK.

If people want a newer HarfBuzz, they can use --with-harfbuzz=system
or upgrade to a newer JDK.
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

* Unknown Key
* 0x35964222


From redestad at openjdk.java.net  Mon Jan 17 11:06:32 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 17 Jan 2022 11:06:32 GMT
Subject: Integrated: 8280032: Update jib-profiles.js to use JMH 1.34 devkit
In-Reply-To: <QZLGRgg89KKoOEx9wyWcyk60subXpJUQG_9cArNWty0=.105600a9-9e3f-4c1b-9e08-8b42565e827a@github.com>
References: <QZLGRgg89KKoOEx9wyWcyk60subXpJUQG_9cArNWty0=.105600a9-9e3f-4c1b-9e08-8b42565e827a@github.com>
Message-ID: <zSXVGq-nu3C9KFmKhtWepERq8xk0Qk0NmfHjNsZWErA=.a8b26d4b-1491-466a-af37-371a1845aac3@github.com>

On Fri, 14 Jan 2022 17:05:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Change so that jib users pick up and use the latest JMH devkit.
> 
> Testing: verified locally

This pull request has now been integrated.

Changeset: 9e536b64
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9e536b64705f841b224d0e64cad0f1609ebf5bca
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8280032: Update jib-profiles.js to use JMH 1.34 devkit

Reviewed-by: erikj, iris

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

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


From duke at openjdk.java.net  Mon Jan 17 15:58:27 2022
From: duke at openjdk.java.net (Martijn Verburg)
Date: Mon, 17 Jan 2022 15:58:27 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <jzBbECe4aS99h4M2FzEWKCJb1hlCroX24H6Qpzkpycc=.5dd50165-b652-4122-9ae0-636204bb491b@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

> /sponser

I think it's _sponsor_

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

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


From duke at openjdk.java.net  Mon Jan 17 16:07:27 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 17 Jan 2022 16:07:27 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder)
In-Reply-To: <fb3uQAhT9A0eUXpBqOWPfzfOGmAJDs1nQRUz4wkfc_M=.95066e8a-e6a9-4ecf-ae36-c9e6fc7615a2@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>
 <fb3uQAhT9A0eUXpBqOWPfzfOGmAJDs1nQRUz4wkfc_M=.95066e8a-e6a9-4ecf-ae36-c9e6fc7615a2@github.com>
Message-ID: <X6xlvhq8lG9ZYA0hc7vB8SOg5KZro2nR5JuZv8VVw9g=.0cb54fee-5668-4022-ade3-0b79eceb30c8@github.com>

On Wed, 22 Dec 2021 04:16:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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.*` ?

@dholmes-ora, That is a fair point. I implemented the functionality before I knew about the project library, but now that I know about it, the cleaner option would be to refactor my solution. I am expecting to make some changes to the code this week, so I will incorporate this one as well. Thanks for the suggestion.

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

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


From duke at openjdk.java.net  Mon Jan 17 16:40:29 2022
From: duke at openjdk.java.net (aamarsh)
Date: Mon, 17 Jan 2022 16:40:29 GMT
Subject: Integrated: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <6NLR7ux4HkRAsuNRZ1P9iubDBK7sQ2Wf1tCNP2V3C7o=.0c3c82a5-6508-413c-83dc-7c947a6dc6ed@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

This pull request has now been integrated.

Changeset: 7b6738fa
Author:    Ana Marsh <anamarsh at microsoft.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b6738fa02023825ed9e602555bd5ed2b87a6ca6
Stats:     12 lines in 4 files changed: 2 ins; 6 del; 4 mod

8278885: Remove Windows ARM64 int8_t workaround in G1

Reviewed-by: erikj, tschatzl, mli

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

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


From duke at openjdk.java.net  Mon Jan 17 19:06:21 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 17 Jan 2022 19:06:21 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v8]
In-Reply-To: <9sr1FosT8HqElw0IZzUJfY9noHxT6rSfgZ9unRu9ijs=.5a3dab44-9e87-40b7-a174-a80c634299e4@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
 <9sr1FosT8HqElw0IZzUJfY9noHxT6rSfgZ9unRu9ijs=.5a3dab44-9e87-40b7-a174-a80c634299e4@github.com>
Message-ID: <s-Kic_9Zm6rKjBUR0vTcHVYkw0rNvetWYPsEPlG2zRo=.e6853bf4-dde9-4ba1-a4e5-c0ca1bb7997e@github.com>

On Wed, 12 Jan 2022 19:29:48 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Speaking of the thread sampler, to ensure stability, you also need a working implementation of os::ThreadCrashProtection. I can see there is the one in os_posix.cpp, and maybe that is the one already in use? Or does there need to be a specialization in os_aix.cpp? Please see https://bugs.openjdk.java.net/browse/JDK-8279077 for more details about crash protection.

Thanks for bringing this to my attention @mgronlun. I spent some time looking over crash protection, and I believe the implementation in os_posix is brought in for >= jdk16. If I understand the project history (especially relating to the issue you linked), this would not necessarily be true for the project before jdk 16, so it will need to be considered if this change is backported.

Is there a way to be sure that ThreadCrashProtection is present on AIX? I have forced a segfault, and it appears to behave the same on Linux x86 as it does on AIX Power.

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

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


From mgronlun at openjdk.java.net  Mon Jan 17 20:49:24 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 17 Jan 2022 20:49:24 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v8]
In-Reply-To: <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
Message-ID: <y62Vj8jaB0C61_iF8QSp6N9o474FZAx6KDNudCrNe3o=.52556aee-87a4-40a6-be8f-7cc69c0c5224@github.com>

On Wed, 12 Jan 2022 15:18:46 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Clean up & testing
>    
>    - Run JFR tests in test/jdk/jdk/jfr
>    - Fix issues found from above test suite
>    - Remove unecessary jtreg & gtest tests
>    - Remove ineffective `qpic=large`
>    - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java
>  - 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

You could test it like this:

In JfrThreadSampler.cpp, you have the OSThreadSampler::protected_task() function:

Insert the following to crash the system:

void OSThreadSampler::protected_task(const os::SuspendedThreadTaskContext& context) {
  +int* null_ptr = nullptr;
  +*null_ptr = 5;
...

If crash protection is enabled and active, for release builds, you will not get a system crash. Instead, you will get this output (in debug builds you will get a crash as expected):

[10.740s][error][jfr        ] Thread method sampler crashed
[10.786s][error][jfr        ] Thread method sampler crashed
[10.798s][error][jfr        ] Thread method sampler crashed
[10.810s][error][jfr        ] Thread method sampler crashed
[10.822s][error][jfr        ] Thread method sampler crashed
[10.834s][error][jfr        ] Thread method sampler crashed
[10.847s][error][jfr        ] Thread method sampler crashed
[10.858s][error][jfr        ] Thread method sampler crashed
...

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

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


From david.holmes at oracle.com  Mon Jan 17 21:50:09 2022
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 Jan 2022 07:50:09 +1000
Subject: Configuration Error in JDK Build Java 8 (JDK8u) for VS
In-Reply-To: <1248377789.1435002.1642431092714@mail.yahoo.com>
References: <503545103.115891.1642031547119.ref@mail.yahoo.com>
 <503545103.115891.1642031547119@mail.yahoo.com>
 <fb47f7cf-fe70-9d13-c062-bc70b378d6f8@oracle.com>
 <1248377789.1435002.1642431092714@mail.yahoo.com>
Message-ID: <c86e6832-5946-170e-82ff-2c24b779ed4e@oracle.com>

Adding back the mailing list.

Hi Ken,

On 18/01/2022 12:51 am, Ken Taylor wrote:
> Hi David,
> 
> The instructions I am following are at
> Building the JDK <https://openjdk.java.net/groups/build/doc/building.html>

Those instructions are for mainline JDK development and not directly 
applicable to 8u. Unfortunately the 8u README-builds.html file has not 
been updated either:

https://github.com/openjdk/jdk8u/blob/master/README-builds.html

but 8u supports building with up to VS 2017 at the moment.

Cheers,
David
-----

> See the section:
>  ????Native Compiler (Toolchain) Requirements
>  ????Microsoft Visual Studio
> 
> I cloned the Git Repo for jdk8u, master branch.
> 
> Ken
> On Sunday, January 16, 2022, 10:35:53 PM CST, David Holmes 
> <david.holmes at oracle.com> wrote:
> 
> 
> Hi Ken,
> 
> On 13/01/2022 9:52 am, Ken Taylor wrote:
>  > I am trying to build JDK 8 from the jdk8u repo, master branch.Project 
> was forked and cloned into a Windows 10 VM.Building in Cygwin.
>  > It appears that the change to support VS 2019 has not been checked in.
>  >
>  > =======================================================
>  >
>  > JDK Build Instructions:
>  > Microsoft Visual Studio
>  >
>  > The minimum accepted version of Visual Studio is 2017. Older versions 
> will not be accepted by configure and will not work.
>  > The maximum accepted version of Visual Studio is 2019.
> 
> What repo exactly and what file contains these build instructions?
> 
> Thanks,
> David
> 
> 
>  > If you have multiple versions of Visual Studio installed, configure 
> will by default pick the latest.
>  >
>  > You can request a specific version to be used by setting
>  >? ?? ?--with-toolchain-version, e.g. --with-toolchain-version=2017.
>  >
>  > =======================================================
>  >
>  > Our Command:
>  >
>  > ./configure
>  >? ?? ?--with-boot-jdk=/cygdrive/c/Programs/Java/jdk1.8.0_301
>  >? ?? ?--with-tools-dir='/cygdrive/c/Program Files (x86)/Microsoft 
> Visual Studio/2019/Community/VC/Auxiliary'
>  >? ?? ?--with-toolchain-version=2019
>  >
>  > =======================================================
>  >
>  > Error:
>  >
>  > configure: Using default toolchain microsoft (Microsoft Visual Studio)
>  > checking for link... /usr/bin/link
>  > checking if the first found link.exe is actually the Cygwin link 
> tool... yes
>  > configure: Visual Studio version 2019 is not valid.
>  > configure: Valid Visual Studio versions: 2010 2012 2013 2015 2017.
>  >
>  > =======================================================
>  >
>  > Was this something that got missed and is there a work-around, or 
> should I install VS 2017?? BTW, VS 2022 also does not work.
>  >
>  > Thanks for any help you can provide.
>  > Ken Taylor
>  >
>  >


From christoph.langer at sap.com  Mon Jan 17 22:34:42 2022
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 17 Jan 2022 22:34:42 +0000
Subject: Heads up: planned Harfbuzz update in jdk11u-dev
In-Reply-To: <YeS4zp+QZNQ/1F2v@hex.discworld.ac.uk>
References: <AM9PR02MB67703D2497B22F5C7F9CD54B93549@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <YeS4zp+QZNQ/1F2v@hex.discworld.ac.uk>
Message-ID: <PAXPR02MB779941C1D3CB7DEEEF7FEDAF8A579@PAXPR02MB7799.eurprd02.prod.outlook.com>

Hi Andrew, all,

> On 09:19 Fri 14 Jan     , Baesken, Matthias wrote:
> > For one of the next jdk11 updates, an update to a more recent harfbuzz
> version is planned.
> >
> > However the new harfbuzz 2.7.2 / 2.8.0 updates need C++11 support (they
> are built with option -std=c++11).
> > So please check that
> >
> > a) your toolchain supports -std=c++11 or you have the option to update
> > your toolchain to a more recent version
> >
> >
> > or as a workaround
> >
> > b) check the -with-harfbuzz=system option to use another precompiled
> > harfbuzz version from your system
> >
> > Best regards, Matthias
> >
> 
> Why?
> 
> 11u is a stable release. I don't think it is appropriate to break existing build
> setups on a 3+ year old JDK.
> 
> If people want a newer HarfBuzz, they can use --with-harfbuzz=system or
> upgrade to a newer JDK.

Andrew, I principally agree with your point. We obviously should try to avoid changes that break existing build setups. However, OTOH, it would be very helpful if OpenJDK 11u can be updated to current harfbuzz versions. One of the main reasons is to be able to keep up with security fixes. I think we should really try to be creative to find a way how harfbuzz could be upgraded.

One approach would be to try to identify the breaking build environments in advance and see if people can make the necessary changes, e.g. updating compilers. If that's not possible in some cases, why can't these "old" build setups not fall back to --with-harfbuzz=system?

Maybe it could also be an option to add the updated harfbuzz version to the code base together with the current version and provide the latter to the old compiler scenarios?

I think further input from the community would be helpful and much appreciated.

Thanks & Best regards
Christoph

From jwilhelm at openjdk.java.net  Tue Jan 18 01:23:21 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 18 Jan 2022 01:23:21 GMT
Subject: RFR: Merge jdk18
Message-ID: <8PYG3aNFWxaqHY3TBzCqtA9mdJedp5I3Sd7xp2ttgWo=.90a15cbc-0f8b-4c55-8df3-15838148f979@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18
 - 8279998: PPC64 debug builds fail with "untested: RangeCheckStub: predicate_failed_trap_id"
 - 8280034: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64
 - 8279924: [PPC64, s390] implement frame::is_interpreted_frame_valid checks
 - 8279702: [macosx] ignore xcodebuild warnings on M1
 - 8279930: Synthetic cast causes generation of store barriers when using heap segments
 - 8279597: [TESTBUG] ReturnBlobToWrongHeapTest.java fails with -XX:TieredStopAtLevel=1 on machines with many cores
 - 8278434: timeouts in test  java/time/test/java/time/format/TestZoneTextPrinterParser.java

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7119&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7119&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/7119/files
  Stats: 403 lines in 9 files changed: 361 ins; 4 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7119/head:pull/7119

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


From jwilhelm at openjdk.java.net  Tue Jan 18 02:00:29 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 18 Jan 2022 02:00:29 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <8PYG3aNFWxaqHY3TBzCqtA9mdJedp5I3Sd7xp2ttgWo=.90a15cbc-0f8b-4c55-8df3-15838148f979@github.com>
References: <8PYG3aNFWxaqHY3TBzCqtA9mdJedp5I3Sd7xp2ttgWo=.90a15cbc-0f8b-4c55-8df3-15838148f979@github.com>
Message-ID: <YHl2pGDs3KCRaXSZVZbH_FsJ60tfKjDc8Q2p651Ioe0=.01c7afdc-641f-402c-8036-5bb2b85d143e@github.com>

On Tue, 18 Jan 2022 01:13:45 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 39f140a2
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/39f140a20120300074167597580f9be34e812cad
Stats:     403 lines in 9 files changed: 361 ins; 4 del; 38 mod

Merge

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

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


From erikj at openjdk.java.net  Tue Jan 18 14:11:30 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 18 Jan 2022 14:11:30 GMT
Subject: RFR: 8279315: Add Git support to update_copyright_year.sh script
 [v2]
In-Reply-To: <XGbyknpWeuwIy8kp2-FURU5X65QiZEd-_Ha0Quih-ek=.42fceb13-9fc5-4eac-8b21-bc3e1eeaee15@github.com>
References: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
 <XGbyknpWeuwIy8kp2-FURU5X65QiZEd-_Ha0Quih-ek=.42fceb13-9fc5-4eac-8b21-bc3e1eeaee15@github.com>
Message-ID: <Q299s6kRdhmqqWDRG8dxslkOYzSml_8bXUjwfmlWjF0=.bcc9aa7c-48e8-4db9-858b-f2c8b850c1bc@github.com>

On Mon, 17 Jan 2022 08:17:01 GMT, Dmitry Kulikov <duke at openjdk.java.net> wrote:

>> Modified the `make/scripts/update_copyright_year.sh` script to support Git as well as Mercurial, as per [JDK-8279315](https://bugs.openjdk.java.net/browse/JDK-8279315). Also added the ability to specify company name as a command line argument instead of being hard-coded into the script.
>
> Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add VCS auto-detection

Marked as reviewed by erikj (Reviewer).

If you need help sponsoring the change, I can do that. You just need to follow the bots instructions and issue the integrate command first.

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

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


From stuefe at openjdk.java.net  Tue Jan 18 15:33:31 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 18 Jan 2022 15:33:31 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v8]
In-Reply-To: <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
Message-ID: <6lsnKj8GEbeqRR_cMhafjvLJI3EzUTjLIIqLG-RfGD4=.55cf8db5-dd5d-46e4-8f49-1c7494bb215e@github.com>

On Wed, 12 Jan 2022 15:18:46 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Clean up & testing
>    
>    - Run JFR tests in test/jdk/jdk/jfr
>    - Fix issues found from above test suite
>    - Remove unecessary jtreg & gtest tests
>    - Remove ineffective `qpic=large`
>    - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java
>  - 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

Hi Tyler,

nice to see this effort. I'm curious, are you associated with IBM?

This is not a full review, but I can take a closer look over the next days if necessary (but looks like you already got your full set of reviewers).

About ThreadCrashProtection, we unified that into os_posix.cpp, so it should work out of the box on any Posix system. Its the usual sigsetjmp/siglongjmp game, covering SIGBUS and SIGSEGV. I am not aware of any AIX peculiarities which would prevent this from working on AIX.

Cheers, Thomas

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

> 419:       # so for debug we build with '-qpic=large -bbigtoc'.
> 420:       DEBUG_CFLAGS_JVM="-qpic=large"
> 421:     fi

Why this removal? Note that getting the TOC not to explode on AIX has been an ongoing struggle, see this string of associated JBS issues: 

https://bugs.openjdk.java.net/browse/JDK-8184344
https://bugs.openjdk.java.net/browse/JDK-8171408
https://bugs.openjdk.java.net/browse/JDK-8196488
https://bugs.openjdk.java.net/browse/JDK-8204935

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

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


From cushon at openjdk.java.net  Tue Jan 18 23:31:55 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 18 Jan 2022 23:31:55 GMT
Subject: RFR: 8280182: HotSpot Style Guide has stale link to chromium style
 guide
Message-ID: <jXhHeeSzazG5Zswmwd4QtABrufKMr6WRpnlgw3bQVW0=.25afbaf4-818e-4962-ba88-c50ffad8fec5@github.com>

Update links to the chromium style guide in the HotSpot Style Guide.

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

Commit messages:
 - 8280182: HotSpot Style Guide has stale link to chromium style guide

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

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


From dholmes at openjdk.java.net  Wed Jan 19 11:55:28 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 19 Jan 2022 11:55:28 GMT
Subject: RFR: 8280182: HotSpot Style Guide has stale link to chromium style
 guide
In-Reply-To: <jXhHeeSzazG5Zswmwd4QtABrufKMr6WRpnlgw3bQVW0=.25afbaf4-818e-4962-ba88-c50ffad8fec5@github.com>
References: <jXhHeeSzazG5Zswmwd4QtABrufKMr6WRpnlgw3bQVW0=.25afbaf4-818e-4962-ba88-c50ffad8fec5@github.com>
Message-ID: <Tfotneicxcv4FFxKzNy339qp0HdhEguLNEIsovF7_Sg=.90008737-91d1-4938-9c6d-2404e5283b79@github.com>

On Tue, 18 Jan 2022 23:09:12 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Update links to the chromium style guide in the HotSpot Style Guide.

Looks good. Thanks for noticing the problem and fixing it.

David

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

Marked as reviewed by dholmes (Reviewer).

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


From duke at openjdk.java.net  Wed Jan 19 13:19:29 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Wed, 19 Jan 2022 13:19:29 GMT
Subject: RFR: 8258240: make vscode-project on Windows generates
 jdk.code-workspace file with unescaped '\' in paths
In-Reply-To: <_ChRC4LbPyh6n41HU6Wnz0oso7awQv-Iyh317MrOQ_I=.f418748d-b636-4186-b24e-7ab986496f07@github.com>
References: <JKIgt2erxvLcBh-uNE7QcBXaHc6HqZqYv6tc_1ufJHs=.1faf8863-5db6-4710-9243-29053018156a@github.com>
 <_ChRC4LbPyh6n41HU6Wnz0oso7awQv-Iyh317MrOQ_I=.f418748d-b636-4186-b24e-7ab986496f07@github.com>
Message-ID: <3kmMEJOmEEUUr6_nCqNK20xee4Z3eeofHd-AWsEkwjs=.0db9b1d1-3eba-4b0c-a2ff-dc354d281f39@github.com>

On Fri, 14 Jan 2022 14:32:00 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Backslashes in `sed` replacement string are interpreted by `sed`. In order to output the strings we want, the replacement text needs to be escaped again. See https://stackoverflow.com/a/2705678
>> 
>> Verified that with this patch VSCode is able to open the workspace, and all files are visible in "Explorer".
>
> Looks good!

Thanks @erikj79 for reviewing this. Could you sponsor?

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

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


From duke at openjdk.java.net  Wed Jan 19 14:21:33 2022
From: duke at openjdk.java.net (Daniel Jelinski)
Date: Wed, 19 Jan 2022 14:21:33 GMT
Subject: Integrated: 8258240: make vscode-project on Windows generates
 jdk.code-workspace file with unescaped '\' in paths
In-Reply-To: <JKIgt2erxvLcBh-uNE7QcBXaHc6HqZqYv6tc_1ufJHs=.1faf8863-5db6-4710-9243-29053018156a@github.com>
References: <JKIgt2erxvLcBh-uNE7QcBXaHc6HqZqYv6tc_1ufJHs=.1faf8863-5db6-4710-9243-29053018156a@github.com>
Message-ID: <yRuXSQjocZtHt5LOqnlstwvXigbmWDbg2UGq3PyFGpI=.665207e8-130a-4263-acb2-e564f856579e@github.com>

On Fri, 14 Jan 2022 13:45:51 GMT, Daniel Jelinski <duke at openjdk.java.net> wrote:

> Backslashes in `sed` replacement string are interpreted by `sed`. In order to output the strings we want, the replacement text needs to be escaped again. See https://stackoverflow.com/a/2705678
> 
> Verified that with this patch VSCode is able to open the workspace, and all files are visible in "Explorer".

This pull request has now been integrated.

Changeset: b20b11cf
Author:    Daniel Jelinski <djelinski1 at gmail.com>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b20b11cf8215238e5cd51a1d3a331d5cbfdad710
Stats:     15 lines in 1 file changed: 7 ins; 0 del; 8 mod

8258240: make vscode-project on Windows generates jdk.code-workspace file with unescaped '\' in paths

Reviewed-by: erikj

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

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


From duke at openjdk.java.net  Wed Jan 19 16:10:30 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 19 Jan 2022 16:10:30 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v8]
In-Reply-To: <6lsnKj8GEbeqRR_cMhafjvLJI3EzUTjLIIqLG-RfGD4=.55cf8db5-dd5d-46e4-8f49-1c7494bb215e@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
 <6lsnKj8GEbeqRR_cMhafjvLJI3EzUTjLIIqLG-RfGD4=.55cf8db5-dd5d-46e4-8f49-1c7494bb215e@github.com>
Message-ID: <HQE92J8NW0EfthuMpqsaGLli_6YSh5PvP-8uUCh-iF8=.0e383939-70dd-4a54-9c81-c5a88bc02bd9@github.com>

On Tue, 18 Jan 2022 15:23:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8203290
>>  - Clean up & testing
>>    
>>    - Run JFR tests in test/jdk/jdk/jfr
>>    - Fix issues found from above test suite
>>    - Remove unecessary jtreg & gtest tests
>>    - Remove ineffective `qpic=large`
>>    - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java
>>  - 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
>
> make/autoconf/flags-cflags.m4 line 421:
> 
>> 419:       # so for debug we build with '-qpic=large -bbigtoc'.
>> 420:       DEBUG_CFLAGS_JVM="-qpic=large"
>> 421:     fi
> 
> Why this removal? Note that getting the TOC not to explode on AIX has been an ongoing struggle, see this string of associated JBS issues: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8184344
> https://bugs.openjdk.java.net/browse/JDK-8171408
> https://bugs.openjdk.java.net/browse/JDK-8196488
> https://bugs.openjdk.java.net/browse/JDK-8204935

Hmm, that is strange. I initially thought my code had caused the TOC overflow, and added  -qpic=large to address this. After realizing that my code was not solely responsible, I (tried) to back out of my changes without removing anything I had not added myself. It seems I should review the changes to this file one more time to ensure that I didn't get a bit carried away with the removal process. Good catch.

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

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


From cushon at openjdk.java.net  Wed Jan 19 20:22:12 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 19 Jan 2022 20:22:12 GMT
Subject: Integrated: 8280182: HotSpot Style Guide has stale link to chromium
 style guide
In-Reply-To: <jXhHeeSzazG5Zswmwd4QtABrufKMr6WRpnlgw3bQVW0=.25afbaf4-818e-4962-ba88-c50ffad8fec5@github.com>
References: <jXhHeeSzazG5Zswmwd4QtABrufKMr6WRpnlgw3bQVW0=.25afbaf4-818e-4962-ba88-c50ffad8fec5@github.com>
Message-ID: <lOtfnt3ccVDITuFmy0YqnQWhA1jYYo4uUCt1ADgSnlA=.e2a52267-fc18-468a-b021-5a98d5276342@github.com>

On Tue, 18 Jan 2022 23:09:12 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Update links to the chromium style guide in the HotSpot Style Guide.

This pull request has now been integrated.

Changeset: dac15efc
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dac15efc1be8fe49d2f6365f9adfb31dc3ea74ba
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8280182: HotSpot Style Guide has stale link to chromium style guide

Reviewed-by: dholmes

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

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


From duke at openjdk.java.net  Thu Jan 20 14:22:21 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 20 Jan 2022 14:22:21 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v12]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <ti5ZYoTvD6ZXwAvbLFjKrwU8OJ-cRTQ2KJrAJpzzUp0=.9ef756f4-9548-4acc-9a1e-82ad2391ee75@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 with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge master
 - Fix assembler for post-merge
 - Change UseROPProtection to UseBranchProtection
   
   Change-Id: I31c5e1bb5c285262f262459c13057a46221682f1
   CustomizedGitHooks: yes
 - Remove BSD/Apple specific code
 - Default to building without branch-protection
 - Fix up UseROPProtection flag
 - Merge master
 - Merge master
 - Rename pauth_authenticate_or_strip_return_address
 - Fix windows aarch64 by restoring pauth file split
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/cf977e88...f6f80412

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

Changes: https://git.openjdk.java.net/jdk/pull/6334/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6334&range=11
  Stats: 1367 lines in 25 files changed: 491 ins; 31 del; 845 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 Jan 20 17:10:39 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 20 Jan 2022 17:10:39 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v13]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <ygjV2Tu1Ins_whTCqKcLrr9lvHetbRq3Dre6PHhBhNY=.3ef1e046-2751-4a2b-80f3-ab3d207a091e@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 two additional commits since the last revision:

 - Fix jvmci tests
 - Fix GC issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/f6f80412..14799421

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

  Stats: 50 lines in 11 files changed: 32 ins; 2 del; 16 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 Jan 20 17:10:44 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 20 Jan 2022 17:10:44 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v12]
In-Reply-To: <ti5ZYoTvD6ZXwAvbLFjKrwU8OJ-cRTQ2KJrAJpzzUp0=.9ef756f4-9548-4acc-9a1e-82ad2391ee75@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <ti5ZYoTvD6ZXwAvbLFjKrwU8OJ-cRTQ2KJrAJpzzUp0=.9ef756f4-9548-4acc-9a1e-82ad2391ee75@github.com>
Message-ID: <6ITO7SRTa4es3yv8HZrbJB2AoHQjjYUC0PBYG9kndgY=.52b4e580-3ade-49d3-a37d-8d048dd3bc7c@github.com>

On Thu, 20 Jan 2022 14:22:21 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 19 commits:
> 
>  - Merge master
>  - Fix assembler for post-merge
>  - Change UseROPProtection to UseBranchProtection
>    
>    Change-Id: I31c5e1bb5c285262f262459c13057a46221682f1
>    CustomizedGitHooks: yes
>  - Remove BSD/Apple specific code
>  - Default to building without branch-protection
>  - Fix up UseROPProtection flag
>  - Merge master
>  - Merge master
>  - Rename pauth_authenticate_or_strip_return_address
>  - Fix windows aarch64 by restoring pauth file split
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/cf977e88...f6f80412

The new commits fix all the GC issues and fixes up the jvmci test.

There are still a few nsk tests that need fixing. I'm looking at those now.

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

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


From darcy at openjdk.java.net  Thu Jan 20 19:09:06 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 20 Jan 2022 19:09:06 GMT
Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK 18
 build 32
Message-ID: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>

Update of JDK 18 symbol information for build 32.

@lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered.

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

Commit messages:
 - JDK-8279397: Update --release 18 symbol information for JDK 18 build 32

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

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


From iris at openjdk.java.net  Thu Jan 20 19:26:49 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 20 Jan 2022 19:26:49 GMT
Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK
 18 build 32
In-Reply-To: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
References: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
Message-ID: <zoL9S51sK0TKua1LS-svxjwINdfalZ72Z6UiGJSphIM=.12035ad0-3d93-4f63-b0d8-4c76f7a0986b@github.com>

On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update of JDK 18 symbol information for build 32.
> 
> @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered.

Marked as reviewed by iris (Reviewer).

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

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


From duke at openjdk.java.net  Thu Jan 20 22:30:24 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 20 Jan 2022 22:30:24 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v9]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <tmdb_5bYrLRRVLd6pLe3FJjyUGxDmgnydZev5DWWt-s=.d1e8a954-532a-4443-a2f1-73adfa273ba9@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 19 additional commits since the last revision:

 - Merge branch 'JDK-8203290' of github.com:backwaterred/jdk into JDK-8203290
 - Merge branch 'JDK-8203290' into JDK-8203290-testing
 - Merge branch 'JDK-8203290-testing' of github.com:backwaterred/jdk into JDK-8203290-testing
 - Reverts flags-cflags.m4
 - wip
 - wip
 - Housekeeping
   
   - Minor cleanups
   - Fetch additional SystemProcess info from /proc/<pid>/psinfo file
   - Implement Event creation for loaded modules (fixes
   TestNativeLibrariesEvent failure)
   - Confirm working ThreadCrashPro on AIX
   - Add missing functionality to libperfstat, refactor os_perf_aix
   to use this project library.
   - [TODO] review changes to flags-cflags.m4. Only keep changes required
   for JFR build.
 - Housekeeping
   
   - Fetch additional SystemProcess info from /proc/<pid>/psinfo file
   - Implement Event creation for loaded modules (fixes
     TestNativeLibrariesEvent failure)
   - Confirm working ThreadCrashPro on AIX
   - Add missing functionality to libperfstat, refactor os_perf_aix
     to use this project library.
   - Revert uneeded changes to flags-cflags.m4.
 - Merge branch 'JDK-8203290' into JDK-8203290-testing
 - Fix issue where network_interface pointer is not updated to newly created list
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/ceabb571...e18d56bc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/ceabb571..e18d56bc

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

  Stats: 410 lines in 8 files changed: 339 ins; 16 del; 55 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  Thu Jan 20 22:51:28 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 20 Jan 2022 22:51:28 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v10]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <UjgtU0YsIGWTd2kDqRL1tFu_WnhMwUEJjS0ypDbrqts=.93baa57f-0a23-4c73-af34-d51777620ed4@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 two additional commits since the last revision:

 - Revert changes to jfrThreadSampler.cpp
 - Update copyright years. Remove 'TODO' where no longer needed.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/e18d56bc..5cbf393a

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

  Stats: 11 lines in 8 files changed: 3 ins; 4 del; 4 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 kbarrett at openjdk.java.net  Fri Jan 21 02:23:49 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 21 Jan 2022 02:23:49 GMT
Subject: RFR: 8280182: HotSpot Style Guide has stale link to chromium style
 guide
In-Reply-To: <jXhHeeSzazG5Zswmwd4QtABrufKMr6WRpnlgw3bQVW0=.25afbaf4-818e-4962-ba88-c50ffad8fec5@github.com>
References: <jXhHeeSzazG5Zswmwd4QtABrufKMr6WRpnlgw3bQVW0=.25afbaf4-818e-4962-ba88-c50ffad8fec5@github.com>
Message-ID: <Dj-M5hifhS_FkNQBq6nhgDnPHoDVL8NcaQQH-vqeWMs=.d1b80355-17b4-4166-abfe-77e023e271b5@github.com>

On Tue, 18 Jan 2022 23:09:12 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Update links to the chromium style guide in the HotSpot Style Guide.

The current change process for the style guide requires voting by HotSpot
group members and a decision by the group lead (Vladimir). That seems overly
heavyweight for small editorial changes like this. I've been meaning to
propose a change to the change process, but haven't gotten around to it.  (And
I have several similar editorial changes pending.)

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

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


From xxinliu at amazon.com  Fri Jan 21 09:25:42 2022
From: xxinliu at amazon.com (Liu, Xin)
Date: Fri, 21 Jan 2022 01:25:42 -0800
Subject: Make test-tier1 doesn't work.
Message-ID: <b92f27c3-fb88-7e34-e311-e89f3942c96a@amazon.com>

Hi,

I recently found that "test-tier1" is not a target of makefile now. This
is different from the testing document.
https://github.com/openjdk/jdk/blob/master/doc/testing.md

The self-contained help also says that we can use test-tier1.
$ make help  | grep "make test-"
 make test-<test>       # Run test, e.g. test-tier1

$ make test-tier1 CONF=linux-x86_64-server-fastdebug
make: *** No rule to make target `test-tier1'.  Stop.
$ make --version
GNU Make 3.82
Built for x86_64-koji-linux-gnu
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

make -qp can dump all targets. I can't find test-tier1, test-jdk_lang etc.

Is this target still available? if so, do we need to update testing.md?

thanks,
--lx

From mdoerr at openjdk.java.net  Fri Jan 21 09:31:54 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 21 Jan 2022 09:31:54 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v10]
In-Reply-To: <UjgtU0YsIGWTd2kDqRL1tFu_WnhMwUEJjS0ypDbrqts=.93baa57f-0a23-4c73-af34-d51777620ed4@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <UjgtU0YsIGWTd2kDqRL1tFu_WnhMwUEJjS0ypDbrqts=.93baa57f-0a23-4c73-af34-d51777620ed4@github.com>
Message-ID: <jOzPtjaz6Ak1DadMspcv1lNbgaG4cTdoXAYfByKH7g4=.719e524e-98fe-44f6-a439-45c88807169b@github.com>

On Thu, 20 Jan 2022 22:51:28 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert changes to jfrThreadSampler.cpp
>  - Update copyright years. Remove 'TODO' where no longer needed.

Thanks for enhancing libperfstat_aix and making it consistent.
I just noticed that JavaThread::pd_get_top_frame_for_profiling does not yet contain all the required checks. I think they should be taken from thread_linux_ppc.cpp (note that there were recent fixes).

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

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


From shade at redhat.com  Fri Jan 21 09:39:46 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 21 Jan 2022 10:39:46 +0100
Subject: Make test-tier1 doesn't work.
In-Reply-To: <b92f27c3-fb88-7e34-e311-e89f3942c96a@amazon.com>
References: <b92f27c3-fb88-7e34-e311-e89f3942c96a@amazon.com>
Message-ID: <871fac34-010c-19c4-168a-2df5b83e8dee@redhat.com>

On 1/21/22 10:25 AM, Liu, Xin wrote:
> make -qp can dump all targets. I can't find test-tier1, test-jdk_lang etc.

Huh?

$ make -qp 2>&1 | grep tier1:
run-test-tier1:
test-tier1:

> Is this target still available? if so, do we need to update testing.md?

I think the "normal" way to access test profiles is:
   $ make test TEST=tier1
   $ make test TEST=jdk_lang

But the fallbacks also work for me in current mainline:

$ make test-tier1 CONF=linux-x86_64-server-fastdebug
Building target 'test-tier1' in configuration 'linux-x86_64-server-fastdebug'
Test selection 'tier1', will run:
* jtreg:test/hotspot/jtreg:tier1
* jtreg:test/jdk:tier1
* jtreg:test/langtools:tier1
* jtreg:test/jaxp:tier1
* jtreg:test/lib-test:tier1

Running test 'jtreg:test/hotspot/jtreg:tier1'

-- 
Thanks,
-Aleksey



From erik.joelsson at oracle.com  Fri Jan 21 13:47:42 2022
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 21 Jan 2022 05:47:42 -0800
Subject: Make test-tier1 doesn't work.
In-Reply-To: <b92f27c3-fb88-7e34-e311-e89f3942c96a@amazon.com>
References: <b92f27c3-fb88-7e34-e311-e89f3942c96a@amazon.com>
Message-ID: <dd861dc3-7bd6-3548-4a48-7a7e8c8a7a25@oracle.com>

Hello,

As Alexey says, this should be working.

The data for generating the test-* targets is cached in 
build/linux-x86_64-server-fastdebug/make-support/find-tests.gmk. Can you 
check if you have this file and if the contents looks corrupted? Try 
removing it and see if it gets generated correctly this time.

/Erik

On 2022-01-21 01:25, Liu, Xin wrote:
> Hi,
>
> I recently found that "test-tier1" is not a target of makefile now. This
> is different from the testing document.
> https://github.com/openjdk/jdk/blob/master/doc/testing.md
>
> The self-contained help also says that we can use test-tier1.
> $ make help  | grep "make test-"
>   make test-<test>       # Run test, e.g. test-tier1
>
> $ make test-tier1 CONF=linux-x86_64-server-fastdebug
> make: *** No rule to make target `test-tier1'.  Stop.
> $ make --version
> GNU Make 3.82
> Built for x86_64-koji-linux-gnu
> Copyright (C) 2010  Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> make -qp can dump all targets. I can't find test-tier1, test-jdk_lang etc.
>
> Is this target still available? if so, do we need to update testing.md?
>
> thanks,
> --lx


From duke at openjdk.java.net  Fri Jan 21 15:22:11 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 21 Jan 2022 15:22:11 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v11]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <VIemFuMHR3jtX7YD9_zRpBz_Yvos5ZgVt5VBb9esq4o=.e3210d79-4996-4c8f-96fc-e6b1dd04a6c9@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 pull request now contains 42 commits:

 - rebase on upstream/master to pick up project changes
 - Revert changes to jfrThreadSampler.cpp
 - Update copyright years. Remove 'TODO' where no longer needed.
 - Merge branch 'JDK-8203290' of github.com:backwaterred/jdk into JDK-8203290
 - Merge branch 'master' into JDK-8203290
 - Merge branch 'JDK-8203290' into JDK-8203290-testing
 - Clean up & testing
   
   - Run JFR tests in test/jdk/jdk/jfr
   - Fix issues found from above test suite
   - Remove unecessary jtreg & gtest tests
   - Remove ineffective `qpic=large`
   - TODO: jdk/jfr/event/runtime/TestNativeLibrariesEvent.java
 - Merge branch 'JDK-8203290-testing' of github.com:backwaterred/jdk into JDK-8203290-testing
 - Reverts flags-cflags.m4
 - wip
 - ... and 32 more: https://git.openjdk.java.net/jdk/compare/35172cda...50cf00e1

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

Changes: https://git.openjdk.java.net/jdk/pull/6885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=10
  Stats: 1134 lines in 10 files changed: 446 ins; 479 del; 209 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  Fri Jan 21 16:09:15 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 21 Jan 2022 16:09:15 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v12]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <3WI6zK8DEAzHWwyynkbRQBCddxZZCbX6zrCHVFjIwZw=.1f7d1e2d-02b4-4037-8870-b37f5ce580ac@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:

  Re-removes changes to flags-cflags.m4

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/50cf00e1..49e0b9bc

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

  Stats: 8 lines in 1 file changed: 0 ins; 8 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  Fri Jan 21 17:29:46 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 21 Jan 2022 17:29:46 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v7]
In-Reply-To: <HQE92J8NW0EfthuMpqsaGLli_6YSh5PvP-8uUCh-iF8=.0e383939-70dd-4a54-9c81-c5a88bc02bd9@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <_wOvTZvHhUJKGpwD2tr9X6YJGS3D1YbHmhDKKHSJXDI=.e75b9765-d73d-405c-a6cb-3284088edd33@github.com>
 <6lsnKj8GEbeqRR_cMhafjvLJI3EzUTjLIIqLG-RfGD4=.55cf8db5-dd5d-46e4-8f49-1c7494bb215e@github.com>
 <HQE92J8NW0EfthuMpqsaGLli_6YSh5PvP-8uUCh-iF8=.0e383939-70dd-4a54-9c81-c5a88bc02bd9@github.com>
Message-ID: <1k5cOZxMK2GZAWrkayLKCUJJRL000Uvw4k2eIR2g6qQ=.6358937a-7bbb-47c3-9054-ea9cf4819728@github.com>

On Wed, 19 Jan 2022 16:07:36 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> make/autoconf/flags-cflags.m4 line 421:
>> 
>>> 419:     DEBUG_SYMBOLS_CFLAGS_JDK="$CFLAGS_DEBUG_SYMBOLS"
>>> 420:   fi
>>> 421: 
>> 
>> Why this removal? Note that getting the TOC not to explode on AIX has been an ongoing struggle, see this string of associated JBS issues: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8184344
>> https://bugs.openjdk.java.net/browse/JDK-8171408
>> https://bugs.openjdk.java.net/browse/JDK-8196488
>> https://bugs.openjdk.java.net/browse/JDK-8204935
>
> Hmm, that is strange. I initially thought my code had caused the TOC overflow, and added  -qpic=large to address this. After realizing that my code was not solely responsible, I (tried) to back out of my changes without removing anything I had not added myself. It seems I should review the changes to this file one more time to ensure that I didn't get a bit carried away with the removal process. Good catch.

I checked out the version of this file from upstream/master. All the changes I needed to make were in jvm-features.m4.

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

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


From duke at openjdk.java.net  Fri Jan 21 17:35:14 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 21 Jan 2022 17:35:14 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v13]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <BYYFJseyaER7rP7ni6tMgPoSvWBn--qr-Xv2bkXkDLA=.ecd6ba16-88e5-458c-9203-a715ba69ba3a@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:

  Copies updates from thread_linux_ppc.cpp to thread_aix.cpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/49e0b9bc..999de23a

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

  Stats: 61 lines in 1 file changed: 57 ins; 0 del; 4 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 jlahoda at openjdk.java.net  Fri Jan 21 18:42:51 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 21 Jan 2022 18:42:51 GMT
Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK
 18 build 32
In-Reply-To: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
References: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
Message-ID: <0vhdXH6xMp15rkFrpxZ3YrfPpke3Ox7YEbUO2wFuccQ=.0460eb20-1bd2-437e-9276-a1d56fc604bb@github.com>

On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update of JDK 18 symbol information for build 32.
> 
> @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered.

I believe this is an artifact of limited optimization of the InnerClasses attribute: if the InnerClasses attribute refers to a class that is not part of `ct.sym`, then it is stripped, but if the class is part of ct.sym, the code does not check if it is used from the headers. So some InnerClass entries may sadly be produced for classes that were only used inside method bodies. Possibly an improvement for the future to do more aggressive cleaning. (In general, recording more/unnecessary classes in the InnerClasses shouldn't be harmful besides wasting space, I believe.)

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

Marked as reviewed by jlahoda (Reviewer).

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


From darcy at openjdk.java.net  Fri Jan 21 18:58:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 21 Jan 2022 18:58:45 GMT
Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK
 18 build 32
In-Reply-To: <0vhdXH6xMp15rkFrpxZ3YrfPpke3Ox7YEbUO2wFuccQ=.0460eb20-1bd2-437e-9276-a1d56fc604bb@github.com>
References: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
 <0vhdXH6xMp15rkFrpxZ3YrfPpke3Ox7YEbUO2wFuccQ=.0460eb20-1bd2-437e-9276-a1d56fc604bb@github.com>
Message-ID: <UuFTXYG7DMKucBvAgRIQCEJ3Hq3cwDqxa9az8RielAA=.64c580af-e712-4a89-beef-221182ef2fdb@github.com>

On Fri, 21 Jan 2022 18:39:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I believe this is an artifact of limited optimization of the InnerClasses attribute: if the InnerClasses attribute refers to a class that is not part of `ct.sym`, then it is stripped, but if the class is part of ct.sym, the code does not check if it is used from the headers. So some InnerClass entries may sadly be produced for classes that were only used inside method bodies. Possibly an improvement for the future to do more aggressive cleaning. (In general, recording more/unnecessary classes in the InnerClasses shouldn't be harmful besides wasting space, I believe.)

Good to know; thanks Jan.

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

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


From darcy at openjdk.java.net  Fri Jan 21 18:58:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 21 Jan 2022 18:58:45 GMT
Subject: Integrated: JDK-8279397: Update --release 18 symbol information for
 JDK 18 build 32
In-Reply-To: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
References: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
Message-ID: <krv5rV5lwUo7FacFscZIHLj1nJtJbOhp_l4uqM1hSPM=.6fda74f6-d658-4953-b9fe-afca814e1a2f@github.com>

On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update of JDK 18 symbol information for build 32.
> 
> @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered.

This pull request has now been integrated.

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

8279397: Update --release 18 symbol information for JDK 18 build 32

Reviewed-by: iris, jlahoda

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

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


From kvn at openjdk.java.net  Fri Jan 21 19:17:23 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 21 Jan 2022 19:17:23 GMT
Subject: RFR: 8280182: HotSpot Style Guide has stale link to chromium style
 guide
In-Reply-To: <jXhHeeSzazG5Zswmwd4QtABrufKMr6WRpnlgw3bQVW0=.25afbaf4-818e-4962-ba88-c50ffad8fec5@github.com>
References: <jXhHeeSzazG5Zswmwd4QtABrufKMr6WRpnlgw3bQVW0=.25afbaf4-818e-4962-ba88-c50ffad8fec5@github.com>
Message-ID: <BpILHYv1QParPRgLDYKlZgbKWGV1mCdcNeDlwpaIe8A=.027761d5-bda2-4f83-868f-ae16ebd573d7@github.com>

On Tue, 18 Jan 2022 23:09:12 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Update links to the chromium style guide in the HotSpot Style Guide.

I agree that for small changes like this the process should be simplified.

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

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


From mdoerr at openjdk.java.net  Fri Jan 21 22:53:16 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 21 Jan 2022 22:53:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v13]
In-Reply-To: <BYYFJseyaER7rP7ni6tMgPoSvWBn--qr-Xv2bkXkDLA=.ecd6ba16-88e5-458c-9203-a715ba69ba3a@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <BYYFJseyaER7rP7ni6tMgPoSvWBn--qr-Xv2bkXkDLA=.ecd6ba16-88e5-458c-9203-a715ba69ba3a@github.com>
Message-ID: <AHgTd1B4suatGGDI5s3L3k12Y9SekLMpwMtu5aR8g8E=.6fd22c94-f0c4-4c4f-a7ba-c3edf9921d79@github.com>

On Fri, 21 Jan 2022 17:35:14 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copies updates from thread_linux_ppc.cpp to thread_aix.cpp

I think this PR needs to get fixed such that it compares to the rebased revision. 131 are not reviewable.

src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp line 62:

> 60:                      (address)uc->uc_mcontext.regs->nip);
> 61: 
> 62:     if (ret_frame.pc() == NULL) {

Null check has been moved before frame constructor in head revision.

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

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


From xxinliu at amazon.com  Sun Jan 23 01:29:47 2022
From: xxinliu at amazon.com (Liu, Xin)
Date: Sat, 22 Jan 2022 17:29:47 -0800
Subject: Make test-tier1 doesn't work.
In-Reply-To: <dd861dc3-7bd6-3548-4a48-7a7e8c8a7a25@oracle.com>
References: <b92f27c3-fb88-7e34-e311-e89f3942c96a@amazon.com>
 <dd861dc3-7bd6-3548-4a48-7a7e8c8a7a25@oracle.com>
Message-ID: <c821c1fd-af0c-ae9a-abe3-bb3ef5211ecb@amazon.com>

hi, Aleksey and Erik,

Thank you for taking look into it. I get the correct makefile db after I
make clean and reconfigure. I damaged find-tests.gmk on my side, whereas
the document is perfect.

thanks,
--lx

On 1/21/22 5:47 AM, erik.joelsson at oracle.com wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Hello,
> 
> As Alexey says, this should be working.
> 
> The data for generating the test-* targets is cached in
> build/linux-x86_64-server-fastdebug/make-support/find-tests.gmk. Can you
> check if you have this file and if the contents looks corrupted? Try
> removing it and see if it gets generated correctly this time.
> 
> /Erik
> 
> On 2022-01-21 01:25, Liu, Xin wrote:
>> Hi,
>>
>> I recently found that "test-tier1" is not a target of makefile now. This
>> is different from the testing document.
>> https://github.com/openjdk/jdk/blob/master/doc/testing.md
>>
>> The self-contained help also says that we can use test-tier1.
>> $ make help  | grep "make test-"
>>   make test-<test>       # Run test, e.g. test-tier1
>>
>> $ make test-tier1 CONF=linux-x86_64-server-fastdebug
>> make: *** No rule to make target `test-tier1'.  Stop.
>> $ make --version
>> GNU Make 3.82
>> Built for x86_64-koji-linux-gnu
>> Copyright (C) 2010  Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>>
>> make -qp can dump all targets. I can't find test-tier1, test-jdk_lang etc.
>>
>> Is this target still available? if so, do we need to update testing.md?
>>
>> thanks,
>> --lx

From duke at openjdk.java.net  Sun Jan 23 13:39:02 2022
From: duke at openjdk.java.net (Dmitry Kulikov)
Date: Sun, 23 Jan 2022 13:39:02 GMT
Subject: RFR: 8279315: Add Git support to update_copyright_year.sh script
 [v2]
In-Reply-To: <Q299s6kRdhmqqWDRG8dxslkOYzSml_8bXUjwfmlWjF0=.bcc9aa7c-48e8-4db9-858b-f2c8b850c1bc@github.com>
References: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
 <XGbyknpWeuwIy8kp2-FURU5X65QiZEd-_Ha0Quih-ek=.42fceb13-9fc5-4eac-8b21-bc3e1eeaee15@github.com>
 <Q299s6kRdhmqqWDRG8dxslkOYzSml_8bXUjwfmlWjF0=.bcc9aa7c-48e8-4db9-858b-f2c8b850c1bc@github.com>
Message-ID: <JhUhzKu_34HkbHZ7X0AX8eF86xuXE_dzsij1FObegPk=.e96ff3cc-613b-4d20-92ba-dd6cd75ca590@github.com>

On Tue, 18 Jan 2022 14:07:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add VCS auto-detection
>
> If you need help sponsoring the change, I can do that. You just need to follow the bots instructions and issue the integrate command first.

@erikj79 I guess the bot says it's ready now, could you please sponsor the change?

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

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


From thomas.stuefe at gmail.com  Mon Jan 24 07:43:38 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 24 Jan 2022 08:43:38 +0100
Subject: GHAs and precompiled headers
Message-ID: <CAA-vtUzQv671yAO8jCNCgUih-HvjOyFF9SP8Gb9S23rbOtvCGA@mail.gmail.com>

Hi,

We generally build without --disable-precompiled-headers in GHAs, which
hides errors from missing includes. Since GHAs are very useful to test
builds on side platforms, would it not make sense to build without
precompiled headers? Or is that too costly?

Thanks, Thomas


From shade at redhat.com  Mon Jan 24 09:15:09 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 24 Jan 2022 10:15:09 +0100
Subject: GHAs and precompiled headers
In-Reply-To: <CAA-vtUzQv671yAO8jCNCgUih-HvjOyFF9SP8Gb9S23rbOtvCGA@mail.gmail.com>
References: <CAA-vtUzQv671yAO8jCNCgUih-HvjOyFF9SP8Gb9S23rbOtvCGA@mail.gmail.com>
Message-ID: <f0ff2100-b989-17f6-0f26-d315fc7b815c@redhat.com>

On 1/24/22 8:43 AM, Thomas St?fe wrote:
> We generally build without --disable-precompiled-headers in GHAs, which
> hides errors from missing includes. Since GHAs are very useful to test
> builds on side platforms, would it not make sense to build without
> precompiled headers? Or is that too costly?

But... We *do* build Hotspot without PCH in "additional" configurations that test different platforms:
 
https://github.com/openjdk/jdk/blob/9bf6ffa19f1ea9efcadb3396d921305c9ec0b1d1/.github/workflows/submit.yml#L408-L432

-- 
Thanks,
-Aleksey



From thomas.stuefe at gmail.com  Mon Jan 24 09:26:30 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 24 Jan 2022 10:26:30 +0100
Subject: GHAs and precompiled headers
In-Reply-To: <f0ff2100-b989-17f6-0f26-d315fc7b815c@redhat.com>
References: <CAA-vtUzQv671yAO8jCNCgUih-HvjOyFF9SP8Gb9S23rbOtvCGA@mail.gmail.com>
 <f0ff2100-b989-17f6-0f26-d315fc7b815c@redhat.com>
Message-ID: <CAA-vtUzzaGZYgob1PBKJpsCyrjLrNb1+0mU32NwDS6k7_OQakQ@mail.gmail.com>

On Mon, Jan 24, 2022 at 10:15 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 1/24/22 8:43 AM, Thomas St?fe wrote:
> > We generally build without --disable-precompiled-headers in GHAs, which
> > hides errors from missing includes. Since GHAs are very useful to test
> > builds on side platforms, would it not make sense to build without
> > precompiled headers? Or is that too costly?
>
> But... We *do* build Hotspot without PCH in "additional" configurations
> that test different platforms:
>
>
> https://github.com/openjdk/jdk/blob/9bf6ffa19f1ea9efcadb3396d921305c9ec0b1d1/.github/workflows/submit.yml#L408-L432
>
>
Yes, but only Linux. Leaves out macOS and Windows. For people who mainly
use Linux and rely on GHA not to break the other two this is inconvenient.

..Thomas


From shade at redhat.com  Mon Jan 24 09:31:41 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 24 Jan 2022 10:31:41 +0100
Subject: GHAs and precompiled headers
In-Reply-To: <CAA-vtUzzaGZYgob1PBKJpsCyrjLrNb1+0mU32NwDS6k7_OQakQ@mail.gmail.com>
References: <CAA-vtUzQv671yAO8jCNCgUih-HvjOyFF9SP8Gb9S23rbOtvCGA@mail.gmail.com>
 <f0ff2100-b989-17f6-0f26-d315fc7b815c@redhat.com>
 <CAA-vtUzzaGZYgob1PBKJpsCyrjLrNb1+0mU32NwDS6k7_OQakQ@mail.gmail.com>
Message-ID: <85d8e772-8494-bc02-c6de-afd70dcde444@redhat.com>

On 1/24/22 10:26 AM, Thomas St?fe wrote:
> 
> 
> On Mon, Jan 24, 2022 at 10:15 AM Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>> wrote:
> 
>     On 1/24/22 8:43 AM, Thomas St?fe wrote:
>      > We generally build without --disable-precompiled-headers in GHAs, which
>      > hides errors from missing includes. Since GHAs are very useful to test
>      > builds on side platforms, would it not make sense to build without
>      > precompiled headers? Or is that too costly?
> 
>     But... We *do* build Hotspot without PCH in "additional" configurations that test different
>     platforms:
> 
>     https://github.com/openjdk/jdk/blob/9bf6ffa19f1ea9efcadb3396d921305c9ec0b1d1/.github/workflows/submit.yml#L408-L432
>     <https://github.com/openjdk/jdk/blob/9bf6ffa19f1ea9efcadb3396d921305c9ec0b1d1/.github/workflows/submit.yml#L408-L432>
> 
> Yes, but only Linux. Leaves out macOS and Windows. For people who mainly use Linux and rely on GHA 

Ah.

The last I checked, dropping PCH on Windows made build times suffer a lot. Given how underpowered 
are the Windows and MacOS build nodes in GHA, I'd rather accept a small possibility of non-PCH 
breakage than slowness of generic GHA workflows.

-- 
Thanks,
-Aleksey



From thomas.stuefe at gmail.com  Mon Jan 24 09:36:55 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 24 Jan 2022 10:36:55 +0100
Subject: GHAs and precompiled headers
In-Reply-To: <85d8e772-8494-bc02-c6de-afd70dcde444@redhat.com>
References: <CAA-vtUzQv671yAO8jCNCgUih-HvjOyFF9SP8Gb9S23rbOtvCGA@mail.gmail.com>
 <f0ff2100-b989-17f6-0f26-d315fc7b815c@redhat.com>
 <CAA-vtUzzaGZYgob1PBKJpsCyrjLrNb1+0mU32NwDS6k7_OQakQ@mail.gmail.com>
 <85d8e772-8494-bc02-c6de-afd70dcde444@redhat.com>
Message-ID: <CAA-vtUxpuyWGbjK9+56FEzgqk-cTz7EQP1c412Y-MFS4in=OjQ@mail.gmail.com>

On Mon, Jan 24, 2022 at 10:31 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 1/24/22 10:26 AM, Thomas St?fe wrote:
> >
> >
> > On Mon, Jan 24, 2022 at 10:15 AM Aleksey Shipilev <shade at redhat.com
> <mailto:shade at redhat.com>> wrote:
> >
> >     On 1/24/22 8:43 AM, Thomas St?fe wrote:
> >      > We generally build without --disable-precompiled-headers in GHAs,
> which
> >      > hides errors from missing includes. Since GHAs are very useful to
> test
> >      > builds on side platforms, would it not make sense to build without
> >      > precompiled headers? Or is that too costly?
> >
> >     But... We *do* build Hotspot without PCH in "additional"
> configurations that test different
> >     platforms:
> >
> >
> https://github.com/openjdk/jdk/blob/9bf6ffa19f1ea9efcadb3396d921305c9ec0b1d1/.github/workflows/submit.yml#L408-L432
> >     <
> https://github.com/openjdk/jdk/blob/9bf6ffa19f1ea9efcadb3396d921305c9ec0b1d1/.github/workflows/submit.yml#L408-L432
> >
> >
> > Yes, but only Linux. Leaves out macOS and Windows. For people who mainly
> use Linux and rely on GHA
>
> Ah.
>
> The last I checked, dropping PCH on Windows made build times suffer a lot.
> Given how underpowered
> are the Windows and MacOS build nodes in GHA, I'd rather accept a small
> possibility of non-PCH
> breakage than slowness of generic GHA workflows.
>
>
Pity, but I guess it cannot be avoided. It hit me this weekend, but at
least I know now the GHA limitations.

Thanks, Thomas


From erikj at openjdk.java.net  Mon Jan 24 14:11:10 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 24 Jan 2022 14:11:10 GMT
Subject: RFR: 8279315: Add Git support to update_copyright_year.sh script
 [v2]
In-Reply-To: <XGbyknpWeuwIy8kp2-FURU5X65QiZEd-_Ha0Quih-ek=.42fceb13-9fc5-4eac-8b21-bc3e1eeaee15@github.com>
References: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
 <XGbyknpWeuwIy8kp2-FURU5X65QiZEd-_Ha0Quih-ek=.42fceb13-9fc5-4eac-8b21-bc3e1eeaee15@github.com>
Message-ID: <5HHTB0x68a3Io0-12KrSvCPGMw6gWpaI9IVDsCR9CAg=.c67beb82-32c9-49d2-9041-972e51a7c5d3@github.com>

On Mon, 17 Jan 2022 08:17:01 GMT, Dmitry Kulikov <duke at openjdk.java.net> wrote:

>> Modified the `make/scripts/update_copyright_year.sh` script to support Git as well as Mercurial, as per [JDK-8279315](https://bugs.openjdk.java.net/browse/JDK-8279315). Also added the ability to specify company name as a command line argument instead of being hard-coded into the script.
>
> Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add VCS auto-detection

Sorry, I don't get any notification that it's ready to be sponsored.

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

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


From duke at openjdk.java.net  Mon Jan 24 14:11:10 2022
From: duke at openjdk.java.net (Dmitry Kulikov)
Date: Mon, 24 Jan 2022 14:11:10 GMT
Subject: Integrated: 8279315: Add Git support to update_copyright_year.sh
 script
In-Reply-To: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
References: <4lq82x0MfPohi_RyDGLa7OpwFBf4SnrhZHim8j0vVr8=.d04ce84f-ba78-4abf-bb01-434ed5afc790@github.com>
Message-ID: <IX-mSRSVJrg0mssgZ5L9TKLAd-hzL-diW5dB6B0lBss=.61e29f9c-505d-4400-921d-9d08e8980aa8@github.com>

On Tue, 11 Jan 2022 13:10:38 GMT, Dmitry Kulikov <duke at openjdk.java.net> wrote:

> Modified the `make/scripts/update_copyright_year.sh` script to support Git as well as Mercurial, as per [JDK-8279315](https://bugs.openjdk.java.net/browse/JDK-8279315). Also added the ability to specify company name as a command line argument instead of being hard-coded into the script.

This pull request has now been integrated.

Changeset: d53d8bd7
Author:    Dmitry Kulikov <projectd8 at yandex.ru>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d53d8bd7088c3dac0ca104aed919ad2dcb1cf6af
Stats:     79 lines in 1 file changed: 60 ins; 4 del; 15 mod

8279315: Add Git support to update_copyright_year.sh script

Reviewed-by: erikj

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

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


From duke at openjdk.java.net  Mon Jan 24 15:56:06 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 24 Jan 2022 15:56:06 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@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 popframe failures

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/14799421..0b476542

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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  Mon Jan 24 15:56:06 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 24 Jan 2022 15:56:06 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v13]
In-Reply-To: <ygjV2Tu1Ins_whTCqKcLrr9lvHetbRq3Dre6PHhBhNY=.3ef1e046-2751-4a2b-80f3-ab3d207a091e@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <ygjV2Tu1Ins_whTCqKcLrr9lvHetbRq3Dre6PHhBhNY=.3ef1e046-2751-4a2b-80f3-ab3d207a091e@github.com>
Message-ID: <dZ30ow-1IrMa2V83RSflKOF6Baa6hkxXLoXEGXIXQ-I=.c494de8a-5b7a-4ee2-a53a-b486107ecf91@github.com>

On Thu, 20 Jan 2022 17:10:39 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 two additional commits since the last revision:
> 
>  - Fix jvmci tests
>  - Fix GC issues

That fixes all the jtreg failures - everything passes now.

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

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


From adinn at openjdk.java.net  Mon Jan 24 16:39:12 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 24 Jan 2022 16:39:12 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
Message-ID: <DayQcbSd_7M-Fz2FZM_m1BJms-uwqes0Yv3UOefsoAk=.53596cf5-f261-46d0-a119-7058b41c1a61@github.com>

On Mon, 24 Jan 2022 15:56:06 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 popframe failures

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 835:

> 833:   __ stp(rlocals, rcpool, Address(sp, 2 * wordSize));
> 834: 
> 835:   __ protect_return_address();

Most of the changes to fix the tests look fairly self-explanatory but I don't really understand why you relocated call to protect_return-_address from its previous location at line 801. Can you explain why it has been moved?

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

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


From adinn at openjdk.java.net  Mon Jan 24 16:47:11 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 24 Jan 2022 16:47:11 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
Message-ID: <dQpy9bR7jipdFQXsdb3zc_Pxwyq9RFz2EVnm1l0s3y0=.2664234b-4a10-41c6-8b57-2631660d753c@github.com>

On Mon, 24 Jan 2022 15:56:06 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 popframe failures

These test fixes all look like they are doing the right thing and  are localized to systems that have PAC_RET support.

It was a bit of a surprise to realize that double-protecting was a faux pas and, in consequence, that there there were places where a protected address was being encountered where a raw one was needed. It makes me wonder if there are other places where that might happen lying dormant which just happen not to have been found by any existing test. Do we have any way of systematically excluding that possibility (I supsect the answer is no but I have to ask).

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

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


From duke at openjdk.java.net  Mon Jan 24 16:54:11 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 24 Jan 2022 16:54:11 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <DayQcbSd_7M-Fz2FZM_m1BJms-uwqes0Yv3UOefsoAk=.53596cf5-f261-46d0-a119-7058b41c1a61@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <DayQcbSd_7M-Fz2FZM_m1BJms-uwqes0Yv3UOefsoAk=.53596cf5-f261-46d0-a119-7058b41c1a61@github.com>
Message-ID: <XC57PsfknPaetn8gichSgj0FtvNVHirvUotnL2VWukE=.bd59116b-e733-43a0-b0a1-c5c8fd2115f4@github.com>

On Mon, 24 Jan 2022 16:36:18 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix popframe failures
>
> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 835:
> 
>> 833:   __ stp(rlocals, rcpool, Address(sp, 2 * wordSize));
>> 834: 
>> 835:   __ protect_return_address();
> 
> Most of the changes to fix the tests look fairly self-explanatory but I don't really understand why you relocated call to protect_return-_address from its previous location at line 801. Can you explain why it has been moved?

I originally moved it as part of debugging (a GC load_at occurs during the load_mirror).
Once all the GC changes went in (all the enter_subframe calls), this change was no longer required.
Then, when I came to change it back, I realised it made more sense in the new place. The protect is now directly before the storing of lr to the stack. That's logically a better place and should make the assembler easier to read.

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

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


From duke at openjdk.java.net  Mon Jan 24 16:55:09 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 24 Jan 2022 16:55:09 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v10]
In-Reply-To: <jOzPtjaz6Ak1DadMspcv1lNbgaG4cTdoXAYfByKH7g4=.719e524e-98fe-44f6-a439-45c88807169b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <UjgtU0YsIGWTd2kDqRL1tFu_WnhMwUEJjS0ypDbrqts=.93baa57f-0a23-4c73-af34-d51777620ed4@github.com>
 <jOzPtjaz6Ak1DadMspcv1lNbgaG4cTdoXAYfByKH7g4=.719e524e-98fe-44f6-a439-45c88807169b@github.com>
Message-ID: <7esM7xma1GIrLRqplbnvP_rnUcSLAb_0dEqSsPd_C8U=.dff246bd-50d5-457f-96a3-78e417c75975@github.com>

On Fri, 21 Jan 2022 09:28:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to jfrThreadSampler.cpp
>>  - Update copyright years. Remove 'TODO' where no longer needed.
>
> Thanks for enhancing libperfstat_aix and making it consistent.
> I just noticed that JavaThread::pd_get_top_frame_for_profiling does not yet contain all the required checks. I think they should be taken from thread_linux_ppc.cpp (note that there were recent fixes).

Thanks for your comments @TheRealMDoerr. I agree that 131 files changed is too many to review; most of them are not files I actually changed, so I will do some digging to understand what happened there. My typical git workflow does not seem to be working well for this project.

Regarding the changes requested to `JavaThread::pd_get_top_frame_for_profiling`, is there an issue/pr for tracking the changes you are requesting?

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

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


From mdoerr at openjdk.java.net  Mon Jan 24 17:02:15 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 24 Jan 2022 17:02:15 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v10]
In-Reply-To: <jOzPtjaz6Ak1DadMspcv1lNbgaG4cTdoXAYfByKH7g4=.719e524e-98fe-44f6-a439-45c88807169b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <UjgtU0YsIGWTd2kDqRL1tFu_WnhMwUEJjS0ypDbrqts=.93baa57f-0a23-4c73-af34-d51777620ed4@github.com>
 <jOzPtjaz6Ak1DadMspcv1lNbgaG4cTdoXAYfByKH7g4=.719e524e-98fe-44f6-a439-45c88807169b@github.com>
Message-ID: <6hBnk5lDMwSrs11CWMjBoOnwcdeTKNG1WAU97PUe4C4=.189e5cc9-cb15-40d4-85c0-fea91c8060d6@github.com>

On Fri, 21 Jan 2022 09:28:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to jfrThreadSampler.cpp
>>  - Update copyright years. Remove 'TODO' where no longer needed.
>
> Thanks for enhancing libperfstat_aix and making it consistent.
> I just noticed that JavaThread::pd_get_top_frame_for_profiling does not yet contain all the required checks. I think they should be taken from thread_linux_ppc.cpp (note that there were recent fixes).

> Thanks for your comments @TheRealMDoerr. I agree that 131 files changed is too many to review; most of them are not files I actually changed, so I will do some digging to understand what happened there. My typical git workflow does not seem to be working well for this project.

I believe you can click on "edit" and then select which branch to use to create the diff.

> Regarding the changes requested to `JavaThread::pd_get_top_frame_for_profiling`, is there an issue/pr for tracking the changes you are requesting?

https://github.com/openjdk/jdk/commit/f37bfeadcf036a75defc64ad7f4a9f5596cd7407

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

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


From duke at openjdk.java.net  Mon Jan 24 17:11:17 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 24 Jan 2022 17:11:17 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <dQpy9bR7jipdFQXsdb3zc_Pxwyq9RFz2EVnm1l0s3y0=.2664234b-4a10-41c6-8b57-2631660d753c@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <dQpy9bR7jipdFQXsdb3zc_Pxwyq9RFz2EVnm1l0s3y0=.2664234b-4a10-41c6-8b57-2631660d753c@github.com>
Message-ID: <ZkZa7Cz_n7cnskZELDPF0UQu8I4ibg8g2Hx60jJu4gg=.ff59bf7c-ddfe-45fb-9f27-3712dfee8a67@github.com>

On Mon, 24 Jan 2022 16:44:23 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> These test fixes all look like they are doing the right thing and are localized to systems that have PAC_RET support.
> 
> It was a bit of a surprise to realize that double-protecting was a faux pas and, in consequence, that there there were places where a protected address was being encountered where a raw one was needed. It makes me wonder if there are other places where that might happen lying dormant which just happen not to have been found by any existing test. Do we have any way of systematically excluding that possibility (I supsect the answer is no but I have to ask).


check_return_address() is being a huge help here. Before signing, the check is used to confirm it's a raw value. Meaning we get a segfault at the point of the second sign. It's a fairly straightforward process to then figure out that issue.

(Without the check, the segfault would occur on return after the authentication. Which could be a long way away from the signing. From experience, that's not a fun debug journey.)

There might still be some places where that code path is currently not executed today by any of the tests. There's no obvious way to catch those issues.

Once this is in, getting some regular testing will be fairly crucial to make sure it doesn't rot.

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

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


From duke at openjdk.java.net  Mon Jan 24 22:17:34 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 24 Jan 2022 22:17:34 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v14]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <6OfW2D85jS9vMYeso_Zh_Y6O6UBCWNwwgZthUSAkUBw=.d8784882-2d70-4d90-a9a1-ba25a76b16a4@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 pull request now contains one commit:

  Implements JFR on AIX
  
  - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
  - Updates libperfstat_aix to contain functionality needed by os_perf_aix
  - Implements missing functionality in loadlib_aix (Fixes failure noted
  by TestNativeLibraies.java)
  - Removes platform checks for --enable-feature-jfr (Now enable-able on
  all platforms)
  - Enables TestNetworkUtilizationEvent.java which now passes on AIX
  - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

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

Changes: https://git.openjdk.java.net/jdk/pull/6885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=13
  Stats: 1195 lines in 10 files changed: 500 ins; 481 del; 214 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  Mon Jan 24 22:23:33 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 24 Jan 2022 22:23:33 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@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 pull request now contains two commits:

 - Merge branch 'master' into JDK-8203290
 - Implements JFR on AIX
   
   - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
   - Updates libperfstat_aix to contain functionality needed by os_perf_aix
   - Implements missing functionality in loadlib_aix (Fixes failure noted
   by TestNativeLibraies.java)
   - Removes platform checks for --enable-feature-jfr (Now enable-able on
   all platforms)
   - Enables TestNetworkUtilizationEvent.java which now passes on AIX
   - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

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

Changes: https://git.openjdk.java.net/jdk/pull/6885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=14
  Stats: 1186 lines in 10 files changed: 495 ins; 477 del; 214 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  Mon Jan 24 23:07:22 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 24 Jan 2022 23:07:22 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v10]
In-Reply-To: <6hBnk5lDMwSrs11CWMjBoOnwcdeTKNG1WAU97PUe4C4=.189e5cc9-cb15-40d4-85c0-fea91c8060d6@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <UjgtU0YsIGWTd2kDqRL1tFu_WnhMwUEJjS0ypDbrqts=.93baa57f-0a23-4c73-af34-d51777620ed4@github.com>
 <jOzPtjaz6Ak1DadMspcv1lNbgaG4cTdoXAYfByKH7g4=.719e524e-98fe-44f6-a439-45c88807169b@github.com>
 <6hBnk5lDMwSrs11CWMjBoOnwcdeTKNG1WAU97PUe4C4=.189e5cc9-cb15-40d4-85c0-fea91c8060d6@github.com>
Message-ID: <wiS0RyLCRNhhpwRn_hYVZ8j95ORVK9MdGJGfXJNnsv4=.31be0c79-24c2-4423-866a-85abf24a930e@github.com>

On Mon, 24 Jan 2022 16:58:38 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > Thanks for your comments @TheRealMDoerr. I agree that 131 files changed is too many to review; most of them are not files I actually changed, so I will do some digging to understand what happened there. My typical git workflow does not seem to be working well for this project.
> 
> I believe you can click on "edit" and then select which branch to use to create the diff.

I was not able to edit the branch, but I was able to find another work around. This most recent commit [consolidates] the messy commit history [into a single commit], and only references the 10 files I actually changed.

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

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


From duke at openjdk.java.net  Mon Jan 24 23:07:27 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 24 Jan 2022 23:07:27 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
Message-ID: <vnA5YkHE6qYRdzVsxofjnGSnrxrNOc9iv24R8hbgfUA=.d789eb13-0555-485c-9620-1258c588f40d@github.com>

On Mon, 24 Jan 2022 22:23:33 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

I am aiming to complete work on this feature by the end of this week if possible. I have a few tier1 test failures to review before I am happy with the PR. All test/jdk/jdk/jfr test are passing, so it's possible that some of the failures are unrelated. 

Are there any files that have not yet been mentioned which will need to be changed?

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

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


From minqi at openjdk.java.net  Tue Jan 25 00:30:51 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 25 Jan 2022 00:30:51 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
Message-ID: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>

Please review,
  When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result.
  The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle.

  Tests: tier1,4,7 in test
   Manually tested user case, and checked output of jimage list <modules> for jlinked files using --compress=2.

Thanks
Yumin

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

Commit messages:
 - 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

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

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


From dholmes at openjdk.java.net  Tue Jan 25 01:40:35 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 25 Jan 2022 01:40:35 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
Message-ID: <SvYgGVI8XbQnV7SEJWwJYLE-6FwN9k4mk8k2rOIeuNM=.b7ab4cdd-d4f8-46d8-8087-55320dceb465@github.com>

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review,
>   When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result.
>   The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle.
> 
>   Tests: tier1,4,7 in test
>    Manually tested user case, and checked output of jimage list <modules> for jlinked files using --compress=2.
> 
> Thanks
> Yumin

This needs reviewing by the jimage folk too.

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

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


From dholmes at openjdk.java.net  Tue Jan 25 02:03:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 25 Jan 2022 02:03:36 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
Message-ID: <Fqwwfxlaulk78_B9mCdVjIE1pEhT3PuvNWFWe1Bd54Q=.7dcac147-e4b4-4b95-9247-013ac2db9ad5@github.com>

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review,
>   When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result.
>   The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle.
> 
>   Tests: tier1,4,7 in test
>    Manually tested user case, and checked output of jimage list <modules> for jlinked files using --compress=2.
> 
> Thanks
> Yumin

Hi Yumin,

So let me see if I have this clear.

- The jimage code was using the OS code (dlopen/loadlibrary etc) to try and load the zip library when needed.
- The VM, which is always loaded first, always used to load the zip library unconditionally, hence the OS would simply return the JVM's zip handle to the jimage code.
- When we changed the VM to only load the zip library if needed (not realizing jimage may also need it) then the jimage code would now only succeed if the zip library was in the appropriate lookup paths for the OS.
- The fix is to change the jimage code so that it asks the JVM for the zip library, as the JVM is always setup correctly to find it.

Does that sum it up?
Thanks.

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

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


From minqi at openjdk.java.net  Tue Jan 25 05:06:39 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 25 Jan 2022 05:06:39 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <Fqwwfxlaulk78_B9mCdVjIE1pEhT3PuvNWFWe1Bd54Q=.7dcac147-e4b4-4b95-9247-013ac2db9ad5@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
 <Fqwwfxlaulk78_B9mCdVjIE1pEhT3PuvNWFWe1Bd54Q=.7dcac147-e4b4-4b95-9247-013ac2db9ad5@github.com>
Message-ID: <1iUBAAAsXbvt0D1eL1MfN_7H9Ou3T8RiDIEHQhp_5bI=.7a9bf5be-407f-452f-887d-879d92bebc70@github.com>

On Tue, 25 Jan 2022 01:59:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> * The jimage code was using the OS code (dlopen/loadlibrary etc) to try and load the zip library when needed.
Yes. The zip library has to be in PATH.
> * The VM, which is always loaded first, always used to load the zip library unconditionally, hence the OS would simply return the JVM's zip handle to the jimage code.
Yes. After the fix, jimage will use the version that JVM is using.
> * When we changed the VM to only load the zip library if needed (not realizing jimage may also need it) then the jimage code would now only succeed if the zip library was in the appropriate lookup paths for the OS.
Yes. When in JVM, zip library was always loaded (before https://bugs.openjdk.java.net/browse/JDK-8237750) so jimage in fact get the loaded zip handle from JVM. Unless user set PATH(other than jdk(jre)\bin) to contain the "zip.dll | libzip.so | libzip.dylib" then jimage will load and use that version. After this fix, jimage will use the same version as jvm. 
> * The fix is to change the jimage code so that it asks the JVM for the zip library, as the JVM is always setup correctly to find it.
Yes.

Thanks for taking a detail look.

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

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


From dholmes at openjdk.java.net  Tue Jan 25 06:14:42 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 25 Jan 2022 06:14:42 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
Message-ID: <EncWfc_J51NOoOzVqitUpiGZZmks6KDmDwHWyE9oNK0=.274322fa-c284-479e-adcb-65bf6f72bfc2@github.com>

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review,
>   When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result.
>   The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle.
> 
>   Tests: tier1,4,7 in test
>    Manually tested user case, and checked output of jimage list <modules> for jlinked files using --compress=2.
> 
> Thanks
> Yumin

Seems okay as long as there are no concerns from jimage folk about usage scenarios we may not be aware of.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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


From stuefe at openjdk.java.net  Tue Jan 25 09:14:48 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 25 Jan 2022 09:14:48 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
Message-ID: <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>

On Mon, 24 Jan 2022 22:23:33 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Hi Tyler,

nice work. This is a non-complete review of some things I spotted. Part of it is bikeshedding, feel free to ignore those.

Cheers, Thomas

src/hotspot/os/aix/libperfstat_aix.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2022, Oracle and/or its affiliates. All rights reserved.

Is there a reason for this copyright addition?

src/hotspot/os/aix/loadlib_aix.cpp line 375:

> 373: }
> 374: 
> 375: bool LoadedLibraries::copy_list(LoadedModuleList** head) {

I'd rename the function to something clearer like `reload_and_copy_list` since the reload may come as a surprise

src/hotspot/os/aix/loadlib_aix.hpp line 79:

> 77:   private:
> 78:     const loaded_module_t _module;
> 79:     const LoadedModuleList* _next;

While looking at this code, I realized how old it is (the copyright is wrong, this predates OpenJDK and was written ~2005). Today I would do some things differently, e.g. use a hash table for string interning.

About your change: `LoadedModuleList` is basically a duplication of the `entry_t`+`loaded_module_t` tupel. While I am not against it, it's duplication and a bit much boilerplate. You should at least redo the recursive deletion scheme. That will blow up if no tail call optimization happens.

I assume the whole copy list business is due to concurrent reloading? And because LoadedLibs does not offer an iteration interface?

If you feel up to it, I would simplify this:
- merge `entry_t` and `loaded_module_t` into one structure: give `loaded_module_t` a `next` pointer and get rid of entry_t. This is a scheme we use all over the hotspot (embedding list pointers directly into the payload structures) so it is fine and we save one indirection
- in LoadedLibs implementation, remove entry_t and use loaded_module_t directly
- in your new copy_libs, build up a list of copied loaded_module_t structures under lock protection like you do now with LoadedModuleList
- Do deletion in a loop, not recursively, with something like a new `static LoadedLibs::delete_list(loaded_module_t* list);`

Alternative: give LoadedLibs a callback-like functionality where you iterate the original list under lock protection and just call the given callback or closure class. In that closure, you call the original perfstat callback, so no need to pollute LoadedLibs with perfstat symbols.

Just as an info, in these files we tried to avoid JVM infrastructure, hence the plain `::malloc` instead of `os::malloc`  and we use none of the helper classes the JVM offers. E.g. instead of just using `GrowableHeapArray`, which would be nice and convenient. That is because using JVM infrastructure introduces dependencies to VM state and time (e.g. there are uninitialized time windows at startup), and we wanted this code to work as reliably as possible. Also should work during signal handling. Because the VM may crash at any point, and at any point we want to see call stacks and list of loaded libraries in the hs-err file.

src/hotspot/os/aix/os_perf_aix.cpp line 33:

> 31: #include "runtime/os_perf.hpp"
> 32: #include "runtime/vm_version.hpp"
> 33: #include "utilities/globalDefinitions.hpp"

include debug.hpp too (you use assert)

src/hotspot/os/aix/os_perf_aix.cpp line 48:

> 46: #include <sys/types.h>
> 47: #include <stdlib.h>
> 48: #include <unistd.h>

nice reordering

src/hotspot/os/aix/os_perf_aix.cpp line 94:

> 92:   int len;
> 93: 
> 94:   memset(buf, 0, BUF_LENGTH);

memset is not needed

src/hotspot/os/aix/os_perf_aix.cpp line 95:

> 93: 
> 94:   memset(buf, 0, BUF_LENGTH);
> 95:   snprintf(buf, BUF_LENGTH, "/proc/%llu/psinfo", pid);

Use jio_snprintf instead, it handles a number of special cases (e.g. truncation) more correctly. Needs, I believe, jvm_io.h.

src/hotspot/os/aix/os_perf_aix.cpp line 102:

> 100:   }
> 101: 
> 102:   len = fread(&psinfo, sizeof(char), sizeof(psinfo_t), fp);

bikeshedding: I think its safe to say that sizeof(char) will always be 1, so I guess you can shorten it to 1 :)

src/hotspot/os/aix/os_perf_aix.cpp line 121:

> 119:     pticks->sys  = 0;
> 120:     pticks->idle = 0;
> 121:     pticks->wait = 0;

bikeshed: memset to 0 instead of setting each member individually?

src/hotspot/os/aix/os_perf_aix.cpp line 146:

> 144:   assert(initialize_libperfstat(), "perfstat lib not available");
> 145: 
> 146:   snprintf(name_holder.name, IDENTIFIER_LENGTH, "%d", getpid());

jio_snprintf

src/hotspot/os/aix/os_perf_aix.cpp line 214:

> 212:   // populate cpu_stats && check that the expected number of records have been populated
> 213:   if (ncpus != libperfstat::perfstat_cpu(&name_holder, all_lcpu_stats, sizeof(perfstat_cpu_t), ncpus)) {
> 214:     FREE_RESOURCE_ARRAY(perfstat_cpu_t, all_lcpu_stats, ncpus);

ResourceArray are stack-based arenas. No need to free them manually (freeing is often a noop anyway unless the allocation is a the top of the arena). Very similar to those AutoReleasePools in Objective-C, if you know that.

The way to use them is don't release them. If those allocations don't escape the function (so, you don't return RA memory from the function), you can set a ResourceMark at the start of the function. That is an RAII object which will clear all RA objects allocated in and under this function upon return.

Arguably, you also could just use malloc and free here (NEW_C_HEAP_ARRAY and FREE_C_HEAP_ARRAY)

src/hotspot/os/aix/os_perf_aix.cpp line 516:

> 514:   }
> 515: 
> 516:   FREE_RESOURCE_ARRAY(perfstat_process_t, proc_stats, records_allocated);

no need for release. Use ResourceMark at the top of the function unless RA memory escapes. Or, C heap.

src/hotspot/os/aix/os_perf_aix.cpp line 639:

> 637:   }
> 638: 
> 639:   FREE_RESOURCE_ARRAY(perfstat_netinterface_t, net_stats, records_allocated);

same

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

Changes requested by stuefe (Reviewer).

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


From chagedorn at openjdk.java.net  Tue Jan 25 09:43:34 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 25 Jan 2022 09:43:34 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <2vxIb1vN8LxdnG_zim6JI_RzovAOSLpJJMgxbgu1pnI=.f6cbbebc-2dc0-44ca-bd4b-4d6d3fc18b0f@github.com>

On Tue, 18 Jan 2022 13:19:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
> 
> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
> 
> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
> 
> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
> 
> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
> 
> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
> 
> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
> 
> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
> 
> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
> 
> **Testing:**
> Apart from manual testing, I've added two kinds of tests:
> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
> 
> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
> 
> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
> 
> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
> 
> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>  
> Thanks,
> Christian

Hi David

> This will be really useful - thank you. :)

I'm glad to hear that! :-) Thanks for your overall comments!

> All build file changes need to be seen by the build team.

Right, thanks for adding it again.

> That said I have two general concerns both related to executing non-async-signal-safe code in the signal handler via the error reporting logic. Now I know we already do a ton of stuff in error reporting not guaranteed (in any way) to be safe to do in a signal handler, but whenever we add something new I have to ask the question: how likely is this additional code to lead to secondary failures (hangs or crashes)?

That's a valid concern. I've also asked myself this question when I had initially started using some assertions. We should not crash again during error reporting. I've therefore tried to be as conservative as possible and added bailouts instead, also in loops when reading data. But of course, this is just a best effort and by no means a guarantee to be safe (especially in terms of crashes). What could be alternatives to make this better?

> Secondly, on the same issue the use of unified logging within this code seems even more likely to be problematic - I'm not aware of us currently using UL during error reporting. It may work in basic usecases but if it triggers logfile rotation or other more complex actions what then?

I haven't thought about this before. To be honest, I think UL printing of the `dwarf` tag is only useful during development when adding something new to the parser or when debugging. I don't see much value of these messages otherwise - even less for a Java user. As a first step, I could change the logs from `log_X()` to `log_develop_X()` but that just shifts the problem to non-product builds. Another option (or additional thing) could be to guard the log messages with a new develop flag that's disabled by default. By setting it for development, we accept that it might be unsafe which should be fine.

Thanks,
Christian

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

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


From stuefe at openjdk.java.net  Tue Jan 25 10:32:37 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 25 Jan 2022 10:32:37 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
Message-ID: <YUzz5lYjdwYy9Y7wTyLGvzWoaLWJ6N4APUhQXwqX3IU=.a69ced53-f5c4-4cd6-9485-e60b6ad508ca@github.com>

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review,
>   When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result.
>   The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle.
> 
>   Tests: tier1,4,7 in test
>    Manually tested user case, and checked output of jimage list <modules> for jlinked files using --compress=2.
> 
> Thanks
> Yumin

I'm curious, under what circumstances would, before https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where the JVM was not involved and hence the zip.dll was not loaded already?

For me, the code looks good unless I miss a scenario where we don't have the JVM loaded already at this point.

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

Marked as reviewed by stuefe (Reviewer).

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


From adinn at openjdk.java.net  Tue Jan 25 11:03:40 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Tue, 25 Jan 2022 11:03:40 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <ZkZa7Cz_n7cnskZELDPF0UQu8I4ibg8g2Hx60jJu4gg=.ff59bf7c-ddfe-45fb-9f27-3712dfee8a67@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <dQpy9bR7jipdFQXsdb3zc_Pxwyq9RFz2EVnm1l0s3y0=.2664234b-4a10-41c6-8b57-2631660d753c@github.com>
 <ZkZa7Cz_n7cnskZELDPF0UQu8I4ibg8g2Hx60jJu4gg=.ff59bf7c-ddfe-45fb-9f27-3712dfee8a67@github.com>
Message-ID: <STtlAKdV3g8QhSosv0OB0VQPdbFgKEc3zRdZRyESrU4=.7f6981d4-56fc-4731-af46-5ad5ecb1c171@github.com>

On Mon, 24 Jan 2022 17:07:54 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> check_return_address() is being a huge help here

Yes, I appreciate that rejecting double signing is a good model.The surprise was solely a reflection of my limited understanding.

> There's no obvious way to catch those issues.

Ok, well in that case I guess I'm all right for this to be pushed as is. However, the other reviewers really need to give a nod before you proceed.

> Once this is in, getting some regular testing will be fairly crucial to make sure it doesn't rot.

I am hoping we will get that *informally* as Java developers get their hands on shiny new M1 macs and start using them in anger. However, I agree that having regular test runs for mac-aarch64 is a necessity.

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

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


From adinn at openjdk.java.net  Tue Jan 25 11:11:44 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Tue, 25 Jan 2022 11:11:44 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <XC57PsfknPaetn8gichSgj0FtvNVHirvUotnL2VWukE=.bd59116b-e733-43a0-b0a1-c5c8fd2115f4@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <DayQcbSd_7M-Fz2FZM_m1BJms-uwqes0Yv3UOefsoAk=.53596cf5-f261-46d0-a119-7058b41c1a61@github.com>
 <XC57PsfknPaetn8gichSgj0FtvNVHirvUotnL2VWukE=.bd59116b-e733-43a0-b0a1-c5c8fd2115f4@github.com>
Message-ID: <AFXXFZT9xpS8t_zKcY-xtcLNHm3iIN6RUVmyO1nhOPA=.c8b8d38d-c8c7-4eaa-aaa6-91a91c4d0c2e@github.com>

On Mon, 24 Jan 2022 16:51:26 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 835:
>> 
>>> 833:   __ stp(rlocals, rcpool, Address(sp, 2 * wordSize));
>>> 834: 
>>> 835:   __ protect_return_address();
>> 
>> Most of the changes to fix the tests look fairly self-explanatory but I don't really understand why you relocated call to protect_return-_address from its previous location at line 801. Can you explain why it has been moved?
>
> I originally moved it as part of debugging (a GC load_at occurs during the load_mirror).
> Once all the GC changes went in (all the enter_subframe calls), this change was no longer required.
> Then, when I came to change it back, I realised it made more sense in the new place. The protect is now directly before the storing of lr to the stack. That's logically a better place and should make the assembler easier to read.

Ok, I thought the new place looked better but was not clear why it had not been there in the first place. Thanks for clarifying.

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

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


From david.holmes at oracle.com  Tue Jan 25 12:19:32 2022
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 25 Jan 2022 22:19:32 +1000
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
 <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
Message-ID: <840cceef-b667-3a84-2afd-5ed922237c40@oracle.com>

On 25/01/2022 7:14 pm, Thomas Stuefe wrote:
> src/hotspot/os/aix/libperfstat_aix.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Is there a reason for this copyright addition?

Just FYI that is an invalid copyright line for Oracle. There are only 
two years when they are different. This will cause a build failure in 
the validate-headers target.

But I suspect this copyright line should not have been added.

David
-----



From aph at openjdk.java.net  Tue Jan 25 13:44:35 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 25 Jan 2022 13:44:35 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v2]
In-Reply-To: <3ViGybkSVRbuD_wN398vEFGxNJfiuS1wA_SdLkGtM18=.86e45177-8525-42dc-b27f-c22a67489108@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <DqpP1khabg9YQPvJsdAZm5Bl-aV5tCBhuIC_2yeNvPU=.1dcc624c-b345-42de-acc6-0341a3118dc7@github.com>
 <I9BcKG5hATOeB9VB4UgUlFE69lrwh7V1kYc1-aM1RZE=.7958349d-a0ce-4e64-ae2f-cb7099db5704@github.com>
 <sRvw2wgcxZAyOO8U59-fponA1ztGPWmVStKnHoNc6ng=.e0640791-f153-48b5-a1bd-dbb469a1059d@github.com>
 <CxZhDtER_g7uvzljbUJt5nwnJkfPiN9uXuyVC82i9Zk=.ed48ead2-53c9-4de2-ac12-2a609902772d@github.com>
 <Jv0eierFbiABcz7HxS5t3KjAsTYPRmqb65PDzQd9lzo=.69f4fe6f-ece5-44a9-a7e6-63021f8f9265@github.com>
 <Zr1odUW1UNBN6g7pk6wcg7Ui6B35zCnDkus-DOx9IlY=.de40bd32-422e-4b5e-a7b5-4fc18d4d1c95@github.com>
 <3ViGybkSVRbuD_wN398vEFGxNJfiuS1wA_SdLkGtM18=.86e45177-8525-42dc-b27f-c22a67489108@github.com>
Message-ID: <Cp4MdD2oU-RW255SpnhovWwMI9ZmYNahpiEVhU-dM84=.738e5d32-85b0-4c0e-bc0a-e2be8c9e5176@github.com>

On Thu, 11 Nov 2021 18:15:08 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> > > > Am I right is saying that for Macos, all generated code is remapped RO before execution?
> > > 
> > > 
> > > Ah, no, it seems the code cache is not RWX all the time as far as Java threads are concerned. The Macos/AArch64 code is strategically calling pthread_jit_write_protect_np at Java <-> JVM transition points.
> > 
> > 
> > And this requires magic kernel support. I did mention it to a kernel engineer who wasn't very impressed, but I think it's pretty cool.
> 
> It's possible to emulate this to some extent with memory protection keys on POWER and (recent) x86. See `pkey_alloc`.

I don't think this does exactly what we need, because (at least according to the docs) it does it for the whole process, not just the jit threads. Unless I've read the docs wrongly.

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

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


From aph at openjdk.java.net  Tue Jan 25 13:44:36 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 25 Jan 2022 13:44:36 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v9]
In-Reply-To: <ZnAkQtCXS15bfrk0LqqfYZZZwdJ-E2EpyhT2zi7IbSg=.16878ca6-f850-4809-ab75-79dec44ac317@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>
 <ZnAkQtCXS15bfrk0LqqfYZZZwdJ-E2EpyhT2zi7IbSg=.16878ca6-f850-4809-ab75-79dec44ac317@github.com>
Message-ID: <dxniOtdXqprD_hapqH5eNX0D4YvaSX6fC5hwTkB2X9o=.485185da-1839-45f9-aa58-a8bb480c2b83@github.com>

On Sat, 11 Dec 2021 09:30:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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.

Was this ever resolved?

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

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


From aph at openjdk.java.net  Tue Jan 25 13:49:37 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 25 Jan 2022 13:49:37 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
Message-ID: <7E6HbfQpDC20d4BJTl8NpafM8_ts3zUJYHoQs5yfe4A=.96b5172e-7540-4f1c-989e-23391d07c9a4@github.com>

On Mon, 24 Jan 2022 15:56:06 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 popframe failures

I've reverted my approval pending my question which wasn't resolved.

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

Changes requested by aph (Reviewer).

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


From erikj at openjdk.java.net  Tue Jan 25 14:03:28 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 25 Jan 2022 14:03:28 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <JcbJ0IRt-ar1wG0GPYXMkXLRjc5njAoh8E70GFVJJUM=.72acfaf8-1627-4199-8e0e-6adc35826191@github.com>

On Tue, 18 Jan 2022 13:19:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
> 
> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
> 
> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
> 
> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
> 
> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
> 
> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
> 
> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
> 
> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
> 
> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
> 
> **Testing:**
> Apart from manual testing, I've added two kinds of tests:
> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
> 
> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
> 
> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
> 
> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
> 
> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>  
> Thanks,
> Christian

Build changes look good. The reference to the new env variable is missing the initial underscore in two places.

test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java line 30:

> 28:  * @summary Test DWARF parser with various crashes if debug symbols are available. If the libjvm debug symbols are not
> 29:  *          in the same directory as the libjvm.so file, in a subdirectory called .debug, or in the path specified
> 30:  *          by the environment variable JVM_DWARF_PATH, then no verification of the hs_err_file is done for libjvm.so.

Suggestion:

 *          by the environment variable _JVM_DWARF_PATH, then no verification of the hs_err_file is done for libjvm.so.

test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java line 165:

> 163:                             Asserts.assertTrue(matcher.find(), "Could not find filename or line number in \"" + line + "\"");
> 164:                             System.out.println("Did not find symbols for " + library + ". If they are not in the same directory as " + library + " consider setting " +
> 165:                                                "the environmental variable JVM_DWARF_PATH to point to the debug symbols directory.");

Suggestion:

                                               "the environmental variable _JVM_DWARF_PATH to point to the debug symbols directory.");

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

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


From erikj at openjdk.java.net  Tue Jan 25 14:10:37 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 25 Jan 2022 14:10:37 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
Message-ID: <RVk9U0MLhimAeFVYAYpwS-KRqiIQB-WWTYGqUsthmVE=.53fad526-46a8-4578-8eb0-5135703c4322@github.com>

On Mon, 24 Jan 2022 22:23:33 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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


From duke at openjdk.java.net  Tue Jan 25 14:25:34 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Tue, 25 Jan 2022 14:25:34 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v9]
In-Reply-To: <dxniOtdXqprD_hapqH5eNX0D4YvaSX6fC5hwTkB2X9o=.485185da-1839-45f9-aa58-a8bb480c2b83@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>
 <ZnAkQtCXS15bfrk0LqqfYZZZwdJ-E2EpyhT2zi7IbSg=.16878ca6-f850-4809-ab75-79dec44ac317@github.com>
 <dxniOtdXqprD_hapqH5eNX0D4YvaSX6fC5hwTkB2X9o=.485185da-1839-45f9-aa58-a8bb480c2b83@github.com>
Message-ID: <7WX8q1UcPHempROiRWX2Z38tiIrKnyM3iiWifPfgnJk=.06701f7e-5f02-45ec-beb5-e876974fb4a5@github.com>

On Tue, 25 Jan 2022 13:41:38 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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.
>
> Was this ever resolved?

Sort of. That code has changed quite a bit - UseROPProtection now is a string field not a bool.
"none" or not set - pac disabled.
"pac-ret" - pac always enabled
"standard" - pac enabled if the cpu+os support it.

Also, the pac instructions used aren't all in the NOP space. So, it will crash on a non-pac machine.  It might be possible to change it so it does only use nop space instructions, but I don't think it'll be optimal (need to double check).

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

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


From chagedorn at openjdk.java.net  Tue Jan 25 15:10:11 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 25 Jan 2022 15:10:11 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>

> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
> 
> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
> 
> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
> 
> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
> 
> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
> 
> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
> 
> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
> 
> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
> 
> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
> 
> **Testing:**
> Apart from manual testing, I've added two kinds of tests:
> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
> 
> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
> 
> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
> 
> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
> 
> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>  
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7126/files
  - new: https://git.openjdk.java.net/jdk/pull/7126/files/f8c98a29..7ddb7737

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

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

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


From chagedorn at openjdk.java.net  Tue Jan 25 15:10:13 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 25 Jan 2022 15:10:13 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <JcbJ0IRt-ar1wG0GPYXMkXLRjc5njAoh8E70GFVJJUM=.72acfaf8-1627-4199-8e0e-6adc35826191@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <JcbJ0IRt-ar1wG0GPYXMkXLRjc5njAoh8E70GFVJJUM=.72acfaf8-1627-4199-8e0e-6adc35826191@github.com>
Message-ID: <hMEnmFTEcxGWfUHlpY6m7RRzGhSgJX1X5d-ZX-dUB5I=.e8e2e3ca-bf6b-4ae4-b78e-a0878466aeb5@github.com>

On Tue, 25 Jan 2022 14:00:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Build changes look good. The reference to the new env variable is missing the initial underscore in two places.

Thanks Erik for reviewing the build changes. I updated the places.

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

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


From aph at openjdk.java.net  Tue Jan 25 15:30:41 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 25 Jan 2022 15:30:41 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v9]
In-Reply-To: <7WX8q1UcPHempROiRWX2Z38tiIrKnyM3iiWifPfgnJk=.06701f7e-5f02-45ec-beb5-e876974fb4a5@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>
 <ZnAkQtCXS15bfrk0LqqfYZZZwdJ-E2EpyhT2zi7IbSg=.16878ca6-f850-4809-ab75-79dec44ac317@github.com>
 <dxniOtdXqprD_hapqH5eNX0D4YvaSX6fC5hwTkB2X9o=.485185da-1839-45f9-aa58-a8bb480c2b83@github.com>
 <7WX8q1UcPHempROiRWX2Z38tiIrKnyM3iiWifPfgnJk=.06701f7e-5f02-45ec-beb5-e876974fb4a5@github.com>
Message-ID: <a8jd1bhXs0GDi3-NLBRYQ5ibmvFubZD7dwFIdHz1CxY=.05615d0e-257a-40c0-af44-fbaba21c9b1f@github.com>

On Tue, 25 Jan 2022 14:22:15 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> Was this ever resolved?
>
> Sort of. That code has changed quite a bit - UseROPProtection now is a string field not a bool.
> "none" or not set - pac disabled.
> "pac-ret" - pac always enabled
> "standard" - pac enabled if the cpu+os support it.
> 
> Also, the pac instructions used aren't all in the NOP space. So, it will crash on a non-pac machine.  It might be possible to change it so it does only use nop space instructions, but I don't think it'll be optimal (need to double check).

OK, cool.

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

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


From duke at openjdk.java.net  Tue Jan 25 15:42:36 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 25 Jan 2022 15:42:36 GMT
Subject: Withdrawn: 8274980: Improve adhoc build version strings
In-Reply-To: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
Message-ID: <msTsoc7lSS2bamiywMZGQaNaVjUDcxBvLLHzEhwfvgU=.d69dd335-60ac-491b-a2ea-e843a49f4bc9@github.com>

On Thu, 28 Oct 2021 09:34:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Current adhoc version build strings are not ideal. Some of the problems:
>  * A build number of "0" is inserted, which make the version string look like it's an official build, at least when not reading carefully
>  * The version string gives little indication on what source code the build was based
> 
> Also, an error was discovered in how the build system generates version strings without a build number (since this basically never happened before). A version without a build number,  and without a PRE value, but with an OPT value, should have a "+-" separator, according to JEP 223. While this was correctly handled, the "+-" separator was also applied to versions without a build, but with both PRE and OPT. In this case, the "+" should be omitted, according to JEP 223. This bug is fixed by this commit.
> 
> Ideally, the adhoc version string should include something along the lines of the output of `git describe`. However, since the version string is set at configure time, not build time, this will almost immediately become misleading. :-( A substitute is proposed in this patch, where the branch name is included in the OPT string (if it's not `master`).
> 
> Finally, this patch fixes hotspot so it can properly build without a build number. This was the last blocker for why the build system always required the "0" as build number before. To facilitate interoperability with external tools (like jib) that still sets build number to "0" to really signal "no build number", a build number exactly matching "0" will be interpreted as having no build number.

This pull request has been closed without being integrated.

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

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


From aph at openjdk.java.net  Tue Jan 25 16:29:42 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 25 Jan 2022 16:29:42 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
Message-ID: <9cG3vLZ7nzDen6cG_H3D8QMEUb1MixD-Q2av3wKVPBU=.e33c1f78-d1de-49e6-a7ab-dd15f8c9195c@github.com>

On Mon, 24 Jan 2022 15:56:06 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 popframe failures

Marked as reviewed by aph (Reviewer).

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

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


From minqi at openjdk.java.net  Tue Jan 25 17:26:34 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 25 Jan 2022 17:26:34 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <YUzz5lYjdwYy9Y7wTyLGvzWoaLWJ6N4APUhQXwqX3IU=.a69ced53-f5c4-4cd6-9485-e60b6ad508ca@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
 <YUzz5lYjdwYy9Y7wTyLGvzWoaLWJ6N4APUhQXwqX3IU=.a69ced53-f5c4-4cd6-9485-e60b6ad508ca@github.com>
Message-ID: <fx7_iQNZUs835iJRwNTPME8jqij93DxXESPhp6q-YuE=.84999e42-6199-4fb9-8ee6-4acb1cde9976@github.com>

On Tue, 25 Jan 2022 10:29:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I'm curious, under what circumstances would, before https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where the JVM was not involved and hence the zip.dll was not loaded already?
> 
> For me, the code looks good unless I miss a scenario where we don't have the JVM loaded already at this point.

Thanks for review.  Before 8237750, the zip library is always loaded so jimage just get the handle of the loaded zip by calling . After that, zip is loaded at need, so if jvm does not use zip, it will not be loaded. Unfortunately, it does not realize that jimage is using this zip, so it failed to get the handle. But there exists a case, if the zip is in PATH, the following fix  8244495 used LoadLibrary("zip.dll") for a rescue. If zip.dll is not in PATH, the call still failed to load zip. This is the current issue.

So far, if user loaded zip from native code before jimage code is executed ( I could not image a scenario how it can happen), the GetModuleHandle("zip.dll") may return the handle to it, but it does not surely it is for the "zip.dll" --- if multiple instances exist, the returned handle is not guaranteed the one you want.
 
With this change, if user loads zip from native code (with different version), JVM does not sense that, it will still load zip from $JDK or $JRE, and jimage still uses handle returned from JVM. The only case is JVM failed to load zip library:
  
  if (_zip_handle == NULL) {
    vm_exit_during_initialization("Unable to load zip library", path);
  }

You cannot make any progress  on the failure.

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

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


From shurailine at openjdk.java.net  Wed Jan 26 00:36:52 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Wed, 26 Jan 2022 00:36:52 GMT
Subject: RFR: JDK-8279636: Update JCov version to 3.0.12
Message-ID: <tvxij3jCBx6sVE2IHoljvEhBMbsvYD1I6-ychKn0CO4=.c06f0c03-2d7e-4b66-91d2-3855b0ade709@github.com>

JDK-8279636: Update JCov version to 3.0.12

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

Commit messages:
 - JDK-8279636: Update JCov version to 3.0.12

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

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


From stuefe at openjdk.java.net  Wed Jan 26 05:54:30 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 26 Jan 2022 05:54:30 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <fx7_iQNZUs835iJRwNTPME8jqij93DxXESPhp6q-YuE=.84999e42-6199-4fb9-8ee6-4acb1cde9976@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
 <YUzz5lYjdwYy9Y7wTyLGvzWoaLWJ6N4APUhQXwqX3IU=.a69ced53-f5c4-4cd6-9485-e60b6ad508ca@github.com>
 <fx7_iQNZUs835iJRwNTPME8jqij93DxXESPhp6q-YuE=.84999e42-6199-4fb9-8ee6-4acb1cde9976@github.com>
Message-ID: <wH3y7NKuTs8VK3Kzh-aIe1nNY9k1NWQ2S3_2YkkSVpk=.4f81cc6b-3f5e-433f-87a5-228c038dfaad@github.com>

On Tue, 25 Jan 2022 17:22:54 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> I'm curious, under what circumstances would, before https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where the JVM was not involved and hence the zip.dll was not loaded already?
>> 
>> For me, the code looks good unless I miss a scenario where we don't have the JVM loaded already at this point.
>
>> I'm curious, under what circumstances would, before https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where the JVM was not involved and hence the zip.dll was not loaded already?
>> 
>> For me, the code looks good unless I miss a scenario where we don't have the JVM loaded already at this point.
> 
> Thanks for review.  Before 8237750, the zip library is always loaded so jimage just get the handle of the loaded zip by calling . After that, zip is loaded at need, so if jvm does not use zip, it will not be loaded. Unfortunately, it does not realize that jimage is using this zip, so it failed to get the handle. But there exists a case, if the zip is in PATH, the following fix  8244495 used LoadLibrary("zip.dll") for a rescue. If zip.dll is not in PATH, the call still failed to load zip. This is the current issue.
> 
> So far, if user loaded zip from native code before jimage code is executed ( I could not image a scenario how it can happen), the GetModuleHandle("zip.dll") may return the handle to it, but it does not surely it is for the "zip.dll" --- if multiple instances exist, the returned handle is not guaranteed the one you want.
>  
> With this change, if user loads zip from native code (with different version), JVM does not sense that, it will still load zip from $JDK or $JRE, and jimage still uses handle returned from JVM. The only case is JVM failed to load zip library:
>   
>   if (_zip_handle == NULL) {
>     vm_exit_during_initialization("Unable to load zip library", path);
>   }
> 
> You cannot make any progress  on the failure.

Thanks for the explanation, @yminqi. Change looks good.

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

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


From stuefe at openjdk.java.net  Wed Jan 26 06:11:44 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 26 Jan 2022 06:11:44 GMT
Subject: RFR: JDK-8280583: Always build NMT
Message-ID: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>

After discussing this on hotspot-runtime-dev [1], the general opinion seems to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT unconditional. This affects minimal builds only. As pointed out in the mail thread, the overhead is very small and it would get rid of one configuration to build and test.

[1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html

Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well as the associated build option.

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

Commit messages:
 - remove INCLUDE_NMT and dependend code

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

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


From stuefe at openjdk.java.net  Wed Jan 26 06:23:41 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 26 Jan 2022 06:23:41 GMT
Subject: RFR: JDK-8280583: Always build NMT [v2]
In-Reply-To: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
Message-ID: <PXqQz6EY9p1Co7K6rbc87bJ7ikmbqXKP_Tlg_VBzsQI=.ba3742e8-6691-4d08-836f-b5f7095acae0@github.com>

> After discussing this on hotspot-runtime-dev [1], the general opinion seems to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT unconditional. This affects minimal builds only. As pointed out in the mail thread, the overhead is very small and it would get rid of one configuration to build and test.
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html
> 
> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well as the associated build option.

Thomas Stuefe has updated the pull request incrementally with 15 additional commits since the last revision:

 - 8280377: MethodHandleProxies does not correctly invoke default methods with varags
   
   Reviewed-by: alanb
 - 8213905: reflection not working for type annotations applied to exception types in the inner class constructor
   
   Reviewed-by: jlahoda
 - 8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement
   
   Reviewed-by: iris, dholmes, mchung
 - 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987
   8258071: Fix for JDK-8255987 can be subverted with ObjectReference.EnableCollection
   
   Reviewed-by: dholmes, pliden
 - 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases
   
   Reviewed-by: sspitsyn, lmesnik
 - 8280041: Retry loop issues in java.io.ClassCache
   
   Co-authored-by: Peter Levart <plevart at openjdk.org>
   Reviewed-by: rkennke, rriggs, plevart
 - 8280168: Add Objects.toIdentityString
   
   Reviewed-by: alanb, mchung, rriggs, smarks
 - 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException
   
   Reviewed-by: alanb
 - 8280396: G1: Full gc mark stack draining should prefer to make work available to other threads
   
   Reviewed-by: sjohanss, ayang
 - 8280414: Memory leak in DefaultProxySelector
   
   Reviewed-by: dfuchs
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/a19176e6...44478392

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7213/files
  - new: https://git.openjdk.java.net/jdk/pull/7213/files/a19176e6..44478392

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

  Stats: 948 lines in 56 files changed: 717 ins; 90 del; 141 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7213.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7213/head:pull/7213

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


From alanb at openjdk.java.net  Wed Jan 26 07:56:35 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 26 Jan 2022 07:56:35 GMT
Subject: RFR: JDK-8279636: Update JCov version to 3.0.12
In-Reply-To: <tvxij3jCBx6sVE2IHoljvEhBMbsvYD1I6-ychKn0CO4=.c06f0c03-2d7e-4b66-91d2-3855b0ade709@github.com>
References: <tvxij3jCBx6sVE2IHoljvEhBMbsvYD1I6-ychKn0CO4=.c06f0c03-2d7e-4b66-91d2-3855b0ade709@github.com>
Message-ID: <mc2HL7xY3edAlkdOG_ggvNd4XeXwVfKQHsDk7qdMOAQ=.bef1d849-1798-4462-8066-8bc1f51be758@github.com>

On Wed, 26 Jan 2022 00:08:36 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> JDK-8279636: Update JCov version to 3.0.12

Thanks, I can confirm that 3.0-12 works with the current main line.

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

Marked as reviewed by alanb (Reviewer).

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


From shade at openjdk.java.net  Wed Jan 26 08:29:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 26 Jan 2022 08:29:33 GMT
Subject: RFR: JDK-8280583: Always build NMT [v2]
In-Reply-To: <PXqQz6EY9p1Co7K6rbc87bJ7ikmbqXKP_Tlg_VBzsQI=.ba3742e8-6691-4d08-836f-b5f7095acae0@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
 <PXqQz6EY9p1Co7K6rbc87bJ7ikmbqXKP_Tlg_VBzsQI=.ba3742e8-6691-4d08-836f-b5f7095acae0@github.com>
Message-ID: <bcpu4IAFIZJI9z2KqXDEVJt72efQz2nn1PSl0Hs5FvA=.572e1cf9-421c-4e8d-a60e-8ee38c62eea1@github.com>

On Wed, 26 Jan 2022 06:23:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> After discussing this on hotspot-runtime-dev [1], the general opinion seems to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT unconditional. This affects minimal builds only. As pointed out in the mail thread, the overhead is very small and it would get rid of one configuration to build and test.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html
>> 
>> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well as the associated build option.
>
> Thomas Stuefe has updated the pull request incrementally with 15 additional commits since the last revision:
> 
>  - 8280377: MethodHandleProxies does not correctly invoke default methods with varags
>    
>    Reviewed-by: alanb
>  - 8213905: reflection not working for type annotations applied to exception types in the inner class constructor
>    
>    Reviewed-by: jlahoda
>  - 8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement
>    
>    Reviewed-by: iris, dholmes, mchung
>  - 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987
>    8258071: Fix for JDK-8255987 can be subverted with ObjectReference.EnableCollection
>    
>    Reviewed-by: dholmes, pliden
>  - 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases
>    
>    Reviewed-by: sspitsyn, lmesnik
>  - 8280041: Retry loop issues in java.io.ClassCache
>    
>    Co-authored-by: Peter Levart <plevart at openjdk.org>
>    Reviewed-by: rkennke, rriggs, plevart
>  - 8280168: Add Objects.toIdentityString
>    
>    Reviewed-by: alanb, mchung, rriggs, smarks
>  - 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException
>    
>    Reviewed-by: alanb
>  - 8280396: G1: Full gc mark stack draining should prefer to make work available to other threads
>    
>    Reviewed-by: sjohanss, ayang
>  - 8280414: Memory leak in DefaultProxySelector
>    
>    Reviewed-by: dfuchs
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/a19176e6...44478392

There is some major weirdness in this PR: it includes a lot of unrelated changes. Consider rebasing to current master and force-pushing?

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

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


From stuefe at openjdk.java.net  Wed Jan 26 08:36:44 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 26 Jan 2022 08:36:44 GMT
Subject: RFR: JDK-8280583: Always build NMT [v3]
In-Reply-To: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
Message-ID: <BMj866n8IshnKOMfq_e0zpKqRcG56VKMKWmFbO5Cd1c=.f99d82dd-f166-4626-a019-b3005bf42c9a@github.com>

> After discussing this on hotspot-runtime-dev [1], the general opinion seems to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT unconditional. This affects minimal builds only. As pointed out in the mail thread, the overhead is very small and it would get rid of one configuration to build and test.
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html
> 
> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well as the associated build option.

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - fix copyrights
 - remove INCLUDE_NMT and dependend code

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

Changes: https://git.openjdk.java.net/jdk/pull/7213/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7213&range=02
  Stats: 243 lines in 28 files changed: 10 ins; 192 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7213.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7213/head:pull/7213

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


From stuefe at openjdk.java.net  Wed Jan 26 08:36:44 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 26 Jan 2022 08:36:44 GMT
Subject: RFR: JDK-8280583: Always build NMT [v2]
In-Reply-To: <bcpu4IAFIZJI9z2KqXDEVJt72efQz2nn1PSl0Hs5FvA=.572e1cf9-421c-4e8d-a60e-8ee38c62eea1@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
 <PXqQz6EY9p1Co7K6rbc87bJ7ikmbqXKP_Tlg_VBzsQI=.ba3742e8-6691-4d08-836f-b5f7095acae0@github.com>
 <bcpu4IAFIZJI9z2KqXDEVJt72efQz2nn1PSl0Hs5FvA=.572e1cf9-421c-4e8d-a60e-8ee38c62eea1@github.com>
Message-ID: <4nRn_jOASRPVRKX-Up0w8psR5-Ar4OWvOBcLWTi_p_k=.1ad61ef7-6628-4995-b891-2636efffac5b@github.com>

On Wed, 26 Jan 2022 08:26:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is some major weirdness in this PR: it includes a lot of unrelated changes. Consider rebasing to current master and force-pushing?

Done.

I wondered about that, I did merge master - normally, this shows up as a single merge change. Not sure what happened.

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

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


From shade at openjdk.java.net  Wed Jan 26 08:45:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 26 Jan 2022 08:45:33 GMT
Subject: RFR: JDK-8280583: Always build NMT [v3]
In-Reply-To: <BMj866n8IshnKOMfq_e0zpKqRcG56VKMKWmFbO5Cd1c=.f99d82dd-f166-4626-a019-b3005bf42c9a@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
 <BMj866n8IshnKOMfq_e0zpKqRcG56VKMKWmFbO5Cd1c=.f99d82dd-f166-4626-a019-b3005bf42c9a@github.com>
Message-ID: <V1Fp9ZJuYQn4Q8oYAtWcHCjm3QPTaKfTIcqM1HOxOY0=.ab91b27d-44a5-453e-9516-0cee56752b6b@github.com>

On Wed, 26 Jan 2022 08:36:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> After discussing this on hotspot-runtime-dev [1], the general opinion seems to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT unconditional. This affects minimal builds only. As pointed out in the mail thread, the overhead is very small and it would get rid of one configuration to build and test.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html
>> 
>> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well as the associated build option.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - fix copyrights
>  - remove INCLUDE_NMT and dependend code

This looks fine to me.

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

Marked as reviewed by shade (Reviewer).

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


From alanb at openjdk.java.net  Wed Jan 26 09:02:34 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 26 Jan 2022 09:02:34 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
Message-ID: <JJorpjnerpX7FPyKt3f9vptI_-_SOqFfxxeBitPlAA4=.139f6463-d7e5-4c00-b3e4-159332474040@github.com>

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review,
>   When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result.
>   The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle.
> 
>   Tests: tier1,4,7 in test
>    Manually tested user case, and checked output of jimage list <modules> for jlinked files using --compress=2.
> 
> Thanks
> Yumin

I think this looks okay but I think @JimLaskey and/or @sundararajana should look at this because it creates a dependency on a JVM_* function. I'm trying to think if there are any interop issues when using jrtfs. Jim/Sundar can correct me but I think we are okay there because a tool on say JDK 8 (or 11 or 17) that accesses a JDK 19 run-time image will use the BasicImageReader and won't use libjimage in the target VM.

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

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


From stuefe at openjdk.java.net  Wed Jan 26 09:27:33 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 26 Jan 2022 09:27:33 GMT
Subject: RFR: JDK-8280583: Always build NMT [v3]
In-Reply-To: <V1Fp9ZJuYQn4Q8oYAtWcHCjm3QPTaKfTIcqM1HOxOY0=.ab91b27d-44a5-453e-9516-0cee56752b6b@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
 <BMj866n8IshnKOMfq_e0zpKqRcG56VKMKWmFbO5Cd1c=.f99d82dd-f166-4626-a019-b3005bf42c9a@github.com>
 <V1Fp9ZJuYQn4Q8oYAtWcHCjm3QPTaKfTIcqM1HOxOY0=.ab91b27d-44a5-453e-9516-0cee56752b6b@github.com>
Message-ID: <yniZqOTkF_6MPvNElLKGrI9ZFfKt9kl2HqCfarOEubI=.a737b13d-5dd8-40dd-815b-faed3379522c@github.com>

On Wed, 26 Jan 2022 08:42:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This looks fine to me.

Thanks, Aleksey!

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

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


From ihse at openjdk.java.net  Wed Jan 26 10:40:29 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 26 Jan 2022 10:40:29 GMT
Subject: RFR: JDK-8280583: Always build NMT [v3]
In-Reply-To: <BMj866n8IshnKOMfq_e0zpKqRcG56VKMKWmFbO5Cd1c=.f99d82dd-f166-4626-a019-b3005bf42c9a@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
 <BMj866n8IshnKOMfq_e0zpKqRcG56VKMKWmFbO5Cd1c=.f99d82dd-f166-4626-a019-b3005bf42c9a@github.com>
Message-ID: <BZJbW7gaR5Pe-piTKlV8dKpDVio5SO5xkteqMBT0SQk=.c2e44a5d-c8cc-41a3-b376-ed6083469a12@github.com>

On Wed, 26 Jan 2022 08:36:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> After discussing this on hotspot-runtime-dev [1], the general opinion seems to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT unconditional. This affects minimal builds only. As pointed out in the mail thread, the overhead is very small and it would get rid of one configuration to build and test.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html
>> 
>> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well as the associated build option.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - fix copyrights
>  - remove INCLUDE_NMT and dependend code

Build changes look fine. Good riddance!

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

Marked as reviewed by ihse (Reviewer).

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


From zgu at openjdk.java.net  Wed Jan 26 13:27:31 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 26 Jan 2022 13:27:31 GMT
Subject: RFR: JDK-8280583: Always build NMT [v3]
In-Reply-To: <BMj866n8IshnKOMfq_e0zpKqRcG56VKMKWmFbO5Cd1c=.f99d82dd-f166-4626-a019-b3005bf42c9a@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
 <BMj866n8IshnKOMfq_e0zpKqRcG56VKMKWmFbO5Cd1c=.f99d82dd-f166-4626-a019-b3005bf42c9a@github.com>
Message-ID: <Ls85VZy55DUKZy_kJi1b0exL4nr7FmZ67biNlYrPiK8=.37037a49-9a30-4196-b698-81ca456711cd@github.com>

On Wed, 26 Jan 2022 08:36:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> After discussing this on hotspot-runtime-dev [1], the general opinion seems to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT unconditional. This affects minimal builds only. As pointed out in the mail thread, the overhead is very small and it would get rid of one configuration to build and test.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html
>> 
>> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well as the associated build option.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - fix copyrights
>  - remove INCLUDE_NMT and dependend code

Good to me.

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

Marked as reviewed by zgu (Reviewer).

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


From erikj at openjdk.java.net  Wed Jan 26 13:29:30 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 26 Jan 2022 13:29:30 GMT
Subject: RFR: JDK-8279636: Update JCov version to 3.0.12
In-Reply-To: <tvxij3jCBx6sVE2IHoljvEhBMbsvYD1I6-ychKn0CO4=.c06f0c03-2d7e-4b66-91d2-3855b0ade709@github.com>
References: <tvxij3jCBx6sVE2IHoljvEhBMbsvYD1I6-ychKn0CO4=.c06f0c03-2d7e-4b66-91d2-3855b0ade709@github.com>
Message-ID: <__K3_iAPtVjxoUukEzTOwLxICovSlHo0BPnEefVxUwg=.4be4e301-5776-4dae-a4d4-0a52573cc4d7@github.com>

On Wed, 26 Jan 2022 00:08:36 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> JDK-8279636: Update JCov version to 3.0.12

Marked as reviewed by erikj (Reviewer).

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

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


From zgu at openjdk.java.net  Wed Jan 26 14:12:35 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 26 Jan 2022 14:12:35 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
Message-ID: <fNezD8VTlYQQBJd-CTJyWK3KQ0Al1nFbsT96VfWg3TY=.eeb67d17-321a-45ce-a627-088e0ec582ca@github.com>

On Tue, 25 Jan 2022 15:10:11 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
>> 
>> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
>> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
>> 
>> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
>> 
>> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
>> 
>> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
>> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
>> 
>> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
>> 
>> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
>> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
>> 
>> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
>> 
>> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
>> 
>> **Testing:**
>> Apart from manual testing, I've added two kinds of tests:
>> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
>> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
>> 
>> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
>> 
>> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
>> 
>> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
>> 
>> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>>  
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Personally, I am in favor of this project. Actually, I were experimenting it with libdwarf.

I would like to add some historical background on this topic, just for consideration.

We had a dwarf parser over a decade ago, a little after elf parser, but never made to mainline. There were several reasons at the time. Good news, some are no longer applied today :-)

- At the time, Solaris still used STABS format, we could not get support from Solaris compiler team.
- If one platform does not support a feature, no one can have it. That's why we could have it on Windows from day one, but did not enable it until much later.
- Different compiler (and different version of the same compiler) can generate DWARF with different version, may not be compatible with each other, as DWARF allows custom fields.
- Maintenance cost to catch up DWARF spec/compiler changes.

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

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


From erikj at openjdk.java.net  Wed Jan 26 14:26:40 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 26 Jan 2022 14:26:40 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
Message-ID: <9kJSXjQdxkkNKDyFOZ3FiHkSda_BVgW632KkKyz3k14=.024fac33-1147-4d22-bdb8-91cefc913e25@github.com>

On Tue, 25 Jan 2022 15:10:11 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
>> 
>> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
>> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
>> 
>> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
>> 
>> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
>> 
>> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
>> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
>> 
>> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
>> 
>> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
>> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
>> 
>> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
>> 
>> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
>> 
>> **Testing:**
>> Apart from manual testing, I've added two kinds of tests:
>> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
>> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
>> 
>> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
>> 
>> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
>> 
>> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
>> 
>> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>>  
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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


From shurailine at openjdk.java.net  Wed Jan 26 18:07:42 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Wed, 26 Jan 2022 18:07:42 GMT
Subject: Integrated: JDK-8279636: Update JCov version to 3.0.12
In-Reply-To: <tvxij3jCBx6sVE2IHoljvEhBMbsvYD1I6-ychKn0CO4=.c06f0c03-2d7e-4b66-91d2-3855b0ade709@github.com>
References: <tvxij3jCBx6sVE2IHoljvEhBMbsvYD1I6-ychKn0CO4=.c06f0c03-2d7e-4b66-91d2-3855b0ade709@github.com>
Message-ID: <2xADiGxeKry09J3m3eBq4bEucQ4zwWdFaUBhRcqby-I=.c9008713-9e18-4f85-8b0b-c2acec43d49f@github.com>

On Wed, 26 Jan 2022 00:08:36 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> JDK-8279636: Update JCov version to 3.0.12

This pull request has now been integrated.

Changeset: d2a50a64
Author:    Alexandre Iline <shurailine at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d2a50a64920d22bbbd19ac7fa8681ff177799faf
Stats:     8 lines in 1 file changed: 0 ins; 7 del; 1 mod

8279636: Update JCov version to 3.0.12

Reviewed-by: alanb, erikj

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

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


From minqi at openjdk.java.net  Wed Jan 26 18:13:35 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 26 Jan 2022 18:13:35 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
Message-ID: <XG_UdtCSiIDxhH7UtrlRroOQ8rDaebJBO9O-LN7OGcg=.cfa86a0b-a156-4ccf-b9f3-770a17350685@github.com>

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review,
>   When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result.
>   The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle.
> 
>   Tests: tier1,4,7 in test
>    Manually tested user case, and checked output of jimage list <modules> for jlinked files using --compress=2.
> 
> Thanks
> Yumin

Update: tier1,tier4 passed tier7 failed on: test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java That is not related to the change since it is not using zip.

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

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


From dcubed at openjdk.java.net  Wed Jan 26 20:53:29 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 26 Jan 2022 20:53:29 GMT
Subject: RFR: 8278753: Runtime crashes with access violation during
 JNI_CreateJavaVM call
In-Reply-To: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
References: <VDKQApKfLuLb84ncVs16N5X8qPv6D3zksRpL7S755p4=.776bb459-8f11-4994-97f5-c0240cf22828@github.com>
Message-ID: <hRMG_1PxmDJESLyuv9879znyL2aj0mg0VMpdpxYhy3s=.565be390-4d67-4ab2-91cb-5660a69924c8@github.com>

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review,
>   When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result.
>   The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle.
> 
>   Tests: tier1,4,7 in test
>    Manually tested user case, and checked output of jimage list <modules> for jlinked files using --compress=2.
> 
> Thanks
> Yumin

Your Tier7 failure is likely this known bug:

    JDK-8280601 ClhsdbThreadContext.java test is triggering codecache related assert in PointerFinder.find()
    https://bugs.openjdk.java.net/browse/JDK-8280601

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

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


From duke at openjdk.java.net  Thu Jan 27 00:19:43 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 27 Jan 2022 00:19:43 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
 <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
Message-ID: <yGkuqDYXrzuHj3UGghVaRf_SfMpv4D9Zy67Y3P9L1rY=.40414e84-7a55-4f3d-947c-2774d5dfb38f@github.com>

On Tue, 25 Jan 2022 06:10:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8203290
>>  - Implements JFR on AIX
>>    
>>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>>    by TestNativeLibraies.java)
>>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>>    all platforms)
>>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux
>
> src/hotspot/os/aix/libperfstat_aix.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Is there a reason for this copyright addition?

Yes there is, but it might not be a correct one as David's and your comments seem to indicate ? 

The thought was that as a member of a company that has signed the OCA, work I do falls under Oracle's copyright. So any files I modify ought to have their copyright years updated. When there wasn't an Oracle copyright line, I added one (this may have been the problematic choice). Any guidance on how to do this properly is appreciated.

> src/hotspot/os/aix/loadlib_aix.hpp line 79:
> 
>> 77:   private:
>> 78:     const loaded_module_t _module;
>> 79:     const LoadedModuleList* _next;
> 
> While looking at this code, I realized how old it is (the copyright is wrong, this predates OpenJDK and was written ~2005). Today I would do some things differently, e.g. use a hash table for string interning.
> 
> About your change: `LoadedModuleList` is basically a duplication of the `entry_t`+`loaded_module_t` tupel. While I am not against it, it's duplication and a bit much boilerplate. You should at least redo the recursive deletion scheme. That will blow up if no tail call optimization happens.
> 
> I assume the whole copy list business is due to concurrent reloading? And because LoadedLibs does not offer an iteration interface?
> 
> If you feel up to it, I would simplify this:
> - merge `entry_t` and `loaded_module_t` into one structure: give `loaded_module_t` a `next` pointer and get rid of entry_t. This is a scheme we use all over the hotspot (embedding list pointers directly into the payload structures) so it is fine and we save one indirection
> - in LoadedLibs implementation, remove entry_t and use loaded_module_t directly
> - in your new copy_libs, build up a list of copied loaded_module_t structures under lock protection like you do now with LoadedModuleList
> - Do deletion in a loop, not recursively, with something like a new `static LoadedLibs::delete_list(loaded_module_t* list);`
> 
> Alternative: give LoadedLibs a callback-like functionality where you iterate the original list under lock protection and just call the given callback or closure class. In that closure, you call the original perfstat callback, so no need to pollute LoadedLibs with perfstat symbols.
> 
> Just as an info, in these files we tried to avoid JVM infrastructure, hence the plain `::malloc` instead of `os::malloc`  and we use none of the helper classes the JVM offers. E.g. instead of just using `GrowableHeapArray`, which would be nice and convenient. That is because using JVM infrastructure introduces dependencies to VM state and time (e.g. there are uninitialized time windows at startup), and we wanted this code to work as reliably as possible. Also should work during signal handling. Because the VM may crash at any point, and at any point we want to see call stacks and list of loaded libraries in the hs-err file.

Thank you for the in-depth review. I appreciate the feedback. I am working on this re-factor.

> src/hotspot/os/aix/os_perf_aix.cpp line 33:
> 
>> 31: #include "runtime/os_perf.hpp"
>> 32: #include "runtime/vm_version.hpp"
>> 33: #include "utilities/globalDefinitions.hpp"
> 
> include debug.hpp too (you use assert)

Thanks! I was wondering why my asserts were silently failing. I thought I might need to enable asserts somewhere.

> src/hotspot/os/aix/os_perf_aix.cpp line 48:
> 
>> 46: #include <sys/types.h>
>> 47: #include <stdlib.h>
>> 48: #include <unistd.h>
> 
> nice reordering

?

> src/hotspot/os/aix/os_perf_aix.cpp line 94:
> 
>> 92:   int len;
>> 93: 
>> 94:   memset(buf, 0, BUF_LENGTH);
> 
> memset is not needed

Agreed. This will be removed.

> src/hotspot/os/aix/os_perf_aix.cpp line 95:
> 
>> 93: 
>> 94:   memset(buf, 0, BUF_LENGTH);
>> 95:   snprintf(buf, BUF_LENGTH, "/proc/%llu/psinfo", pid);
> 
> Use jio_snprintf instead, it handles a number of special cases (e.g. truncation) more correctly. Needs, I believe, jvm_io.h.

Thanks for clarifying. I've made this change.

> src/hotspot/os/aix/os_perf_aix.cpp line 102:
> 
>> 100:   }
>> 101: 
>> 102:   len = fread(&psinfo, sizeof(char), sizeof(psinfo_t), fp);
> 
> bikeshedding: I think its safe to say that sizeof(char) will always be 1, so I guess you can shorten it to 1 :)

Fair point. I initially felt that this would be more clear, but I don't feel that way reading it now. I've made this change too.

> src/hotspot/os/aix/os_perf_aix.cpp line 121:
> 
>> 119:     pticks->sys  = 0;
>> 120:     pticks->idle = 0;
>> 121:     pticks->wait = 0;
> 
> bikeshed: memset to 0 instead of setting each member individually?

Agreed!

> src/hotspot/os/aix/os_perf_aix.cpp line 146:
> 
>> 144:   assert(initialize_libperfstat(), "perfstat lib not available");
>> 145: 
>> 146:   snprintf(name_holder.name, IDENTIFIER_LENGTH, "%d", getpid());
> 
> jio_snprintf

Done.

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

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


From david.holmes at oracle.com  Thu Jan 27 07:33:41 2022
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 27 Jan 2022 17:33:41 +1000
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <yGkuqDYXrzuHj3UGghVaRf_SfMpv4D9Zy67Y3P9L1rY=.40414e84-7a55-4f3d-947c-2774d5dfb38f@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
 <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
 <yGkuqDYXrzuHj3UGghVaRf_SfMpv4D9Zy67Y3P9L1rY=.40414e84-7a55-4f3d-947c-2774d5dfb38f@github.com>
Message-ID: <95c1a364-cf91-27e3-298b-a45a023ea1be@oracle.com>

On 27/01/2022 10:19 am, Tyler Steele wrote:
> On Tue, 25 Jan 2022 06:10:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
>>> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>>>
>>>   - Merge branch 'master' into JDK-8203290
>>>   - Implements JFR on AIX
>>>     
>>>     - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>>>     - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>>>     - Implements missing functionality in loadlib_aix (Fixes failure noted
>>>     by TestNativeLibraies.java)
>>>     - Removes platform checks for --enable-feature-jfr (Now enable-able on
>>>     all platforms)
>>>     - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>>>     - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux
>>
>> src/hotspot/os/aix/libperfstat_aix.cpp line 2:
>>
>>> 1: /*
>>> 2:  * Copyright (c) 2022, 2022, Oracle and/or its affiliates. All rights reserved.
>>
>> Is there a reason for this copyright addition?
> 
> Yes there is, but it might not be a correct one as David's and your comments seem to indicate ?
> 
> The thought was that as a member of a company that has signed the OCA, work I do falls under Oracle's copyright. So any files I modify ought to have their copyright years updated. When there wasn't an Oracle copyright line, I added one (this may have been the problematic choice). Any guidance on how to do this properly is appreciated.

IANAL but a basic rule I epouse is to never touch anyone else's 
copyright line. If a file with a non-Oracle copyright is updated 
significantly by anyone they can add their own copyright line 
appropriate to their situation. But AFAIK only Oracle employees should 
add Oracle copyright lines.

Cheers,
David
-----



From chagedorn at openjdk.java.net  Thu Jan 27 08:41:34 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 27 Jan 2022 08:41:34 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <hMEnmFTEcxGWfUHlpY6m7RRzGhSgJX1X5d-ZX-dUB5I=.e8e2e3ca-bf6b-4ae4-b78e-a0878466aeb5@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <JcbJ0IRt-ar1wG0GPYXMkXLRjc5njAoh8E70GFVJJUM=.72acfaf8-1627-4199-8e0e-6adc35826191@github.com>
 <hMEnmFTEcxGWfUHlpY6m7RRzGhSgJX1X5d-ZX-dUB5I=.e8e2e3ca-bf6b-4ae4-b78e-a0878466aeb5@github.com>
Message-ID: <54FxD8Y6tYN9qIxG9kM1609F8U5qX1L2q5k36XCYnzs=.776977b4-80f0-41f9-99d3-6829f8e1d067@github.com>

On Tue, 25 Jan 2022 15:06:41 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Build changes look good.

Thanks Erik!


> Personally, I am in favor of this project. Actually, I were experimenting it with libdwarf.
> 
> I would like to add some historical background on this topic, just for consideration.

Thanks Zhengyu for sharing some background!

> We had a dwarf parser over a decade ago, a little after elf parser, but never made to mainline. There were several reasons at the time. Good news, some are no longer applied today :-)

That's interesting. Is this implementation still around somewhere? I'm glad that some of the mentioned things are not a problem anymore.

> * Different compiler (and different version of the same compiler) can generate DWARF with different version, may not be compatible with each other, as DWARF allows custom fields.
> * Maintenance cost to catch up DWARF spec/compiler changes.

That's indeed a problem of facing different DWARF versions. For this parser, I tried to support the current default of GCC 10.x which is DWARF 4. This standard was introduced in 2010 and is probably used by most compilers nowadays at least (if not already DWARF 5 which was introduced in 2017). However, even with GCC 10.x, it emitted DWARF 3 for one of the sections (I'm not sure why) which I also needed to support - thus you can never be sure. 

DWARF 5 is still experimental for GCC 10.x and had some issues when I tried that out back there - so I stayed away from implementing parsing steps for it. But now with GCC 11.x, DWARF 5 seems to have become the default. I might have to try out what's being emitted for HotSpot. But I think for now, it is better to only focus on DWARF 4 instead of trying to support various versions in one patch - we could still come back to that later if it becomes widely used. Even if DWARF 5 is emitted, GCC could be configured, for example, to emit DWARF 4 only which is probably an acceptable workaround for testing environments.

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

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


From duke at openjdk.java.net  Thu Jan 27 08:59:44 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Thu, 27 Jan 2022 08:59:44 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) (Update building.md and building.html to reflect change)
Message-ID: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>

Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSys 2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.

I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.

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

Commit messages:
 - Update documentation to mention MSys 2 support

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

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


From stuefe at openjdk.java.net  Thu Jan 27 09:21:38 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 27 Jan 2022 09:21:38 GMT
Subject: RFR: JDK-8280583: Always build NMT [v2]
In-Reply-To: <bcpu4IAFIZJI9z2KqXDEVJt72efQz2nn1PSl0Hs5FvA=.572e1cf9-421c-4e8d-a60e-8ee38c62eea1@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
 <PXqQz6EY9p1Co7K6rbc87bJ7ikmbqXKP_Tlg_VBzsQI=.ba3742e8-6691-4d08-836f-b5f7095acae0@github.com>
 <bcpu4IAFIZJI9z2KqXDEVJt72efQz2nn1PSl0Hs5FvA=.572e1cf9-421c-4e8d-a60e-8ee38c62eea1@github.com>
Message-ID: <MQ_IPjV1o0w6x6RgzJYKETK3Lk7BX9beLMt_NzTbwHE=.29c5ce53-1bdc-4bbf-b5c1-8ce7e895835d@github.com>

On Wed, 26 Jan 2022 08:26:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with 15 additional commits since the last revision:
>> 
>>  - 8280377: MethodHandleProxies does not correctly invoke default methods with varags
>>    
>>    Reviewed-by: alanb
>>  - 8213905: reflection not working for type annotations applied to exception types in the inner class constructor
>>    
>>    Reviewed-by: jlahoda
>>  - 8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement
>>    
>>    Reviewed-by: iris, dholmes, mchung
>>  - 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987
>>    8258071: Fix for JDK-8255987 can be subverted with ObjectReference.EnableCollection
>>    
>>    Reviewed-by: dholmes, pliden
>>  - 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases
>>    
>>    Reviewed-by: sspitsyn, lmesnik
>>  - 8280041: Retry loop issues in java.io.ClassCache
>>    
>>    Co-authored-by: Peter Levart <plevart at openjdk.org>
>>    Reviewed-by: rkennke, rriggs, plevart
>>  - 8280168: Add Objects.toIdentityString
>>    
>>    Reviewed-by: alanb, mchung, rriggs, smarks
>>  - 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException
>>    
>>    Reviewed-by: alanb
>>  - 8280396: G1: Full gc mark stack draining should prefer to make work available to other threads
>>    
>>    Reviewed-by: sjohanss, ayang
>>  - 8280414: Memory leak in DefaultProxySelector
>>    
>>    Reviewed-by: dfuchs
>>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/a19176e6...44478392
>
> There is some major weirdness in this PR: it includes a lot of unrelated changes. Consider rebasing to current master and force-pushing?

Thanks @shipilev, @magicus and @zhengyu123 !

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

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


From stuefe at openjdk.java.net  Thu Jan 27 09:21:39 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 27 Jan 2022 09:21:39 GMT
Subject: Integrated: JDK-8280583: Always build NMT
In-Reply-To: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
References: <_RJK80WSxCYhWSqjjoQYbVPr2_uEnlNqp_UdwniQp4c=.d3b51bfa-ffe7-4a72-97fe-64dbb25e1f5a@github.com>
Message-ID: <pm1j0OIwnd009rMsNuiWaeS_GivSqptwT6VEBtvJ460=.43aa6d94-0e15-4fd3-9577-ffc40e4784db@github.com>

On Tue, 25 Jan 2022 10:57:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> After discussing this on hotspot-runtime-dev [1], the general opinion seems to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT unconditional. This affects minimal builds only. As pointed out in the mail thread, the overhead is very small and it would get rid of one configuration to build and test.
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html
> 
> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well as the associated build option.

This pull request has now been integrated.

Changeset: cab59051
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cab590517bf705418c7376edd5d7066b13b6dde8
Stats:     243 lines in 28 files changed: 10 ins; 192 del; 41 mod

8280583: Always build NMT

Reviewed-by: shade, ihse, zgu

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

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


From stuefe at openjdk.java.net  Thu Jan 27 09:29:30 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 27 Jan 2022 09:29:30 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
Message-ID: <EaLNOk7R9f2_uOU_KlxsY2xWFOBEF7DIGoDpaOz3UME=.cb619410-e9aa-4a4e-b245-1c87eebe104e@github.com>

On Tue, 25 Jan 2022 15:10:11 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
>> 
>> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
>> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
>> 
>> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
>> 
>> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
>> 
>> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
>> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
>> 
>> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
>> 
>> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
>> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
>> 
>> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
>> 
>> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
>> 
>> **Testing:**
>> Apart from manual testing, I've added two kinds of tests:
>> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
>> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
>> 
>> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
>> 
>> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
>> 
>> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
>> 
>> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>>  
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Hi Christian, this is very nice and useful!

Two general remarks. One concern I have is that the new functionality should be super stable, since nothing is more annoying than to crash during stack dumping in hs-err file; I much rather have a call stack without bells and whistles than an abridged one. Maybe we could, in hs-err printing, if we got secondary crashes during callstack dumping, repeat the step with all optional features (also name demangling) disabled? This could also be done in a separate RFE. We'll know when this happens, we can react then.

Another small concern, we parse the Elf file while dumping the stack, right? I remember having a lot of problems on Solaris when dumping callstacks, because there parsing the elf file was really slow. And that delayed call stack printing by a lot, so much that the ErrorCrashTimeout often kicked in and spoiled the crash logs for us.

Cheers, Thomas

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

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


From stuefe at openjdk.java.net  Thu Jan 27 10:47:40 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 27 Jan 2022 10:47:40 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <yGkuqDYXrzuHj3UGghVaRf_SfMpv4D9Zy67Y3P9L1rY=.40414e84-7a55-4f3d-947c-2774d5dfb38f@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
 <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
 <yGkuqDYXrzuHj3UGghVaRf_SfMpv4D9Zy67Y3P9L1rY=.40414e84-7a55-4f3d-947c-2774d5dfb38f@github.com>
Message-ID: <w1TXdcanGJ4Ap0PfFWKskqmPaXWbH0LmWBcXXvGc0D4=.ea21d5b7-4df3-4858-8536-48348058415a@github.com>

On Thu, 27 Jan 2022 00:17:17 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> src/hotspot/os/aix/os_perf_aix.cpp line 33:
>> 
>>> 31: #include "runtime/os_perf.hpp"
>>> 32: #include "runtime/vm_version.hpp"
>>> 33: #include "utilities/globalDefinitions.hpp"
>> 
>> include debug.hpp too (you use assert)
>
> Thanks! I was wondering why my asserts were silently failing. I thought I might need to enable asserts somewhere.

No, silently failing asserts shouldn't happen. That's weird. You should either get a compile time error or all should work. If it works, debug.hpp gets pulled via some other include somewhere, or because you use precompiled headers.

I only did ask you to explicitly include it since it's our policy: you always include all headers which you need in your compilation unit, directly, without relying on other includes pulling them. People often forget though, and as you saw, forgetting is usually benign. There are also exceptions (e.g. system headers usually are pulled via globalDefinitions.hpp). Wish we had this written down somewhere :-/

The reason we do this is that it makes the build more robust. If everyone includes what he needs, chances that some innocuous change in an include breaks the build for faraway code.

Note that it is a good practice to build - at least once, before pushing - with precompiled headers off. `--disable-precompiled-headers` configure option. I set this always, but I build on Linux, where builds are fast. Maybe AIX is too slow to always enable it.

Cheers, Thomas

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

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


From goetz at openjdk.java.net  Thu Jan 27 11:01:42 2022
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Thu, 27 Jan 2022 11:01:42 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
Message-ID: <rbFZfXueaKYr4rQfYI1gsIr0bLMuRMeMbI5JIR1pu3M=.b807090c-693f-4188-995b-dbd65ac2f7aa@github.com>

On Mon, 24 Jan 2022 22:23:33 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Hi, 
IANALE :)
> basic rule I epouse is to never touch anyone else's copyright line

On first sight, this makes sense. But it is not the reality.
All external contributors are asked to update the copyright year in the 
Oracle Copyright line if they contribute a fix. 
Also, when we did the port, we added the Oracle line to many new
files because they were derived from files with Oracle copyright.
But the files in question here are special, they are some of the few 
that were completely developed by us, i.e., by Thomas.

I think Tyler should not update the SAP Copyright, because
we do not have any rights on the code he implements. 
I agree with Tyler that as he signed the OCA Oracle has
the Copyright on the code once he opens a PR with the patch.
So adding an Oracle line can not be wrong. Alternatively, he
also could add his own Copyright line.

Isn't there any documentation about this? All I found is this:
http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html
I'll ping Iris and Jesper, maybe they can shed light on this.

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

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


From zgu at openjdk.java.net  Thu Jan 27 13:46:29 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 27 Jan 2022 13:46:29 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <54FxD8Y6tYN9qIxG9kM1609F8U5qX1L2q5k36XCYnzs=.776977b4-80f0-41f9-99d3-6829f8e1d067@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <JcbJ0IRt-ar1wG0GPYXMkXLRjc5njAoh8E70GFVJJUM=.72acfaf8-1627-4199-8e0e-6adc35826191@github.com>
 <hMEnmFTEcxGWfUHlpY6m7RRzGhSgJX1X5d-ZX-dUB5I=.e8e2e3ca-bf6b-4ae4-b78e-a0878466aeb5@github.com>
 <54FxD8Y6tYN9qIxG9kM1609F8U5qX1L2q5k36XCYnzs=.776977b4-80f0-41f9-99d3-6829f8e1d067@github.com>
Message-ID: <OUsrKSumxqskvlyhndWvQyrp9e2HiiEIYKOX1rSXJPo=.e957df7c-07a9-4fa5-b97c-fc2e7d2b1655@github.com>

On Thu, 27 Jan 2022 08:38:02 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> > Build changes look good.
> 
> Thanks Erik!
> 
> > Personally, I am in favor of this project. Actually, I were experimenting it with libdwarf.
> > I would like to add some historical background on this topic, just for consideration.
> 
> Thanks Zhengyu for sharing some background!
> 
> > We had a dwarf parser over a decade ago, a little after elf parser, but never made to mainline. There were several reasons at the time. Good news, some are no longer applied today :-)
> 
> That's interesting. Is this implementation still around somewhere? I'm glad that some of the mentioned things are not a problem anymore.
> 
Not I know. IIRC, it was based on DWARF 2.

> > * Different compiler (and different version of the same compiler) can generate DWARF with different version, may not be compatible with each other, as DWARF allows custom fields.
> > * Maintenance cost to catch up DWARF spec/compiler changes.
> 
> That's indeed a problem of facing different DWARF versions. For this parser, I tried to support the current default of GCC 10.x which is DWARF 4. This standard was introduced in 2010 and is probably used by most compilers nowadays at least (if not already DWARF 5 which was introduced in 2017). However, even with GCC 10.x, it emitted DWARF 3 for one of the sections (I'm not sure why) which I also needed to support - thus you can never be sure.
> 
> DWARF 5 is still experimental for GCC 10.x and had some issues when I tried that out back there - so I stayed away from implementing parsing steps for it. But now with GCC 11.x, DWARF 5 seems to have become the default. I might have to try out what's being emitted for HotSpot. But I think for now, it is better to only focus on DWARF 4 instead of trying to support various versions in one patch - we could still come back to that later if it becomes widely used. Even if DWARF 5 is emitted, GCC could be configured, for example, to emit DWARF 4 only which is probably an acceptable workaround for testing environments.

I think maintenance and test could be major pain points. Based on build.html, we can use gcc version anywhere between 5.0 and 10.2, it could be a challenge to ensure all supported version work correctly.

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

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


From erikj at openjdk.java.net  Thu Jan 27 14:40:30 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 27 Jan 2022 14:40:30 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) (Update building.md and building.html to reflect change)
In-Reply-To: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
Message-ID: <kML31_nAANPIyNVUxrU8RFoF1nqiBQKOMylR19CMA88=.032f705c-711e-496d-b273-766866fd7135@github.com>

On Thu, 27 Jan 2022 08:49:08 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSys 2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
> 
> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.

The updated wording seems fine to me.

The html file should not be edited by hand, but generated (by pandoc) using the make target `update-build-docs`. If you don't have access to pandoc, I can help you regenerate the file.

It looks like you are trying to reuse an existing and already resolved BugID for this change. That is not possible. A new bug must be filed for each change in OpenJDK.

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

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


From ihse at openjdk.java.net  Thu Jan 27 14:53:34 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 27 Jan 2022 14:53:34 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) (Update building.md and building.html to reflect change)
In-Reply-To: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
Message-ID: <Kv2FeSOYJ7ROTjyOp_hJoNi31PlZcCmFEy-eJuSsNM8=.2b74af64-79c6-449c-b041-230ab40b362f@github.com>

On Thu, 27 Jan 2022 08:49:08 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSys 2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
> 
> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.

@TheShermanTanker Some comments in no particular order.

* The MSYS2 project calls themselves "MSYS2"; I think it'd be proper to reflect this capitalization/lack of space before the 2. 

* This PR has technical problems. You are trying to reuse the old JBS bug issue. You'll need a new bug entry for the problem you are trying to solve here. If you do not have access to the bug system, let me know and I can help you.

* I have actually a similar fix on a personal branch, where I'm updating several omissions in the build README. However, when I went to try building on an MSYS2 installation with the mainline head, it actually failed.. :-( Have you successfully built on MSYS2 with the mainline JDK?

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

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


From duke at openjdk.java.net  Thu Jan 27 15:30:40 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 27 Jan 2022 15:30:40 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
Message-ID: <RviNtyQyThaa-hbAteRg8nYk-MFZm1DafnvuREOZ7gk=.2a091ffc-e1ff-4082-8063-49f2ef3e6e2a@github.com>

On Mon, 24 Jan 2022 22:23:33 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Thanks Goetz, David, and Thomas for your comments on copyrights, and thanks to Goetz for reaching out to Iris. I'll keep an eye on the mailing list for their response and make changes accordingly.

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

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


From duke at openjdk.java.net  Thu Jan 27 16:46:39 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 27 Jan 2022 16:46:39 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
 <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
Message-ID: <6uLV6ZyA87-gRSMXTxRk0irfzlJbFT4Gn6oGbKesfrE=.1a752650-f90e-44cb-9843-810e750ef8b3@github.com>

On Tue, 25 Jan 2022 09:06:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8203290
>>  - Implements JFR on AIX
>>    
>>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>>    by TestNativeLibraies.java)
>>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>>    all platforms)
>>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux
>
> src/hotspot/os/aix/os_perf_aix.cpp line 214:
> 
>> 212:   // populate cpu_stats && check that the expected number of records have been populated
>> 213:   if (ncpus != libperfstat::perfstat_cpu(&name_holder, all_lcpu_stats, sizeof(perfstat_cpu_t), ncpus)) {
>> 214:     FREE_RESOURCE_ARRAY(perfstat_cpu_t, all_lcpu_stats, ncpus);
> 
> ResourceArray are stack-based arenas. No need to free them manually (freeing is often a noop anyway unless the allocation is a the top of the arena). Very similar to those AutoReleasePools in Objective-C, if you know that.
> 
> The way to use them is don't release them. If those allocations don't escape the function (so, you don't return RA memory from the function), you can set a ResourceMark at the start of the function. That is an RAII object which will clear all RA objects allocated in and under this function upon return.
> 
> Arguably, you also could just use malloc and free here (NEW_C_HEAP_ARRAY and FREE_C_HEAP_ARRAY)

This is interesting, and definitely good to know. I have removed all FREE_RESOURCE_ARRAY calls and added a ResourceMark to the top of all procedures which use RESOURCE_ARRAYs.

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

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


From duke at openjdk.java.net  Thu Jan 27 19:31:43 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 27 Jan 2022 19:31:43 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <yGkuqDYXrzuHj3UGghVaRf_SfMpv4D9Zy67Y3P9L1rY=.40414e84-7a55-4f3d-947c-2774d5dfb38f@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
 <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
 <yGkuqDYXrzuHj3UGghVaRf_SfMpv4D9Zy67Y3P9L1rY=.40414e84-7a55-4f3d-947c-2774d5dfb38f@github.com>
Message-ID: <4tUtLg5ffj-6TmRQUd7gm0lmZNTi2NB20fvV0Zz_6zM=.fcedb49c-f498-45bb-91a0-ad0d3e5878d9@github.com>

On Thu, 27 Jan 2022 00:15:52 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> src/hotspot/os/aix/loadlib_aix.hpp line 79:
>> 
>>> 77:   private:
>>> 78:     const loaded_module_t _module;
>>> 79:     const LoadedModuleList* _next;
>> 
>> While looking at this code, I realized how old it is (the copyright is wrong, this predates OpenJDK and was written ~2005). Today I would do some things differently, e.g. use a hash table for string interning.
>> 
>> About your change: `LoadedModuleList` is basically a duplication of the `entry_t`+`loaded_module_t` tupel. While I am not against it, it's duplication and a bit much boilerplate. You should at least redo the recursive deletion scheme. That will blow up if no tail call optimization happens.
>> 
>> I assume the whole copy list business is due to concurrent reloading? And because LoadedLibs does not offer an iteration interface?
>> 
>> If you feel up to it, I would simplify this:
>> - merge `entry_t` and `loaded_module_t` into one structure: give `loaded_module_t` a `next` pointer and get rid of entry_t. This is a scheme we use all over the hotspot (embedding list pointers directly into the payload structures) so it is fine and we save one indirection
>> - in LoadedLibs implementation, remove entry_t and use loaded_module_t directly
>> - in your new copy_libs, build up a list of copied loaded_module_t structures under lock protection like you do now with LoadedModuleList
>> - Do deletion in a loop, not recursively, with something like a new `static LoadedLibs::delete_list(loaded_module_t* list);`
>> 
>> Alternative: give LoadedLibs a callback-like functionality where you iterate the original list under lock protection and just call the given callback or closure class. In that closure, you call the original perfstat callback, so no need to pollute LoadedLibs with perfstat symbols.
>> 
>> Just as an info, in these files we tried to avoid JVM infrastructure, hence the plain `::malloc` instead of `os::malloc`  and we use none of the helper classes the JVM offers. E.g. instead of just using `GrowableHeapArray`, which would be nice and convenient. That is because using JVM infrastructure introduces dependencies to VM state and time (e.g. there are uninitialized time windows at startup), and we wanted this code to work as reliably as possible. Also should work during signal handling. Because the VM may crash at any point, and at any point we want to see call stacks and list of loaded libraries in the hs-err file.
>
> Thank you for the in-depth review. I appreciate the feedback. I am working on this re-factor.

I performed the refactor (removing entry_t, and adding a next pointer to loaded_module_t). This was pretty straightforward, but required writing an explicit copy procedure since the new struct loaded_module_t no longer met the requirements of the compiler-generated one.

> Alternative: give LoadedLibs a callback-like functionality where you iterate the original list under lock protection and just call the given callback or closure class. In that closure, you call the original perfstat callback, so no need to pollute LoadedLibs with perfstat symbols.

This is a good suggestion. I thought about doing it before, but I am used to tamping down my functional programming instincts when writing C. That said, this option required no additional memory allocation, so it removes any need for the class I wrote before. My implementation is a little brittle, as I chose to take os::LoadedModulesCallbackFunc, rather than a more general type (and having to construct a closure etc.). This should save on indirection for now, and could be extended in the future if needed.

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

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


From ysuenaga at openjdk.java.net  Fri Jan 28 02:29:10 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 28 Jan 2022 02:29:10 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
Message-ID: <GEVA_2Q-3ZD3egEW0VXBRlwsAE_T3zHKqDl7qTtlunI=.8390d269-afaf-4765-8989-a10b3feaac2e@github.com>

On Tue, 25 Jan 2022 15:10:11 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
>> 
>> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
>> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
>> 
>> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
>> 
>> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
>> 
>> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
>> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
>> 
>> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
>> 
>> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
>> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
>> 
>> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
>> 
>> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
>> 
>> **Testing:**
>> Apart from manual testing, I've added two kinds of tests:
>> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
>> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
>> 
>> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
>> 
>> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
>> 
>> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
>> 
>> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>>  
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

I think this feature is very useful, thanks Christian!

SA already has similar feature to gather call stacks with DWARF, so it would be nice to share DWARF parser between SA and HotSpot.

P.S. I've proposed to use elfutils to parse DWARF in SA in [JDK-8245234](https://bugs.openjdk.java.net/browse/JDK-8245234).

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

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


From david.holmes at oracle.com  Fri Jan 28 04:41:35 2022
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 28 Jan 2022 14:41:35 +1000
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <rbFZfXueaKYr4rQfYI1gsIr0bLMuRMeMbI5JIR1pu3M=.b807090c-693f-4188-995b-dbd65ac2f7aa@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
 <rbFZfXueaKYr4rQfYI1gsIr0bLMuRMeMbI5JIR1pu3M=.b807090c-693f-4188-995b-dbd65ac2f7aa@github.com>
Message-ID: <85ddce52-5660-c6ef-e69f-3c1002636f21@oracle.com>

On 27/01/2022 9:01 pm, Goetz Lindenmaier wrote:
> On Mon, 24 Jan 2022 22:23:33 GMT, Tyler Steele <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.
>>
>> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>>
>>   - Merge branch 'master' into JDK-8203290
>>   - Implements JFR on AIX
>>     
>>     - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>>     - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>>     - Implements missing functionality in loadlib_aix (Fixes failure noted
>>     by TestNativeLibraies.java)
>>     - Removes platform checks for --enable-feature-jfr (Now enable-able on
>>     all platforms)
>>     - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>>     - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux
> 
> Hi,
> IANALE :)
>> basic rule I epouse is to never touch anyone else's copyright line
> 
> On first sight, this makes sense. But it is not the reality.
> All external contributors are asked to update the copyright year in the
> Oracle Copyright line if they contribute a fix.

Yes, I should expand that statement with "unless requested to by a 
representative of that copyright holder". :)

> Also, when we did the port, we added the Oracle line to many new
> files because they were derived from files with Oracle copyright.

That makes sense too.

Cheers,
David
-----

> But the files in question here are special, they are some of the few
> that were completely developed by us, i.e., by Thomas.
> 
> I think Tyler should not update the SAP Copyright, because
> we do not have any rights on the code he implements.
> I agree with Tyler that as he signed the OCA Oracle has
> the Copyright on the code once he opens a PR with the patch.
> So adding an Oracle line can not be wrong. Alternatively, he
> also could add his own Copyright line.
> 
> Isn't there any documentation about this? All I found is this:
> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html
> I'll ping Iris and Jesper, maybe they can shed light on this.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6885


From stuefe at openjdk.java.net  Fri Jan 28 06:31:13 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 28 Jan 2022 06:31:13 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <4tUtLg5ffj-6TmRQUd7gm0lmZNTi2NB20fvV0Zz_6zM=.fcedb49c-f498-45bb-91a0-ad0d3e5878d9@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
 <hxK8u39PAo1zSmkOyHUkSrd6EhWENTcTQleB6RrSZZo=.bd7ab94e-ce54-4af4-899c-eaff99d837af@github.com>
 <yGkuqDYXrzuHj3UGghVaRf_SfMpv4D9Zy67Y3P9L1rY=.40414e84-7a55-4f3d-947c-2774d5dfb38f@github.com>
 <4tUtLg5ffj-6TmRQUd7gm0lmZNTi2NB20fvV0Zz_6zM=.fcedb49c-f498-45bb-91a0-ad0d3e5878d9@github.com>
Message-ID: <QdOzYzcoV5BJdS3nco3s57LSbVKna4cfcOMyvzsaXG4=.c6cbfe0b-17c4-448d-a7f8-dd40e50aaeb7@github.com>

On Thu, 27 Jan 2022 19:28:01 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> 
> This is a good suggestion. I thought about doing it before, but I am used to tamping down my functional programming instincts when writing C.

You are right, it's generally good to do things the way they are done. When in Rome. But in this case, Rome already uses closures. Not textbook-like with operator overloading, but still. Just grep the hotspot sources for "Closure" and you see what I mean.

> That said, this option required no additional memory allocation, so it removes any need for the class I wrote before. My implementation is a little brittle, as I chose to take os::LoadedModulesCallbackFunc, rather than a more general type (and having to construct a closure etc.). This should save on indirection for now, and could be extended in the future if needed.

I'm sure whatever you come up will be fine from your description. Note that long term you'll be the maintainer, so you will have first say in taste matters like these.

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

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


From duke at openjdk.java.net  Fri Jan 28 08:25:08 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Fri, 28 Jan 2022 08:25:08 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) (Update building.md and building.html to reflect change)
In-Reply-To: <kML31_nAANPIyNVUxrU8RFoF1nqiBQKOMylR19CMA88=.032f705c-711e-496d-b273-766866fd7135@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
 <kML31_nAANPIyNVUxrU8RFoF1nqiBQKOMylR19CMA88=.032f705c-711e-496d-b273-766866fd7135@github.com>
Message-ID: <xF7dCHXQ0nTnAYsTsxCa_6LvEL2jlNkyuBuNM7kXTEw=.34abaefc-d39e-4694-81d8-84383bc9205e@github.com>

On Thu, 27 Jan 2022 14:37:51 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The updated wording seems fine to me.
> 
> The html file should not be edited by hand, but generated (by pandoc) using the make target `update-build-docs`. If you don't have access to pandoc, I can help you regenerate the file.
> 
> It looks like you are trying to reuse an existing and already resolved BugID for this change. That is not possible. A new bug must be filed for each change in OpenJDK.

@erikj79 
I don't have access to pandoc, would be appreciated if you could help me out with that!



> @TheShermanTanker Some comments in no particular order.
> 
> * The MSYS2 project calls themselves "MSYS2"; I think it'd be proper to reflect this capitalization/lack of space before the 2.
> * This PR has technical problems. You are trying to reuse the old JBS bug issue. You'll need a new bug entry for the problem you are trying to solve here. If you do not have access to the bug system, let me know and I can help you.
> * I have actually a similar fix on a personal branch, where I'm updating several omissions in the build README. However, when I went to try building on an MSYS2 installation with the mainline head, it actually failed.. :-( Have you successfully built on MSYS2 with the mainline JDK?

@magicus
-Noted, will update the PR to reflect that soon
-I don't have access to the bug system unfortunately, would be great if you could help me file a new one. How do I get access to it for any future PRs?
-Yep, I initially used it since i did want to try building the JDK with gcc, but then found out gcc wasn't supported on Windows, but building it with the default MSVC worked well. Odd that it didn't work for you though, what was the failure?

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

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


From duke at openjdk.java.net  Fri Jan 28 08:49:56 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Fri, 28 Jan 2022 08:49:56 GMT
Subject: RFR: 8280863: Update build README to reflect that MSYS2 is
 supported [v2]
In-Reply-To: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
Message-ID: <tSw9hhOMrey87UwLaANEszksCM-bxQyMoGcuhPkwFnM=.6eee9171-bf56-49be-b5ba-1126a3ad7d38@github.com>

> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSys 2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
> 
> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.

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

 - Clean up documentation and MSys 2 -> MSYS2
 - Update documentation to mention MSys 2 support

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7242/files
  - new: https://git.openjdk.java.net/jdk/pull/7242/files/ec5dd921..e0a4896e

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

  Stats: 1115 lines in 77 files changed: 438 ins; 379 del; 298 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7242.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7242/head:pull/7242

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


From ihse at openjdk.java.net  Fri Jan 28 08:49:58 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 28 Jan 2022 08:49:58 GMT
Subject: RFR: 8280863: Update build README to reflect that MSYS2 is
 supported
In-Reply-To: <xF7dCHXQ0nTnAYsTsxCa_6LvEL2jlNkyuBuNM7kXTEw=.34abaefc-d39e-4694-81d8-84383bc9205e@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
 <kML31_nAANPIyNVUxrU8RFoF1nqiBQKOMylR19CMA88=.032f705c-711e-496d-b273-766866fd7135@github.com>
 <xF7dCHXQ0nTnAYsTsxCa_6LvEL2jlNkyuBuNM7kXTEw=.34abaefc-d39e-4694-81d8-84383bc9205e@github.com>
Message-ID: <-Tqjrwm9lRh0Hu3dnhGsgnaFchIYQAZVkWE8tDbSvlQ=.d16b1a4a-f676-4ce0-a91a-70b3fc90e36d@github.com>

On Fri, 28 Jan 2022 08:21:13 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

>> The updated wording seems fine to me.
>> 
>> The html file should not be edited by hand, but generated (by pandoc) using the make target `update-build-docs`. If you don't have access to pandoc, I can help you regenerate the file.
>> 
>> It looks like you are trying to reuse an existing and already resolved BugID for this change. That is not possible. A new bug must be filed for each change in OpenJDK.
>
>> The updated wording seems fine to me.
>> 
>> The html file should not be edited by hand, but generated (by pandoc) using the make target `update-build-docs`. If you don't have access to pandoc, I can help you regenerate the file.
>> 
>> It looks like you are trying to reuse an existing and already resolved BugID for this change. That is not possible. A new bug must be filed for each change in OpenJDK.
> 
> @erikj79 
> I don't have access to pandoc, would be appreciated if you could help me out with that!
> 
> 
> 
>> @TheShermanTanker Some comments in no particular order.
>> 
>> * The MSYS2 project calls themselves "MSYS2"; I think it'd be proper to reflect this capitalization/lack of space before the 2.
>> * This PR has technical problems. You are trying to reuse the old JBS bug issue. You'll need a new bug entry for the problem you are trying to solve here. If you do not have access to the bug system, let me know and I can help you.
>> * I have actually a similar fix on a personal branch, where I'm updating several omissions in the build README. However, when I went to try building on an MSYS2 installation with the mainline head, it actually failed.. :-( Have you successfully built on MSYS2 with the mainline JDK?
> 
> @magicus
> -Noted, will update the PR to reflect that soon
> -I don't have access to the bug system unfortunately, would be great if you could help me file a new one. How do I get access to it for any future PRs?
> -Yep, I initially used it since i did want to try building the JDK with gcc, but then found out gcc wasn't supported on Windows, but building it with the default MSVC worked well. Odd that it didn't work for you though, what was the failure?

@TheShermanTanker I have now created https://bugs.openjdk.java.net/browse/JDK-8280863 for you. To get access, you need to get Author status in the JDK project, which you can get by submitting repeated high-quality PRs.

Please update the bug title to read "8280863" and the proper format will be filled in for you.

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

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


From duke at openjdk.java.net  Fri Jan 28 08:49:58 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Fri, 28 Jan 2022 08:49:58 GMT
Subject: RFR: 8280863: Update build README to reflect that MSYS2 is
 supported
In-Reply-To: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
Message-ID: <8oTS6xedqxb9qeAqHj21wI2iG1JkwDcFBICVsJTfucU=.25ed6650-e897-4c68-a69d-0f53da7dd46f@github.com>

On Thu, 27 Jan 2022 08:49:08 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSys 2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
> 
> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.

Updated MSYS2 name and prettify building.md (html left out as requested)

@magicus Thank you!

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

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


From ihse at openjdk.java.net  Fri Jan 28 08:49:59 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 28 Jan 2022 08:49:59 GMT
Subject: RFR: 8280863: Update build README to reflect that MSYS2 is
 supported
In-Reply-To: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
Message-ID: <QWeE8MvwbQ2ggtpi1lvX4E1_5RjkPLaXLlz4j-Ot8Hw=.0db37878-9115-467f-b8b7-9d949860f29d@github.com>

On Thu, 27 Jan 2022 08:49:08 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSys 2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
> 
> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.

Also, please do not rebase or force-push to a PR; this makes reviewing much harder. Use merge instead. 

https://openjdk.java.net/guide/ is a great start to read if you want to contribute to OpenJDK projects.

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

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


From ihse at openjdk.java.net  Fri Jan 28 09:04:13 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 28 Jan 2022 09:04:13 GMT
Subject: RFR: 8280863: Update build README to reflect that MSYS2 is
 supported [v2]
In-Reply-To: <tSw9hhOMrey87UwLaANEszksCM-bxQyMoGcuhPkwFnM=.6eee9171-bf56-49be-b5ba-1126a3ad7d38@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
 <tSw9hhOMrey87UwLaANEszksCM-bxQyMoGcuhPkwFnM=.6eee9171-bf56-49be-b5ba-1126a3ad7d38@github.com>
Message-ID: <m-Pe8fJijm7bqTBaVvmRiNKubcf63TXanFaaBF2aoG8=.52751b33-81c3-4aed-a9fe-ca91ab76ef66@github.com>

On Fri, 28 Jan 2022 08:49:56 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

>> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSys 2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
>> 
>> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.
>
> TheShermanTanker has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Clean up documentation and MSys 2 -> MSYS2
>  - Update documentation to mention MSys 2 support

You don't need to give the `/issue` command. That is only used if you want to resolve multiple issues with one fix. The issue number is extracted from the bug title. Now the same issue is listed twice (!). Try removing it by `/issue remove 8280863`

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

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


From ihse at openjdk.java.net  Fri Jan 28 09:15:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 28 Jan 2022 09:15:10 GMT
Subject: RFR: 8280863: Update build README to reflect that MSYS2 is
 supported [v2]
In-Reply-To: <tSw9hhOMrey87UwLaANEszksCM-bxQyMoGcuhPkwFnM=.6eee9171-bf56-49be-b5ba-1126a3ad7d38@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
 <tSw9hhOMrey87UwLaANEszksCM-bxQyMoGcuhPkwFnM=.6eee9171-bf56-49be-b5ba-1126a3ad7d38@github.com>
Message-ID: <MrUxMVR62xNyRQketwF0C2ZJ8YrSridrDT6IBO_-xpk=.e47620f5-580b-442e-b0d1-dd9dc92ef181@github.com>

On Fri, 28 Jan 2022 08:49:56 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

>> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSYS2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
>> 
>> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.
>
> TheShermanTanker has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Clean up documentation and MSys 2 -> MSYS2
>  - Update documentation to mention MSys 2 support

I'm not quite sure of the best way to help you with the html part. I've pushed a fix to https://github.com/magicus/jdk/tree/pull/7242, it is available as commit https://github.com/openjdk/jdk/commit/85024eb1e84425ead40fcc2278ca085ca8fbb5df. Try merging that into your branch.

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

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


From chagedorn at openjdk.java.net  Fri Jan 28 09:22:14 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 28 Jan 2022 09:22:14 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <EaLNOk7R9f2_uOU_KlxsY2xWFOBEF7DIGoDpaOz3UME=.cb619410-e9aa-4a4e-b245-1c87eebe104e@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
 <EaLNOk7R9f2_uOU_KlxsY2xWFOBEF7DIGoDpaOz3UME=.cb619410-e9aa-4a4e-b245-1c87eebe104e@github.com>
Message-ID: <M9PRzl55cxHRbhdu-qhMtuMtXEde6tK_zj3aWFXeSjs=.c6c12823-0867-43a5-94bb-e18c99e32c6b@github.com>

On Thu, 27 Jan 2022 09:26:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Christian, this is very nice and useful!

Thanks Thomas!

> Two general remarks. One concern I have is that the new functionality should be super stable, since nothing is more annoying than to crash during stack dumping in hs-err file; I much rather have a call stack without bells and whistles than an abridged one. Maybe we could, in hs-err printing, if we got secondary crashes during callstack dumping, repeat the step with all optional features (also name demangling) disabled? This could also be done in a separate RFE. We'll know when this happens, we can react then.

I absolutely agree - stability should be the primary concern. An incomplete hs-err file should be avoided at any cost. Doing an additional "catch and repeat without optional features" sounds interesting to get more safety. Would such a thing be easy to add? Yes, it might be better to do that in a separate RFE.

> Another small concern, we parse the Elf file while dumping the stack, right? I remember having a lot of problems on Solaris when dumping callstacks, because there parsing the elf file was really slow. And that delayed call stack printing by a lot, so much that the ErrorCrashTimeout often kicked in and spoiled the crash logs for us.

Yes, a pc for a frame is directly parsed when printing the corresponding frame. It takes some more time to do the additional parsing but not that much. These are the timestamps from a quick `-XX:CICrashAt=1` run with `-Xlog:dwarf=info` on my local machine on `Ubuntu 20.04` with a `fastdebug` build:


[1.862s][info][dwarf] Open DWARF file: /home/christian/Downloads/test/jdk-19/fastdebug/lib/server/libjvm.debuginfo
[1.867s][info][dwarf] pc: 0x00007ffa35c8a9cf, offset: 0x007749cf, filename: c1_Compiler.cpp, line: 250
[1.871s][info][dwarf] pc: 0x00007ffa35fbfb28, offset: 0x00aa9b28, filename: compileBroker.cpp, line: 2291
[1.876s][info][dwarf] pc: 0x00007ffa35fc08e8, offset: 0x00aaa8e8, filename: compileBroker.cpp, line: 1966
[1.881s][info][dwarf] pc: 0x00007ffa36e50cca, offset: 0x0193acca, filename: thread.cpp, line: 1297
[1.890s][info][dwarf] pc: 0x00007ffa36e59010, offset: 0x01943010, filename: thread.cpp, line: 358
[1.897s][info][dwarf] pc: 0x00007ffa36b3c524, offset: 0x01626524, filename: os_linux.cpp, line: 705


The parsing of a single pc takes a little less than 0.01s. Of course, this is not a great way to measure performance. It also highly depends on the source files themselves, the machine setup etc. Thus, this cannot be considered a valid performance test. But still, I think these numbers can give us some indication of the order of magnitude. Compared to the current `ErrorLogTimeout` default value of 2min this looks promising.

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

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


From duke at openjdk.java.net  Fri Jan 28 09:28:44 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Fri, 28 Jan 2022 09:28:44 GMT
Subject: RFR: 8280863: Update build README to reflect that MSYS2 is
 supported [v3]
In-Reply-To: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
Message-ID: <KqR9qrPVhtcxWgI9dlaskfLM8GjX5onuj7KofS7CkhM=.dbd00c9e-0faf-4f1a-9849-0f5b50f04f5c@github.com>

> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSYS2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
> 
> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.

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

  Update htmlm using pandoc.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7242/files
  - new: https://git.openjdk.java.net/jdk/pull/7242/files/e0a4896e..85024eb1

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

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

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


From chagedorn at openjdk.java.net  Fri Jan 28 09:41:12 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 28 Jan 2022 09:41:12 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <OUsrKSumxqskvlyhndWvQyrp9e2HiiEIYKOX1rSXJPo=.e957df7c-07a9-4fa5-b97c-fc2e7d2b1655@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <JcbJ0IRt-ar1wG0GPYXMkXLRjc5njAoh8E70GFVJJUM=.72acfaf8-1627-4199-8e0e-6adc35826191@github.com>
 <hMEnmFTEcxGWfUHlpY6m7RRzGhSgJX1X5d-ZX-dUB5I=.e8e2e3ca-bf6b-4ae4-b78e-a0878466aeb5@github.com>
 <54FxD8Y6tYN9qIxG9kM1609F8U5qX1L2q5k36XCYnzs=.776977b4-80f0-41f9-99d3-6829f8e1d067@github.com>
 <OUsrKSumxqskvlyhndWvQyrp9e2HiiEIYKOX1rSXJPo=.e957df7c-07a9-4fa5-b97c-fc2e7d2b1655@github.com>
Message-ID: <mJkvmOb2ORSiFiOhorybggl5RH45as3TI9rZE43-JFs=.29db1f81-50a4-4297-9a9d-b932d80db572@github.com>

On Thu, 27 Jan 2022 13:43:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > That's interesting. Is this implementation still around somewhere? I'm glad that some of the mentioned things are not a problem anymore.
> 
> Not I know. IIRC, it was based on DWARF 2.

Okay, thanks.

> 
> > > * Different compiler (and different version of the same compiler) can generate DWARF with different version, may not be compatible with each other, as DWARF allows custom fields.
> > > * Maintenance cost to catch up DWARF spec/compiler changes.
> > 
> > 
> > That's indeed a problem of facing different DWARF versions. For this parser, I tried to support the current default of GCC 10.x which is DWARF 4. This standard was introduced in 2010 and is probably used by most compilers nowadays at least (if not already DWARF 5 which was introduced in 2017). However, even with GCC 10.x, it emitted DWARF 3 for one of the sections (I'm not sure why) which I also needed to support - thus you can never be sure.
> > DWARF 5 is still experimental for GCC 10.x and had some issues when I tried that out back there - so I stayed away from implementing parsing steps for it. But now with GCC 11.x, DWARF 5 seems to have become the default. I might have to try out what's being emitted for HotSpot. But I think for now, it is better to only focus on DWARF 4 instead of trying to support various versions in one patch - we could still come back to that later if it becomes widely used. Even if DWARF 5 is emitted, GCC could be configured, for example, to emit DWARF 4 only which is probably an acceptable workaround for testing environments.
> 
> I think maintenance and test could be major pain points. Based on build.html, we can use gcc version anywhere between 5.0 and 10.2, it could be a challenge to ensure all supported version work correctly.

I agree, that wide range is a problem and older GCC versions emitting older DWARF version are not covered with this patch. If I parse a DWARF section header with an unsupported version I will just bail out and it falls back to the stack trace we are seeing today without source information. That's probably fine for the scope of this patch. We could still come back and add support for other missing versions.

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

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


From ihse at openjdk.java.net  Fri Jan 28 09:42:11 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 28 Jan 2022 09:42:11 GMT
Subject: RFR: 8280863: Update build README to reflect that MSYS2 is
 supported [v3]
In-Reply-To: <KqR9qrPVhtcxWgI9dlaskfLM8GjX5onuj7KofS7CkhM=.dbd00c9e-0faf-4f1a-9849-0f5b50f04f5c@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
 <KqR9qrPVhtcxWgI9dlaskfLM8GjX5onuj7KofS7CkhM=.dbd00c9e-0faf-4f1a-9849-0f5b50f04f5c@github.com>
Message-ID: <Tzy6wZqETFFjrqpEPZ9c-8zfWGo93MHUc60s0ScPb7w=.dd3e2996-7152-4915-9e60-3ae1755435ad@github.com>

On Fri, 28 Jan 2022 09:28:44 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

>> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSYS2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
>> 
>> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.
>
> TheShermanTanker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update htmlm using pandoc.

Looks good now. Continue by giving the `/integrate` command, I'll sponsor it for you.

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

Marked as reviewed by ihse (Reviewer).

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


From chagedorn at openjdk.java.net  Fri Jan 28 09:47:11 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 28 Jan 2022 09:47:11 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <GEVA_2Q-3ZD3egEW0VXBRlwsAE_T3zHKqDl7qTtlunI=.8390d269-afaf-4765-8989-a10b3feaac2e@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
 <GEVA_2Q-3ZD3egEW0VXBRlwsAE_T3zHKqDl7qTtlunI=.8390d269-afaf-4765-8989-a10b3feaac2e@github.com>
Message-ID: <uNmb5Gc8fabeYM2ta5-Z3pcrbAsqibEJDO1mp_wVCEE=.e0576249-9e66-49d3-b5b9-78805771dd4a@github.com>

On Fri, 28 Jan 2022 02:26:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I think this feature is very useful, thanks Christian!

Thanks Yasumasa!

> SA already has similar feature to gather call stacks with DWARF, so it would be nice to share DWARF parser between SA and HotSpot.

I agree, that would be a good idea!

> P.S. I've proposed to use elfutils to parse DWARF in SA in [JDK-8245234](https://bugs.openjdk.java.net/browse/JDK-8245234).

Ah that's interesting, I've missed that. I had a look at SA when I've started to do some work on this patch back in 2020 and even took some things over.

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

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


From stuefe at openjdk.java.net  Fri Jan 28 10:02:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 28 Jan 2022 10:02:15 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <M9PRzl55cxHRbhdu-qhMtuMtXEde6tK_zj3aWFXeSjs=.c6c12823-0867-43a5-94bb-e18c99e32c6b@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
 <EaLNOk7R9f2_uOU_KlxsY2xWFOBEF7DIGoDpaOz3UME=.cb619410-e9aa-4a4e-b245-1c87eebe104e@github.com>
 <M9PRzl55cxHRbhdu-qhMtuMtXEde6tK_zj3aWFXeSjs=.c6c12823-0867-43a5-94bb-e18c99e32c6b@github.com>
Message-ID: <OYbaSf2NMeZXuD8X2iAkWui5__Me7O9CF-MrWmvac8M=.ffb61c88-b874-4c54-b1fe-3247dea3c1be@github.com>

On Fri, 28 Jan 2022 09:19:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> > Two general remarks. One concern I have is that the new functionality should be super stable, since nothing is more annoying than to crash during stack dumping in hs-err file; I much rather have a call stack without bells and whistles than an abridged one. Maybe we could, in hs-err printing, if we got secondary crashes during callstack dumping, repeat the step with all optional features (also name demangling) disabled? This could also be done in a separate RFE. We'll know when this happens, we can react then.
> 
> I absolutely agree - stability should be the primary concern. An incomplete hs-err file should be avoided at any cost. Doing an additional "catch and repeat without optional features" sounds interesting to get more safety. Would such a thing be easy to add? Yes, it might be better to do that in a separate RFE.

It is probably easy, but I also thing this would be better in a separate RFE. And we already have a timeout per reporting step since JDK-8166944, so that long-running steps don't spoil error reporting for everyone. We can just add a second call stack print step if the first one failed.

> 
> > Another small concern, we parse the Elf file while dumping the stack, right? I remember having a lot of problems on Solaris when dumping callstacks, because there parsing the elf file was really slow. And that delayed call stack printing by a lot, so much that the ErrorCrashTimeout often kicked in and spoiled the crash logs for us.
> 
> Yes, a pc for a frame is directly parsed when printing the corresponding frame. It takes some more time to do the additional parsing but not that much. These are the timestamps from a quick `-XX:CICrashAt=1` run with `-Xlog:dwarf=info` on my local machine on `Ubuntu 20.04` with a `fastdebug` build:
> 
> ```
> [1.862s][info][dwarf] Open DWARF file: /home/christian/Downloads/test/jdk-19/fastdebug/lib/server/libjvm.debuginfo
> [1.867s][info][dwarf] pc: 0x00007ffa35c8a9cf, offset: 0x007749cf, filename: c1_Compiler.cpp, line: 250
> [1.871s][info][dwarf] pc: 0x00007ffa35fbfb28, offset: 0x00aa9b28, filename: compileBroker.cpp, line: 2291
> [1.876s][info][dwarf] pc: 0x00007ffa35fc08e8, offset: 0x00aaa8e8, filename: compileBroker.cpp, line: 1966
> [1.881s][info][dwarf] pc: 0x00007ffa36e50cca, offset: 0x0193acca, filename: thread.cpp, line: 1297
> [1.890s][info][dwarf] pc: 0x00007ffa36e59010, offset: 0x01943010, filename: thread.cpp, line: 358
> [1.897s][info][dwarf] pc: 0x00007ffa36b3c524, offset: 0x01626524, filename: os_linux.cpp, line: 705
> ```
> 
> The parsing of a single pc takes a little less than 0.01s. Of course, this is not a great way to measure performance. It also highly depends on the source files themselves, the machine setup etc. Thus, this cannot be considered a valid performance test. But still, I think these numbers can give us some indication of the order of magnitude. Compared to the current `ErrorLogTimeout` default value of 2min this looks promising.

Okay, this looks reasonable. In our case, I remember having a very slow file system and an overloaded machine. But this would be solved also by just repeating call stack printing if the first attempt times out.

Cheers, and thanks for this patch!

..Thomas

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

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


From ihse at openjdk.java.net  Fri Jan 28 10:45:16 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 28 Jan 2022 10:45:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
Message-ID: <p4SxfgwvMeKQlaHcIJ4P5or20bj4C8COnwAIRC2LlfM=.cf4f03ff-d996-413b-b1cd-baab61c791d0@github.com>

On Mon, 24 Jan 2022 22:23:33 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Build changes look good. (I have no opinion on the rest of the code).

`JVM_FEATURES_PLATFORM_FILTER` is not used anymore after this patch, however I think it's good to keep it if it might be needed in the future.

test/jdk/ProblemList.txt line 823:

> 821: # jdk_jfr
> 822: 
> 823: jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java          8228990 macoss-all,linux-all,windows-all

That's not how you spell `macosx`. :)

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

Marked as reviewed by ihse (Reviewer).

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


From chagedorn at openjdk.java.net  Fri Jan 28 10:50:11 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 28 Jan 2022 10:50:11 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <OYbaSf2NMeZXuD8X2iAkWui5__Me7O9CF-MrWmvac8M=.ffb61c88-b874-4c54-b1fe-3247dea3c1be@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <jOoUnMIxp3TCfxowjkrfjMDtKxMNEvPSh1-OnaPwfOQ=.b6db4313-6cbe-4095-ae24-ec6cfb398138@github.com>
 <EaLNOk7R9f2_uOU_KlxsY2xWFOBEF7DIGoDpaOz3UME=.cb619410-e9aa-4a4e-b245-1c87eebe104e@github.com>
 <M9PRzl55cxHRbhdu-qhMtuMtXEde6tK_zj3aWFXeSjs=.c6c12823-0867-43a5-94bb-e18c99e32c6b@github.com>
 <OYbaSf2NMeZXuD8X2iAkWui5__Me7O9CF-MrWmvac8M=.ffb61c88-b874-4c54-b1fe-3247dea3c1be@github.com>
Message-ID: <8-tXxWKUxKMA9z_uf2hTInUcmNfVT8nWXFFv1taQWP4=.d712ba08-ed79-4ee7-8930-bf75af97680d@github.com>

On Fri, 28 Jan 2022 09:58:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > Two general remarks. One concern I have is that the new functionality should be super stable, since nothing is more annoying than to crash during stack dumping in hs-err file; I much rather have a call stack without bells and whistles than an abridged one. Maybe we could, in hs-err printing, if we got secondary crashes during callstack dumping, repeat the step with all optional features (also name demangling) disabled? This could also be done in a separate RFE. We'll know when this happens, we can react then.
> > 
> > 
> > I absolutely agree - stability should be the primary concern. An incomplete hs-err file should be avoided at any cost. Doing an additional "catch and repeat without optional features" sounds interesting to get more safety. Would such a thing be easy to add? Yes, it might be better to do that in a separate RFE.
> 
> It is probably easy, but I also thing this would be better in a separate RFE. And we already have a timeout per reporting step since JDK-8166944, so that long-running steps don't spoil error reporting for everyone. We can just add a second call stack print step if the first one failed.

That sounds great. And good to know about JDK-8166944!

> > The parsing of a single pc takes a little less than 0.01s. Of course, this is not a great way to measure performance. It also highly depends on the source files themselves, the machine setup etc. Thus, this cannot be considered a valid performance test. But still, I think these numbers can give us some indication of the order of magnitude. Compared to the current `ErrorLogTimeout` default value of 2min this looks promising.
> 
> Okay, this looks reasonable. In our case, I remember having a very slow file system and an overloaded machine. But this would be solved also by just repeating call stack printing if the first attempt times out.

Yes, I think so, too. Ah, I see, yes that would be an option in this case.

> Cheers, and thanks for this patch!

You're welcome! I'm glad this can help with the analysis of crashes in the future :-)

Cheers,
Christian

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

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


From duke at openjdk.java.net  Fri Jan 28 10:53:19 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Fri, 28 Jan 2022 10:53:19 GMT
Subject: RFR: 8280863: Update build README to reflect that MSYS2 is
 supported [v2]
In-Reply-To: <MrUxMVR62xNyRQketwF0C2ZJ8YrSridrDT6IBO_-xpk=.e47620f5-580b-442e-b0d1-dd9dc92ef181@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
 <tSw9hhOMrey87UwLaANEszksCM-bxQyMoGcuhPkwFnM=.6eee9171-bf56-49be-b5ba-1126a3ad7d38@github.com>
 <MrUxMVR62xNyRQketwF0C2ZJ8YrSridrDT6IBO_-xpk=.e47620f5-580b-442e-b0d1-dd9dc92ef181@github.com>
Message-ID: <06c3oY6CAjnD_Y7RDbgpckuATLAydG5z4lz_iisouKQ=.8c6efdc3-0da5-46ee-a39f-bc663a2ec698@github.com>

On Fri, 28 Jan 2022 09:12:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> TheShermanTanker has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Clean up documentation and MSys 2 -> MSYS2
>>  - Update documentation to mention MSys 2 support
>
> I'm not quite sure of the best way to help you with the html part. I've pushed a fix to https://github.com/magicus/jdk/tree/pull/7242, it is available as commit https://github.com/openjdk/jdk/commit/85024eb1e84425ead40fcc2278ca085ca8fbb5df. Try merging that into your branch.

@magicus Thank you!

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

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


From duke at openjdk.java.net  Fri Jan 28 12:49:13 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Fri, 28 Jan 2022 12:49:13 GMT
Subject: Integrated: 8280863: Update build README to reflect that MSYS2 is
 supported
In-Reply-To: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
References: <udDMJ9aGK4kDYfeAcvZKaOOM_JWqZeI3luk1XH-ia5k=.66ac6238-9d1c-4470-aa74-72419db4f9c4@github.com>
Message-ID: <SxsvWiRQ6yKFAyKSQDV_ugfTIrf3Aq-Qvjqq9p672_c=.a05ea07b-f001-462e-a0e8-6f14d2555738@github.com>

On Thu, 27 Jan 2022 08:49:08 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

> Ever since [JDK-8257679](https://bugs.openjdk.java.net/browse/JDK-8257679) was merged in 16, MSYS2 became capable of building a functional JDK on Windows. This PR updates some outdated documentation in building.html and building.md to reflect that change.
> 
> I appreciate any reviews, and would like to know how I might be able to improve the wording of both updated docs, if possible.

This pull request has now been integrated.

Changeset: 6de90ad9
Author:    Magnus Ihse Bursie <mag at icus.se>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6de90ad9800b83c4a5f364c3645603fcb6828d6c
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8280863: Update build README to reflect that MSYS2 is supported

Reviewed-by: ihse

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

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


From zgu at openjdk.java.net  Fri Jan 28 13:48:13 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 28 Jan 2022 13:48:13 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v2]
In-Reply-To: <mJkvmOb2ORSiFiOhorybggl5RH45as3TI9rZE43-JFs=.29db1f81-50a4-4297-9a9d-b932d80db572@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <JcbJ0IRt-ar1wG0GPYXMkXLRjc5njAoh8E70GFVJJUM=.72acfaf8-1627-4199-8e0e-6adc35826191@github.com>
 <hMEnmFTEcxGWfUHlpY6m7RRzGhSgJX1X5d-ZX-dUB5I=.e8e2e3ca-bf6b-4ae4-b78e-a0878466aeb5@github.com>
 <54FxD8Y6tYN9qIxG9kM1609F8U5qX1L2q5k36XCYnzs=.776977b4-80f0-41f9-99d3-6829f8e1d067@github.com>
 <OUsrKSumxqskvlyhndWvQyrp9e2HiiEIYKOX1rSXJPo=.e957df7c-07a9-4fa5-b97c-fc2e7d2b1655@github.com>
 <mJkvmOb2ORSiFiOhorybggl5RH45as3TI9rZE43-JFs=.29db1f81-50a4-4297-9a9d-b932d80db572@github.com>
Message-ID: <wISgTPcBQPtY6rut5nv8B4NOF3z5PI9ZO9hulKPXO6U=.31132cde-e668-49e1-ab83-f6ad4d82191d@github.com>

On Fri, 28 Jan 2022 09:38:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> > > That's interesting. Is this implementation still around somewhere? I'm glad that some of the mentioned things are not a problem anymore.
> > 
> > 
> > Not I know. IIRC, it was based on DWARF 2.
> 
> Okay, thanks.
> 
> > > > * Different compiler (and different version of the same compiler) can generate DWARF with different version, may not be compatible with each other, as DWARF allows custom fields.
> > > > * Maintenance cost to catch up DWARF spec/compiler changes.
> > > 
> > > 
> > > That's indeed a problem of facing different DWARF versions. For this parser, I tried to support the current default of GCC 10.x which is DWARF 4. This standard was introduced in 2010 and is probably used by most compilers nowadays at least (if not already DWARF 5 which was introduced in 2017). However, even with GCC 10.x, it emitted DWARF 3 for one of the sections (I'm not sure why) which I also needed to support - thus you can never be sure.
> > > DWARF 5 is still experimental for GCC 10.x and had some issues when I tried that out back there - so I stayed away from implementing parsing steps for it. But now with GCC 11.x, DWARF 5 seems to have become the default. I might have to try out what's being emitted for HotSpot. But I think for now, it is better to only focus on DWARF 4 instead of trying to support various versions in one patch - we could still come back to that later if it becomes widely used. Even if DWARF 5 is emitted, GCC could be configured, for example, to emit DWARF 4 only which is probably an acceptable workaround for testing environments.
> > 
> > 
> > I think maintenance and test could be major pain points. Based on build.html, we can use gcc version anywhere between 5.0 and 10.2, it could be a challenge to ensure all supported version work correctly.
> 
> I agree, that wide range is a problem and older GCC versions emitting older DWARF version are not covered with this patch. If I parse a DWARF section header with an unsupported version I will just bail out and it falls back to the stack trace we are seeing today without source information. That's probably fine for the scope of this patch. We could still come back and add support for other missing versions.

I see, it makes sense. Thanks!

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

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


From duke at openjdk.java.net  Fri Jan 28 15:02:17 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 28 Jan 2022 15:02:17 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v15]
In-Reply-To: <p4SxfgwvMeKQlaHcIJ4P5or20bj4C8COnwAIRC2LlfM=.cf4f03ff-d996-413b-b1cd-baab61c791d0@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <a3ls5C4pKxSMEUa2q_asZ2QPJrVDAQv7ofBX7Tkc5X4=.00c3c8b8-1dbe-4746-bb59-5b013cd9c057@github.com>
 <p4SxfgwvMeKQlaHcIJ4P5or20bj4C8COnwAIRC2LlfM=.cf4f03ff-d996-413b-b1cd-baab61c791d0@github.com>
Message-ID: <6fXDrx7YX13cLn3DUxQgVv-EndJyr1QQMd0bkTOrFL0=.33b7a6eb-9464-4ee0-8a5f-2edecf405ae0@github.com>

On Fri, 28 Jan 2022 10:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8203290
>>  - Implements JFR on AIX
>>    
>>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>>    by TestNativeLibraies.java)
>>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>>    all platforms)
>>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux
>
> test/jdk/ProblemList.txt line 823:
> 
>> 821: # jdk_jfr
>> 822: 
>> 823: jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java          8228990 macoss-all,linux-all,windows-all
> 
> That's not how you spell `macosx`. :)

Indeed it is not :-)

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

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


From duke at openjdk.java.net  Fri Jan 28 15:07:56 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 28 Jan 2022 15:07:56 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v16]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@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 two additional commits since the last revision:

 - Changes macoss -> macosx in problem list
 - Refactors loadlib_aix: Removes redundant c++ class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/bcfb25be..08837098

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

  Stats: 163 lines in 5 files changed: 27 ins; 54 del; 82 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 stuefe at openjdk.java.net  Fri Jan 28 18:25:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 28 Jan 2022 18:25:15 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v16]
In-Reply-To: <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@github.com>
Message-ID: <oIHpuJBGJgXWjuDGbdX_cVVWwH9nyb_GUNX2_Du8Kew=.b733fa27-623d-4777-9917-9598b814a51a@github.com>

On Fri, 28 Jan 2022 15:07:56 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class

src/hotspot/os/aix/os_perf_aix.cpp line 31:

> 29: #include "memory/resourceArea.hpp"
> 30: #include "os_aix.inline.hpp"
> 31: #include "precompiled.hpp"

precompiled.hpp must appear at the very top of the cpp file. The one exception from the "order includes alphabetically" rule. Oh, that, and people usually include system headers after hotspot ones.

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

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


From stuefe at openjdk.java.net  Sat Jan 29 07:02:16 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 29 Jan 2022 07:02:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v16]
In-Reply-To: <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@github.com>
Message-ID: <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>

On Fri, 28 Jan 2022 15:07:56 GMT, Tyler Steele <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.
>
> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class

Hi Tyler,

looks better. See comments inline.

src/hotspot/os/aix/loadlib_aix.cpp line 116:

> 114: //   entry_t* next;
> 115: //   loaded_module_t info;
> 116: // };

please remove

src/hotspot/os/aix/loadlib_aix.cpp line 326:

> 324: // Helper for copying loaded module info to external callers.
> 325: // To avoid dangling pointers 'next' is set to null
> 326: static bool copy_lm_to_external(const loaded_module_t* const from, loaded_module_t* to) {

So, just to understand, the point of this function is to handle to==NULL (from is never NULL) and to set next to NULL? 

I'd probably keep doing this inline in the two places where this happens, but I leave it up to you. If you think this is cleaner, its fine too.

src/hotspot/os/aix/loadlib_aix.hpp line 37:

> 35: 
> 36: #include "misc_aix.hpp"
> 37: #include "runtime/os.hpp"

Bikeshed: I would like to have avoided including os.hpp (its a monster) - hence my recommendation about a separate callback or closure definition. But it is not super important, this is fine too.

src/hotspot/os/aix/os_perf_aix.cpp line 72:

> 70: 
> 71: static bool initialize_libperfstat() {
> 72:   static bool is_libperfstat_loaded = false;

I don't think this is needed. libperfstat is initialized as part of os::init in os_aix.cpp.

https://github.com/openjdk/jdk/blob/d366d15d67a08833d93a5806edef8145cb7803e5/src/hotspot/os/aix/os_aix.cpp#L2999-L3008
https://github.com/openjdk/jdk/blob/d366d15d67a08833d93a5806edef8145cb7803e5/src/hotspot/os/aix/os_aix.cpp#L2329-L2333

Should be already active at this point. Its functions are stubbed out in case the library cannot be loaded, so you should be able to call them in here, without an additional init check. You just have to handle the errors on the individual API calls, as if the real APIs returned errors. But you do this already I think.

Long term, if you think libperfstat should be always there, we can simplify things and treat libperfstat load errors as hard VM errors in release builds too. We already assert in `os::Aix::initialize_libperfstat()`. (Note: "assert" fires in debug builds (ASSERT macro), and "guarantee" fires in all builds).

src/hotspot/os/aix/os_perf_aix.cpp line 495:

> 493:     char* name     = NEW_C_HEAP_ARRAY(char, IDENTIFIER_LENGTH, mtInternal);
> 494:     char* exe_name = NEW_C_HEAP_ARRAY(char, PRFNSZ, mtInternal);
> 495:     char* cmd_line = NEW_C_HEAP_ARRAY(char, PRARGSZ, mtInternal);

So the contract with SystemProcess is that its ctor arguments need to be C-heap allocated, and releases them itself? ... okay. May be worthwhile to clean up at some point, or at least comment.

src/hotspot/os/aix/os_perf_aix.cpp line 611:

> 609: 
> 610:   // calling perfstat_<subsystem>(NULL, NULL, _, 0) returns number of available records
> 611:   if ((n_records = libperfstat::perfstat_netinterface(NULL, NULL, sizeof(perfstat_netinterface_t), 0)) <= 0) {

is n=0 an error? Could there conceivably be zero interfaces?

src/hotspot/os/aix/os_perf_aix.cpp line 631:

> 629:                                                            net_stats[i].ibytes,
> 630:                                                            net_stats[i].obytes,
> 631:                                                            *network_interfaces);

When looking at NetworkInterface, I saw that it copies the name into its own resource-area allocated string in the constructor. This is all over the place, SystemProcess assumes C-heap storage, NetworkInterface uses RA... :(

The problem now is that your ResourceMark above may also destroy the internal string in NetworkInterface when the Stack is unwound beyond this function.

Side note: this is what I don't like about how hotspot uses RA. Its often not clear which data are RA allocated without looking at the code. In Objective-C (at least how its used on Mac) they had a clear naming convention for methods that returned storage from the AutoReleasePool.

The problem is also that with ResourceMarks cutting off your data, you may not see the problem until much later. Usually you only see immediate problems if the underlying arena (a chained list of malloced slabs) added a new slab under your ResourceMark, which then gets free'd when the ResourceMark goes out of scope.

How to fix this:
1) revert to NEW_C_HEAP_ARRAY for your records array here, with appropriate cleanup, and remove ResourceMark
3) Change NetworkInterface class to use C-heap instead.

I'd opt for (1) since it avoids discussions about changing shared code. I opened https://bugs.openjdk.java.net/browse/JDK-8280912 to change NetworkInterface, but don't wait for me.

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

Changes requested by stuefe (Reviewer).

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


From kbarrett at openjdk.java.net  Sun Jan 30 00:35:27 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 30 Jan 2022 00:35:27 GMT
Subject: RFR: 8280916: Simplify HotSpot Style Guide editorial changes
Message-ID: <eHIvtcDZf4wFLz2YHRM1eHmzoRSVCunYddbjOo_VA10=.e692ac8c-9836-445b-a890-8fdb95d65352@github.com>

Please review this change to the HotSpot Style Guide change process.

The current process involves gathering consensus among the HotSpot Group
Members.  That's fine for changes of substance.  But it seems overly weighty
for editorial changes that don't affect the substance of the guide, but only
it's clarity or accuracy.

The proposed change would permit the normal PR process to be used for such
changes, but require the requisite reviewers to additionally be HotSpot Group
Members.

Note that there have already been a couple of changes that effectively
followed the proposed new process.
https://bugs.openjdk.java.net/browse/JDK-8274169
https://bugs.openjdk.java.net/browse/JDK-8280182

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

Commit messages:
 - update generated html
 - editorial change process

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

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


From kbarrett at openjdk.java.net  Sun Jan 30 00:40:09 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 30 Jan 2022 00:40:09 GMT
Subject: RFR: 8280916: Simplify HotSpot Style Guide editorial changes
In-Reply-To: <eHIvtcDZf4wFLz2YHRM1eHmzoRSVCunYddbjOo_VA10=.e692ac8c-9836-445b-a890-8fdb95d65352@github.com>
References: <eHIvtcDZf4wFLz2YHRM1eHmzoRSVCunYddbjOo_VA10=.e692ac8c-9836-445b-a890-8fdb95d65352@github.com>
Message-ID: <GbJI4QsFJOnaTqLxa5nQec595Mi_mMjxwWiZG87VHmQ=.a8c81ed3-296d-451e-b044-7f55461f4b14@github.com>

On Sun, 30 Jan 2022 00:28:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide change process.
> 
> The current process involves gathering consensus among the HotSpot Group
> Members.  That's fine for changes of substance.  But it seems overly weighty
> for editorial changes that don't affect the substance of the guide, but only
> it's clarity or accuracy.
> 
> The proposed change would permit the normal PR process to be used for such
> changes, but require the requisite reviewers to additionally be HotSpot Group
> Members.
> 
> Note that there have already been a couple of changes that effectively
> followed the proposed new process.
> https://bugs.openjdk.java.net/browse/JDK-8274169
> https://bugs.openjdk.java.net/browse/JDK-8280182

I messed up the PR submission for this.  Closing and will open a new one.

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

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


From kbarrett at openjdk.java.net  Sun Jan 30 00:40:09 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 30 Jan 2022 00:40:09 GMT
Subject: Withdrawn: 8280916: Simplify HotSpot Style Guide editorial changes
In-Reply-To: <eHIvtcDZf4wFLz2YHRM1eHmzoRSVCunYddbjOo_VA10=.e692ac8c-9836-445b-a890-8fdb95d65352@github.com>
References: <eHIvtcDZf4wFLz2YHRM1eHmzoRSVCunYddbjOo_VA10=.e692ac8c-9836-445b-a890-8fdb95d65352@github.com>
Message-ID: <CdOTYbtbJoCcBT3bTzCvTrteH3yVaIDNskC2kUkY-lc=.fa6d2a89-9416-4b33-8cd4-d57799d8df1a@github.com>

On Sun, 30 Jan 2022 00:28:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide change process.
> 
> The current process involves gathering consensus among the HotSpot Group
> Members.  That's fine for changes of substance.  But it seems overly weighty
> for editorial changes that don't affect the substance of the guide, but only
> it's clarity or accuracy.
> 
> The proposed change would permit the normal PR process to be used for such
> changes, but require the requisite reviewers to additionally be HotSpot Group
> Members.
> 
> Note that there have already been a couple of changes that effectively
> followed the proposed new process.
> https://bugs.openjdk.java.net/browse/JDK-8274169
> https://bugs.openjdk.java.net/browse/JDK-8280182

This pull request has been closed without being integrated.

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

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


From kbarrett at openjdk.java.net  Sun Jan 30 00:48:32 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 30 Jan 2022 00:48:32 GMT
Subject: RFR: 8280916: Simplify HotSpot Style Guide editorial changes
Message-ID: <SDUK8k1OZZU7qha8dERVEj34cNap1YPEqEv92b1hCxw=.908aecb5-b941-48c6-a690-49690f2359ad@github.com>

Please review this change to the HotSpot Style Guide change process.

The current process involves gathering consensus among the HotSpot Group
Members.  That's fine for changes of substance.  But it seems overly weighty
for editorial changes that don't affect the substance of the guide, but only
it's clarity or accuracy.

The proposed change would permit the normal PR process to be used for such
changes, but require the requisite reviewers to additionally be HotSpot Group
Members.

Note that there have already been a couple of changes that effectively
followed the proposed new process.
https://bugs.openjdk.java.net/browse/JDK-8274169
https://bugs.openjdk.java.net/browse/JDK-8280182

This is a modification of the Style Guide, so rough consensus among the
HotSpot Group members is required to make this change. Only Group members
should vote for approval (via the github PR), though reasoned objections or
comments from anyone will be considered. A decision on this proposal will not
be made before Monday 14-Feb-2022 at 12h00 UTC.

Since we're piggybacking on github PRs here, please use the PR review process
to approve (click on Review Changes > Approve), rather than sending a "vote:
yes" email reply that would be normal for a CFV.

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

Commit messages:
 - update generated html
 - editorial change process

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

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


From dcubed at openjdk.java.net  Sun Jan 30 14:14:13 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 30 Jan 2022 14:14:13 GMT
Subject: RFR: 8280916: Simplify HotSpot Style Guide editorial changes
In-Reply-To: <SDUK8k1OZZU7qha8dERVEj34cNap1YPEqEv92b1hCxw=.908aecb5-b941-48c6-a690-49690f2359ad@github.com>
References: <SDUK8k1OZZU7qha8dERVEj34cNap1YPEqEv92b1hCxw=.908aecb5-b941-48c6-a690-49690f2359ad@github.com>
Message-ID: <hoEZfXEWVHDWkYXLaGYzFzv_ljqYN7XLNxkZ4LNaNhU=.4773b207-a5dd-4d82-af67-3710de3e9212@github.com>

On Sun, 30 Jan 2022 00:39:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide change process.
> 
> The current process involves gathering consensus among the HotSpot Group
> Members.  That's fine for changes of substance.  But it seems overly weighty
> for editorial changes that don't affect the substance of the guide, but only
> it's clarity or accuracy.
> 
> The proposed change would permit the normal PR process to be used for such
> changes, but require the requisite reviewers to additionally be HotSpot Group
> Members.
> 
> Note that there have already been a couple of changes that effectively
> followed the proposed new process.
> https://bugs.openjdk.java.net/browse/JDK-8274169
> https://bugs.openjdk.java.net/browse/JDK-8280182
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change. Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered. A decision on this proposal will not
> be made before Monday 14-Feb-2022 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review process
> to approve (click on Review Changes > Approve), rather than sending a "vote:
> yes" email reply that would be normal for a CFV.

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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


From dholmes at openjdk.java.net  Sun Jan 30 21:59:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 30 Jan 2022 21:59:06 GMT
Subject: RFR: 8280916: Simplify HotSpot Style Guide editorial changes
In-Reply-To: <SDUK8k1OZZU7qha8dERVEj34cNap1YPEqEv92b1hCxw=.908aecb5-b941-48c6-a690-49690f2359ad@github.com>
References: <SDUK8k1OZZU7qha8dERVEj34cNap1YPEqEv92b1hCxw=.908aecb5-b941-48c6-a690-49690f2359ad@github.com>
Message-ID: <Js5enSzI4e7LjD1WXBqdQ78BGe6GxpoOrJPVq50ppDA=.c1b33dda-0185-49aa-8606-e0549929cb68@github.com>

On Sun, 30 Jan 2022 00:39:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide change process.
> 
> The current process involves gathering consensus among the HotSpot Group
> Members.  That's fine for changes of substance.  But it seems overly weighty
> for editorial changes that don't affect the substance of the guide, but only
> it's clarity or accuracy.
> 
> The proposed change would permit the normal PR process to be used for such
> changes, but require the requisite reviewers to additionally be HotSpot Group
> Members.
> 
> Note that there have already been a couple of changes that effectively
> followed the proposed new process.
> https://bugs.openjdk.java.net/browse/JDK-8274169
> https://bugs.openjdk.java.net/browse/JDK-8280182
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change. Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered. A decision on this proposal will not
> be made before Monday 14-Feb-2022 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review process
> to approve (click on Review Changes > Approve), rather than sending a "vote:
> yes" email reply that would be normal for a CFV.

Marked as reviewed by dholmes (Reviewer).

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

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


From stuefe at openjdk.java.net  Mon Jan 31 07:18:09 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 31 Jan 2022 07:18:09 GMT
Subject: RFR: 8280916: Simplify HotSpot Style Guide editorial changes
In-Reply-To: <SDUK8k1OZZU7qha8dERVEj34cNap1YPEqEv92b1hCxw=.908aecb5-b941-48c6-a690-49690f2359ad@github.com>
References: <SDUK8k1OZZU7qha8dERVEj34cNap1YPEqEv92b1hCxw=.908aecb5-b941-48c6-a690-49690f2359ad@github.com>
Message-ID: <KVKWIdojXA_4ALc8pcmKGNcTT-W-akXxdiWnpkVZdD0=.af0e0c53-a412-4efe-9784-71e511b3b403@github.com>

On Sun, 30 Jan 2022 00:39:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide change process.
> 
> The current process involves gathering consensus among the HotSpot Group
> Members.  That's fine for changes of substance.  But it seems overly weighty
> for editorial changes that don't affect the substance of the guide, but only
> it's clarity or accuracy.
> 
> The proposed change would permit the normal PR process to be used for such
> changes, but require the requisite reviewers to additionally be HotSpot Group
> Members.
> 
> Note that there have already been a couple of changes that effectively
> followed the proposed new process.
> https://bugs.openjdk.java.net/browse/JDK-8274169
> https://bugs.openjdk.java.net/browse/JDK-8280182
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change. Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered. A decision on this proposal will not
> be made before Monday 14-Feb-2022 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review process
> to approve (click on Review Changes > Approve), rather than sending a "vote:
> yes" email reply that would be normal for a CFV.

This makes sense.

About substantive changes: since those affect a lot of people, would it make sense to include a clause for a minimum time to collect answers on a proposed style change? Like the 24hrs clause for code reviews?

Thanks, Thomas

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

Marked as reviewed by stuefe (Reviewer).

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


From stefank at openjdk.java.net  Mon Jan 31 08:58:11 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 Jan 2022 08:58:11 GMT
Subject: RFR: 8280916: Simplify HotSpot Style Guide editorial changes
In-Reply-To: <SDUK8k1OZZU7qha8dERVEj34cNap1YPEqEv92b1hCxw=.908aecb5-b941-48c6-a690-49690f2359ad@github.com>
References: <SDUK8k1OZZU7qha8dERVEj34cNap1YPEqEv92b1hCxw=.908aecb5-b941-48c6-a690-49690f2359ad@github.com>
Message-ID: <szrMMN0g9w7WZcp7jDC0mlqFL8KJW3E7BRgTdo_Qwl0=.bed9d6ff-95df-428b-a2b3-231ef546fe8e@github.com>

On Sun, 30 Jan 2022 00:39:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide change process.
> 
> The current process involves gathering consensus among the HotSpot Group
> Members.  That's fine for changes of substance.  But it seems overly weighty
> for editorial changes that don't affect the substance of the guide, but only
> it's clarity or accuracy.
> 
> The proposed change would permit the normal PR process to be used for such
> changes, but require the requisite reviewers to additionally be HotSpot Group
> Members.
> 
> Note that there have already been a couple of changes that effectively
> followed the proposed new process.
> https://bugs.openjdk.java.net/browse/JDK-8274169
> https://bugs.openjdk.java.net/browse/JDK-8280182
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change. Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered. A decision on this proposal will not
> be made before Monday 14-Feb-2022 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review process
> to approve (click on Review Changes > Approve), rather than sending a "vote:
> yes" email reply that would be normal for a CFV.

Marked as reviewed by stefank (Reviewer).

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

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


From duke at openjdk.java.net  Mon Jan 31 14:23:17 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 31 Jan 2022 14:23:17 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
Message-ID: <2SkxCOa_V6nHyzep29ZEDo4QEOyuBIv2fhxNCgceLXc=.fb5a680c-74ec-4b13-9748-7b4d173fefe4@github.com>

On Mon, 24 Jan 2022 15:56:06 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 popframe failures

Can anyone give the CSR a review please? It's blocked on having a hotspot engineer review it.

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

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

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


From david.holmes at oracle.com  Mon Jan 31 22:10:43 2022
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Feb 2022 08:10:43 +1000
Subject: RFR: 8242181: [Linux] Show source information when printing
 native stack traces in hs_err files
In-Reply-To: <2vxIb1vN8LxdnG_zim6JI_RzovAOSLpJJMgxbgu1pnI=.f6cbbebc-2dc0-44ca-bd4b-4d6d3fc18b0f@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <2vxIb1vN8LxdnG_zim6JI_RzovAOSLpJJMgxbgu1pnI=.f6cbbebc-2dc0-44ca-bd4b-4d6d3fc18b0f@github.com>
Message-ID: <fa97b38d-44a7-dec7-503b-f0f29bcafcd7@oracle.com>

Hi Christian,

Sorry for the delay in coming back to this, I wanted to see what other 
feedback arose.

On 25/01/2022 7:43 pm, Christian Hagedorn wrote:
> Hi David
> 
>> This will be really useful - thank you. :)
> 
> I'm glad to hear that! :-) Thanks for your overall comments!
> 
>> All build file changes need to be seen by the build team.
> 
> Right, thanks for adding it again.
> 
>> That said I have two general concerns both related to executing non-async-signal-safe code in the signal handler via the error reporting logic. Now I know we already do a ton of stuff in error reporting not guaranteed (in any way) to be safe to do in a signal handler, but whenever we add something new I have to ask the question: how likely is this additional code to lead to secondary failures (hangs or crashes)?
> 
> That's a valid concern. I've also asked myself this question when I had initially started using some assertions. We should not crash again during error reporting. I've therefore tried to be as conservative as possible and added bailouts instead, also in loops when reading data. But of course, this is just a best effort and by no means a guarantee to be safe (especially in terms of crashes). What could be alternatives to make this better?

If the parsing code turns out to be very problematic in a signal 
handling context, then we could disable it in that context. So we really 
want to try and do a lot of testing by throwing random signals at the VM 
and see what breaks.

>> Secondly, on the same issue the use of unified logging within this code seems even more likely to be problematic - I'm not aware of us currently using UL during error reporting. It may work in basic usecases but if it triggers logfile rotation or other more complex actions what then?
> 
> I haven't thought about this before. To be honest, I think UL printing of the `dwarf` tag is only useful during development when adding something new to the parser or when debugging. I don't see much value of these messages otherwise - even less for a Java user. As a first step, I could change the logs from `log_X()` to `log_develop_X()` but that just shifts the problem to non-product builds. Another option (or additional thing) could be to guard the log messages with a new develop flag that's disabled by default. By setting it for development, we accept that it might be unsafe which should be fine.

I think changing the logging to develop only is a reasonable step. I 
don't see logging of crash handling / error reporting as generally 
useful for the end user.

Thanks,
David

> Thanks,
> Christian
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/7126


From dholmes at openjdk.java.net  Mon Jan 31 22:39:18 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 31 Jan 2022 22:39:18 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
Message-ID: <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>

On Mon, 24 Jan 2022 15:56:06 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 popframe failures

A few stylistic nits below. And one query.

Thanks,
David

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

> 121:           range(1, 99)                                                  \
> 122:   product(ccstr, UseBranchProtection, "none",                           \
> 123:           "Branch Protection to use: none,standard,pac-ret")            \

Nit: spaces after commas please.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5286:

> 5284: 
> 5285: void MacroAssembler::enter()
> 5286: {

Style nit: opening braces go on the same line as the function declaration.

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

> 415:     // Enable PAC if this code has been built with branch-protection and the CPU/OS supports it.
> 416: #ifdef __ARM_FEATURE_PAC_DEFAULT
> 417:     if (_features & CPU_PACA) {

Style nit: no implicit booleans - expand as "if ( A & B != 0)"

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

> 427: #else
> 428:     warning("UseROPProtection specified, but not supported in the VM.");
> 429: #endif

If we issue these warnings should `_rop_protection` still be set true?

src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 58:

> 56: 
> 57:   address return_address = *return_address_ptr;
> 58:   AARCH64_ONLY(return_address=pauth_strip_pointer(return_address));

Style nit: spaces around binary operators please. There are a couple of occurrences.

src/hotspot/share/runtime/frame.cpp line 1115:

> 1113:   AARCH64_ONLY(if (!pauth_ptr_is_raw(x)) {
> 1114:     return false;
> 1115:   })

Style nit: Use ifdef for multi-line code blocks.

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

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


From duke at openjdk.java.net  Mon Jan 31 22:52:16 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 31 Jan 2022 22:52:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v16]
In-Reply-To: <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@github.com>
 <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
Message-ID: <5p0-vTNNtM1PjqyT5PBcAdSH0kIe9RNEIIOnor8GVOk=.c6a168da-0a5f-453b-bf36-b69e9a2aa78f@github.com>

On Sat, 29 Jan 2022 05:58:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Changes macoss -> macosx in problem list
>>  - Refactors loadlib_aix: Removes redundant c++ class
>
> src/hotspot/os/aix/loadlib_aix.cpp line 116:
> 
>> 114: //   entry_t* next;
>> 115: //   loaded_module_t info;
>> 116: // };
> 
> please remove

Agreed. Thanks for catching this.

> src/hotspot/os/aix/os_perf_aix.cpp line 31:
> 
>> 29: #include "memory/resourceArea.hpp"
>> 30: #include "os_aix.inline.hpp"
>> 31: #include "precompiled.hpp"
> 
> precompiled.hpp must appear at the very top of the cpp file. The one exception from the "order includes alphabetically" rule. Oh, that, and people usually include system headers after hotspot ones.

? 

Also, since I'm thinking of it here. I ran without precompiled.hpp as you mentioned elsewhere. No issues detected.

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

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


From duke at openjdk.java.net  Mon Jan 31 22:58:17 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 31 Jan 2022 22:58:17 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v16]
In-Reply-To: <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@github.com>
 <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
Message-ID: <1mZ-Tz00l9COXSU32cTT_OwqWsMX5YJq_JTLdGPfq8s=.8a91af1d-1d8a-4445-931d-2c06f671fbca@github.com>

On Sat, 29 Jan 2022 06:09:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Changes macoss -> macosx in problem list
>>  - Refactors loadlib_aix: Removes redundant c++ class
>
> src/hotspot/os/aix/loadlib_aix.cpp line 326:
> 
>> 324: // Helper for copying loaded module info to external callers.
>> 325: // To avoid dangling pointers 'next' is set to null
>> 326: static bool copy_lm_to_external(const loaded_module_t* const from, loaded_module_t* to) {
> 
> So, just to understand, the point of this function is to handle to==NULL (from is never NULL) and to set next to NULL? 
> 
> I'd probably keep doing this inline in the two places where this happens, but I leave it up to you. If you think this is cleaner, its fine too.

The purpose was actually to work through a compiler error that cropped up when I changed loaded_module_t. It ended up being simple to fix, but I left the plumbing in. I agree this is not worth keeping around. Thanks for pointing this out.

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

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


From duke at openjdk.java.net  Mon Jan 31 23:10:14 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 31 Jan 2022 23:10:14 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v16]
In-Reply-To: <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@github.com>
 <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
Message-ID: <JqNKLgTRv6jNQMN1Ae9JHJNebmzt0rPql6JU9L6izs0=.e130d249-51dc-44f0-a147-2385bd81c996@github.com>

On Sat, 29 Jan 2022 06:30:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Changes macoss -> macosx in problem list
>>  - Refactors loadlib_aix: Removes redundant c++ class
>
> src/hotspot/os/aix/os_perf_aix.cpp line 72:
> 
>> 70: 
>> 71: static bool initialize_libperfstat() {
>> 72:   static bool is_libperfstat_loaded = false;
> 
> I don't think this is needed. libperfstat is initialized as part of os::init in os_aix.cpp.
> 
> https://github.com/openjdk/jdk/blob/d366d15d67a08833d93a5806edef8145cb7803e5/src/hotspot/os/aix/os_aix.cpp#L2999-L3008
> https://github.com/openjdk/jdk/blob/d366d15d67a08833d93a5806edef8145cb7803e5/src/hotspot/os/aix/os_aix.cpp#L2329-L2333
> 
> Should be already active at this point. Its functions are stubbed out in case the library cannot be loaded, so you should be able to call them in here, without an additional init check. You just have to handle the errors on the individual API calls, as if the real APIs returned errors. But you do this already I think.
> 
> Long term, if you think libperfstat should be always there, we can simplify things and treat libperfstat load errors as hard VM errors in release builds too. We already assert in `os::Aix::initialize_libperfstat()`. (Note: "assert" fires in debug builds (ASSERT macro), and "guarantee" fires in all builds).

Aha! I saw the definition of initialize_libperfstat(), but not that it was later called in os::init(). It did always feel strange to manually initialize libperfstat as I was doing. Thanks for pointing this out.

> src/hotspot/os/aix/os_perf_aix.cpp line 611:
> 
>> 609: 
>> 610:   // calling perfstat_<subsystem>(NULL, NULL, _, 0) returns number of available records
>> 611:   if ((n_records = libperfstat::perfstat_netinterface(NULL, NULL, sizeof(perfstat_netinterface_t), 0)) <= 0) {
> 
> is n=0 an error? Could there conceivably be zero interfaces?

Good point. I agree it's not reasonable to return an error if there are simply no network interfaces.

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

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