From duke at openjdk.java.net  Tue Feb  1 00:09:12 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 1 Feb 2022 00:09:12 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: <wFCT69pboMgiJx3_3ce-cdczm-kN5pNXFAjD-k4UwuY=.b17c1b4e-9347-425b-8f73-d070b6f30fdc@github.com>

On Sat, 29 Jan 2022 06:36:32 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 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.

Yeah, this was a bit of a gotcha during development (especially since NetworkInterface is different); I agree it's worth documenting.

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

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


From stuefe at openjdk.java.net  Tue Feb  1 05:57:10 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 1 Feb 2022 05:57:10 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files
In-Reply-To: <fa97b38d-44a7-dec7-503b-f0f29bcafcd7@oracle.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <fa97b38d-44a7-dec7-503b-f0f29bcafcd7@oracle.com>
Message-ID: <KaUCyMZ1dd4fp8zmUN9gJS_0_jOZWT21w6t_xQqB--E=.0bcd5768-660f-4ab5-a9a1-73b929d54ba3@github.com>

On Mon, 31 Jan 2022 22:12:30 GMT, David Holmes <david.holmes at oracle.com> wrote:

> > 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.
> 

Source information in hs-err file stacks can be tremendously useful. Lets try the retry-callstack-dumping without features idea in case of a secondary crash, outlined above, first.

> > > 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.

I think the right way to go longterm would be to give us a minimalistic safe logging API for these cases (signal handling, pre-initialization) or make UL safe to use always.

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

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


From duke at openjdk.java.net  Tue Feb  1 11:09:20 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Tue, 1 Feb 2022 11:09:20 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
Message-ID: <CMLktPRTckFYGJ2T5qnG4bMZ1Nz_zx87X-CvW5OBd8U=.8effa526-d736-4d81-9111-b607bfd91c33@github.com>

On Mon, 31 Jan 2022 22:35:35 GMT, David Holmes <dholmes 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/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?

As per this conversation: https://github.com/openjdk/jdk/pull/6334#discussion_r791722292

The idea was, the user is explicitly asking for asking for pac-ret so we should honour that. Whereas standard would only enable what is supported for that system.

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

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


From dholmes at openjdk.java.net  Tue Feb  1 12:45:12 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Feb 2022 12:45:12 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <CMLktPRTckFYGJ2T5qnG4bMZ1Nz_zx87X-CvW5OBd8U=.8effa526-d736-4d81-9111-b607bfd91c33@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
 <CMLktPRTckFYGJ2T5qnG4bMZ1Nz_zx87X-CvW5OBd8U=.8effa526-d736-4d81-9111-b607bfd91c33@github.com>
Message-ID: <NBdOT35ZQo_rb5t8H3OSHle_OGQEMlR_nsu2quY3PZA=.390b67c7-c532-41fa-9c12-87221d311c3e@github.com>

On Tue, 1 Feb 2022 11:05:46 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> 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?
>
> As per this conversation: https://github.com/openjdk/jdk/pull/6334#discussion_r791722292
> 
> The idea was, the user is explicitly asking for asking for pac-ret so we should honour that. Whereas standard would only enable what is supported for that system.

But we can't honour that because it is not supported. Further, the suggestion in the referenced discussion seemed to be based on the assumption that doing so would be harmless because it is NOP based, but you have indicated that may not be the case and so it may actually lead to a crash!

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

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


From duke at openjdk.java.net  Tue Feb  1 13:47:12 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Tue, 1 Feb 2022 13:47:12 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <NBdOT35ZQo_rb5t8H3OSHle_OGQEMlR_nsu2quY3PZA=.390b67c7-c532-41fa-9c12-87221d311c3e@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
 <CMLktPRTckFYGJ2T5qnG4bMZ1Nz_zx87X-CvW5OBd8U=.8effa526-d736-4d81-9111-b607bfd91c33@github.com>
 <NBdOT35ZQo_rb5t8H3OSHle_OGQEMlR_nsu2quY3PZA=.390b67c7-c532-41fa-9c12-87221d311c3e@github.com>
Message-ID: <igLdlFO5Kqt5hIOJuHH43frWNFF3HT6o6zfxEspSiZs=.4f03831b-26be-42ba-b2a7-591034105cb2@github.com>

On Tue, 1 Feb 2022 12:42:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As per this conversation: https://github.com/openjdk/jdk/pull/6334#discussion_r791722292
>> 
>> The idea was, the user is explicitly asking for asking for pac-ret so we should honour that. Whereas standard would only enable what is supported for that system.
>
> But we can't honour that because it is not supported. Further, the suggestion in the referenced discussion seemed to be based on the assumption that doing so would be harmless because it is NOP based, but you have indicated that may not be the case and so it may actually lead to a crash!

Before I change anything - @theRealAph you had an opinion here too...

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

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


From chagedorn at openjdk.java.net  Tue Feb  1 14:56:10 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 1 Feb 2022 14:56:10 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files
In-Reply-To: <fa97b38d-44a7-dec7-503b-f0f29bcafcd7@oracle.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <fa97b38d-44a7-dec7-503b-f0f29bcafcd7@oracle.com>
Message-ID: <E2hfGlG_BXtlyvoS-0ijMibFTv9aMd2L0_eKg3UD_4A=.6e26b041-9d95-4dca-a677-cf25dc32b047@github.com>

On Mon, 31 Jan 2022 22:12:30 GMT, David Holmes <david.holmes at oracle.com> wrote:

> Hi Christian,
> 
> Sorry for the delay in coming back to this, I wanted to see what other feedback arose.

No problem, thanks for your feedback David!

> > > 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.
> 
> Source information in hs-err file stacks can be tremendously useful. Lets try the retry-callstack-dumping without features idea in case of a secondary crash, outlined above, first.

Should we still handle that in a separate RFE later or should this go along with this patch/prerequisite? What do you think?

> > > > 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.
> 
> I think the right way to go longterm would be to give us a minimalistic safe logging API for these cases (signal handling, pre-initialization) or make UL safe to use always.

That would be ideal if UL usage could be made safe in the future for these cases. But as for now, I will start by changing the logging to develop to limit UL usage to debug builds only which does not affect end users anymore.

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

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


From aph at openjdk.java.net  Tue Feb  1 18:38:21 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 1 Feb 2022 18:38:21 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
Message-ID: <HbfthVhtbYa9SGgArnj2xCzFv0BfPb6dZ87Wz6pcUoM=.12208f6b-db6e-4b83-8e8d-e5b4c406fff7@github.com>

On Mon, 31 Jan 2022 22:25:38 GMT, David Holmes <dholmes 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/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)"

Oh yuck, really? This is my punishment for not paying attention to the style guide dicussions.

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

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


From aph at openjdk.java.net  Tue Feb  1 18:38:21 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 1 Feb 2022 18:38:21 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <NBdOT35ZQo_rb5t8H3OSHle_OGQEMlR_nsu2quY3PZA=.390b67c7-c532-41fa-9c12-87221d311c3e@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
 <CMLktPRTckFYGJ2T5qnG4bMZ1Nz_zx87X-CvW5OBd8U=.8effa526-d736-4d81-9111-b607bfd91c33@github.com>
 <NBdOT35ZQo_rb5t8H3OSHle_OGQEMlR_nsu2quY3PZA=.390b67c7-c532-41fa-9c12-87221d311c3e@github.com>
Message-ID: <K0ktVZTFjc9Gpij2CBsFjqzxIYLoRy2YRxYmzbGjV_o=.0731f464-b456-4160-b090-d6432038ecdd@github.com>

On Tue, 1 Feb 2022 12:42:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As per this conversation: https://github.com/openjdk/jdk/pull/6334#discussion_r791722292
>> 
>> The idea was, the user is explicitly asking for asking for pac-ret so we should honour that. Whereas standard would only enable what is supported for that system.
>
> But we can't honour that because it is not supported. Further, the suggestion in the referenced discussion seemed to be based on the assumption that doing so would be harmless because it is NOP based, but you have indicated that may not be the case and so it may actually lead to a crash!

Given that the implementation has now changed so much that it's no longer NOP based, I'll go with @dholmes-ora .
One other thing, though: it might be better to say here "but this VM was built without ROP-protection support." That's more informative, IMO.

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

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


From duke at openjdk.java.net  Tue Feb  1 21:36:58 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 1 Feb 2022 21:36:58 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: <ojkdO_C32KnPz5oGH416vlYpLg7Tg8nJmLex62oYmcw=.bfb7e570-5adc-4669-9ed7-ffad775c203c@github.com>

On Sat, 29 Jan 2022 06:51:59 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 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.

I made the change in (1) as recommended.

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

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


From duke at openjdk.java.net  Tue Feb  1 21:36:56 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 1 Feb 2022 21:36:56 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v17]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ?
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

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

  Addresses issues from review and other sm fixes
  
  - Adds commenting in regards to memory handling by SystemProcess &
  NetworkInterface classes
  - Replaces explicit initialization and copy of structs with memcpy
  and memset as appropriate
  - Renames internal struct definitions in os_perf_aix
  - Other minor fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/08837098..3618a77d

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

  Stats: 108 lines in 2 files changed: 19 ins; 56 del; 33 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 dev at kb6.ee  Wed Feb  2 05:01:06 2022
From: dev at kb6.ee (Abigail G)
Date: Wed, 02 Feb 2022 00:01:06 -0500
Subject: Segfault when building openjdk13 with openjdk12
Message-ID: <d8ebcbf69663bfcf233efebcd477427a7e935582.camel@kb6.ee>

Hello,

I'm working on packaging several openjdk versions for Void Linux.

When I build jdk13 with jdk12 as the boot jdk, I get a segfault very
soon into the build. I am not a java developer, so I'm not quite sure
what to make of the log, trace, and core dump. Anyone have any ideas?

Interestingly, when I repeatedly restart the build without removing any
of the partially-built state, it eventually succeeds (usually after 1-3
retries), and I have been able to use the result to build jdk14 without
issue.

I've attached a .zip with the relevant build logs, hotspot error log,
and core dump (if that doesn't work:?https://0x0.st/oHxe.zip).

The scripts I'm using to build jdk12 and 13 are available here:
https://github.com/classabbyamp/void-packages/blob/openjdk17/srcpkgs/openjdk12-bootstrap/template
https://github.com/classabbyamp/void-packages/blob/openjdk17/srcpkgs/openjdk13-bootstrap/template

TIA,

Abigail G


From david.holmes at oracle.com  Wed Feb  2 05:48:58 2022
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 2 Feb 2022 15:48:58 +1000
Subject: Segfault when building openjdk13 with openjdk12
In-Reply-To: <d8ebcbf69663bfcf233efebcd477427a7e935582.camel@kb6.ee>
References: <d8ebcbf69663bfcf233efebcd477427a7e935582.camel@kb6.ee>
Message-ID: <ac7ad1e4-1d0b-c3ae-6ef1-f69f4c8d4762@oracle.com>

Hi Abigail,

On 2/02/2022 3:01 pm, Abigail G wrote:
> Hello,
> 
> I'm working on packaging several openjdk versions for Void Linux.
> 
> When I build jdk13 with jdk12 as the boot jdk, I get a segfault very
> soon into the build. I am not a java developer, so I'm not quite sure
> what to make of the log, trace, and core dump. Anyone have any ideas?

Could just be a bug in 12, fixed later.

> Interestingly, when I repeatedly restart the build without removing any
> of the partially-built state, it eventually succeeds (usually after 1-3
> retries), and I have been able to use the result to build jdk14 without
> issue.
> 
> I've attached a .zip with the relevant build logs, hotspot error log,
> and core dump (if that doesn't work:?https://0x0.st/oHxe.zip).

The mailing list strips attachments and the link to the zip file gave a 
file with a single empty directory in it - no logs.

Cheers,
David

> The scripts I'm using to build jdk12 and 13 are available here:
> https://github.com/classabbyamp/void-packages/blob/openjdk17/srcpkgs/openjdk12-bootstrap/template
> https://github.com/classabbyamp/void-packages/blob/openjdk17/srcpkgs/openjdk13-bootstrap/template
> 
> TIA,
> 
> Abigail G


From dev at kb6.ee  Wed Feb  2 05:53:30 2022
From: dev at kb6.ee (Abigail G)
Date: Wed, 02 Feb 2022 00:53:30 -0500
Subject: Segfault when building openjdk13 with openjdk12
In-Reply-To: <ac7ad1e4-1d0b-c3ae-6ef1-f69f4c8d4762@oracle.com>
References: <d8ebcbf69663bfcf233efebcd477427a7e935582.camel@kb6.ee>
 <ac7ad1e4-1d0b-c3ae-6ef1-f69f4c8d4762@oracle.com>
Message-ID: <8cb1205d174f96dc72596a2d9eceb868776413b9.camel@kb6.ee>

On Wed, 2022-02-02 at 15:48 +1000, David Holmes wrote:
> Hi Abigail,
> 
> On 2/02/2022 3:01 pm, Abigail G wrote:
> > Hello,
> > 
> > I'm working on packaging several openjdk versions for Void Linux.
> > 
> > When I build jdk13 with jdk12 as the boot jdk, I get a segfault
> > very
> > soon into the build. I am not a java developer, so I'm not quite
> > sure
> > what to make of the log, trace, and core dump. Anyone have any
> > ideas?
> 
> Could just be a bug in 12, fixed later.
> 
> > Interestingly, when I repeatedly restart the build without removing
> > any
> > of the partially-built state, it eventually succeeds (usually after
> > 1-3
> > retries), and I have been able to use the result to build jdk14
> > without
> > issue.
> > 
> > I've attached a .zip with the relevant build logs, hotspot error
> > log,
> > and core dump (if that doesn't work:?https://0x0.st/oHxe.zip).
> 
> The mailing list strips attachments and the link to the zip file gave
> a 
> file with a single empty directory in it - no logs.
> 
> Cheers,
> David
> 
> > The scripts I'm using to build jdk12 and 13 are available here:
> > https://github.com/classabbyamp/void-packages/blob/openjdk17/srcpkgs/openjdk12-bootstrap/template
> > https://github.com/classabbyamp/void-packages/blob/openjdk17/srcpkgs/openjdk13-bootstrap/template
> > 
> > TIA,
> > 
> > Abigail G

Whoops, looks like I made the zip wrong, this one should work:
https://0x0.st/oHxy.zip

Abigail G


From david.holmes at oracle.com  Wed Feb  2 07:18:48 2022
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 2 Feb 2022 17:18:48 +1000
Subject: Segfault when building openjdk13 with openjdk12
In-Reply-To: <8cb1205d174f96dc72596a2d9eceb868776413b9.camel@kb6.ee>
References: <d8ebcbf69663bfcf233efebcd477427a7e935582.camel@kb6.ee>
 <ac7ad1e4-1d0b-c3ae-6ef1-f69f4c8d4762@oracle.com>
 <8cb1205d174f96dc72596a2d9eceb868776413b9.camel@kb6.ee>
Message-ID: <e2f55b17-5009-5fd9-a20c-012873d6086f@oracle.com>

On 2/02/2022 3:53 pm, Abigail G wrote:
> On Wed, 2022-02-02 at 15:48 +1000, David Holmes wrote:
>> Hi Abigail,
>>
>> On 2/02/2022 3:01 pm, Abigail G wrote:
>>> Hello,
>>>
>>> I'm working on packaging several openjdk versions for Void Linux.
>>>
>>> When I build jdk13 with jdk12 as the boot jdk, I get a segfault
>>> very
>>> soon into the build. I am not a java developer, so I'm not quite
>>> sure
>>> what to make of the log, trace, and core dump. Anyone have any
>>> ideas?
>>
>> Could just be a bug in 12, fixed later.
>>
>>> Interestingly, when I repeatedly restart the build without removing
>>> any
>>> of the partially-built state, it eventually succeeds (usually after
>>> 1-3
>>> retries), and I have been able to use the result to build jdk14
>>> without
>>> issue.
>>>
>>> I've attached a .zip with the relevant build logs, hotspot error
>>> log,
>>> and core dump (if that doesn't work:?https://0x0.st/oHxe.zip).
>>
>> The mailing list strips attachments and the link to the zip file gave
>> a
>> file with a single empty directory in it - no logs.
>>
>> Cheers,
>> David
>>
>>> The scripts I'm using to build jdk12 and 13 are available here:
>>> https://github.com/classabbyamp/void-packages/blob/openjdk17/srcpkgs/openjdk12-bootstrap/template
>>> https://github.com/classabbyamp/void-packages/blob/openjdk17/srcpkgs/openjdk13-bootstrap/template
>>>
>>> TIA,
>>>
>>> Abigail G
> 
> Whoops, looks like I made the zip wrong, this one should work:
> https://0x0.st/oHxy.zip

Unfortunately no symbolic info in the hs-err file so nothing to go on.

All I can suggest is that you build the latest 12u to use to bootstrap 
the latest 13u etc.

Cheers,
David

> Abigail G


From stuefe at openjdk.java.net  Wed Feb  2 09:02:16 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 2 Feb 2022 09:02:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v17]
In-Reply-To: <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>
Message-ID: <KbIKws5G7jt2cpb8X5ao5foDkDHmc4iBB05ge-ArPbA=.e8ca77a2-56d4-4fd5-8ade-278102f38944@github.com>

On Tue, 1 Feb 2022 21:36: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 one additional commit since the last revision:
> 
>   Addresses issues from review and other sm fixes
>   
>   - Adds commenting in regards to memory handling by SystemProcess &
>   NetworkInterface classes
>   - Replaces explicit initialization and copy of structs with memcpy
>   and memset as appropriate
>   - Renames internal struct definitions in os_perf_aix
>   - Other minor fixes

Looks good to me now. 

Can you now use JFR/JMC on AIX with this patch or is further work needed?

Thanks for doing this!

Cheers, Thomas

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

Marked as reviewed by stuefe (Reviewer).

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


From shade at redhat.com  Wed Feb  2 09:12:23 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 2 Feb 2022 12:12:23 +0300
Subject: Segfault when building openjdk13 with openjdk12
In-Reply-To: <8cb1205d174f96dc72596a2d9eceb868776413b9.camel@kb6.ee>
References: <d8ebcbf69663bfcf233efebcd477427a7e935582.camel@kb6.ee>
 <ac7ad1e4-1d0b-c3ae-6ef1-f69f4c8d4762@oracle.com>
 <8cb1205d174f96dc72596a2d9eceb868776413b9.camel@kb6.ee>
Message-ID: <21252d0d-f6bf-2f09-20c3-e7240b973f64@redhat.com>

On 2/2/22 08:53, Abigail G wrote:
> Whoops, looks like I made the zip wrong, this one should work:
> https://0x0.st/oHxy.zip

So it looks like a GC crash:

#  SIGSEGV (0xb) at pc=0x00007fa2ba719208, pid=29539, tid=29557

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000100

Current thread (0x00007fa2b4091800):  GCTaskThread "GC Thread#0" [stack: 
0x00007fa2b8c10000,0x00007fa2b8d10000] [id=29557]


If I was stuck with issue like this, I'll try the following:

  *) Test the memory. Memory problems frequently manifest as GC bugs:
    https://shipilev.net/jvm/test-your-memory/

  *) Use fastdebug JDK as the boot JDK, looking for a reasonable assert instead of anonymous crash. 
This probably requires building it first after configuring using --with-debug-level=fastdebug. You 
said the build eventually succeeds, so a few tries might be in order.

  *) Bootstrap JDK 13 build with JDK 13. AFAICS, the actual requirement for boot JDK is 12..13.

Regardless, even if you find a bug in JDK 12, it is unlikely to get fixed, as no one maintains JDK 
12. Azul maintains JDK 13, so depending on your luck of identifying the issue with JDK 13, I'd say 
fixing JDK 13 might be possible.

-- 
Thanks,
-Aleksey



From mdoerr at openjdk.java.net  Wed Feb  2 09:18:16 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 2 Feb 2022 09:18:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v17]
In-Reply-To: <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>
Message-ID: <Nmh1kOvrUKgzzJi8STmXXct8jVFPot1C4IzrGZdwIrw=.a5df2577-e585-439b-bded-09bf91950fc4@github.com>

On Tue, 1 Feb 2022 21:36: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 one additional commit since the last revision:
> 
>   Addresses issues from review and other sm fixes
>   
>   - Adds commenting in regards to memory handling by SystemProcess &
>   NetworkInterface classes
>   - Replaces explicit initialization and copy of structs with memcpy
>   and memset as appropriate
>   - Renames internal struct definitions in os_perf_aix
>   - Other minor fixes

Please don't forget src/hotspot/os_cpu/linux_ppc/thread_linux_ppc.cpp update https://github.com/openjdk/jdk/commit/f37bfeadcf036a75defc64ad7f4a9f5596cd7407

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

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


From duke at openjdk.java.net  Wed Feb  2 09:28:48 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Wed, 2 Feb 2022 09:28:48 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v15]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <3RcA40D5i_vhwGr49mD78aBNsaLjV_d13kEsTuL9S5I=.1d9d6d4a-a055-47b1-ae6f-41c26d1fae76@github.com>

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

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

  Fix up nits

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/0b476542..b7925614

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

  Stats: 15 lines in 6 files changed: 2 ins; 3 del; 10 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  Wed Feb  2 09:32:14 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Wed, 2 Feb 2022 09:32:14 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <K0ktVZTFjc9Gpij2CBsFjqzxIYLoRy2YRxYmzbGjV_o=.0731f464-b456-4160-b090-d6432038ecdd@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
 <CMLktPRTckFYGJ2T5qnG4bMZ1Nz_zx87X-CvW5OBd8U=.8effa526-d736-4d81-9111-b607bfd91c33@github.com>
 <NBdOT35ZQo_rb5t8H3OSHle_OGQEMlR_nsu2quY3PZA=.390b67c7-c532-41fa-9c12-87221d311c3e@github.com>
 <K0ktVZTFjc9Gpij2CBsFjqzxIYLoRy2YRxYmzbGjV_o=.0731f464-b456-4160-b090-d6432038ecdd@github.com>
Message-ID: <L0_01FsEw9Xxj4aEz-9CTmfrE5D9VVElO8vhzdu7pQA=.7504284f-5c17-4d8d-849c-3ba24bfc6b92@github.com>

On Tue, 1 Feb 2022 18:33:28 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> But we can't honour that because it is not supported. Further, the suggestion in the referenced discussion seemed to be based on the assumption that doing so would be harmless because it is NOP based, but you have indicated that may not be the case and so it may actually lead to a crash!
>
> Given that the implementation has now changed so much that it's no longer NOP based, I'll go with @dholmes-ora .
> One other thing, though: it might be better to say here "but this VM was built without ROP-protection support." That's more informative, IMO.

Ok, I'll fix up as suggested.

The beginning part of that message needs fixing too - UseROPProtection is no longer the name of the flag. I'll switch to:
"ROP-protection specified, but this VM was built without ROP-protection support."

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

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


From duke at openjdk.java.net  Wed Feb  2 09:37:15 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Wed, 2 Feb 2022 09:37:15 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <L0_01FsEw9Xxj4aEz-9CTmfrE5D9VVElO8vhzdu7pQA=.7504284f-5c17-4d8d-849c-3ba24bfc6b92@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
 <CMLktPRTckFYGJ2T5qnG4bMZ1Nz_zx87X-CvW5OBd8U=.8effa526-d736-4d81-9111-b607bfd91c33@github.com>
 <NBdOT35ZQo_rb5t8H3OSHle_OGQEMlR_nsu2quY3PZA=.390b67c7-c532-41fa-9c12-87221d311c3e@github.com>
 <K0ktVZTFjc9Gpij2CBsFjqzxIYLoRy2YRxYmzbGjV_o=.0731f464-b456-4160-b090-d6432038ecdd@github.com>
 <L0_01FsEw9Xxj4aEz-9CTmfrE5D9VVElO8vhzdu7pQA=.7504284f-5c17-4d8d-849c-3ba24bfc6b92@github.com>
Message-ID: <oiqgcS6gDWPTBxG8KmAaDjswmAQ0Jl5rEuVtoQJKlRo=.fdf20545-05bb-45fb-bad8-d2ca244880e8@github.com>

On Wed, 2 Feb 2022 09:29:21 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> Given that the implementation has now changed so much that it's no longer NOP based, I'll go with @dholmes-ora .
>> One other thing, though: it might be better to say here "but this VM was built without ROP-protection support." That's more informative, IMO.
>
> Ok, I'll fix up as suggested.
> 
> The beginning part of that message needs fixing too - UseROPProtection is no longer the name of the flag. I'll switch to:
> "ROP-protection specified, but this VM was built without ROP-protection support."

And this change will keep ROP protection enabled if we fall into the "this VM was built without ROP-protection support.". In that case we'll be protecting generated code, but the VM itself won't be protected. This will run without crashing.

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

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


From aph at openjdk.java.net  Wed Feb  2 10:22:13 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 2 Feb 2022 10:22:13 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <oiqgcS6gDWPTBxG8KmAaDjswmAQ0Jl5rEuVtoQJKlRo=.fdf20545-05bb-45fb-bad8-d2ca244880e8@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
 <CMLktPRTckFYGJ2T5qnG4bMZ1Nz_zx87X-CvW5OBd8U=.8effa526-d736-4d81-9111-b607bfd91c33@github.com>
 <NBdOT35ZQo_rb5t8H3OSHle_OGQEMlR_nsu2quY3PZA=.390b67c7-c532-41fa-9c12-87221d311c3e@github.com>
 <K0ktVZTFjc9Gpij2CBsFjqzxIYLoRy2YRxYmzbGjV_o=.0731f464-b456-4160-b090-d6432038ecdd@github.com>
 <L0_01FsEw9Xxj4aEz-9CTmfrE5D9VVElO8vhzdu7pQA=.7504284f-5c17-4d8d-849c-3ba24bfc6b92@github.com>
 <oiqgcS6gDWPTBxG8KmAaDjswmAQ0Jl5rEuVtoQJKlRo=.fdf20545-05bb-45fb-bad8-d2ca244880e8@github.com>
Message-ID: <Y73LvR7JcG4SUXZllgPQLmDeElg1XgEyzZCNLLWglw0=.43ea398e-ace9-45e1-97e3-d020adad51fb@github.com>

On Wed, 2 Feb 2022 09:34:20 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> And this change will keep ROP protection enabled if we fall into the "this VM was built without ROP-protection support.". In that case we'll be protecting generated code, but the VM itself won't be protected. This will run without crashing.

That's perfect.

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

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


From duke at openjdk.java.net  Wed Feb  2 13:55:42 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Wed, 2 Feb 2022 13:55:42 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v16]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <QE5OEfpY-HbXrbkbfUkOrr8ZQoJKv91RGp66VoGM9hE=.c81de446-7f0c-4976-a335-299befb8595a@github.com>

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

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

  Change pac-ret defaults on non PAC machines

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/b7925614..78da1bd0

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

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

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


From duke at openjdk.java.net  Wed Feb  2 16:03:48 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Wed, 2 Feb 2022 16:03:48 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v17]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <52o8K8q5wBP4HgBI3AljysgeR6tbogiOtQYu0VhWOAA=.80d5b306-f67f-4a87-836f-44bdbb0713f1@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:

  Update copyrights to 2022

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/78da1bd0..6255d4c8

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

  Stats: 16 lines in 16 files changed: 0 ins; 0 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  Wed Feb  2 16:30:56 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 2 Feb 2022 16:30:56 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v18]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@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:

  Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/3618a77d..4ab28477

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

  Stats: 8 lines in 1 file changed: 2 ins; 2 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 duke at openjdk.java.net  Wed Feb  2 16:30:59 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 2 Feb 2022 16:30:59 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v13]
In-Reply-To: <AHgTd1B4suatGGDI5s3L3k12Y9SekLMpwMtu5aR8g8E=.6fd22c94-f0c4-4c4f-a7ba-c3edf9921d79@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <BYYFJseyaER7rP7ni6tMgPoSvWBn--qr-Xv2bkXkDLA=.ecd6ba16-88e5-458c-9203-a715ba69ba3a@github.com>
 <AHgTd1B4suatGGDI5s3L3k12Y9SekLMpwMtu5aR8g8E=.6fd22c94-f0c4-4c4f-a7ba-c3edf9921d79@github.com>
Message-ID: <iu1oFn1FEGk5-3qblw4DejFig0QpN4e3wkgjPSJGoLw=.d3bc84e0-36cf-40e8-8d07-34e02b8c80aa@github.com>

On Fri, 21 Jan 2022 22:48:20 GMT, Martin Doerr <mdoerr 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.
>
> src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp line 63:
> 
>> 61: 
>> 62:     if (ret_frame.pc() == NULL) {
>> 63:       // ucontext wasn't useful
> 
> Null check has been moved before frame constructor in head revision.

Thanks for the reminder. I made this change in a recent push.

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

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


From mdoerr at openjdk.java.net  Wed Feb  2 17:20:17 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 2 Feb 2022 17:20:17 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v18]
In-Reply-To: <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@github.com>
Message-ID: <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>

On Wed, 2 Feb 2022 16:30: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 one additional commit since the last revision:
> 
>   Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler

Thanks for the update. As David had written, the Oracle Copyright lines you have added are not correct: "Copyright (c) 2022, 2022". I suggest to avoid adding new lines for this change until the topic is clarified.

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

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


From duke at openjdk.java.net  Wed Feb  2 22:42:48 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 2 Feb 2022 22:42:48 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v18]
In-Reply-To: <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@github.com>
 <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>
Message-ID: <6ol-wPa7GrBaEpVwy2Pqx547qDZ3iCv28itzlLksc1Q=.76921069-30a7-42db-9c7c-dc65d1876418@github.com>

On Wed, 2 Feb 2022 17:17:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks for the update. As David had written, the Oracle Copyright lines you have added are not correct: "Copyright (c) 2022, 2022". I suggest to avoid adding new lines for this change until the topic is clarified.

Agreed. I have removed the incorrect header line and will add a new one when I receive clarification.

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

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


From duke at openjdk.java.net  Wed Feb  2 22:42:47 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 2 Feb 2022 22:42:47 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@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:

  Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/4ab28477..0551e65e

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

  Stats: 3 lines in 3 files changed: 0 ins; 3 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 dholmes at openjdk.java.net  Thu Feb  3 01:56:15 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 3 Feb 2022 01:56:15 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v14]
In-Reply-To: <Y73LvR7JcG4SUXZllgPQLmDeElg1XgEyzZCNLLWglw0=.43ea398e-ace9-45e1-97e3-d020adad51fb@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <B0Uq8FlB1tzZYgPGJuiKFlBwYtLOyfZDvKg-c92S7ss=.726cf230-373a-4afe-b37b-8fe977f9d8b3@github.com>
 <cZrItxwKFe8rg7-UPKcdI0IN4LbCe9EjVoRg_mli4v4=.ed7993a7-9ba1-40e3-84fa-b9b671352dc5@github.com>
 <CMLktPRTckFYGJ2T5qnG4bMZ1Nz_zx87X-CvW5OBd8U=.8effa526-d736-4d81-9111-b607bfd91c33@github.com>
 <NBdOT35ZQo_rb5t8H3OSHle_OGQEMlR_nsu2quY3PZA=.390b67c7-c532-41fa-9c12-87221d311c3e@github.com>
 <K0ktVZTFjc9Gpij2CBsFjqzxIYLoRy2YRxYmzbGjV_o=.0731f464-b456-4160-b090-d6432038ecdd@github.com>
 <L0_01FsEw9Xxj4aEz-9CTmfrE5D9VVElO8vhzdu7pQA=.7504284f-5c17-4d8d-849c-3ba24bfc6b92@github.com>
 <oiqgcS6gDWPTBxG8KmAaDjswmAQ0Jl5rEuVtoQJKlRo=.fdf20545-05bb-45fb-bad8-d2ca244880e8@github.com>
 <Y73LvR7JcG4SUXZllgPQLmDeElg1XgEyzZCNLLWglw0=.43ea398e-ace9-45e1-97e3-d020adad51fb@github.com>
Message-ID: <hVRM-YVODZ6u6cs-_Y4CRjxbcLehu-a_6M5tVArNd3I=.b0180f0a-2ba6-42cd-adc8-dc492ae09f0f@github.com>

On Wed, 2 Feb 2022 10:18:38 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> And this change will keep ROP protection enabled if we fall into the "this VM was built without ROP-protection support.". In that case we'll be protecting generated code, but the VM itself won't be protected. This will run without crashing.
>
>> And this change will keep ROP protection enabled if we fall into the "this VM was built without ROP-protection support.". In that case we'll be protecting generated code, but the VM itself won't be protected. This will run without crashing.
> 
> That's perfect.

Okay, that makes sense. Thanks.

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

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


From mdoerr at openjdk.java.net  Thu Feb  3 11:17:16 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 3 Feb 2022 11:17:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
Message-ID: <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>

On Wed, 2 Feb 2022 22:42:47 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:
> 
>   Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp

Looks good to me, too. I think it is ready for integration assuming all change requests were taken care of and tests have passed.

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

Marked as reviewed by mdoerr (Reviewer).

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


From stuefe at openjdk.java.net  Thu Feb  3 11:25:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 3 Feb 2022 11:25:15 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
 <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>
Message-ID: <WNVSezqF2f-7JUgyAm84PmtU1EVRPF0KJPALz_qNYM8=.376c4ede-9d09-4d6f-85dc-af043a4eeacf@github.com>

On Thu, 3 Feb 2022 11:14:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Looks good to me, too. I think it is ready for integration assuming all change requests were taken care of and tests have passed.

@TheRealMDoerr we should test the latest version of this patch in our nightlies, just in case

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

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


From duke at openjdk.java.net  Thu Feb  3 12:14:18 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 3 Feb 2022 12:14:18 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v17]
In-Reply-To: <52o8K8q5wBP4HgBI3AljysgeR6tbogiOtQYu0VhWOAA=.80d5b306-f67f-4a87-836f-44bdbb0713f1@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <52o8K8q5wBP4HgBI3AljysgeR6tbogiOtQYu0VhWOAA=.80d5b306-f67f-4a87-836f-44bdbb0713f1@github.com>
Message-ID: <HaDwxAQNR0HLLvJCkKM0opQ85gzYUtSTZPOWjdDzddY=.53a2527b-6b8f-43bb-b4bf-2e328e313384@github.com>

On Wed, 2 Feb 2022 16:03:48 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:
> 
>   Update copyrights to 2022

As mentioned on the CSR, the JEP is being dropped - unless anyone has any objections.
JDK-8277204 will become a normal RFE.

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

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


From ihse at openjdk.java.net  Thu Feb  3 12:56:12 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 3 Feb 2022 12:56:12 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v4]
In-Reply-To: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
Message-ID: <2lh5MBJu9m7qiiF27rVWF94Jq8Pt3PVco7TCDBdWpDo=.21274feb-d77c-4fd0-84cc-2493fb1de274@github.com>

> 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.

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

 - Merge branch 'master' into improve-adhoc-version-string
 - IS_EMPTY define did not work on msvc
 - Break long lines
 - Skip setting git branch in adhoc version opt
 - Fix for abtract_vm_version so it really handles empty VERSION_BUILD
 - 8274980: Improve adhoc build version strings

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6152/files
  - new: https://git.openjdk.java.net/jdk/pull/6152/files/3c93c740..0954dd55

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

  Stats: 999707 lines in 3982 files changed: 531148 ins; 444662 del; 23897 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6152/head:pull/6152

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


From aph at openjdk.java.net  Thu Feb  3 13:05:12 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 3 Feb 2022 13:05:12 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v17]
In-Reply-To: <HaDwxAQNR0HLLvJCkKM0opQ85gzYUtSTZPOWjdDzddY=.53a2527b-6b8f-43bb-b4bf-2e328e313384@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <52o8K8q5wBP4HgBI3AljysgeR6tbogiOtQYu0VhWOAA=.80d5b306-f67f-4a87-836f-44bdbb0713f1@github.com>
 <HaDwxAQNR0HLLvJCkKM0opQ85gzYUtSTZPOWjdDzddY=.53a2527b-6b8f-43bb-b4bf-2e328e313384@github.com>
Message-ID: <_Bbro08HLFKOtrG9jBdy9s3W6FOgeqZkh0_Sttkm8EM=.a7080cfc-2c89-434b-9898-4f9e1ceb4817@github.com>

On Thu, 3 Feb 2022 12:11:16 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> As mentioned on the CSR, the JEP is being dropped - unless anyone has any objections. JDK-8277204 will become a normal RFE.

Good decision.

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

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


From duke at openjdk.java.net  Thu Feb  3 16:51:50 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 3 Feb 2022 16:51:50 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v17]
In-Reply-To: <52o8K8q5wBP4HgBI3AljysgeR6tbogiOtQYu0VhWOAA=.80d5b306-f67f-4a87-836f-44bdbb0713f1@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <52o8K8q5wBP4HgBI3AljysgeR6tbogiOtQYu0VhWOAA=.80d5b306-f67f-4a87-836f-44bdbb0713f1@github.com>
Message-ID: <Dok0bE7QDan5hdeiCnuctzvNFc4KC1bAw7uegPTpb7s=.92e247fe-ec36-4a1c-9055-7d1986514d86@github.com>

On Wed, 2 Feb 2022 16:03:48 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:
> 
>   Update copyrights to 2022

As requested in the RFE, added the new flag to the man page. Also updated the building.md instructions.

However, I'm not sure how to add to the release notes - I can't find any files or a process.

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

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


From duke at openjdk.java.net  Thu Feb  3 16:51:48 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 3 Feb 2022 16:51:48 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v18]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@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:

  Documentation updates

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/6255d4c8..d97883b5

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

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

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


From dev at kb6.ee  Thu Feb  3 17:31:14 2022
From: dev at kb6.ee (Abigail G)
Date: Thu, 03 Feb 2022 12:31:14 -0500
Subject: Segfault when building openjdk13 with openjdk12
In-Reply-To: <21252d0d-f6bf-2f09-20c3-e7240b973f64@redhat.com>
References: <d8ebcbf69663bfcf233efebcd477427a7e935582.camel@kb6.ee>
 <ac7ad1e4-1d0b-c3ae-6ef1-f69f4c8d4762@oracle.com>
 <8cb1205d174f96dc72596a2d9eceb868776413b9.camel@kb6.ee>
 <21252d0d-f6bf-2f09-20c3-e7240b973f64@redhat.com>
Message-ID: <7d9a4f03a7df135b61bab0910ed6bf08ec841603.camel@kb6.ee>

On Wed, 2022-02-02 at 12:12 +0300, Aleksey Shipilev wrote:
> On 2/2/22 08:53, Abigail G wrote:
> > Whoops, looks like I made the zip wrong, this one should work:
> > https://0x0.st/oHxy.zip
> 
> So it looks like a GC crash:
> 
> #? SIGSEGV (0xb) at pc=0x00007fa2ba719208, pid=29539, tid=29557
> 
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x0000000000000100
> 
> Current thread (0x00007fa2b4091800):? GCTaskThread "GC Thread#0"
> [stack: 
> 0x00007fa2b8c10000,0x00007fa2b8d10000] [id=29557]
> 
> 
> If I was stuck with issue like this, I'll try the following:
> 
> ? *) Test the memory. Memory problems frequently manifest as GC bugs:
> ??? https://shipilev.net/jvm/test-your-memory/

Can confirm it's not memory, I was able to reproduce it on another
machine.

> 
> ? *) Use fastdebug JDK as the boot JDK, looking for a reasonable
> assert instead of anonymous crash. 
> This probably requires building it first after configuring using --
> with-debug-level=fastdebug. You 
> said the build eventually succeeds, so a few tries might be in order.

Will try this.

> 
> ? *) Bootstrap JDK 13 build with JDK 13. AFAICS, the actual
> requirement for boot JDK is 12..13.

The problem with this is jdk13 doesn't exist yet in void, so we have to
do a bootstrap chain up from 11 (the latest version packaged).

> Regardless, even if you find a bug in JDK 12, it is unlikely to get
> fixed, as no one maintains JDK 
> 12. Azul maintains JDK 13, so depending on your luck of identifying
> the issue with JDK 13, I'd say 
> fixing JDK 13 might be possible.
> 

Thanks for the tips!

Abigail G


From dev at kb6.ee  Thu Feb  3 17:55:37 2022
From: dev at kb6.ee (Abigail G)
Date: Thu, 03 Feb 2022 12:55:37 -0500
Subject: Segfault when building openjdk13 with openjdk12
In-Reply-To: <7d9a4f03a7df135b61bab0910ed6bf08ec841603.camel@kb6.ee>
References: <d8ebcbf69663bfcf233efebcd477427a7e935582.camel@kb6.ee>
 <ac7ad1e4-1d0b-c3ae-6ef1-f69f4c8d4762@oracle.com>
 <8cb1205d174f96dc72596a2d9eceb868776413b9.camel@kb6.ee>
 <21252d0d-f6bf-2f09-20c3-e7240b973f64@redhat.com>
 <7d9a4f03a7df135b61bab0910ed6bf08ec841603.camel@kb6.ee>
Message-ID: <16da107fb08fac1be66d03a9354adb15b02b95d3.camel@kb6.ee>

On Thu, 2022-02-03 at 12:31 -0500, Abigail G wrote:
> On Wed, 2022-02-02 at 12:12 +0300, Aleksey Shipilev wrote:
> > On 2/2/22 08:53, Abigail G wrote:
> > > Whoops, looks like I made the zip wrong, this one should work:
> > > https://0x0.st/oHxy.zip
> > 
> > So it looks like a GC crash:
> > 
> > #? SIGSEGV (0xb) at pc=0x00007fa2ba719208, pid=29539, tid=29557
> > 
> > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> > 0x0000000000000100
> > 
> > Current thread (0x00007fa2b4091800):? GCTaskThread "GC Thread#0"
> > [stack: 
> > 0x00007fa2b8c10000,0x00007fa2b8d10000] [id=29557]
> > 
> > 
> > If I was stuck with issue like this, I'll try the following:
> > 
> > ? *) Test the memory. Memory problems frequently manifest as GC
> > bugs:
> > ??? https://shipilev.net/jvm/test-your-memory/
> 
> Can confirm it's not memory, I was able to reproduce it on another
> machine.
> 
> > 
> > ? *) Use fastdebug JDK as the boot JDK, looking for a reasonable
> > assert instead of anonymous crash. 
> > This probably requires building it first after configuring using --
> > with-debug-level=fastdebug. You 
> > said the build eventually succeeds, so a few tries might be in
> > order.
> 
> Will try this.
> 
> > 
> > ? *) Bootstrap JDK 13 build with JDK 13. AFAICS, the actual
> > requirement for boot JDK is 12..13.
> 
> The problem with this is jdk13 doesn't exist yet in void, so we have
> to
> do a bootstrap chain up from 11 (the latest version packaged).
> 
> > Regardless, even if you find a bug in JDK 12, it is unlikely to get
> > fixed, as no one maintains JDK 
> > 12. Azul maintains JDK 13, so depending on your luck of identifying
> > the issue with JDK 13, I'd say 
> > fixing JDK 13 might be possible.
> > 
> 
> Thanks for the tips!
> 
> Abigail G

Ok, I build jdk12 with fastdebug and built jdk13 with that, still
segfaults but maybe the core dump will have more info now:
https://0x0.st/oHkf.zip

Abigail G


From sgehwolf at redhat.com  Thu Feb  3 19:33:58 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 03 Feb 2022 20:33:58 +0100
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
Message-ID: <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>

On Wed, 2021-12-22 at 11:14 +0100, Severin Gehwolf wrote:
> On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote:
> > Hi,
> > 
> > Please review this adaptation of the corresponding JDK 11 patch. The
> > JDK 11u patch didn't apply because the build system is widely different
> > between these two releases.
> > 
> > The main difference is make/common/MakeBase.gmk (JDK 8) vs
> > make/SourceRevision.gmk (JDK 11). I've basically rewritten those parts
> > of the patch. All the SCM handling in JDK 8 is in MakeBase.
> > FindAllReposAbs isn't present in JDK 8u.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210283
> > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/01/webrev/
> > 
> > Testing: "make --trace source-tips" on mercurial tree as well as
> > ???????? the git mirror. $IMAGE_DIR/release file contains the SHA of
> > ???????? the sources it was built from with 'git:' or 'hg:' prefixes.
> > 
> > Thoughts?
> 
> Anyone? When building from the git read-only mirror the "release" file
> no longer includes the git sha it was built from without this fix.

Anyone willing to review this?

Thanks,
Severin



From naoto at openjdk.java.net  Fri Feb  4 00:11:20 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Feb 2022 00:11:20 GMT
Subject: RFR: 8176706: Additional Date-Time Formats
Message-ID: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>

Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion.

[1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html

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

Commit messages:
 - Removed trailing space
 - Merge branch 'master' into skeleton
 - Tidying up
 - Some more tests
 - Brought back the part that was mistakenly removed
 - Merge branch 'master' into skeleton
 - Reverted IllegalArgumentException back
 - Further cleanups
 - Removed exceptions from ofLocalizedPattern() method, as they are lazily thrown on format()
 - Cleanup
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/cda9c301...f9311dce

Changes: https://git.openjdk.java.net/jdk/pull/7340/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8176706
  Stats: 777 lines in 12 files changed: 733 ins; 9 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7340.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7340/head:pull/7340

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


From duke at openjdk.java.net  Fri Feb  4 00:25:43 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Feb 2022 00:25:43 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@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 ten commits:

 - Merge branch 'master' into JDK-8203290
 - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
 - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
 - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
 - Addresses issues from review and other sm fixes
   
   - Adds commenting in regards to memory handling by SystemProcess &
   NetworkInterface classes
   - Replaces explicit initialization and copy of structs with memcpy
   and memset as appropriate
   - Renames internal struct definitions in os_perf_aix
   - Other minor fixes
 - Changes macoss -> macosx in problem list
 - Refactors loadlib_aix: Removes redundant c++ class
 - 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=19
  Stats: 1235 lines in 10 files changed: 466 ins; 502 del; 267 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 Feb  4 00:34:17 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Feb 2022 00:34:17 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v18]
In-Reply-To: <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@github.com>
 <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>
Message-ID: <he54ulCsnFWkTs-HA3_fAiz7gqNwIf4uDsEBt19la2o=.1f9aad0f-25e8-4993-828c-2d8637e0fbe4@github.com>

On Wed, 2 Feb 2022 17:17:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>
> Thanks for the update. As David had written, the Oracle Copyright lines you have added are not correct: "Copyright (c) 2022, 2022". I suggest to avoid adding new lines for this change until the topic is clarified.

I received some guidance from our legal team. They suggested that I add the Oracle copyright header to files that only had the SAP header if I have made changes. They also suggested adding an IBM copyright line to files I have modified as well. @TheRealMDoerr, I know you also reached out to Iris. Have you heard back from them?

I'm a fan of more testing @tstuefe. Let me know if you discover anything interesting.

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

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


From duke at openjdk.java.net  Fri Feb  4 09:19:15 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Fri, 4 Feb 2022 09:19:15 GMT
Subject: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection
 for Linux/AArch64 [v17]
In-Reply-To: <Dok0bE7QDan5hdeiCnuctzvNFc4KC1bAw7uegPTpb7s=.92e247fe-ec36-4a1c-9055-7d1986514d86@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <52o8K8q5wBP4HgBI3AljysgeR6tbogiOtQYu0VhWOAA=.80d5b306-f67f-4a87-836f-44bdbb0713f1@github.com>
 <Dok0bE7QDan5hdeiCnuctzvNFc4KC1bAw7uegPTpb7s=.92e247fe-ec36-4a1c-9055-7d1986514d86@github.com>
Message-ID: <rzaJ13bQtHco6JmgxkgovaoFb6Q7IYRBdJ3oCFrYX9U=.e250fb9d-23a0-447a-ba15-9f7d35e623c6@github.com>

On Thu, 3 Feb 2022 16:49:08 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> However, I'm not sure how to add to the release notes - I can't find any files or a process.

Ok, This part I understand now :)

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

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


From mdoerr at openjdk.java.net  Fri Feb  4 09:30:21 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 4 Feb 2022 09:30:21 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
Message-ID: <XDrx2Bd8_q11_t3iKi_AWP2yLL3TNZ8304Cb_yQPIDM=.7000e977-7215-479f-a601-0c63b6d15b63@github.com>

On Fri, 4 Feb 2022 00:25:43 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 ten commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - 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

Adding IBM Copyright may be appropriate in files in which you have made significant contributions.
If you add Oracle Copyright lines, please make sure to do it correctly (not "2022, 2022").
Note that your former colleagues haven't done any of that in most cases. I can't tell if this should be done and I think the change can get integrated as it is.
There's no answer, yet: https://mail.openjdk.java.net/pipermail/jdk-dev/2022-January/006364.html

> I'm a fan of more testing @tstuefe. Let me know if you discover anything interesting.

Testing is hard for us because we don't have nightly builds and tests on AIX any more. I don't know if he can afford doing much for it.

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

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


From duke at openjdk.java.net  Fri Feb  4 10:04:16 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Fri, 4 Feb 2022 10:04:16 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v4]
In-Reply-To: <2lh5MBJu9m7qiiF27rVWF94Jq8Pt3PVco7TCDBdWpDo=.21274feb-d77c-4fd0-84cc-2493fb1de274@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
 <2lh5MBJu9m7qiiF27rVWF94Jq8Pt3PVco7TCDBdWpDo=.21274feb-d77c-4fd0-84cc-2493fb1de274@github.com>
Message-ID: <bt6uIX1ZOpmsR2JqVv3At2ujpgaSwv_7U8zg84hNAro=.f979536a-8b4d-438d-970f-d78404d81bca@github.com>

On Thu, 3 Feb 2022 12:56:12 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.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into improve-adhoc-version-string
>  - IS_EMPTY define did not work on msvc
>  - Break long lines
>  - Skip setting git branch in adhoc version opt
>  - Fix for abtract_vm_version so it really handles empty VERSION_BUILD
>  - 8274980: Improve adhoc build version strings

Is the version string for the following `build 17+35-LTS-2724`?

java 17 2021-09-14 LTS
Java(TM) SE Runtime Environment (build 17+35-LTS-2724)
Java HotSpot(TM) 64-Bit Server VM (build 17+35-LTS-2724, mixed mode, sharing)

(I can't remember what they were like since I built the jdk a while ago) 

If that's the case, I'm wondering if instead of changing `18-internal+0-adhoc.shade.jdk (18-internal)` to something like `18-internal-jdk-18+17-80-gcdf89304eaf.shade (18-internal)`, `build 18<+build number, not required>-internal-<branch name + commit id>` would be more understandable and slightly easier on one's eyes, while conveying the same information the usual (verbose) version string otherwise tries to display

I can help with resolving the test failures, if needed?

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

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


From shade at openjdk.java.net  Fri Feb  4 10:08:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Feb 2022 10:08:06 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v4]
In-Reply-To: <bt6uIX1ZOpmsR2JqVv3At2ujpgaSwv_7U8zg84hNAro=.f979536a-8b4d-438d-970f-d78404d81bca@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
 <2lh5MBJu9m7qiiF27rVWF94Jq8Pt3PVco7TCDBdWpDo=.21274feb-d77c-4fd0-84cc-2493fb1de274@github.com>
 <bt6uIX1ZOpmsR2JqVv3At2ujpgaSwv_7U8zg84hNAro=.f979536a-8b4d-438d-970f-d78404d81bca@github.com>
Message-ID: <0NrmJBeGI8FaxECdSPZIAideKrwn6oSlmK0bLhOlF2Q=.15ec8d81-23f7-4d13-928f-d4cc2f4ef07b@github.com>

On Fri, 4 Feb 2022 10:00:50 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

> If that's the case, I'm wondering if instead of changing `18-internal+0-adhoc.shade.jdk (18-internal)` to something like `18-internal-jdk-18+17-80-gcdf89304eaf.shade (18-internal)`, `build 18<+build number, not required>-internal-<branch name + commit id>` would be more understandable and slightly easier on one's eyes, while conveying the same information the usual (verbose) version string otherwise tries to display

We have been discussing this (see the bug comments in JIRA). The showstopper is that versions are captured during `configure`, which means you can configure on one branch, switch to another, and your build would still be recorded as produced by old branch.

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

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


From duke at openjdk.java.net  Fri Feb  4 10:36:05 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Fri, 4 Feb 2022 10:36:05 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v4]
In-Reply-To: <0NrmJBeGI8FaxECdSPZIAideKrwn6oSlmK0bLhOlF2Q=.15ec8d81-23f7-4d13-928f-d4cc2f4ef07b@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
 <2lh5MBJu9m7qiiF27rVWF94Jq8Pt3PVco7TCDBdWpDo=.21274feb-d77c-4fd0-84cc-2493fb1de274@github.com>
 <bt6uIX1ZOpmsR2JqVv3At2ujpgaSwv_7U8zg84hNAro=.f979536a-8b4d-438d-970f-d78404d81bca@github.com>
 <0NrmJBeGI8FaxECdSPZIAideKrwn6oSlmK0bLhOlF2Q=.15ec8d81-23f7-4d13-928f-d4cc2f4ef07b@github.com>
Message-ID: <76VqFqRqYxwJz5OrDkRgv8AqKelU7HMz9xKYUV_tWbA=.828726bf-5de4-481f-a6bb-8632a082515c@github.com>

On Fri, 4 Feb 2022 10:05:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > If that's the case, I'm wondering if instead of changing `18-internal+0-adhoc.shade.jdk (18-internal)` to something like `18-internal-jdk-18+17-80-gcdf89304eaf.shade (18-internal)`, `build 18<+build number, not required>-internal-<branch name + commit id>` would be more understandable and slightly easier on one's eyes, while conveying the same information the usual (verbose) version string otherwise tries to display
> 
> We have been discussing this (see the bug comments in JIRA). The showstopper is that versions are captured during `configure`, which means you can configure on one branch, switch to another, and your build would still be recorded as produced by old branch.

I must've missed that, my bad. I was referring to the original issue though, where the final generated version string is ultimately something along the lines of `18-internal-jdk-18+17-80.shade (18-internal)`, which could potentially be shortened to something like `build 18<+build number>-internal`, which is much less verbose and somewhat easier to understand.

All that aside though, would it be possible to detect the branch and commit at compile time?

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

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


From duke at openjdk.java.net  Fri Feb  4 11:03:35 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 4 Feb 2022 11:03:35 GMT
Subject: RFR: 8281262: Windows builds in different directories are not fully
 reproducible
Message-ID: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>

Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.

For example:

$ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
-pathmap:C:cygwin64homemaximworkrepr.build.1=s

However, if a "normal" Unix-style path is provided, it gets converted correctly:

$ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
-pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 


This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 

Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.


Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:

 ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
make reconfigure clean
make images

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

Commit messages:
 - 8281262: Windows builds in different directories are not fully reproducible

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

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


From erikj at openjdk.java.net  Fri Feb  4 15:01:13 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Feb 2022 15:01:13 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible
In-Reply-To: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
Message-ID: <6pqQIA-bpoqpo_vb8oXollq-Yy2WULoi7Yl9C_YwW4M=.767cc1ad-30cf-4042-a5e5-2d677bbe4d7e@github.com>

On Fri, 4 Feb 2022 10:55:40 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
> 
> For example:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
> 
> However, if a "normal" Unix-style path is provided, it gets converted correctly:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
> 
> 
> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
> 
> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
> 
> 
> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
> 
>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
> make reconfigure clean
> make images

Thank you for finding this! We do have a test that is supposed to catch an issue like this, but unfortunately it seems that test is suffering a similar issue. It's not looking for the correct path strings as the backslashes have been truncated by one too many shell expansions on the way. I created a fix for the test in a branch here: 

https://github.com/erikj79/jdk/tree/JDK-8281262-abspath-windows

I've verified that your fix makes the test pass together with my fix. Something like this should go in with this fix. Feel free to take my change.

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

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


From duke at openjdk.java.net  Fri Feb  4 15:34:42 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 4 Feb 2022 15:34:42 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible [v2]
In-Reply-To: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
Message-ID: <JG9d23Rdg69f23uotgtEXDnjpGyy3dIVOI_RiyRZFs8=.fc2b5625-54e2-4697-b727-f9ec54ac0a1a@github.com>

> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
> 
> For example:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
> 
> However, if a "normal" Unix-style path is provided, it gets converted correctly:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
> 
> 
> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
> 
> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
> 
> 
> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
> 
>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
> make reconfigure clean
> make images

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

  Fixed the test that was supposed to catch this kind of problem.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7344/files
  - new: https://git.openjdk.java.net/jdk/pull/7344/files/bf395cb6..2f99ca5b

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

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

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


From duke at openjdk.java.net  Fri Feb  4 16:08:23 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Feb 2022 16:08:23 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
Message-ID: <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>

On Fri, 4 Feb 2022 00:25:43 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 ten commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - 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 like the idea of adding the IBM copyright line more judiciously, and only when the changes I've made are significant. ProblemList.txt, where I've made a single line change, stands out in my mind as an example of where this line could be removed.

I don't believe there are any files which contain the Oracle "2022, 2022" copyright header anymore. Did you see any I'm missing @TheRealMDoerr?

Regarding testing: I have been regularly building and testing on my AIX 7.1 dev machine. In addition, I have run tier1 tests when the changes I'm making are complete. The only tier1 failures I observe are also failing on the master branch. I'm happy for a second tester if either of you feel it's warranted, but I don't feel it is a necessity.

---

I'll sit tight for a response from Iris before proceeding.

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

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


From mdoerr at openjdk.java.net  Fri Feb  4 16:20:12 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 4 Feb 2022 16:20:12 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>
Message-ID: <N5geXLEn8vaODaHSwb-MqnngHDUgg1BAJMwB-iIx4Gk=.1641fafb-1721-4cd3-b781-36600db7760e@github.com>

On Fri, 4 Feb 2022 16:05:02 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> I like the idea of adding the IBM copyright line more judiciously, and only when the changes I've made are significant. ProblemList.txt, where I've made a single line change, stands out in my mind as an example of where this line could be removed.

Right. Please remove it where you didn't make significant contributions. Simple changes or even removals don't justify IBMs Copyright on the whole file. I don't think this is acceptable.

> I don't believe there are any files which contain the Oracle "2022, 2022" copyright header anymore. Did you see any I'm missing @TheRealMDoerr?

Seems like you fixed them already.

> Regarding testing: I have been regularly building and testing on my AIX 7.1 dev machine. In addition, I have run tier1 tests when the changes I'm making are complete. The only tier1 failures I observe are also failing on the master branch. I'm happy for a second tester if either of you feel it's warranted, but I don't feel it is a necessity.

That sounds good. There are not many people working on AIX. You may be alone. But, I'm glad you're doing it!

> I'll sit tight for a response from Iris before proceeding.

Be warned: This may take time. You certainly want your change to get integrated at some point of time.

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

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


From duke at openjdk.java.net  Fri Feb  4 15:38:06 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 4 Feb 2022 15:38:06 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible
In-Reply-To: <6pqQIA-bpoqpo_vb8oXollq-Yy2WULoi7Yl9C_YwW4M=.767cc1ad-30cf-4042-a5e5-2d677bbe4d7e@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
 <6pqQIA-bpoqpo_vb8oXollq-Yy2WULoi7Yl9C_YwW4M=.767cc1ad-30cf-4042-a5e5-2d677bbe4d7e@github.com>
Message-ID: <NQiS9s0oI8U49P-It19UMFa60KQvpkZo0IcS7toprqE=.22030c3a-0b60-4d81-913a-07d56cd24a12@github.com>

On Fri, 4 Feb 2022 14:57:04 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
>> 
>> For example:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
>> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
>> 
>> However, if a "normal" Unix-style path is provided, it gets converted correctly:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
>> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
>> 
>> 
>> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
>> 
>> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
>> 
>> 
>> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
>> 
>>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
>> make reconfigure clean
>> make images
>
> Thank you for finding this! We do have a test that is supposed to catch an issue like this, but unfortunately it seems that test is suffering a similar issue. It's not looking for the correct path strings as the backslashes have been truncated by one too many shell expansions on the way. I created a fix for the test in a branch here: 
> 
> https://github.com/erikj79/jdk/tree/JDK-8281262-abspath-windows
> 
> I've verified that your fix makes the test pass together with my fix. Something like this should go in with this fix. Feel free to take my change.

@erikj79 Thank you! I added another commit (under your name) with your changes to this pull request.

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

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


From erikj at openjdk.java.net  Fri Feb  4 17:26:14 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Feb 2022 17:26:14 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible [v2]
In-Reply-To: <JG9d23Rdg69f23uotgtEXDnjpGyy3dIVOI_RiyRZFs8=.fc2b5625-54e2-4697-b727-f9ec54ac0a1a@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
 <JG9d23Rdg69f23uotgtEXDnjpGyy3dIVOI_RiyRZFs8=.fc2b5625-54e2-4697-b727-f9ec54ac0a1a@github.com>
Message-ID: <IoEjqyjC0urpFBnV2F1_VmjT0y8xSjF2lBTp3gKay2Y=.865b05fe-cfd5-4ee3-a6fe-53d184749fe2@github.com>

On Fri, 4 Feb 2022 15:34:42 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
>> 
>> For example:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
>> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
>> 
>> However, if a "normal" Unix-style path is provided, it gets converted correctly:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
>> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
>> 
>> 
>> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
>> 
>> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
>> 
>> 
>> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
>> 
>>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
>> make reconfigure clean
>> make images
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the test that was supposed to catch this kind of problem.

Thanks for incorporating my change. After thinking about this some more, I figured we could add some form of validation of the root paths that would actually catch the build problem as well. I added another change to the same branch with this. The test now makes sure the root paths can be parsed as paths and are absolute. This validation fails on Windows without my previous patch, causing the test to fail.

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

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


From stuefe at openjdk.java.net  Fri Feb  4 17:39:12 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 17:39:12 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <WNVSezqF2f-7JUgyAm84PmtU1EVRPF0KJPALz_qNYM8=.376c4ede-9d09-4d6f-85dc-af043a4eeacf@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
 <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>
 <WNVSezqF2f-7JUgyAm84PmtU1EVRPF0KJPALz_qNYM8=.376c4ede-9d09-4d6f-85dc-af043a4eeacf@github.com>
Message-ID: <yUN7arOagrcsemLCuH90O8lGAPME9gRMlW_5huu6YhQ=.e6655e17-af6f-4ffd-9bcc-d3b46cefc661@github.com>

On Thu, 3 Feb 2022 11:22:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Looks good to me, too. I think it is ready for integration assuming all change requests were taken care of and tests have passed.
>
>> Looks good to me, too. I think it is ready for integration assuming all change requests were taken care of and tests have passed.
> 
> @TheRealMDoerr we should test the latest version of this patch in our nightlies, just in case

> > I'm a fan of more testing @tstuefe. Let me know if you discover anything interesting.
> 
> Testing is hard for us because we don't have nightly builds and tests on AIX any more. I don't know if he can afford doing much for it.

Yes, I was assuming this patch fixes JFR for all IBM platforms (also Linux PPC and s390). But this is only AIX. Maybe the issue should be renamed to reflect that. "Implement JFR on AIX". Leave that up to Martin. I think Tyler has no write access to JBS yet.



> Regarding testing: I have been regularly building and testing on my AIX 7.1 dev machine. In addition, I have run tier1 tests when the changes I'm making are complete. The only tier1 failures I observe are also failing on the master branch. I'm happy for a second tester if either of you feel it's warranted, but I don't feel it is a necessity.

I would feel better if more than tier 1 jtreg tests would be done, but I know AIX is sluggish. Maybe @egahlin can recommend what tests to run beyond tier1 to exercise JFR a bit. Are all relevant JFR tests part of tier1?

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

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


From duke at openjdk.java.net  Fri Feb  4 18:37:51 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 4 Feb 2022 18:37:51 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible [v3]
In-Reply-To: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
Message-ID: <7W0KLfLePAm7WJIML5nKsG8kxgWEGw-5XsRqJMBiMAc=.d7c78265-5c28-4672-b4b3-1499fb715ce6@github.com>

> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
> 
> For example:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
> 
> However, if a "normal" Unix-style path is provided, it gets converted correctly:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
> 
> 
> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
> 
> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
> 
> 
> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
> 
>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
> make reconfigure clean
> make images

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

  Added validation of root paths.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7344/files
  - new: https://git.openjdk.java.net/jdk/pull/7344/files/2f99ca5b..c66ea187

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

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

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


From duke at openjdk.java.net  Fri Feb  4 19:40:23 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Feb 2022 19:40:23 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <yUN7arOagrcsemLCuH90O8lGAPME9gRMlW_5huu6YhQ=.e6655e17-af6f-4ffd-9bcc-d3b46cefc661@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
 <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>
 <WNVSezqF2f-7JUgyAm84PmtU1EVRPF0KJPALz_qNYM8=.376c4ede-9d09-4d6f-85dc-af043a4eeacf@github.com>
 <yUN7arOagrcsemLCuH90O8lGAPME9gRMlW_5huu6YhQ=.e6655e17-af6f-4ffd-9bcc-d3b46cefc661@github.com>
Message-ID: <7_RBQjRF-6wQL7CDPihG0mdgqeM2nJUUxbHzjZOKodE=.0d431ab5-4b8f-4ef1-a6d9-b113720f210c@github.com>

On Fri, 4 Feb 2022 17:35:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I think Tyler has no write access to JBS yet.

This is correct.

> Are all relevant JFR tests part of tier1?

I run the tests in `test/jdk/jdk/jfr` as I develop as well, so those have been run whether or not they are part of the tier1 tests. I have also created a recording using jcmd, and analyzed it with jmc. Things are working as I expect them to :-)

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

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


From erikj at openjdk.java.net  Fri Feb  4 20:52:11 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Feb 2022 20:52:11 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible [v3]
In-Reply-To: <7W0KLfLePAm7WJIML5nKsG8kxgWEGw-5XsRqJMBiMAc=.d7c78265-5c28-4672-b4b3-1499fb715ce6@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
 <7W0KLfLePAm7WJIML5nKsG8kxgWEGw-5XsRqJMBiMAc=.d7c78265-5c28-4672-b4b3-1499fb715ce6@github.com>
Message-ID: <_FW8mTwrYzIdpk68jP1yTt7s58AllxtXMLvmlB4jiuU=.a3c4fbe5-eb8b-43a1-85d5-945cbded12ec@github.com>

On Fri, 4 Feb 2022 18:37:51 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
>> 
>> For example:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
>> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
>> 
>> However, if a "normal" Unix-style path is provided, it gets converted correctly:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
>> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
>> 
>> 
>> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
>> 
>> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
>> 
>> 
>> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
>> 
>>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
>> make reconfigure clean
>> make images
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added validation of root paths.

I think this looks good, but would be good if Magnus could take a look as well.

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

Marked as reviewed by erikj (Reviewer).

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


From duke at openjdk.java.net  Sun Feb  6 06:13:15 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Sun, 6 Feb 2022 06:13:15 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v4]
In-Reply-To: <2lh5MBJu9m7qiiF27rVWF94Jq8Pt3PVco7TCDBdWpDo=.21274feb-d77c-4fd0-84cc-2493fb1de274@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
 <2lh5MBJu9m7qiiF27rVWF94Jq8Pt3PVco7TCDBdWpDo=.21274feb-d77c-4fd0-84cc-2493fb1de274@github.com>
Message-ID: <BMKCHGMX7FtGX-cdqEU6M9Mtf6PkZfQAuzcuDRrBAUQ=.acfecdda-5c52-4659-aea2-bed3e97a0f18@github.com>

On Thu, 3 Feb 2022 12:56:12 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.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into improve-adhoc-version-string
>  - IS_EMPTY define did not work on msvc
>  - Break long lines
>  - Skip setting git branch in adhoc version opt
>  - Fix for abtract_vm_version so it really handles empty VERSION_BUILD
>  - 8274980: Improve adhoc build version strings

I'm not sure if there's a neater way to do this, but I did come up with a fix for [IS_EMPTY define did not work on msvc](https://github.com/openjdk/jdk/pull/6152/commits/3c93c740e6d0d8624be6f87b5495d61b408167bd): https://github.com/magicus/jdk/commit/085ae29f2f01df1f06433713f5a554e7f3b375aa which seems to work properly for MSVC when building on Windows when handling empty version build numbers. I'm not too well versed with the build system though, so I'm not entirely sure that it working with MSVC is a direct result of the change or just a coincidence (Potentially caused by the change made to make/autoconf/spec.gmk.in in this PR)

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

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


From duke at openjdk.java.net  Mon Feb  7 06:09:13 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Mon, 7 Feb 2022 06:09:13 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible [v3]
In-Reply-To: <_FW8mTwrYzIdpk68jP1yTt7s58AllxtXMLvmlB4jiuU=.a3c4fbe5-eb8b-43a1-85d5-945cbded12ec@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
 <7W0KLfLePAm7WJIML5nKsG8kxgWEGw-5XsRqJMBiMAc=.d7c78265-5c28-4672-b4b3-1499fb715ce6@github.com>
 <_FW8mTwrYzIdpk68jP1yTt7s58AllxtXMLvmlB4jiuU=.a3c4fbe5-eb8b-43a1-85d5-945cbded12ec@github.com>
Message-ID: <EwIwJiteEf3-UiRkdtM8zT-KJQPIJnQPmEkouO9-FyE=.98b2a32f-98be-4ad3-8145-9cde5d0c6f03@github.com>

On Fri, 4 Feb 2022 20:49:14 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> would be good if Magnus could take a look as well.

Now that a good part of the PR is authored by you, `jcheck` wouldn't have it any other way :-)

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

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


From mdoerr at openjdk.java.net  Mon Feb  7 10:29:11 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 7 Feb 2022 10:29:11 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
Message-ID: <hMYVGzquS5A3h3WAGPY63wSwqDRHjewl5sAiAtEK9bk=.70f129a5-cd67-4c98-918d-3c668db9aa5b@github.com>

On Fri, 4 Feb 2022 00:25:43 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 ten commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - 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've updated the JBS issue. Please adapt the PR title to match it: "[AIX] Check functionality of JDK-8199712 (Flight Recorder)".

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

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


From aph at openjdk.java.net  Mon Feb  7 10:53:14 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 10:53:14 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
Message-ID: <-FQjRIxxiyiMqo8kEwUVP6XzCEfHIiRdbmlmGaPfXmA=.c56eee79-194a-425b-a645-775deb963d7b@github.com>

On Thu, 3 Feb 2022 16:51:48 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:
> 
>   Documentation updates

doc/building.md line 141:

> 139: 
> 140: In order to use Branch Protection features in the VM, `--enable-branch-protection`
> 141: must be provided. This requires compiler support (GCC 9.1.0+ or Clang 10+). The

Suggestion:

must be used. This option requires C++ compiler support (GCC 9.1.0+ or Clang 10+). The

doc/building.md line 143:

> 141: must be provided. This requires compiler support (GCC 9.1.0+ or Clang 10+). The
> 142: resulting build can be run on both machines with and without support for branch
> 143: protection in hardware. This is only supported for Linux targets.

Suggestion:

protection in hardware. Branch Protection is only supported for Linux targets.

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

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


From aph at openjdk.java.net  Mon Feb  7 11:02:11 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 11:02:11 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
Message-ID: <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>

On Thu, 3 Feb 2022 16:51:48 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:
> 
>   Documentation updates

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 1163:

> 1161: #undef INSN
> 1162: 
> 1163:   // PAC branch instructions (with register modifier)

This section title is wrong. According to DDI0487G, the correct section title is "Unconditional branch (register)". All of the instructions in each section of this file should be grouped in the same way that they are in the Arm ARM.

src/hotspot/cpu/aarch64/frame_aarch64.cpp line 275:

> 273:   if (TracePcPatching) {
> 274:     tty->print_cr("patch_pc at address " INTPTR_FORMAT " [" INTPTR_FORMAT " -> " INTPTR_FORMAT "]",
> 275:                   p2i(pc_addr), p2i(*pc_addr), p2i(signed_pc));

Let's see both pc and signed pc here.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5293:

> 5291: // Create an additional frame for a function.
> 5292: void MacroAssembler::enter_subframe() {
> 5293:   // Addresses can only be signed once, so strip it first. PAC safe because the value is not

This needs a more descriptive name. `enter_and_sign()` ? No, that's not right either. How do we come up with a name that's more descriptive?

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

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


From aph at openjdk.java.net  Mon Feb  7 11:02:11 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 11:02:11 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
Message-ID: <uwm53WfSm6lIeOTDR7dRew2L39VCIAQNaWFgi9g4vwc=.e66d74a1-c261-457d-8d22-7499400b64ee@github.com>

On Mon, 7 Feb 2022 10:55:52 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Documentation updates
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5293:
> 
>> 5291: // Create an additional frame for a function.
>> 5292: void MacroAssembler::enter_subframe() {
>> 5293:   // Addresses can only be signed once, so strip it first. PAC safe because the value is not
> 
> This needs a more descriptive name. `enter_and_sign()` ? No, that's not right either. How do we come up with a name that's more descriptive?

Because enter always enters a subframe. That's what it's for.

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

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


From aph at openjdk.java.net  Mon Feb  7 11:09:14 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 11:09:14 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
Message-ID: <RzxoYr-y8OWsLLQtdUnZeT2E3P3ScmXQ_Kr8Rp-NQyc=.4458672a-1b51-424c-84c8-abd7b6cf4518@github.com>

On Thu, 3 Feb 2022 16:51:48 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:
> 
>   Documentation updates

src/hotspot/os_cpu/linux_aarch64/pauth_linux_aarch64.inline.hpp line 57:

> 55:     register address r17 __asm("r17") = ret_addr;
> 56:     register address r16 __asm("r16") = sp;
> 57:     asm volatile (PACIA1716 : "+r"(r17) : "r"(r16));

I don't see the point of `volatile` here, any more than you'd use volatile on an addition. `volatile` is when you have a side effect you care about.

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

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


From aph at openjdk.java.net  Mon Feb  7 11:09:14 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 11:09:14 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
Message-ID: <z94AJk6GHQRxUcbNQdGd3K_1M2XUJoFE9ZcgoydG0h8=.2d7fe08f-475e-4625-84f6-6503d52d42b9@github.com>

On Mon, 7 Feb 2022 10:58:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Documentation updates
>
> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 275:
> 
>> 273:   if (TracePcPatching) {
>> 274:     tty->print_cr("patch_pc at address " INTPTR_FORMAT " [" INTPTR_FORMAT " -> " INTPTR_FORMAT "]",
>> 275:                   p2i(pc_addr), p2i(*pc_addr), p2i(signed_pc));
> 
> Let's see both pc and signed pc here.

> Let's see both pc and signed pc here, if they are different.

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

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


From aph at openjdk.java.net  Mon Feb  7 11:17:18 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 11:17:18 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
Message-ID: <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>

On Thu, 3 Feb 2022 16:51:48 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:
> 
>   Documentation updates

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5328:

> 5326: // Uses the FP from the start of the function as the modifier - which is stored at the address of
> 5327: // the current FP.
> 5328: //

Is it? C2 uses FP as a scratch register. I guess we know that this is never used in C2-generated code? I'm tempted to put an assertion here, just in case. Or does it not matter?

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

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


From duke at openjdk.java.net  Mon Feb  7 11:32:15 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 7 Feb 2022 11:32:15 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <z94AJk6GHQRxUcbNQdGd3K_1M2XUJoFE9ZcgoydG0h8=.2d7fe08f-475e-4625-84f6-6503d52d42b9@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
 <z94AJk6GHQRxUcbNQdGd3K_1M2XUJoFE9ZcgoydG0h8=.2d7fe08f-475e-4625-84f6-6503d52d42b9@github.com>
Message-ID: <NPNfy4lZLmfwsENiGsvDorKLZ_FeiAYzHougna3gwMs=.7b4e3251-9ff3-4886-98ea-75a6f15c2dbb@github.com>

On Mon, 7 Feb 2022 11:06:20 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 275:
>> 
>>> 273:   if (TracePcPatching) {
>>> 274:     tty->print_cr("patch_pc at address " INTPTR_FORMAT " [" INTPTR_FORMAT " -> " INTPTR_FORMAT "]",
>>> 275:                   p2i(pc_addr), p2i(*pc_addr), p2i(signed_pc));
>> 
>> Let's see both pc and signed pc here.
>
>> Let's see both pc and signed pc here, if they are different.

Are you sure? At the moment with PAC we get:

patch_pc at address 0x0000fffff58edf98 [0x0068ffffed17b5fc -> 0x00abffffed17b7f8]

With both signed and unsigned you'd have:

patch_pc at address 0x0000fffff58edf98 [0x0068ffffed17b5fc (0x0000ffffed17b5fc) -> 0x00abffffed17b7f8 (0x0000ffffed17b7f8)]

I prefer the first - it's shorter and you can infer the address from the signed version. Happy to go with the longer version if you think the shorter version is confusing.

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

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


From aph at openjdk.java.net  Mon Feb  7 11:46:20 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 11:46:20 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <NPNfy4lZLmfwsENiGsvDorKLZ_FeiAYzHougna3gwMs=.7b4e3251-9ff3-4886-98ea-75a6f15c2dbb@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
 <z94AJk6GHQRxUcbNQdGd3K_1M2XUJoFE9ZcgoydG0h8=.2d7fe08f-475e-4625-84f6-6503d52d42b9@github.com>
 <NPNfy4lZLmfwsENiGsvDorKLZ_FeiAYzHougna3gwMs=.7b4e3251-9ff3-4886-98ea-75a6f15c2dbb@github.com>
Message-ID: <bUnkLEe5QvHNyxwlD4ILN57TrCyRvdj-n_r3G2AXTMc=.efec51c1-c062-4da4-8c93-7c601923d86d@github.com>

On Mon, 7 Feb 2022 11:28:30 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>>> Let's see both pc and signed pc here, if they are different.
>
> Are you sure? At the moment with PAC we get:
> 
> patch_pc at address 0x0000fffff58edf98 [0x0068ffffed17b5fc -> 0x00abffffed17b7f8]
> 
> With both signed and unsigned you'd have:
> 
> patch_pc at address 0x0000fffff58edf98 [0x0068ffffed17b5fc (0x0000ffffed17b5fc) -> 0x00abffffed17b7f8 (0x0000ffffed17b7f8)]
> 
> I prefer the first - it's shorter and you can infer the address from the signed version. Happy to go with the longer version if you think the shorter version is confusing.

You've been looking at PAC-signed addresses for a long time. 
Let's see "at address [prev true dest -> new true dest] [signed prev signed dest -> new signed dest]", but only show the signed dests if they're different. So it appears as 
`patch_pc at address 0x0000fffff58edf98 [0x0068ffffed17b5fc -> 0x00abffffed17b7f8] [signed 0x0000ffffed17b5fc ->  0x0000ffffed17b7f8]` .

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

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


From duke at openjdk.java.net  Mon Feb  7 11:46:21 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 7 Feb 2022 11:46:21 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <uwm53WfSm6lIeOTDR7dRew2L39VCIAQNaWFgi9g4vwc=.e66d74a1-c261-457d-8d22-7499400b64ee@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
 <uwm53WfSm6lIeOTDR7dRew2L39VCIAQNaWFgi9g4vwc=.e66d74a1-c261-457d-8d22-7499400b64ee@github.com>
Message-ID: <CPrtaN-iAmOQIS0MCMo9Ss3z_RDqKkeifZ2Ij6FRcCo=.62f9ade2-8472-4b3f-b448-ef73655eeb0b@github.com>

On Mon, 7 Feb 2022 10:57:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5293:
>> 
>>> 5291: // Create an additional frame for a function.
>>> 5292: void MacroAssembler::enter_subframe() {
>>> 5293:   // Addresses can only be signed once, so strip it first. PAC safe because the value is not
>> 
>> This needs a more descriptive name. `enter_and_sign()` ? No, that's not right either. How do we come up with a name that's more descriptive?
>
> Because enter always enters a subframe. That's what it's for.

enter_nested() ?
enter_inner() ?

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

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


From duke at openjdk.java.net  Mon Feb  7 11:46:21 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 7 Feb 2022 11:46:21 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
Message-ID: <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>

On Mon, 7 Feb 2022 11:11:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Alan Hayward has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Documentation updates
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5328:
> 
>> 5326: // Uses the FP from the start of the function as the modifier - which is stored at the address of
>> 5327: // the current FP.
>> 5328: //
> 
> Is it? C2 uses FP as a scratch register. I guess we know that this is never used in C2-generated code? I'm tempted to put an assertion here, just in case. Or does it not matter?

Allocating FP is disabled for rop protection:

aarch64.md has:
// r29 is not allocatable when PreserveFramePointer or ROP protection is on
if (PreserveFramePointer || VM_Version::use_rop_protection()) {

I think that covers it.
What assertion would you want to check?

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

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


From duke at openjdk.java.net  Mon Feb  7 11:57:12 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 7 Feb 2022 11:57:12 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <bUnkLEe5QvHNyxwlD4ILN57TrCyRvdj-n_r3G2AXTMc=.efec51c1-c062-4da4-8c93-7c601923d86d@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
 <z94AJk6GHQRxUcbNQdGd3K_1M2XUJoFE9ZcgoydG0h8=.2d7fe08f-475e-4625-84f6-6503d52d42b9@github.com>
 <NPNfy4lZLmfwsENiGsvDorKLZ_FeiAYzHougna3gwMs=.7b4e3251-9ff3-4886-98ea-75a6f15c2dbb@github.com>
 <bUnkLEe5QvHNyxwlD4ILN57TrCyRvdj-n_r3G2AXTMc=.efec51c1-c062-4da4-8c93-7c601923d86d@github.com>
Message-ID: <RFD3_8xVu95FK1eppLHDTkL3-hdvVXNDOHfzzLd5sb0=.7725501b-cbe1-43a9-8f21-dfa83c9c22f2@github.com>

On Mon, 7 Feb 2022 11:43:13 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Are you sure? At the moment with PAC we get:
>> 
>> patch_pc at address 0x0000fffff58edf98 [0x0068ffffed17b5fc -> 0x00abffffed17b7f8]
>> 
>> With both signed and unsigned you'd have:
>> 
>> patch_pc at address 0x0000fffff58edf98 [0x0068ffffed17b5fc (0x0000ffffed17b5fc) -> 0x00abffffed17b7f8 (0x0000ffffed17b7f8)]
>> 
>> I prefer the first - it's shorter and you can infer the address from the signed version. Happy to go with the longer version if you think the shorter version is confusing.
>
> You've been looking at PAC-signed addresses for a long time. 
> Let's see "at address [prev true dest -> new true dest] [signed prev signed dest -> new signed dest]", but only show the signed dests if they're different. So it appears as 
> `patch_pc at address 0x0000fffff58edf98 [0x0068ffffed17b5fc -> 0x00abffffed17b7f8] [signed 0x0000ffffed17b5fc ->  0x0000ffffed17b7f8]` .

ok, that looks better than my longer version, I'll go with that

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

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


From aph at openjdk.java.net  Mon Feb  7 11:57:12 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 11:57:12 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
 <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>
Message-ID: <SlWAICcj0RKZKakcqy3yPPvV_FrEu0An9LYrjkFiUvA=.905f6d29-edb9-4ad0-812c-0cdc1b748000@github.com>

On Mon, 7 Feb 2022 11:41:57 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5328:
>> 
>>> 5326: // Uses the FP from the start of the function as the modifier - which is stored at the address of
>>> 5327: // the current FP.
>>> 5328: //
>> 
>> Is it? C2 uses FP as a scratch register. I guess we know that this is never used in C2-generated code? I'm tempted to put an assertion here, just in case. Or does it not matter?
>
> Allocating FP is disabled for rop protection:
> 
> aarch64.md has:
> // r29 is not allocatable when PreserveFramePointer or ROP protection is on
> if (PreserveFramePointer || VM_Version::use_rop_protection()) {
> 
> I think that covers it.
> What assertion would you want to check?

If `UseROPProtection` is on, is there any reason not to set `PreserveFramePointer`, and assert here that it is set? It is a crucial assumption, so let's assert it.

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

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


From aph at openjdk.java.net  Mon Feb  7 12:01:13 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 12:01:13 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <CPrtaN-iAmOQIS0MCMo9Ss3z_RDqKkeifZ2Ij6FRcCo=.62f9ade2-8472-4b3f-b448-ef73655eeb0b@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
 <uwm53WfSm6lIeOTDR7dRew2L39VCIAQNaWFgi9g4vwc=.e66d74a1-c261-457d-8d22-7499400b64ee@github.com>
 <CPrtaN-iAmOQIS0MCMo9Ss3z_RDqKkeifZ2Ij6FRcCo=.62f9ade2-8472-4b3f-b448-ef73655eeb0b@github.com>
Message-ID: <QbRR80JhYnzAnB9o9HMSJFU-lVpINvDXfh4AisP9VEM=.513ff0b8-d42e-4ef1-8c8b-88db1b72b772@github.com>

On Mon, 7 Feb 2022 11:42:43 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> Because enter always enters a subframe. That's what it's for.
>
> enter_nested() ?
> enter_inner() ?

Tell you what, first put a comment here that says when it should (and therefore, should not) be used. Once it's clear exactly what this is for, thinking of a name maight be easier.

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

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


From duke at openjdk.java.net  Mon Feb  7 12:04:16 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 7 Feb 2022 12:04:16 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <SlWAICcj0RKZKakcqy3yPPvV_FrEu0An9LYrjkFiUvA=.905f6d29-edb9-4ad0-812c-0cdc1b748000@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
 <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>
 <SlWAICcj0RKZKakcqy3yPPvV_FrEu0An9LYrjkFiUvA=.905f6d29-edb9-4ad0-812c-0cdc1b748000@github.com>
Message-ID: <32e7_CnkkIaj2GOsvi9mT-xzgLO8B60uHrzMEAZXHko=.2ea9eaff-39c6-4401-9820-4536f03d5ec7@github.com>

On Mon, 7 Feb 2022 11:54:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Allocating FP is disabled for rop protection:
>> 
>> aarch64.md has:
>> // r29 is not allocatable when PreserveFramePointer or ROP protection is on
>> if (PreserveFramePointer || VM_Version::use_rop_protection()) {
>> 
>> I think that covers it.
>> What assertion would you want to check?
>
> If `UseROPProtection` is on, is there any reason not to set `PreserveFramePointer`, and assert here that it is set? It is a crucial assumption, so let's assert it.

PreserveFramePointer is doing some additional stuff. I'll give it a test to make sure everything still works with PreserveFramePointer fully set. It would make things easier just to force it set with rop protection on.

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

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


From aph at openjdk.java.net  Mon Feb  7 12:29:21 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 12:29:21 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <32e7_CnkkIaj2GOsvi9mT-xzgLO8B60uHrzMEAZXHko=.2ea9eaff-39c6-4401-9820-4536f03d5ec7@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
 <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>
 <SlWAICcj0RKZKakcqy3yPPvV_FrEu0An9LYrjkFiUvA=.905f6d29-edb9-4ad0-812c-0cdc1b748000@github.com>
 <32e7_CnkkIaj2GOsvi9mT-xzgLO8B60uHrzMEAZXHko=.2ea9eaff-39c6-4401-9820-4536f03d5ec7@github.com>
Message-ID: <PSXG9ufu1E8eEMInOxEogYJiWgeg051cY10oQv9G1T4=.bf62e54d-16b7-4032-ae44-55dee24a0877@github.com>

On Mon, 7 Feb 2022 12:01:18 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> PreserveFramePointer is doing some additional stuff. I'll give it a test to make sure everything still works with PreserveFramePointer fully set. It would make things easier just to force it set with rop protection on.

Using PreserveFramePointer greatly simplifies the testing matrix, and has little adverse performance impact beyond disallowing C2 from allocating FP as a scratch register. It also simplifies this patch, which would be a very Good Thing. Let's do it.

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

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


From duke at openjdk.java.net  Mon Feb  7 13:47:14 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 7 Feb 2022 13:47:14 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <QbRR80JhYnzAnB9o9HMSJFU-lVpINvDXfh4AisP9VEM=.513ff0b8-d42e-4ef1-8c8b-88db1b72b772@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
 <uwm53WfSm6lIeOTDR7dRew2L39VCIAQNaWFgi9g4vwc=.e66d74a1-c261-457d-8d22-7499400b64ee@github.com>
 <CPrtaN-iAmOQIS0MCMo9Ss3z_RDqKkeifZ2Ij6FRcCo=.62f9ade2-8472-4b3f-b448-ef73655eeb0b@github.com>
 <QbRR80JhYnzAnB9o9HMSJFU-lVpINvDXfh4AisP9VEM=.513ff0b8-d42e-4ef1-8c8b-88db1b72b772@github.com>
Message-ID: <-V7ptCS4QdcpFHOomMnTPPYvFtKSQ0nswzFNXQDoWLg=.2d72897f-ef45-4867-892f-64df085eca85@github.com>

On Mon, 7 Feb 2022 11:58:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> enter_nested() ?
>> enter_inner() ?
>
> Tell you what, first put a comment here that says when it should (and therefore, should not) be used. Once it's clear exactly what this is for, thinking of a name maight be easier.

How about extending the existing enter() function: 

// Enter a new stack frame for the current method.
// nested:     Indicates a frame has already been entered (and not left) for the current method. 
void MacroAssembler::enter(bool nested=false) {
   if (nested) strip()
   protect()
   stp()
   mov()
}

This would add an additional bool check for every call of enter() - that's at code generation time, so probably not an issue.

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

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


From duke at openjdk.java.net  Mon Feb  7 13:58:51 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 7 Feb 2022 13:58:51 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v19]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <jLq9QGE621_DBir4higkvKirBRyAMjZ43S1A8Gn1lKQ=.7c184c9c-24f0-4e9f-aa28-c1ccaf9eb7af@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:

  Review fixups

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/d97883b5..614a3262

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

  Stats: 20 lines in 4 files changed: 7 ins; 6 del; 7 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 chagedorn at openjdk.java.net  Mon Feb  7 15:04:10 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 7 Feb 2022 15:04:10 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v3]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <N3jsXjCt7lKMP99M8f_JY5ncSmdGGQYdCe1AAc0wo98=.1e21096c-812d-46a1-8d98-b644d2a78b6e@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 one additional commit since the last revision:

  Change log_* to log_develop_* and log_warning to log_develop_info

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7126/files
  - new: https://git.openjdk.java.net/jdk/pull/7126/files/7ddb7737..698663b9

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

  Stats: 74 lines in 2 files changed: 0 ins; 0 del; 74 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 aph at openjdk.java.net  Mon Feb  7 15:15:17 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 7 Feb 2022 15:15:17 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <-V7ptCS4QdcpFHOomMnTPPYvFtKSQ0nswzFNXQDoWLg=.2d72897f-ef45-4867-892f-64df085eca85@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
 <uwm53WfSm6lIeOTDR7dRew2L39VCIAQNaWFgi9g4vwc=.e66d74a1-c261-457d-8d22-7499400b64ee@github.com>
 <CPrtaN-iAmOQIS0MCMo9Ss3z_RDqKkeifZ2Ij6FRcCo=.62f9ade2-8472-4b3f-b448-ef73655eeb0b@github.com>
 <QbRR80JhYnzAnB9o9HMSJFU-lVpINvDXfh4AisP9VEM=.513ff0b8-d42e-4ef1-8c8b-88db1b72b772@github.com>
 <-V7ptCS4QdcpFHOomMnTPPYvFtKSQ0nswzFNXQDoWLg=.2d72897f-ef45-4867-892f-64df085eca85@github.com>
Message-ID: <-nQf8_Gh666U_KH2wCMBEApxI3GFXre1cghHN41KoVg=.c0bc85fd-16ed-49f5-a595-73893facf6df@github.com>

On Mon, 7 Feb 2022 13:43:55 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> Tell you what, first put a comment here that says when it should (and therefore, should not) be used. Once it's clear exactly what this is for, thinking of a name maight be easier.
>
> How about extending the existing enter() function: 
> 
> // Enter a new stack frame for the current method.
> // nested:     Indicates a frame has already been entered (and not left) for the current method. 
> void MacroAssembler::enter(bool nested=false) {
>    if (nested) strip()
>    protect()
>    stp()
>    mov()
> }
> 
> This would add an additional bool check for every call of enter() - that's at code generation time, so probably not an issue.

So, `nested` is true iff we are, say, pushing an extra frame for a runtime call in the middle of generated code, but for some mysterious reason the logic is inline instead of being implemented in the obvious way as a stub.

Please do this as:

` MacroAssembler::enter(bool strip_return_address=false)`

and I'll be happy. Please make sure that all calls are commented, as in

`__ enter(/*strip_return_address*/true);`

and I'll be happy.

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

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


From rriggs at openjdk.java.net  Mon Feb  7 23:27:04 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 7 Feb 2022 23:27:04 GMT
Subject: RFR: 8176706: Additional Date-Time Formats
In-Reply-To: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
Message-ID: <TLTr9A2TSl_uSuJLSq7o3UIbxghRaaXd1NQkW2hqd8U=.b534747f-751d-4f12-8cc3-4f1332704954@github.com>

On Thu, 3 Feb 2022 23:29:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion.
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5115:

> 5113: 
> 5114:         private LocalizedPrinterParser(FormatStyle dateStyle, FormatStyle timeStyle, String requestedTemplate) {
> 5115:             this.dateStyle = dateStyle;

Drop this constructor; it opens up the possibility of ambiguity between the modes.
Keep only the two constructors with disjoint checking and initialization.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5151:

> 5149:          */
> 5150:         private DateTimeFormatter formatter(Locale locale, Chronology chrono) {
> 5151:             var dtStyle = dateStyle !=null || timeStyle != null;

Switch to using requestedTemplate == null or != null as the discriminator.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5162:

> 5160: 
> 5161:                 formatter = new DateTimeFormatterBuilder().appendPattern(pattern).toFormatter(locale);
> 5162:                 DateTimeFormatter old = FORMATTER_CACHE.putIfAbsent(key, formatter);

.computeIfAbsent(key, () -> {....}) might be a bit cleaner/clearer here and avoid the race a few lines of code below. (a slight improvement in old code).

src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java line 606:

> 604:         var matcher = VALID_SKELETON_PATTERN.matcher(skeleton);
> 605:         if (!matcher.matches()) {
> 606:             throw new IllegalArgumentException("Requested template is invalid: " + requestedTemplate);

The substitutions are not going to be visible in the exception message.
That might make it harder to identify and fix the cause of the exception. Perhaps the message can make it clear that the matching was done after substitutions and show the 'skeleton'.

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

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


From joehw at openjdk.java.net  Tue Feb  8 01:06:07 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 8 Feb 2022 01:06:07 GMT
Subject: RFR: 8176706: Additional Date-Time Formats
In-Reply-To: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
Message-ID: <YgLawT4ZXr7VIR7Cjq2PztFFAAlnMp87O4IDibD0YoM=.648d175a-ad71-42a1-a1cf-b7260f120aa7@github.com>

On Thu, 3 Feb 2022 23:29:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion.
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 254:

> 252:     public static String getLocalizedDateTimePattern(String requestedTemplate,
> 253:                                                      Chronology chrono, Locale locale) {
> 254:         Objects.requireNonNull(locale, "requestedTemplate");

Typo, "locale" should have been requestedTemplate.

src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java line 77:

> 75:         LocaleProviderAdapter lpa = LocaleProviderAdapter.getResourceBundleBased();
> 76:         // CLDR's 'u'/'U' are not supported in the JDK. Replace them with 'y' instead
> 77:         final var modifiedSkeleton = requestedTemplate.replaceAll("[uU]", "y");

Seems to me requestedTemplate needs to be validated when it gets passed to getLocalizedDateTimePattern,  similar as to appendLocalized

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

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


From duke at openjdk.java.net  Tue Feb  8 07:56:09 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Tue, 8 Feb 2022 07:56:09 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible [v3]
In-Reply-To: <7W0KLfLePAm7WJIML5nKsG8kxgWEGw-5XsRqJMBiMAc=.d7c78265-5c28-4672-b4b3-1499fb715ce6@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
 <7W0KLfLePAm7WJIML5nKsG8kxgWEGw-5XsRqJMBiMAc=.d7c78265-5c28-4672-b4b3-1499fb715ce6@github.com>
Message-ID: <K4erR8JzatcOi6cRPcVq157wwRhk6J0BBdnMaqpOlgQ=.85a656b4-64f5-40be-99d3-532a380de4a0@github.com>

On Fri, 4 Feb 2022 18:37:51 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
>> 
>> For example:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
>> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
>> 
>> However, if a "normal" Unix-style path is provided, it gets converted correctly:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
>> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
>> 
>> 
>> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
>> 
>> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
>> 
>> 
>> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
>> 
>>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
>> make reconfigure clean
>> make images
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added validation of root paths.

@magicus Could you please take a look?

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

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


From chagedorn at openjdk.java.net  Tue Feb  8 08:17:17 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 8 Feb 2022 08:17:17 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v4]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <PESchU9s7SJ30uIlIhCkZZZb84bvppiRwBPMFBNJvs0=.1308e4f4-a4af-427b-b2db-f13f2a05be3a@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 one additional commit since the last revision:

  Make dwarf tag NOT_PRODUCT

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7126/files
  - new: https://git.openjdk.java.net/jdk/pull/7126/files/698663b9..820f0da6

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.java.net  Tue Feb  8 09:26:14 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Tue, 8 Feb 2022 09:26:14 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <PSXG9ufu1E8eEMInOxEogYJiWgeg051cY10oQv9G1T4=.bf62e54d-16b7-4032-ae44-55dee24a0877@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
 <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>
 <SlWAICcj0RKZKakcqy3yPPvV_FrEu0An9LYrjkFiUvA=.905f6d29-edb9-4ad0-812c-0cdc1b748000@github.com>
 <32e7_CnkkIaj2GOsvi9mT-xzgLO8B60uHrzMEAZXHko=.2ea9eaff-39c6-4401-9820-4536f03d5ec7@github.com>
 <PSXG9ufu1E8eEMInOxEogYJiWgeg051cY10oQv9G1T4=.bf62e54d-16b7-4032-ae44-55dee24a0877@github.com>
Message-ID: <n5enwyIUBovTlCjVXWbKBCayt4O2227qRPzbmzajzr0=.ba48446a-9279-453c-9cde-82b7755e1767@github.com>

On Mon, 7 Feb 2022 12:25:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> PreserveFramePointer is doing some additional stuff. I'll give it a test to make sure everything still works with PreserveFramePointer fully set. It would make things easier just to force it set with rop protection on.
>
>> PreserveFramePointer is doing some additional stuff. I'll give it a test to make sure everything still works with PreserveFramePointer fully set. It would make things easier just to force it set with rop protection on.
> 
> Using PreserveFramePointer greatly simplifies the testing matrix, and has little adverse performance impact beyond disallowing C2 from allocating FP as a scratch register. It also simplifies this patch, which would be a very Good Thing. Let's do it.

Doing this caused 7 failures across a full jtreg run, namely:

serviceability/sa/ClhsdbFindPC.java#xcomp-core
vmTestbase/jit/misctests/fpustack/GraphApplet.java
vmTestbase/nsk/jdi/MonitorWaitRequest/MonitorWaitRequest001/TestDescription.java
vmTestbase/nsk/jdi/MonitorWaitedRequest/MonitorWaitedRequest001/TestDescription.java
vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo002/ownedMonitorsStackDepthInfo002.java
vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java

....I'll investigate.

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

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


From aph at openjdk.java.net  Tue Feb  8 09:44:16 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 8 Feb 2022 09:44:16 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <n5enwyIUBovTlCjVXWbKBCayt4O2227qRPzbmzajzr0=.ba48446a-9279-453c-9cde-82b7755e1767@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
 <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>
 <SlWAICcj0RKZKakcqy3yPPvV_FrEu0An9LYrjkFiUvA=.905f6d29-edb9-4ad0-812c-0cdc1b748000@github.com>
 <32e7_CnkkIaj2GOsvi9mT-xzgLO8B60uHrzMEAZXHko=.2ea9eaff-39c6-4401-9820-4536f03d5ec7@github.com>
 <PSXG9ufu1E8eEMInOxEogYJiWgeg051cY10oQv9G1T4=.bf62e54d-16b7-4032-ae44-55dee24a0877@github.com>
 <n5enwyIUBovTlCjVXWbKBCayt4O2227qRPzbmzajzr0=.ba48446a-9279-453c-9cde-82b7755e1767@github.com>
Message-ID: <GXUcAo55K4vReK737EJE8VWuNh5fUP0O01nxczF5fV8=.0bb1ca06-d8d7-4440-92bb-eaad4e22a169@github.com>

On Tue, 8 Feb 2022 09:22:39 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

> Doing this caused 7 failures across a full jtreg run, namely:

I'm glad we caught that.

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

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


From naoto at openjdk.java.net  Tue Feb  8 18:40:40 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 8 Feb 2022 18:40:40 GMT
Subject: RFR: 8176706: Additional Date-Time Formats [v2]
In-Reply-To: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
Message-ID: <G8S_hI-nSpegyGkiW1oEzZ3JBh1ZFMmzmqylUspB5So=.17e26241-f4f7-4aa6-b144-489bd094f1f7@github.com>

> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion.
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html

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

  Modified per suggestions on the PR

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7340/files
  - new: https://git.openjdk.java.net/jdk/pull/7340/files/f9311dce..059132f5

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

  Stats: 80 lines in 4 files changed: 23 ins; 37 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7340.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7340/head:pull/7340

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


From naoto at openjdk.java.net  Tue Feb  8 18:47:06 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 8 Feb 2022 18:47:06 GMT
Subject: RFR: 8176706: Additional Date-Time Formats [v2]
In-Reply-To: <YgLawT4ZXr7VIR7Cjq2PztFFAAlnMp87O4IDibD0YoM=.648d175a-ad71-42a1-a1cf-b7260f120aa7@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
 <YgLawT4ZXr7VIR7Cjq2PztFFAAlnMp87O4IDibD0YoM=.648d175a-ad71-42a1-a1cf-b7260f120aa7@github.com>
Message-ID: <BrE1m2LdxaA_ycy3TcS6qKsrgj9p81GyS3nb0wCQ4jo=.7221a59a-b02c-474b-a949-1f137e1a45bf@github.com>

On Tue, 8 Feb 2022 00:39:04 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified per suggestions on the PR
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 254:
> 
>> 252:     public static String getLocalizedDateTimePattern(String requestedTemplate,
>> 253:                                                      Chronology chrono, Locale locale) {
>> 254:         Objects.requireNonNull(locale, "requestedTemplate");
> 
> Typo, "locale" should have been requestedTemplate.

Good catch!

> src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java line 77:
> 
>> 75:         LocaleProviderAdapter lpa = LocaleProviderAdapter.getResourceBundleBased();
>> 76:         // CLDR's 'u'/'U' are not supported in the JDK. Replace them with 'y' instead
>> 77:         final var modifiedSkeleton = requestedTemplate.replaceAll("[uU]", "y");
> 
> Seems to me requestedTemplate needs to be validated when it gets passed to getLocalizedDateTimePattern,  similar as to appendLocalized

This was a left over which should be removed. In fact, CLDR specific pattern symbols should not be accepted as the requested template. Removed the substitutions. As to the validation, it will be performed in the following `LocaleResources.getLocalizedPattern()` method.

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

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


From naoto at openjdk.java.net  Tue Feb  8 18:47:07 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 8 Feb 2022 18:47:07 GMT
Subject: RFR: 8176706: Additional Date-Time Formats [v2]
In-Reply-To: <TLTr9A2TSl_uSuJLSq7o3UIbxghRaaXd1NQkW2hqd8U=.b534747f-751d-4f12-8cc3-4f1332704954@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
 <TLTr9A2TSl_uSuJLSq7o3UIbxghRaaXd1NQkW2hqd8U=.b534747f-751d-4f12-8cc3-4f1332704954@github.com>
Message-ID: <htvPajLT-Ozv5sPMoisKjupzlfFaa9p42y2atfE3bjM=.c2735030-fcb8-46b5-83ae-b7059c3d01c5@github.com>

On Mon, 7 Feb 2022 21:22:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified per suggestions on the PR
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5162:
> 
>> 5160: 
>> 5161:                 formatter = new DateTimeFormatterBuilder().appendPattern(pattern).toFormatter(locale);
>> 5162:                 DateTimeFormatter old = FORMATTER_CACHE.putIfAbsent(key, formatter);
> 
> .computeIfAbsent(key, () -> {....}) might be a bit cleaner/clearer here and avoid the race a few lines of code below. (a slight improvement in old code).

Good point. Changed to `computeIfAbsent()`.

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

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


From naoto at openjdk.java.net  Tue Feb  8 19:08:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 8 Feb 2022 19:08:45 GMT
Subject: RFR: 8176706: Additional Date-Time Formats [v3]
In-Reply-To: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
Message-ID: <NEELCyXlakTpC-IEykVKSEDJLWP31TY-TgItmaKQNaM=.4f022565-7889-42e5-a738-94c85799e83b@github.com>

> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion.
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html

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

  Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7340/files
  - new: https://git.openjdk.java.net/jdk/pull/7340/files/059132f5..41408ff3

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

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

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


From joehw at openjdk.java.net  Tue Feb  8 22:30:05 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 8 Feb 2022 22:30:05 GMT
Subject: RFR: 8176706: Additional Date-Time Formats [v3]
In-Reply-To: <NEELCyXlakTpC-IEykVKSEDJLWP31TY-TgItmaKQNaM=.4f022565-7889-42e5-a738-94c85799e83b@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
 <NEELCyXlakTpC-IEykVKSEDJLWP31TY-TgItmaKQNaM=.4f022565-7889-42e5-a738-94c85799e83b@github.com>
Message-ID: <2dgb4gSfu-fI50MrhPVEkdnADRNN66izgUPngz8moKI=.6a74b414-0480-4fac-9bfe-1eefbe8c9256@github.com>

On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate

Marked as reviewed by joehw (Reviewer).

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

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


From gnu.andrew at redhat.com  Wed Feb  9 03:54:51 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 9 Feb 2022 03:54:51 +0000
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
 <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
Message-ID: <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>

On 20:33 Thu 03 Feb     , Severin Gehwolf wrote:
> On Wed, 2021-12-22 at 11:14 +0100, Severin Gehwolf wrote:
> > On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote:
> > > Hi,
> > > 
> > > Please review this adaptation of the corresponding JDK 11 patch. The
> > > JDK 11u patch didn't apply because the build system is widely different
> > > between these two releases.
> > > 
> > > The main difference is make/common/MakeBase.gmk (JDK 8) vs
> > > make/SourceRevision.gmk (JDK 11). I've basically rewritten those parts
> > > of the patch. All the SCM handling in JDK 8 is in MakeBase.
> > > FindAllReposAbs isn't present in JDK 8u.
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210283
> > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/01/webrev/
> > > 
> > > Testing: "make --trace source-tips" on mercurial tree as well as
> > > ???????? the git mirror. $IMAGE_DIR/release file contains the SHA of
> > > ???????? the sources it was built from with 'git:' or 'hg:' prefixes.
> > > 
> > > Thoughts?
> > 
> > Anyone? When building from the git read-only mirror the "release" file
> > no longer includes the git sha it was built from without this fix.
>

Well, surely it's never contained a git SHA? :)
It doesn't have the source IDs because there is no Mercurial repository
information, so it's as if it was built from a source tarball or some such.

> Anyone willing to review this?
> 
> Thanks,
> Severin
> 

This looks ok to me. I would omit the line "Called from
jdk/make/closed/bundles.gmk" because this file doesn't exist in our
repository and we have no idea what it does or doesn't contain.

I think it's also worth noting in the summary text that this removes
the forest handling, which wasn't part of the original change for
obvious reasons.

JDK-8031567 was the change that introduced make/SourceRevision.gmk,
but that was at a time when Mercurial forests were still in use, and
it seems that the use of `hg id` has been adopted in 8u separately
form that bug anyway.

I think this change is simple enough as is for what we need, though
I'll admit I've never made use of this functionality myself.

Thanks,
-- 
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 ihse at openjdk.java.net  Thu Feb 10 09:20:04 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 09:20:04 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible [v3]
In-Reply-To: <7W0KLfLePAm7WJIML5nKsG8kxgWEGw-5XsRqJMBiMAc=.d7c78265-5c28-4672-b4b3-1499fb715ce6@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
 <7W0KLfLePAm7WJIML5nKsG8kxgWEGw-5XsRqJMBiMAc=.d7c78265-5c28-4672-b4b3-1499fb715ce6@github.com>
Message-ID: <YlkDO4l7jY7GsY9zW6ITHtqbiVBOMp5z8Ah-YmAH8jY=.b64df25b-0e30-4041-b9ec-74d694721a39@github.com>

On Fri, 4 Feb 2022 18:37:51 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
>> 
>> For example:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
>> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
>> 
>> However, if a "normal" Unix-style path is provided, it gets converted correctly:
>> 
>> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
>> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
>> 
>> 
>> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
>> 
>> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
>> 
>> 
>> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
>> 
>>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
>> make reconfigure clean
>> make images
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added validation of root paths.

Looks good. Thanks for catching this!

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Thu Feb 10 10:24:42 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 10:24:42 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v5]
In-Reply-To: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
Message-ID: <S3JZ6NgJUHSVWz67ElrUeQo9_gXmow_IPoQWSsMwoEs=.aaac93ba-9a86-4a0d-b54a-49dbec989828@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix incorrect assumptions about fullVersion in InfoOptsTest

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6152/files
  - new: https://git.openjdk.java.net/jdk/pull/6152/files/0954dd55..fa33f675

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

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

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


From ihse at openjdk.java.net  Thu Feb 10 10:34:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 10:34:10 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <4nC5k7QaTy0Z9_-7o_sErdrsRFzxvIqC01Xr5V_xvgg=.d4dbd7e7-71b7-45f8-a136-19c0fa87bd65@github.com>

On Wed, 13 Oct 2021 00:00:22 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.

Yes bot, thank you for the reminder.

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

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


From duke at openjdk.java.net  Thu Feb 10 10:34:37 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Thu, 10 Feb 2022 10:34:37 GMT
Subject: RFR: 8281262: Windows builds in different directories are not
 fully reproducible [v4]
In-Reply-To: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
Message-ID: <ZyWtp1x3ogtt-SXtfy4vfcNwOFcAgA3kDhjrvGaNujI=.c54cd0fc-b933-4a3f-bea2-5d3be8e5c250@github.com>

> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
> 
> For example:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
> 
> However, if a "normal" Unix-style path is provided, it gets converted correctly:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
> 
> 
> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
> 
> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
> 
> 
> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
> 
>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
> make reconfigure clean
> make images

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

  Update full name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7344/files
  - new: https://git.openjdk.java.net/jdk/pull/7344/files/c66ea187..7c6dc561

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

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

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


From duke at openjdk.java.net  Thu Feb 10 10:50:13 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Thu, 10 Feb 2022 10:50:13 GMT
Subject: Integrated: 8281262: Windows builds in different directories are not
 fully reproducible
In-Reply-To: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
References: <406hB5Jotvef6L7ygbA2d8qJj7yw94nhc_E0D9QfD00=.6a50061e-1399-48b2-9377-fe026b77cf3f@github.com>
Message-ID: <38OcFA2DDq1pyURfRFx4U8954aLoLPtMC88SyHXdIiw=.0ff1df09-94e0-4a49-9eae-ce3afa878126@github.com>

On Fri, 4 Feb 2022 10:55:40 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
> 
> For example:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
> 
> However, if a "normal" Unix-style path is provided, it gets converted correctly:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
> 
> 
> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
> 
> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
> 
> 
> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
> 
>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
> make reconfigure clean
> make images

This pull request has now been integrated.

Changeset: d442328b
Author:    Maxim Kartashev <maxim.kartashev at jetbrains.com>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d442328bc2f2f4bc35dd054487a78552e3d9a759
Stats:     12 lines in 3 files changed: 7 ins; 2 del; 3 mod

8281262: Windows builds in different directories are not fully reproducible

Co-authored-by: Erik Joelsson <erikj at openjdk.org>
Reviewed-by: erikj, ihse

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

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


From sgehwolf at redhat.com  Thu Feb 10 13:09:16 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 10 Feb 2022 14:09:16 +0100
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
 <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
 <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>
Message-ID: <1ab8f8792f8b4bb66704b8a60c35991b1d372ae5.camel@redhat.com>

Hi Andrew,

On Wed, 2022-02-09 at 03:54 +0000, Andrew Hughes wrote:
> On 20:33 Thu 03 Feb???? , Severin Gehwolf wrote:
> > On Wed, 2021-12-22 at 11:14 +0100, Severin Gehwolf wrote:
> > > On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Please review this adaptation of the corresponding JDK 11 patch. The
> > > > JDK 11u patch didn't apply because the build system is widely different
> > > > between these two releases.
> > > > 
> > > > The main difference is make/common/MakeBase.gmk (JDK 8) vs
> > > > make/SourceRevision.gmk (JDK 11). I've basically rewritten those parts
> > > > of the patch. All the SCM handling in JDK 8 is in MakeBase.
> > > > FindAllReposAbs isn't present in JDK 8u.
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210283
> > > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/01/webrev/
> > > > 
> > > > Testing: "make --trace source-tips" on mercurial tree as well as
> > > > ???????? the git mirror. $IMAGE_DIR/release file contains the SHA of
> > > > ???????? the sources it was built from with 'git:' or 'hg:' prefixes.
> > > > 
> > > > Thoughts?
> > > 
> > > Anyone? When building from the git read-only mirror the "release" file
> > > no longer includes the git sha it was built from without this fix.
> > 
> 
> Well, surely it's never contained a git SHA? :)
> It doesn't have the source IDs because there is no Mercurial repository
> information, so it's as if it was built from a source tarball or some such.
> 
> > Anyone willing to review this?
> > 
> > Thanks,
> > Severin
> > 
> 
> This looks ok to me. I would omit the line "Called from
> jdk/make/closed/bundles.gmk" because this file doesn't exist in our
> repository and we have no idea what it does or doesn't contain.

Removed that part of the comment.

> I think it's also worth noting in the summary text that this removes
> the forest handling, which wasn't part of the original change for
> obvious reasons.

Done.

> JDK-8031567 was the change that introduced make/SourceRevision.gmk,
> but that was at a time when Mercurial forests were still in use, and
> it seems that the use of `hg id` has been adopted in 8u separately
> form that bug anyway.
> 
> I think this change is simple enough as is for what we need, though
> I'll admit I've never made use of this functionality myself.

Latest webrev:
https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/02/webrev/

OK?

Thanks,
Severin



From ihse at openjdk.java.net  Thu Feb 10 15:19:47 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 15:19:47 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v6]
In-Reply-To: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
Message-ID: <dU_WaHl0km_g5z-46EQbsbuDEGr4yiyu1A7z52R2Yyk=.ff0ecef6-81f7-4793-b5fa-a632e32531d8@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix incorrect version string format assumption in Basic.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6152/files
  - new: https://git.openjdk.java.net/jdk/pull/6152/files/fa33f675..92d78c48

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

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

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


From ihse at openjdk.java.net  Thu Feb 10 15:52:50 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 15:52:50 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v7]
In-Reply-To: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
Message-ID: <kk1fDxkmcHgBMQZy6cVaL2WVg-ScfetBfZBcSt59M0A=.6140cbc2-37ee-471c-b39a-2a1e49aa4834@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove "build 0" from GHA builds
 - Warn that build 0 is "no build"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6152/files
  - new: https://git.openjdk.java.net/jdk/pull/6152/files/92d78c48..d433de3a

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

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

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


From ihse at openjdk.java.net  Thu Feb 10 15:58:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 15:58:10 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v7]
In-Reply-To: <kk1fDxkmcHgBMQZy6cVaL2WVg-ScfetBfZBcSt59M0A=.6140cbc2-37ee-471c-b39a-2a1e49aa4834@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
 <kk1fDxkmcHgBMQZy6cVaL2WVg-ScfetBfZBcSt59M0A=.6140cbc2-37ee-471c-b39a-2a1e49aa4834@github.com>
Message-ID: <tqFaUddPNYW_Bch9qQeRzAjaYW1SO6149djXkKmriLw=.cbeecd48-789f-4ec6-896c-f91c9246fef2@github.com>

On Thu, 10 Feb 2022 15:52:50 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.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove "build 0" from GHA builds
>  - Warn that build 0 is "no build"

This was more problematic than expected. Two tests made unfounded assumptions about version string format; one was simple to fix but the other tricky to track down, since I initially could not reproduce it locally but only in our CI testing. (It turned out that this was since the CI testing made a specially formatted version string.) 

The GHA actions all made use of "--with-version-build=0", and thus all of them failed when trying to upload builds. It took me a while to realize that this was due to file names with version strings in them, and not general shakiness of the GHA builds.

I think this is finally ready for review now. :-)

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

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


From ihse at openjdk.java.net  Thu Feb 10 16:09:47 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 16:09:47 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v8]
In-Reply-To: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
Message-ID: <Yp4OgbHCIRqAI12q9P9vjGbrK7h9ILPAQo-gMO2agsQ=.01841a8b-0763-4540-a42c-73a65443c277@github.com>

> 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.

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

 - Merge branch 'master' into improve-adhoc-version-string
 - Remove "build 0" from GHA builds
 - Warn that build 0 is "no build"
 - Fix incorrect version string format assumption in Basic.java
 - Fix incorrect assumptions about fullVersion in InfoOptsTest
 - Merge branch 'master' into improve-adhoc-version-string
 - IS_EMPTY define did not work on msvc
 - Break long lines
 - Skip setting git branch in adhoc version opt
 - Fix for abtract_vm_version so it really handles empty VERSION_BUILD
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/655da37e...15216c9a

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6152/files
  - new: https://git.openjdk.java.net/jdk/pull/6152/files/d433de3a..15216c9a

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

  Stats: 7108 lines in 181 files changed: 5450 ins; 888 del; 770 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6152/head:pull/6152

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


From aph at openjdk.java.net  Thu Feb 10 16:21:12 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 10 Feb 2022 16:21:12 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <GXUcAo55K4vReK737EJE8VWuNh5fUP0O01nxczF5fV8=.0bb1ca06-d8d7-4440-92bb-eaad4e22a169@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
 <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>
 <SlWAICcj0RKZKakcqy3yPPvV_FrEu0An9LYrjkFiUvA=.905f6d29-edb9-4ad0-812c-0cdc1b748000@github.com>
 <32e7_CnkkIaj2GOsvi9mT-xzgLO8B60uHrzMEAZXHko=.2ea9eaff-39c6-4401-9820-4536f03d5ec7@github.com>
 <PSXG9ufu1E8eEMInOxEogYJiWgeg051cY10oQv9G1T4=.bf62e54d-16b7-4032-ae44-55dee24a0877@github.com>
 <n5enwyIUBovTlCjVXWbKBCayt4O2227qRPzbmzajzr0=.ba48446a-9279-453c-9cde-82b7755e1767@github.com>
 <GXUcAo55K4vReK737EJE8VWuNh5fUP0O01nxczF5fV8=.0bb1ca06-d8d7-4440-92bb-eaad4e22a169@github.com>
Message-ID: <9wCVZ8gCStf_tUT8_WQjhLzXqqQlQMsijeiBaAXDVVk=.aace6af6-bf1b-40c9-ba19-6fd0ab9b1b0a@github.com>

On Tue, 8 Feb 2022 09:40:49 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Doing this caused 7 failures across a full jtreg run, namely:
>> 
>> serviceability/sa/ClhsdbFindPC.java#xcomp-core
>> vmTestbase/jit/misctests/fpustack/GraphApplet.java
>> vmTestbase/nsk/jdi/MonitorWaitRequest/MonitorWaitRequest001/TestDescription.java
>> vmTestbase/nsk/jdi/MonitorWaitedRequest/MonitorWaitedRequest001/TestDescription.java
>> vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
>> vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo002/ownedMonitorsStackDepthInfo002.java
>> vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java
>> 
>> ....I'll investigate.
>
>> Doing this caused 7 failures across a full jtreg run, namely:
> 
> I'm glad we caught that.

Status? Is branch protection really incompatible with PreserveFramePointer?

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

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


From ihse at openjdk.java.net  Thu Feb 10 16:37:42 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 16:37:42 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v9]
In-Reply-To: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
Message-ID: <ZSgItDrBKs5cmLGRpd_bcAvz28YjWuOjU82Ksp_icA8=.aaeb8c34-906f-452c-87b8-2737c61d2d62@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Bundle names was broken, too...

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6152/files
  - new: https://git.openjdk.java.net/jdk/pull/6152/files/15216c9a..35a1dfe0

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

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

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


From duke at openjdk.java.net  Thu Feb 10 16:39:53 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 10 Feb 2022 16:39:53 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <9wCVZ8gCStf_tUT8_WQjhLzXqqQlQMsijeiBaAXDVVk=.aace6af6-bf1b-40c9-ba19-6fd0ab9b1b0a@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
 <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>
 <SlWAICcj0RKZKakcqy3yPPvV_FrEu0An9LYrjkFiUvA=.905f6d29-edb9-4ad0-812c-0cdc1b748000@github.com>
 <32e7_CnkkIaj2GOsvi9mT-xzgLO8B60uHrzMEAZXHko=.2ea9eaff-39c6-4401-9820-4536f03d5ec7@github.com>
 <PSXG9ufu1E8eEMInOxEogYJiWgeg051cY10oQv9G1T4=.bf62e54d-16b7-4032-ae44-55dee24a0877@github.com>
 <n5enwyIUBovTlCjVXWbKBCayt4O2227qRPzbmzajzr0=.ba48446a-9279-453c-9cde-82b7755e1767@github.com>
 <GXUcAo55K4vReK737EJE8VWuNh5fUP0O01nxczF5fV8=.0bb1ca06-d8d7-4440-92bb-eaad4e22a169@github.com>
 <9wCVZ8gCStf_tUT8_WQjhLzXqqQlQMsijeiBaAXDVVk=.aace6af6-bf1b-40c9-ba19-6fd0ab9b1b0a@github.com>
Message-ID: <Uty-dsfgY9W0NYBBRCf8a_RKA3RpTVSEPTeowxIBeoI=.1e872980-760a-452f-87a7-1e725e92ab4b@github.com>

On Thu, 10 Feb 2022 16:18:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> Doing this caused 7 failures across a full jtreg run, namely:
>> 
>> I'm glad we caught that.
>
> Status? Is branch protection really incompatible with PreserveFramePointer?

Eventually found a missing signing in the exception handling. I'm running the full suite now, so should hopefully get something posted tomorrow.

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

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


From duke at openjdk.java.net  Thu Feb 10 16:39:52 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 10 Feb 2022 16:39:52 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <-nQf8_Gh666U_KH2wCMBEApxI3GFXre1cghHN41KoVg=.c0bc85fd-16ed-49f5-a595-73893facf6df@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <1oSiO-f26IoFOcPDhOOeWrr8x2cH_Wyv4aAjI9gX9-0=.21f677c9-61a4-469e-891c-f35bc469b7e2@github.com>
 <uwm53WfSm6lIeOTDR7dRew2L39VCIAQNaWFgi9g4vwc=.e66d74a1-c261-457d-8d22-7499400b64ee@github.com>
 <CPrtaN-iAmOQIS0MCMo9Ss3z_RDqKkeifZ2Ij6FRcCo=.62f9ade2-8472-4b3f-b448-ef73655eeb0b@github.com>
 <QbRR80JhYnzAnB9o9HMSJFU-lVpINvDXfh4AisP9VEM=.513ff0b8-d42e-4ef1-8c8b-88db1b72b772@github.com>
 <-V7ptCS4QdcpFHOomMnTPPYvFtKSQ0nswzFNXQDoWLg=.2d72897f-ef45-4867-892f-64df085eca85@github.com>
 <-nQf8_Gh666U_KH2wCMBEApxI3GFXre1cghHN41KoVg=.c0bc85fd-16ed-49f5-a595-73893facf6df@github.com>
Message-ID: <tSbASAhYFyOZexuxf45FDIFZ2nsz2b7qtqGHc-x_IfI=.e1ea8c5e-02e1-4759-afaf-74d4f184f7a9@github.com>

On Mon, 7 Feb 2022 15:12:04 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> How about extending the existing enter() function: 
>> 
>> // Enter a new stack frame for the current method.
>> // nested:     Indicates a frame has already been entered (and not left) for the current method. 
>> void MacroAssembler::enter(bool nested=false) {
>>    if (nested) strip()
>>    protect()
>>    stp()
>>    mov()
>> }
>> 
>> This would add an additional bool check for every call of enter() - that's at code generation time, so probably not an issue.
>
> So, `nested` is true iff we are, say, pushing an extra frame for a runtime call in the middle of generated code, but for some mysterious reason the logic is inline instead of being implemented in the obvious way as a stub.
> 
> Please do this as:
> 
> ` MacroAssembler::enter(bool strip_return_address=false)`
> 
> and I'll be happy. Please make sure that all calls are commented, as in
> 
> `__ enter(/*strip_return_address*/true);`
> 
> and I'll be happy.

Just about to resolve this ... then spotted the "make sure that all calls are commented". Will fix up.

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

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


From duke at openjdk.java.net  Thu Feb 10 16:39:51 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 10 Feb 2022 16:39:51 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v20]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <fVz9lmTGhMrS6aKv-bS3isMfwujZLJ123Ce8hGjiQ_A=.ec3ec98f-e7a3-44c6-8df5-c86ee187b261@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:

  Merge enter_subframe into enter

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/614a3262..f779513b

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

  Stats: 20 lines in 5 files changed: 5 ins; 9 del; 6 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 ihse at openjdk.java.net  Thu Feb 10 16:42:47 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 16:42:47 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v10]
In-Reply-To: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
Message-ID: <H-sfUvRqu6Uy5eyqQamPywjJYCJZUrtNdcRw0mAflKA=.400064f5-13cb-4ed2-b7d2-e9fa41c07654@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Adhoc build marker needs correction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6152/files
  - new: https://git.openjdk.java.net/jdk/pull/6152/files/35a1dfe0..726a69e1

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

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

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


From duke at openjdk.java.net  Thu Feb 10 18:53:45 2022
From: duke at openjdk.java.net (Pavel Kharskii)
Date: Thu, 10 Feb 2022 18:53:45 GMT
Subject: [jdk18] RFR: 8280415: Remove EA from JDK 18 version string starting
 with Initial RC promotion B35 on February 10, 2022
Message-ID: <hsFt6X0WOcJ91p2_6yTKLsoiEvjR6IWKkS3sKFBEYsk=.af0ac42a-8c52-4818-a11c-af44b2f7dea2@github.com>

?C promotion B35 on February 10, 2022

Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022

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

Commit messages:
 - 8280415: Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022

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

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


From erikj at openjdk.java.net  Thu Feb 10 19:11:16 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 10 Feb 2022 19:11:16 GMT
Subject: [jdk18] RFR: 8280415: Remove EA from JDK 18 version string
 starting with Initial RC promotion B35 on February 10, 2022
In-Reply-To: <hsFt6X0WOcJ91p2_6yTKLsoiEvjR6IWKkS3sKFBEYsk=.af0ac42a-8c52-4818-a11c-af44b2f7dea2@github.com>
References: <hsFt6X0WOcJ91p2_6yTKLsoiEvjR6IWKkS3sKFBEYsk=.af0ac42a-8c52-4818-a11c-af44b2f7dea2@github.com>
Message-ID: <1zd8gmExVypmAUblp2fhclra4wpz0UF5oygtte9NQzk=.0c33c256-5092-4daf-9611-a1167168e1cc@github.com>

On Thu, 10 Feb 2022 18:46:13 GMT, Pavel Kharskii <duke at openjdk.java.net> wrote:

> ?C promotion B35 on February 10, 2022
> 
> Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022

Marked as reviewed by erikj (Reviewer).

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

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


From iris at openjdk.java.net  Thu Feb 10 19:19:10 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 10 Feb 2022 19:19:10 GMT
Subject: [jdk18] RFR: 8280415: Remove EA from JDK 18 version string
 starting with Initial RC promotion B35 on February 10, 2022
In-Reply-To: <hsFt6X0WOcJ91p2_6yTKLsoiEvjR6IWKkS3sKFBEYsk=.af0ac42a-8c52-4818-a11c-af44b2f7dea2@github.com>
References: <hsFt6X0WOcJ91p2_6yTKLsoiEvjR6IWKkS3sKFBEYsk=.af0ac42a-8c52-4818-a11c-af44b2f7dea2@github.com>
Message-ID: <Qj01NMpfdUCW5vvD_wVMNdDo0SXb8hFJ1uMilducN1E=.acf9b701-1f82-463c-b0b0-c226490fe325@github.com>

On Thu, 10 Feb 2022 18:46:13 GMT, Pavel Kharskii <duke at openjdk.java.net> wrote:

> ?C promotion B35 on February 10, 2022
> 
> Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022

Marked as reviewed by iris (Reviewer).

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

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


From rriggs at openjdk.java.net  Thu Feb 10 21:35:11 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 10 Feb 2022 21:35:11 GMT
Subject: RFR: 8176706: Additional Date-Time Formats [v3]
In-Reply-To: <NEELCyXlakTpC-IEykVKSEDJLWP31TY-TgItmaKQNaM=.4f022565-7889-42e5-a738-94c85799e83b@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
 <NEELCyXlakTpC-IEykVKSEDJLWP31TY-TgItmaKQNaM=.4f022565-7889-42e5-a738-94c85799e83b@github.com>
Message-ID: <O695cf6rDfQEwYJJ5574_Zg2WBTPPWBsiVCAWCtSk6A=.63723c3c-6d7c-4731-822d-f739b28ef670@github.com>

On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate

make/jdk/src/classes/build/tools/cldrconverter/Bundle.java line 113:

> 111:     // DateFormatItem prefix
> 112:     final static String DATEFORMATITEM_KEY_PREFIX = "DateFormatItem.";
> 113:     final static String DATEFORMATITEM_INPUT_REGIONS_PREFIX = "DateFormatItemInputRegions.";

The canonical order of modifiers is "static final".

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

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


From rriggs at openjdk.java.net  Thu Feb 10 22:26:30 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 10 Feb 2022 22:26:30 GMT
Subject: RFR: 8176706: Additional Date-Time Formats [v3]
In-Reply-To: <NEELCyXlakTpC-IEykVKSEDJLWP31TY-TgItmaKQNaM=.4f022565-7889-42e5-a738-94c85799e83b@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
 <NEELCyXlakTpC-IEykVKSEDJLWP31TY-TgItmaKQNaM=.4f022565-7889-42e5-a738-94c85799e83b@github.com>
Message-ID: <X3bETQRvMdAjt0OgyU3o7r3ITnD_ziwwVlR0GmMHKik=.01789868-4b50-4415-802b-07f7d35f3bea@github.com>

On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 742:

> 740:      * All pattern symbols are optional, and each pattern symbol represents the field it is in,
> 741:      * e.g., 'M' represents the Month field. The number of the pattern symbol letters follows the
> 742:      * same presentation, such as "number" or "text" as in the <a href="#patterns">Patterns for

I would reword as:
     * All pattern symbols are optional, and each pattern symbol represents a field,
     * for example, 'M' represents the Month field. The number of the pattern symbol letters follows the

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 753:

> 751:      * <p>
> 752:      * The locale is determined from the formatter. The formatter returned directly by
> 753:      * this method will use the {@link Locale#getDefault() default FORMAT locale}.

Editorial suggestion:
* this method uses the {https://github.com/link Locale#getDefault() default FORMAT locale}.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 231:

> 229: 
> 230:     /**
> 231:      * Gets the formatting pattern for the requested template for a locale and chronology.

"Returns" is more conventional (than "Gets; though it is consistent within the file)

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 246:

> 244:      * @param locale  the locale, non-null
> 245:      * @return the locale and Chronology specific formatting pattern
> 246:      * @throws IllegalArgumentException if {@code requestedTemplate} is invalid

The meaning "Invalid" should be clearly defined; repeating or refering to the template regex.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1485:

> 1483:      * <li>the {@code requestedTemplate} specified to this method
> 1484:      * <li>the {@code Locale} of the {@code DateTimeFormatter}
> 1485:      * <li>the {@code Chronology}, selecting the best available

Perhaps "best available" should be well defined, or just drop "best".
or ...
"of the {@code DateTimeFormatter} unless overridden"

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1513:

> 1511:      * }
> 1512:      * All pattern symbols are optional, and each pattern symbol represents the field it is in,
> 1513:      * e.g., 'M' represents the Month field. The number of the pattern symbol letters follows the

Ditto above:
    * All pattern symbols are optional, and each pattern symbol represents the field,
     * for example, 'M' represents the Month field. The number of the pattern symbol letters follows the

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5148:

> 5146:             var useRequestedTemplate = requestedTemplate != null;
> 5147:             String key = chrono.getId() + '|' + locale.toString() + '|' +
> 5148:                     (useRequestedTemplate ? requestedTemplate : Objects.toString(dateStyle) + timeStyle);

The boolean `useRequestedTemplate` isn't necessary, replace with `requestedTemplate != null`.

src/java.base/share/classes/sun/text/spi/JavaTimeDateTimePatternProvider.java line 64:

> 62: 
> 63:     /**
> 64:      * Gets the formatting pattern for the requested template, calendarType, and locale.

"Returns" is more conventional.

src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java line 69:

> 67:     public String getJavaTimeDateTimePattern(int timeStyle, int dateStyle, String calType, Locale locale) {
> 68:         LocaleResources lr = LocaleProviderAdapter.getResourceBundleBased().getLocaleResources(locale);
> 69:         return lr.getJavaTimeDateTimePattern(

Fold the parameters onto a single line.

src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java line 690:

> 688:     private String resolveInputSkeleton(String type) {
> 689:         var regionToSkeletonMap = inputSkeletons.get(type);
> 690:         return regionToSkeletonMap.getOrDefault(locale.getLanguage() + "-" + locale.getCountry(),

This structure computes all the defaults even if the value isn't needed (because the value has to be passed to the `getOrDefault` method.  Perhaps performance isn't an issue.

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

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


From naoto at openjdk.java.net  Fri Feb 11 00:03:50 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 11 Feb 2022 00:03:50 GMT
Subject: RFR: 8176706: Additional Date-Time Formats [v4]
In-Reply-To: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
Message-ID: <oiclTmjmh-Ik4Qg59_ErggSMKtOc-jLxJeVvFbID_dE=.780a5d6e-4838-4d31-8df9-ba6c91012ced@github.com>

> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion.
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html

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

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7340/files
  - new: https://git.openjdk.java.net/jdk/pull/7340/files/41408ff3..af3c0d62

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

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

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


From naoto at openjdk.java.net  Fri Feb 11 00:03:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 11 Feb 2022 00:03:52 GMT
Subject: RFR: 8176706: Additional Date-Time Formats [v3]
In-Reply-To: <X3bETQRvMdAjt0OgyU3o7r3ITnD_ziwwVlR0GmMHKik=.01789868-4b50-4415-802b-07f7d35f3bea@github.com>
References: <PTDvD7wARfs_lb54r4SepBZzfe6WrYnCXSwrDpwd7yw=.48744d8f-2293-4bdb-a1a9-ba901513354a@github.com>
 <NEELCyXlakTpC-IEykVKSEDJLWP31TY-TgItmaKQNaM=.4f022565-7889-42e5-a738-94c85799e83b@github.com>
 <X3bETQRvMdAjt0OgyU3o7r3ITnD_ziwwVlR0GmMHKik=.01789868-4b50-4415-802b-07f7d35f3bea@github.com>
Message-ID: <WCUIB1H5SQnpeejuSgMvhLIu4wRGiQO44LQ49z0vmbM=.d97bcfc4-ca22-414c-9d44-e50779412314@github.com>

On Thu, 10 Feb 2022 22:20:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate
>
> src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java line 690:
> 
>> 688:     private String resolveInputSkeleton(String type) {
>> 689:         var regionToSkeletonMap = inputSkeletons.get(type);
>> 690:         return regionToSkeletonMap.getOrDefault(locale.getLanguage() + "-" + locale.getCountry(),
> 
> This structure computes all the defaults even if the value isn't needed (because the value has to be passed to the `getOrDefault` method.  Perhaps performance isn't an issue.

Indeed, yes. I thought this was simple enough, and as you said, not performance-critical.

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

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


From shade at openjdk.java.net  Fri Feb 11 10:11:05 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 11 Feb 2022 10:11:05 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v10]
In-Reply-To: <H-sfUvRqu6Uy5eyqQamPywjJYCJZUrtNdcRw0mAflKA=.400064f5-13cb-4ed2-b7d2-e9fa41c07654@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
 <H-sfUvRqu6Uy5eyqQamPywjJYCJZUrtNdcRw0mAflKA=.400064f5-13cb-4ed2-b7d2-e9fa41c07654@github.com>
Message-ID: <xR5BUrwhMgaX7wfUFSVOJtyFYTmUymEF4rIC2s7H0Mg=.f06fe801-f3bb-4dde-a904-621fcc7a57b7@github.com>

On Thu, 10 Feb 2022 16:42:47 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.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adhoc build marker needs correction

I like this. Built the adhoc binary with this patch, and version string is nice:


$ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -version
openjdk version "19-internal" 2022-09-20
OpenJDK Runtime Environment (fastdebug build 19-internal-adhoc.shade.jdk)
OpenJDK 64-Bit Server VM (fastdebug build 19-internal-adhoc.shade.jdk, mixed mode, sharing)

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

Marked as reviewed by shade (Reviewer).

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


From duke at openjdk.java.net  Fri Feb 11 11:37:56 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Fri, 11 Feb 2022 11:37:56 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v21]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <q7COfX45QCv3kkh7_TESYcpjBed_V0bC-ehP6IZjmIc=.83dac5d1-1da3-4c05-b11b-202ba6934d6d@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:

 - Add comments to enter calls
 - Set PreserveFramePointer if use_rop_protection is set

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/f779513b..2062cce7

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

  Stats: 26 lines in 8 files changed: 16 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6334.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6334/head:pull/6334

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


From duke at openjdk.java.net  Fri Feb 11 11:37:56 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Fri, 11 Feb 2022 11:37:56 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v18]
In-Reply-To: <Uty-dsfgY9W0NYBBRCf8a_RKA3RpTVSEPTeowxIBeoI=.1e872980-760a-452f-87a7-1e725e92ab4b@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <8eyrOM5Brgjz4517k80s5RW3HhTDdhevVZOCS8jbIl0=.b41a377e-2235-4310-9b4c-e75e473eb236@github.com>
 <XinD5VcGuT9VrlzDYqaJkwk29Q_CjJAtbHUDCgAfxWo=.bbfac0b0-b844-4a9a-a6fc-bd210928aadc@github.com>
 <aB-65S2vlvi8YgK05r0nIiLnxaOoCueWt030UI_QhgQ=.4a1eccba-b87a-43e4-babe-14c75c755aa5@github.com>
 <SlWAICcj0RKZKakcqy3yPPvV_FrEu0An9LYrjkFiUvA=.905f6d29-edb9-4ad0-812c-0cdc1b748000@github.com>
 <32e7_CnkkIaj2GOsvi9mT-xzgLO8B60uHrzMEAZXHko=.2ea9eaff-39c6-4401-9820-4536f03d5ec7@github.com>
 <PSXG9ufu1E8eEMInOxEogYJiWgeg051cY10oQv9G1T4=.bf62e54d-16b7-4032-ae44-55dee24a0877@github.com>
 <n5enwyIUBovTlCjVXWbKBCayt4O2227qRPzbmzajzr0=.ba48446a-9279-453c-9cde-82b7755e1767@github.com>
 <GXUcAo55K4vReK737EJE8VWuNh5fUP0O01nxczF5fV8=.0bb1ca06-d8d7-4440-92bb-eaad4e22a169@github.com>
 <9wCVZ8gCStf_tUT8_WQjhLzXqqQlQMsijeiBaAXDVVk=.aace6af6-bf1b-40c9-ba19-6fd0ab9b1b0a@github.com>
 <Uty-dsfgY9W0NYBBRCf8a_RKA3RpTVSEPTe
 owxIBeoI=.1e872980-760a-452f-87a7-1e725e92ab4b@github.com>
Message-ID: <44zejAzpVh55H_lUbDPm3eCzG5NoUjvO2zJVQRZ83G8=.22ae70e3-76fb-4e33-9cae-41c4a4876a54@github.com>

On Thu, 10 Feb 2022 16:32:25 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> Status? Is branch protection really incompatible with PreserveFramePointer?
>
> Eventually found a missing signing in the exception handling. I'm running the full suite now, so should hopefully get something posted tomorrow.

New patches fix the failures

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

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


From erikj at openjdk.java.net  Fri Feb 11 13:44:04 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 11 Feb 2022 13:44:04 GMT
Subject: RFR: 8274980: Improve adhoc build version strings [v10]
In-Reply-To: <H-sfUvRqu6Uy5eyqQamPywjJYCJZUrtNdcRw0mAflKA=.400064f5-13cb-4ed2-b7d2-e9fa41c07654@github.com>
References: <_-ASswZ8ksJQA9q6BpdLwCZWXfT_Fbq4o6FHgnC9pbY=.bf2fa1fb-aa32-400e-b257-263b2348e563@github.com>
 <H-sfUvRqu6Uy5eyqQamPywjJYCJZUrtNdcRw0mAflKA=.400064f5-13cb-4ed2-b7d2-e9fa41c07654@github.com>
Message-ID: <WkmPPAtVbSf-ieAAPAM6ByfZPvKf_jX9cxrQAn33CVM=.affbe700-ebeb-418a-b3ad-fb36749c4842@github.com>

On Thu, 10 Feb 2022 16:42:47 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.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adhoc build marker needs correction

Marked as reviewed by erikj (Reviewer).

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

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


From aph at openjdk.java.net  Fri Feb 11 16:42:16 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 11 Feb 2022 16:42:16 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v21]
In-Reply-To: <q7COfX45QCv3kkh7_TESYcpjBed_V0bC-ehP6IZjmIc=.83dac5d1-1da3-4c05-b11b-202ba6934d6d@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <q7COfX45QCv3kkh7_TESYcpjBed_V0bC-ehP6IZjmIc=.83dac5d1-1da3-4c05-b11b-202ba6934d6d@github.com>
Message-ID: <U-Z_r06zb3PTwB5u0vU_3OsNTfe3_sZRtpcNdYl50dI=.337ae303-8e9c-4cce-95af-8ce57a4282d1@github.com>

On Fri, 11 Feb 2022 11:37:56 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:
> 
>  - Add comments to enter calls
>  - Set PreserveFramePointer if use_rop_protection is set

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

> 437:   if (_rop_protection == true) {
> 438:     PreserveFramePointer = true;
> 439:   }

You need an error message for -PreserveFramePointer +UseROPProtection.

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

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


From aph at openjdk.java.net  Fri Feb 11 16:52:16 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 11 Feb 2022 16:52:16 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v21]
In-Reply-To: <q7COfX45QCv3kkh7_TESYcpjBed_V0bC-ehP6IZjmIc=.83dac5d1-1da3-4c05-b11b-202ba6934d6d@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <q7COfX45QCv3kkh7_TESYcpjBed_V0bC-ehP6IZjmIc=.83dac5d1-1da3-4c05-b11b-202ba6934d6d@github.com>
Message-ID: <_8bU9rjmxZtiKw_7zHvR5kZxEGV0zPYsmLjwwzb78Eg=.41b11771-c173-4492-bcff-400a632a5ed1@github.com>

On Fri, 11 Feb 2022 11:37:56 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:
> 
>  - Add comments to enter calls
>  - Set PreserveFramePointer if use_rop_protection is set

This is looking pretty nice now. With the check for -XX:-UseFramePointer argument consistency we're done.

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

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


From duke at openjdk.java.net  Fri Feb 11 17:12:15 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Fri, 11 Feb 2022 17:12:15 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v21]
In-Reply-To: <_8bU9rjmxZtiKw_7zHvR5kZxEGV0zPYsmLjwwzb78Eg=.41b11771-c173-4492-bcff-400a632a5ed1@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <q7COfX45QCv3kkh7_TESYcpjBed_V0bC-ehP6IZjmIc=.83dac5d1-1da3-4c05-b11b-202ba6934d6d@github.com>
 <_8bU9rjmxZtiKw_7zHvR5kZxEGV0zPYsmLjwwzb78Eg=.41b11771-c173-4492-bcff-400a632a5ed1@github.com>
Message-ID: <E9LzReZFAb7Vn3Cxg0AG9BEWtDaR_00Kvbzo665O5Aw=.5d39ed86-c36f-4dda-822f-3ee74a38853b@github.com>

On Fri, 11 Feb 2022 16:48:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This is looking pretty nice now. With the check for -XX:-UseFramePointer argument consistency we're done.

Excellent! I'm away all next week, so will add the check when I get back.

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

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


From duke at openjdk.java.net  Fri Feb 11 20:41:39 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Fri, 11 Feb 2022 20:41:39 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
Message-ID: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>

JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

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

Commit messages:
 - Merge branch 'master' into JDK-8281003
 - Merge branch 'master' into JDK-8281003
 - removed commented out code
 - Moved null caller MethodHandles.lookup() test to a more reasonable location
 - JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

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

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


From duke at openjdk.java.net  Fri Feb 11 20:45:39 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Fri, 11 Feb 2022 20:45:39 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if
 caller is null
Message-ID: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>

JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

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

Commit messages:
 - Merge branch 'master' into JDK-8281000
 - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

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

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


From mchung at openjdk.java.net  Fri Feb 11 22:41:05 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 11 Feb 2022 22:41:05 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <7EXvojgCiyWx6vAjErWVakLoPpswTZzZo8K-FCylrLw=.b1a57a71-e6d1-49d8-a257-5610fd0bd00d@github.com>

On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

Thanks for taking on these null caller issue.

To give more context to this issue, the spec of `ClassLoader::isRegisteredAsParallelCapable` returns true if this class loader is registered as parallel capable, otherwise false.  The current spec does not specify what if the caller class is not a class loader.  The current implementation throws NPE if caller is null.  I initially proposed to return false for simplicity.   However, if the caller is not a subclass of `ClassLoader`, the current implementation throws `ClassCastException`.  Both cases are invalid caller and they should be handled in the same way, either return false or throw an exception.

Having a second thought, since this API expects to be called by a class loader, I think throwing `IllegalCallerException` to indicate this method is called by an illegal caller.    This will need a CSR due to the spec change.

What do you think?

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

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


From erikj at openjdk.java.net  Fri Feb 11 23:29:05 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 11 Feb 2022 23:29:05 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <jNNPFfExaYVScTDXGyqsjmD7WiBVXtTbpJzMFCOIEOk=.1ef1e05c-a1ec-4b91-821f-34d45111875c@github.com>

On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

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


From bchristi at openjdk.java.net  Fri Feb 11 23:29:05 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 11 Feb 2022 23:29:05 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null
In-Reply-To: <7EXvojgCiyWx6vAjErWVakLoPpswTZzZo8K-FCylrLw=.b1a57a71-e6d1-49d8-a257-5610fd0bd00d@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
 <7EXvojgCiyWx6vAjErWVakLoPpswTZzZo8K-FCylrLw=.b1a57a71-e6d1-49d8-a257-5610fd0bd00d@github.com>
Message-ID: <gG-6tsjVTsJQuy9fNtRW9bXcismeGGNjC11dofdztYA=.4d354db1-ff01-4806-a810-42943c6b90a5@github.com>

On Fri, 11 Feb 2022 22:37:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Thanks for taking on these null caller issue.
> 
> To give more context to this issue, the spec of `ClassLoader::isRegisteredAsParallelCapable` returns true if this class loader is registered as parallel capable, otherwise false. The current spec does not specify what if the caller class is not a class loader. The current implementation throws NPE if caller is null. I initially proposed to return false for simplicity. However, if the caller is not a subclass of `ClassLoader`, the current implementation throws `ClassCastException`. Both cases are invalid caller and they should be handled in the same way, either return false or throw an exception.
> 
> Having a second thought, since this API expects to be called by a class loader, I think throwing `IllegalCallerException` to indicate this method is called by an illegal caller. This will need a CSR due to the spec change.
> 
> What do you think?

Throwing IllegalCallerException sounds good to me.
As a static method, from a language standpoint, the call could appear almost anywhere. But its intended usage is pretty narrow. I think it's worth notifying the developer of a pretty obvious error.

Is this method mainly meant to be called from a classloader's static initializer?  That might be worth mentioning in the JavaDoc (if we're doing a CSR anyway...).

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

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


From duke at openjdk.java.net  Fri Feb 11 23:59:14 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 11 Feb 2022 23:59:14 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <N5geXLEn8vaODaHSwb-MqnngHDUgg1BAJMwB-iIx4Gk=.1641fafb-1721-4cd3-b781-36600db7760e@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>
 <N5geXLEn8vaODaHSwb-MqnngHDUgg1BAJMwB-iIx4Gk=.1641fafb-1721-4cd3-b781-36600db7760e@github.com>
Message-ID: <VRwNaccQWMLV2ECiQfcDYrjqCK2ZoNDjoz_svgrgi7o=.bb51a28f-d405-4bf1-b617-a920fd0ff366@github.com>

On Fri, 4 Feb 2022 16:17:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Be warned: This may take time. You certainly want your change to get integrated at some point of time.

I think this has turned out to be sage advice from Martin, as I believe neither of us has received a reply from the Oracle copyright advisor. In the interests of completing this change, I would be happy to move forward with either of the following.

1. The suggestion from IBM legal department to add both Oracle, and IBM copyright lines (with IBM lines only added to files with significant modification, as discussed above).
2. Reverting copyright header modifications other than year updates.

What are you most comfortable with, my sterling team of reviewers?

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

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


From duke at openjdk.java.net  Sat Feb 12 00:30:05 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Sat, 12 Feb 2022 00:30:05 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <j7kJh7b7fTtt5FABkpbujCbxlPeDDm74DLvwFGfTq54=.ef22a6c8-6bbf-4009-a7b5-255c75d3c2f6@github.com>

On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

Yes, I like the IllegalCallerException.

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

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


From alanb at openjdk.java.net  Sat Feb 12 15:20:01 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 12 Feb 2022 15:20:01 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null
In-Reply-To: <gG-6tsjVTsJQuy9fNtRW9bXcismeGGNjC11dofdztYA=.4d354db1-ff01-4806-a810-42943c6b90a5@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
 <7EXvojgCiyWx6vAjErWVakLoPpswTZzZo8K-FCylrLw=.b1a57a71-e6d1-49d8-a257-5610fd0bd00d@github.com>
 <gG-6tsjVTsJQuy9fNtRW9bXcismeGGNjC11dofdztYA=.4d354db1-ff01-4806-a810-42943c6b90a5@github.com>
Message-ID: <BsLPmPzRmlxF98xmJ-HL4XGIwu05ImzvS2z4H8Dmvjc=.2fb63657-2aac-483f-a5ca-037773b3c32d@github.com>

On Fri, 11 Feb 2022 23:25:44 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Having a second thought, since this API expects to be called by a class loader, I think throwing `IllegalCallerException` to indicate this method is called by an illegal caller. This will need a CSR due to the spec change.

I think this would work for both the "no caller" case and also the case where there is reflection hackery calling this method from somewhere other than a ClassLoader. So it would be a small change in behavior from CCE to ICE.

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

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


From stuefe at openjdk.java.net  Mon Feb 14 07:52:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 07:52:15 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <VRwNaccQWMLV2ECiQfcDYrjqCK2ZoNDjoz_svgrgi7o=.bb51a28f-d405-4bf1-b617-a920fd0ff366@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>
 <N5geXLEn8vaODaHSwb-MqnngHDUgg1BAJMwB-iIx4Gk=.1641fafb-1721-4cd3-b781-36600db7760e@github.com>
 <VRwNaccQWMLV2ECiQfcDYrjqCK2ZoNDjoz_svgrgi7o=.bb51a28f-d405-4bf1-b617-a920fd0ff366@github.com>
Message-ID: <aIq2iCa6NySxJYwAO_D20CIjTWtNJRSI4akO6Fmv60w=.f0c719f7-2c05-4974-925d-46a5c19a271f@github.com>

On Fri, 11 Feb 2022 23:56:19 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> > Be warned: This may take time. You certainly want your change to get integrated at some point of time.
> 
> I think this has turned out to be sage advice from Martin, as I believe neither of us has received a reply from the Oracle copyright advisor. In the interests of completing this change, I would be happy to move forward with either of the following.
> 
> 1. The suggestion from IBM legal department to add both Oracle, and IBM copyright lines (with IBM lines only added to files with significant modification, as discussed above).
> 2. Reverting copyright header modifications other than year updates.
> 
> What are you most comfortable with, my sterling team of reviewers?

Hi Tyler, I'm fine with either.

Cheers, Thomas

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

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


From ihse at openjdk.java.net  Mon Feb 14 10:35:15 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 14 Feb 2022 10:35:15 GMT
Subject: Integrated: 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: <_wb4Heil772dh0aOsJXMHGjH0dazkHD2QYEwdTuQeUk=.678a3c4c-b275-4dff-b492-f388cf128f46@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 now been integrated.

Changeset: 95f198b2
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/95f198b2b1b2d5437515dc837cc160e4224c0ff3
Stats:     92 lines in 7 files changed: 29 ins; 10 del; 53 mod

8274980: Improve adhoc build version strings

Reviewed-by: shade, erikj

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

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


From ihse at openjdk.java.net  Mon Feb 14 10:35:19 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 14 Feb 2022 10:35:19 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
Message-ID: <OiTHp7Kc3A6wnomUUABPM3GFWn4iUanEm2-U42iiTa4=.5e42991c-aa4d-4034-9dde-7cb4d81d4d79@github.com>

On Fri, 4 Feb 2022 00:25:43 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 ten commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - 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

make/autoconf/jvm-features.m4 line 3:

> 1: #
> 2: # Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved.
> 3: # Copyright (c) 2022, IBM Corp.

I understand the discussion about copyright lines has plagued this PR, but this really looks odd: adding an IBM copyright line when just removing code. That does not make sense to me.

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

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


From alanb at openjdk.java.net  Mon Feb 14 11:59:11 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 14 Feb 2022 11:59:11 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <bvNVcOk7RRHcw0QwL9h4ndYMsa9JzmVyjb_aO66BUCo=.dbf08e71-5062-4556-8b75-bbc13a29d2ba@github.com>

On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

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

> 119:         Class<?> c = Reflection.getCallerClass();
> 120:         if (c == null) {
> 121:             throw new IllegalCallerException();

Throwing ICE is probably okay here, I just wonder if there is any practical advantage to having it return publicLookup instead, e.g. is there any scenario where a JNI attached thread might want to invoke a method with a Lookup parameter?

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

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


From ihse at openjdk.java.net  Mon Feb 14 12:11:09 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 14 Feb 2022 12:11:09 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <isGOs9fZwe5P6SvXEDQN8VwjmkUVJICt9pHRQGxlxRg=.4d5297c2-306c-4da2-9d02-f74460e2824f@github.com>

On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

Build changes LGTM.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Mon Feb 14 12:11:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 14 Feb 2022 12:11:10 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <cjmfBS-LwNYkZc91wXkzyu7taSi4yDDMZ7CfFLr6XH0=.9e6f7fdb-ff77-49aa-b89e-5ac2b094a80b@github.com>

On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

Build changes are OK

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Mon Feb 14 16:30:35 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 14 Feb 2022 16:30:35 GMT
Subject: RFR: 8246033: bin/print_config.js script uses nashorn jjs tool
Message-ID: <ubRN838BSlxg-d-qK7CLTKoabqpR1_T2u4cNGLyPWvQ=.3d7e0730-a92f-40bb-90d2-5e110f64c066@github.com>

The print_config.js tool was written for Nashorn. With the removal of Nashorn, this script serves no function and should be removed.

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

Commit messages:
 - 8246033: bin/print_config.js script uses nashorn jjs tool

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

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


From stuefe at openjdk.java.net  Mon Feb 14 17:14:19 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 17:14:19 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <OiTHp7Kc3A6wnomUUABPM3GFWn4iUanEm2-U42iiTa4=.5e42991c-aa4d-4034-9dde-7cb4d81d4d79@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <OiTHp7Kc3A6wnomUUABPM3GFWn4iUanEm2-U42iiTa4=.5e42991c-aa4d-4034-9dde-7cb4d81d4d79@github.com>
Message-ID: <ks-myorQ2juvYDwyy55_GmpQgTLnvy1Pj2TBxzuH2-I=.28ccb775-8873-4e70-8611-e65907ef47d2@github.com>

On Mon, 14 Feb 2022 10:32:11 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 ten commits:
>> 
>>  - Merge branch 'master' into JDK-8203290
>>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>>  - Addresses issues from review and other sm fixes
>>    
>>    - Adds commenting in regards to memory handling by SystemProcess &
>>    NetworkInterface classes
>>    - Replaces explicit initialization and copy of structs with memcpy
>>    and memset as appropriate
>>    - Renames internal struct definitions in os_perf_aix
>>    - Other minor fixes
>>  - Changes macoss -> macosx in problem list
>>  - Refactors loadlib_aix: Removes redundant c++ class
>>  - 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
>
> make/autoconf/jvm-features.m4 line 3:
> 
>> 1: #
>> 2: # Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved.
>> 3: # Copyright (c) 2022, IBM Corp.
> 
> I understand the discussion about copyright lines has plagued this PR, but this really looks odd: adding an IBM copyright line when just removing code. That does not make sense to me.

+1 Removing code does not add anything copyrightable; I'd remove that copyright line.

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

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


From erikj at openjdk.java.net  Mon Feb 14 17:28:09 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 14 Feb 2022 17:28:09 GMT
Subject: RFR: 8246033: bin/print_config.js script uses nashorn jjs tool
In-Reply-To: <ubRN838BSlxg-d-qK7CLTKoabqpR1_T2u4cNGLyPWvQ=.3d7e0730-a92f-40bb-90d2-5e110f64c066@github.com>
References: <ubRN838BSlxg-d-qK7CLTKoabqpR1_T2u4cNGLyPWvQ=.3d7e0730-a92f-40bb-90d2-5e110f64c066@github.com>
Message-ID: <06hB6CVeey3A7lh917zZzEvv3V5ytUAOn4cndTcszk0=.17d0914d-e8ef-4105-99f2-97f8112ce0ab@github.com>

On Mon, 14 Feb 2022 16:23:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The print_config.js tool was written for Nashorn. With the removal of Nashorn, this script serves no function and should be removed.

Marked as reviewed by erikj (Reviewer).

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

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


From mchung at openjdk.java.net  Mon Feb 14 18:07:09 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 14 Feb 2022 18:07:09 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
In-Reply-To: <bvNVcOk7RRHcw0QwL9h4ndYMsa9JzmVyjb_aO66BUCo=.dbf08e71-5062-4556-8b75-bbc13a29d2ba@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
 <bvNVcOk7RRHcw0QwL9h4ndYMsa9JzmVyjb_aO66BUCo=.dbf08e71-5062-4556-8b75-bbc13a29d2ba@github.com>
Message-ID: <wVuYIN3ltC6CY9HqaIkRQAMqn9-5IwziCButsqaOqN8=.4ab59991-3821-41b4-8b94-a36daa38a7d3@github.com>

On Mon, 14 Feb 2022 11:56:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
> 
>> 119:         Class<?> c = Reflection.getCallerClass();
>> 120:         if (c == null) {
>> 121:             throw new IllegalCallerException();
> 
> Throwing ICE is probably okay here, I just wonder if there is any practical advantage to having it return publicLookup instead, e.g. is there any scenario where a JNI attached thread might want to invoke a method with a Lookup parameter?

`MethodHandles::publicLookup` can be called instead to get a public Lookup to invoke a method with a Lookup parameter.   The dilemma here is whether the API should be made null-caller friendly or using a proper API `MethodHandles::publicLookup` for such case.

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

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


From alanb at openjdk.java.net  Mon Feb 14 18:15:08 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 14 Feb 2022 18:15:08 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
In-Reply-To: <wVuYIN3ltC6CY9HqaIkRQAMqn9-5IwziCButsqaOqN8=.4ab59991-3821-41b4-8b94-a36daa38a7d3@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
 <bvNVcOk7RRHcw0QwL9h4ndYMsa9JzmVyjb_aO66BUCo=.dbf08e71-5062-4556-8b75-bbc13a29d2ba@github.com>
 <wVuYIN3ltC6CY9HqaIkRQAMqn9-5IwziCButsqaOqN8=.4ab59991-3821-41b4-8b94-a36daa38a7d3@github.com>
Message-ID: <HP_9n0JTGaXlrzqRDUxNahxeRC3S9FAVL5uTj39XSdE=.8b582fea-1fa0-4be3-9eaa-81defcf0bf7f@github.com>

On Mon, 14 Feb 2022 18:03:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
>> 
>>> 119:         Class<?> c = Reflection.getCallerClass();
>>> 120:         if (c == null) {
>>> 121:             throw new IllegalCallerException();
>> 
>> Throwing ICE is probably okay here, I just wonder if there is any practical advantage to having it return publicLookup instead, e.g. is there any scenario where a JNI attached thread might want to invoke a method with a Lookup parameter?
>
> `MethodHandles::publicLookup` can be called instead to get a public Lookup to invoke a method with a Lookup parameter.   The dilemma here is whether the API should be made null-caller friendly or using a proper API `MethodHandles::publicLookup` for such case.

You are right. If a JNI attached thread with no Java frames wants a Lookup then it can invoke publicLookup. I think the proposal here is good.

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

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


From alanb at openjdk.java.net  Mon Feb 14 18:15:08 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 14 Feb 2022 18:15:08 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <XQIeVBaot3I4qiukoYaL3moCs3drJQbZgxzEY4IUlS4=.0cf38015-eecb-4d84-a546-eaa7fc0543cb@github.com>

On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

test/jdk/java/lang/invoke/MethodHandles/exeNullCallerMethodHandlesLookup/NullCallerMethodHandlesLookupTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2022, Oracle and/or its affiliates. All rights reserved.

As this is a new file then I assume it should be 2022 only.

test/jdk/java/lang/invoke/MethodHandles/exeNullCallerMethodHandlesLookup/NullCallerMethodHandlesLookupTest.java line 48:

> 46: public class NullCallerMethodHandlesLookupTest {
> 47:     public static void main(String[] args) throws IOException {
> 48:         Path launcher = Paths.get(System.getProperty("test.nativepath"), "NullCallerMethodHandlesLookupTest");

Path.of might be nicer here but doesn't matter.

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

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


From mchung at openjdk.java.net  Mon Feb 14 18:37:09 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 14 Feb 2022 18:37:09 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <7n-jij4H0hg3F1eeArL1SuR1mJ9Qnm8NbP1Fhkz5Yro=.1c1c5df3-b1f2-444d-9dfd-c106a41bed99@github.com>

On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

This needs a CSR and the spec needs update.  

The test name could be shortened to `s/exeNullCallerMethodHandlesLookup/exeNullCallerLookup/`.

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

> 119:         Class<?> c = Reflection.getCallerClass();
> 120:         if (c == null) {
> 121:             throw new IllegalCallerException();

Suggestion:

            throw new IllegalCallerException("no caller frame");

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

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


From mchung at openjdk.java.net  Mon Feb 14 18:37:10 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 14 Feb 2022 18:37:10 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
In-Reply-To: <7n-jij4H0hg3F1eeArL1SuR1mJ9Qnm8NbP1Fhkz5Yro=.1c1c5df3-b1f2-444d-9dfd-c106a41bed99@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
 <7n-jij4H0hg3F1eeArL1SuR1mJ9Qnm8NbP1Fhkz5Yro=.1c1c5df3-b1f2-444d-9dfd-c106a41bed99@github.com>
Message-ID: <3R3yOvHFQsMjYXK2ccrQDMUK_u-kqWpGodTE7_w17M0=.14f0fb54-a6c8-4e02-a174-91e18885f2cd@github.com>

On Mon, 14 Feb 2022 18:28:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
> 
>> 119:         Class<?> c = Reflection.getCallerClass();
>> 120:         if (c == null) {
>> 121:             throw new IllegalCallerException();
> 
> Suggestion:
> 
>             throw new IllegalCallerException("no caller frame");

The javadoc needs to be updated to specify this `IllegalCallerException` be thrown.


    * @throws IllegalCallerException if there is no caller frame on the stack when called
    * directly from a JNI attached thread

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

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


From jrose at openjdk.java.net  Mon Feb 14 18:55:07 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 14 Feb 2022 18:55:07 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <159C_yfAzGOHHJ2ThjrpjZgefdbdAoUBFYR6ZgEFV8Q=.c6f0770c-c1de-419d-bcb1-39a6743ba3e9@github.com>

On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

Marked as reviewed by jrose (Reviewer).

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

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


From jrose at openjdk.java.net  Mon Feb 14 18:55:07 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 14 Feb 2022 18:55:07 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
In-Reply-To: <HP_9n0JTGaXlrzqRDUxNahxeRC3S9FAVL5uTj39XSdE=.8b582fea-1fa0-4be3-9eaa-81defcf0bf7f@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
 <bvNVcOk7RRHcw0QwL9h4ndYMsa9JzmVyjb_aO66BUCo=.dbf08e71-5062-4556-8b75-bbc13a29d2ba@github.com>
 <wVuYIN3ltC6CY9HqaIkRQAMqn9-5IwziCButsqaOqN8=.4ab59991-3821-41b4-8b94-a36daa38a7d3@github.com>
 <HP_9n0JTGaXlrzqRDUxNahxeRC3S9FAVL5uTj39XSdE=.8b582fea-1fa0-4be3-9eaa-81defcf0bf7f@github.com>
Message-ID: <bYLuhx3k9N339Pw9egg41AkQKpGgOk1o5sSJyNNMwrE=.d514aef9-73cc-41ec-a8a2-cdd462fd19b6@github.com>

On Mon, 14 Feb 2022 18:10:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `MethodHandles::publicLookup` can be called instead to get a public Lookup to invoke a method with a Lookup parameter.   The dilemma here is whether the API should be made null-caller friendly or using a proper API `MethodHandles::publicLookup` for such case.
>
> You are right. If a JNI attached thread with no Java frames wants a Lookup then it can invoke publicLookup. I think the proposal here is good.

Agreed.  In this case there is no caller and any kind of fail-over to a designated caller would risk privilege escalation.  So we should throw.  I have no objection to throwing something more "diagnostic" than a NPE.

Arguably, JNI code is full-privileged, so someone might suggest, "just return a fully privileged lookup on some designated class".  But, even if such a class could be designated somehow (e.g., by rummaging down the  stack), handing out privileges on that class might be unexpected to the JNI author.  In fact, if the JNI code is working on behalf of a *low-privileged class* (whatever that means in context), then handing back a `Lookup` with higher privileges potentially leaks those privileges to the low-privileged class (depending on data flow, of course).  Trying to guess at a `Lookup` in this case would only create potential privilege escalations.  So we throw, and require the JNI programmer to say something clearer about their intentions.

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

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


From duke at openjdk.java.net  Mon Feb 14 22:40:01 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Mon, 14 Feb 2022 22:40:01 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null [v2]
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <ZeBJpyDcZzlj4OaIDecP8EApZNHhvF6ic2L_bkyfovY=.7ca7b74c-bdd4-4438-b945-259426092a87@github.com>

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

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

  Changes from feedback.
  
  - Improved javadoc.
  - Single copyright date in new files.
  - Informative string in exception that is thrown.
  - Shortened the test name.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7447/files
  - new: https://git.openjdk.java.net/jdk/pull/7447/files/1bb6316f..02d00ecb

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

  Stats: 152 lines in 5 files changed: 77 ins; 70 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7447.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447

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


From duke at openjdk.java.net  Mon Feb 14 23:38:53 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Mon, 14 Feb 2022 23:38:53 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null [v3]
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <v5rL4vKJwLF5EM4NSwBtDKq2FL5-l3k5BZ0IFyWw8RI=.cfde55ce-3dd4-4bcb-aa7b-6a3a18d51ac6@github.com>

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

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

  missing dot

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7447/files
  - new: https://git.openjdk.java.net/jdk/pull/7447/files/02d00ecb..c803a93b

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

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

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


From duke at openjdk.java.net  Mon Feb 14 23:44:40 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 14 Feb 2022 23:44:40 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@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 eight commits:

 - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
 - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
 - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
 - Addresses issues from review and other sm fixes
   
   - Adds commenting in regards to memory handling by SystemProcess &
   NetworkInterface classes
   - Replaces explicit initialization and copy of structs with memcpy
   and memset as appropriate
   - Renames internal struct definitions in os_perf_aix
   - Other minor fixes
 - Changes macoss -> macosx in problem list
 - Refactors loadlib_aix: Removes redundant c++ class
 - 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=20
  Stats: 1231 lines in 10 files changed: 461 ins; 502 del; 268 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 Feb 14 23:44:42 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 14 Feb 2022 23:44:42 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <ks-myorQ2juvYDwyy55_GmpQgTLnvy1Pj2TBxzuH2-I=.28ccb775-8873-4e70-8611-e65907ef47d2@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <OiTHp7Kc3A6wnomUUABPM3GFWn4iUanEm2-U42iiTa4=.5e42991c-aa4d-4034-9dde-7cb4d81d4d79@github.com>
 <ks-myorQ2juvYDwyy55_GmpQgTLnvy1Pj2TBxzuH2-I=.28ccb775-8873-4e70-8611-e65907ef47d2@github.com>
Message-ID: <RM6SIE5T6lEONegknvxi96xGph4oEvIpNTYCuoWQwBo=.0f721b69-9b9a-49a9-aa43-87cbf27b68cb@github.com>

On Mon, 14 Feb 2022 17:11:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> make/autoconf/jvm-features.m4 line 3:
>> 
>>> 1: #
>>> 2: # Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved.
>>> 3: # Copyright (c) 2022, IBM Corp.
>> 
>> I understand the discussion about copyright lines has plagued this PR, but this really looks odd: adding an IBM copyright line when just removing code. That does not make sense to me.
>
> +1 Removing code does not add anything copyrightable; I'd remove that copyright line.

I agree. I no longer add the IBM copyright for files where a one line change, or only removals took place.

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

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


From duke at openjdk.java.net  Mon Feb 14 23:48:11 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 14 Feb 2022 23:48:11 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
Message-ID: <6XT1pHUBTLmQUGXs9LyRSNghnued-YvUQITnXgY3Lr8=.08bd4674-572f-4e9f-94bd-72d863f0fb2c@github.com>

On Mon, 14 Feb 2022 23:44:40 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 eight commits:
> 
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - 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

Updated to remove IBM from the copyright header when only a small change to the file took place. I am ready to integrate, but I will leave it open for a day or so to allow for any more comments.

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

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


From duke at openjdk.java.net  Tue Feb 15 00:10:44 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Tue, 15 Feb 2022 00:10:44 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null [v4]
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <HZPdauBa9EaxHeC9xNVDO91ewfikzM3BAr8-S5mPCZo=.3dc99fc7-f522-4ff9-a183-cca0545e3493@github.com>

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

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

  remove excess description

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7447/files
  - new: https://git.openjdk.java.net/jdk/pull/7447/files/c803a93b..7d1b97fe

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

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

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


From gnu.andrew at redhat.com  Tue Feb 15 02:53:30 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 15 Feb 2022 02:53:30 +0000
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <1ab8f8792f8b4bb66704b8a60c35991b1d372ae5.camel@redhat.com>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
 <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
 <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>
 <1ab8f8792f8b4bb66704b8a60c35991b1d372ae5.camel@redhat.com>
Message-ID: <YgsVqogbjsrRcXGU@hex.discworld.ac.uk>

On 14:09 Thu 10 Feb     , Severin Gehwolf wrote:
> 
> Latest webrev:
> https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/02/webrev/
> 
> OK?
> 
> Thanks,
> Severin
> 

This looks fine. Please flag for approval.

Thanks,
-- 
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 duke at openjdk.java.net  Tue Feb 15 09:28:22 2022
From: duke at openjdk.java.net (Pavel Kharskii)
Date: Tue, 15 Feb 2022 09:28:22 GMT
Subject: [jdk18] Integrated: 8280415: Remove EA from JDK 18 version string
 starting with Initial RC promotion B35 on February 10, 2022
In-Reply-To: <hsFt6X0WOcJ91p2_6yTKLsoiEvjR6IWKkS3sKFBEYsk=.af0ac42a-8c52-4818-a11c-af44b2f7dea2@github.com>
References: <hsFt6X0WOcJ91p2_6yTKLsoiEvjR6IWKkS3sKFBEYsk=.af0ac42a-8c52-4818-a11c-af44b2f7dea2@github.com>
Message-ID: <WENZfUJT9sZcLt9lFMt8HDaOYE9MMq5g71kv6kiJdbA=.85b39070-5bc7-4594-a796-fac250702bc5@github.com>

On Thu, 10 Feb 2022 18:46:13 GMT, Pavel Kharskii <duke at openjdk.java.net> wrote:

> ?C promotion B35 on February 10, 2022
> 
> Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022

This pull request has now been integrated.

Changeset: 0f2113ce
Author:    Pavel Kharskii <gipperon at gmail.com>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/0f2113cee79b9645105b4753c7d7eacb83b872c2
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8280415: Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022

Reviewed-by: erikj, iris

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

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


From sgehwolf at redhat.com  Tue Feb 15 10:53:37 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 15 Feb 2022 11:53:37 +0100
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <YgsVqogbjsrRcXGU@hex.discworld.ac.uk>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
 <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
 <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>
 <1ab8f8792f8b4bb66704b8a60c35991b1d372ae5.camel@redhat.com>
 <YgsVqogbjsrRcXGU@hex.discworld.ac.uk>
Message-ID: <87a4d5cbf3899ee351dba89d46c42dfe69799e9a.camel@redhat.com>

On Tue, 2022-02-15 at 02:53 +0000, Andrew Hughes wrote:
> On 14:09 Thu 10 Feb???? , Severin Gehwolf wrote:
> > 
> > Latest webrev:
> > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/02/webrev/
> > 
> > OK?
> > 
> > Thanks,
> > Severin
> > 
> 
> This looks fine. Please flag for approval.

Thanks for the review. Done.

Cheers,
Severin



From ihse at openjdk.java.net  Tue Feb 15 11:11:16 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 11:11:16 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
Message-ID: <NMMk6oNwnihqatYzjjsHgo5ARuhV5rwYhpXOL6OlCdU=.d0b97f9a-e972-48a9-9b79-832618033d68@github.com>

On Mon, 14 Feb 2022 23:44:40 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 eight commits:
> 
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - 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 now look good.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Tue Feb 15 11:15:12 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 11:15:12 GMT
Subject: Integrated: 8246033: bin/print_config.js script uses nashorn jjs tool
In-Reply-To: <ubRN838BSlxg-d-qK7CLTKoabqpR1_T2u4cNGLyPWvQ=.3d7e0730-a92f-40bb-90d2-5e110f64c066@github.com>
References: <ubRN838BSlxg-d-qK7CLTKoabqpR1_T2u4cNGLyPWvQ=.3d7e0730-a92f-40bb-90d2-5e110f64c066@github.com>
Message-ID: <w3bR8bZ3U-w6UvXhDoJDGovp3Tx2c9xfQRgKd5h6tAY=.206de23d-3453-4182-8e1c-4b1804b35832@github.com>

On Mon, 14 Feb 2022 16:23:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The print_config.js tool was written for Nashorn. With the removal of Nashorn, this script serves no function and should be removed.

This pull request has now been integrated.

Changeset: 2112a9dc
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2112a9dc49a41e11433f19d258d72806b321106c
Stats:     45 lines in 1 file changed: 0 ins; 45 del; 0 mod

8246033: bin/print_config.js script uses nashorn jjs tool

Reviewed-by: erikj

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

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


From stuefe at openjdk.java.net  Tue Feb 15 13:22:14 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 15 Feb 2022 13:22:14 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
Message-ID: <65raOl-IqN_v_gVtB314q1tigH6pl_pCCbF3MmIEjqQ=.4ee6fbcd-39cc-4dc6-a3ec-9e56e765298c@github.com>

On Mon, 14 Feb 2022 23:44:40 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 eight commits:
> 
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - 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

Looks still good to me.

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

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


From ihse at openjdk.java.net  Tue Feb 15 15:18:35 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 15:18:35 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v2]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <E1FBhnWLLdl1EhzQaqkB4PimaCpzBgw3FXp4fTc1FLc=.2aef9632-7a90-4f6f-b94f-0fbccd2edb9f@github.com>

> 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.

Magnus Ihse Bursie 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 hsdis-backend-llvm
 - Create hsdis backend using LLVM

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

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

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


From ihse at openjdk.java.net  Tue Feb 15 15:23:58 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 15:23:58 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v3]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <8Dp9ejGHYpmoUjoR2-nw2Ewxaugs4icy65v62S7yhMM=.295c27a9-b3d2-4879-9f78-a9b62d422f02@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Find llvm-config on mac-aarch64 homebrew as well

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/c16dcb21..9f2ab6d9

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

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

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


From ihse at openjdk.java.net  Tue Feb 15 15:34:52 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 15:34:52 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v4]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <m6Ej95nyzpN2hObs_tq6mwwstAi-xTqZxB2IV43ZdQw=.69f12fab-83b1-4628-b281-2c8a9a0629a8@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Handle unknown instructions from LLVM. Solution suggested by ngasson.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/9f2ab6d9..7d866725

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

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

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


From ihse at openjdk.java.net  Tue Feb 15 15:48:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 15:48:43 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v5]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <E7Al6P0s8iYPkuLPR-2Vs30gvSC7wwddLfbQU3yzKyI=.44e5e9e7-db07-458e-97be-35febe8c0df2@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix install-hsdis warning

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/7d866725..a4d9896e

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

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

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


From ihse at openjdk.java.net  Tue Feb 15 16:19:32 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 16:19:32 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v6]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <hCnUcZ4GEnRRmKXv9Xii_H1ZYjMpnUUL7E3WFN9g5vQ=.7fd67df0-32c0-458f-ac1e-0f968baceeaf@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restructure README to prepare for section on LLVM

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/a4d9896e..47cf9a1b

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

  Stats: 58 lines in 1 file changed: 30 ins; 22 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5920/head:pull/5920

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


From mchung at openjdk.java.net  Tue Feb 15 18:45:05 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 15 Feb 2022 18:45:05 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null [v4]
In-Reply-To: <HZPdauBa9EaxHeC9xNVDO91ewfikzM3BAr8-S5mPCZo=.3dc99fc7-f522-4ff9-a183-cca0545e3493@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
 <HZPdauBa9EaxHeC9xNVDO91ewfikzM3BAr8-S5mPCZo=.3dc99fc7-f522-4ff9-a183-cca0545e3493@github.com>
Message-ID: <T3R7JzkSVq9JBl9bXS7UzzPVYTeOuZbyCtgU0_aoCA4=.4611ef0f-d05a-43ba-a574-9029a2215290@github.com>

On Tue, 15 Feb 2022 00:10:44 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove excess description

Looks good.

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

Marked as reviewed by mchung (Reviewer).

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


From duke at openjdk.java.net  Tue Feb 15 22:17:53 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Tue, 15 Feb 2022 22:17:53 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v2]
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <jeJEXPXL4KjlYVozlKhQFZqAN4NmJm7Lt-EaOgDFPfc=.89a38b6a-c8a6-4c4d-9cf8-b9e8613bd0dd@github.com>

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

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

  Changes from feedback.
  
  - Copyright dates fixed
  - IllegalCallerException thrown for no caller frame, and associated
  javadoc changes
  - test changed to look for IllegalCallerException thrown.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/c6d37069..fa66af15

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

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

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


From mchung at openjdk.java.net  Tue Feb 15 23:23:11 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 15 Feb 2022 23:23:11 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v2]
In-Reply-To: <jeJEXPXL4KjlYVozlKhQFZqAN4NmJm7Lt-EaOgDFPfc=.89a38b6a-c8a6-4c4d-9cf8-b9e8613bd0dd@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
 <jeJEXPXL4KjlYVozlKhQFZqAN4NmJm7Lt-EaOgDFPfc=.89a38b6a-c8a6-4c4d-9cf8-b9e8613bd0dd@github.com>
Message-ID: <DAntxEnNRgB_smHgAm8npLuwjdUCvRHwD-4wh6KWThA=.81058dba-bf3c-43d2-9b04-8c40e5266511@github.com>

On Tue, 15 Feb 2022 22:17:53 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes from feedback.
>   
>   - Copyright dates fixed
>   - IllegalCallerException thrown for no caller frame, and associated
>   javadoc changes
>   - test changed to look for IllegalCallerException thrown.

src/java.base/share/classes/java/lang/ClassLoader.java line 1612:

> 1610:      * In cases where {@code ClassLoader.registerAsParallelCapable} is called from a context where
> 1611:      * there is no caller frame on the stack (e.g. when called directly
> 1612:      * from a JNI attached thread), {@code IllegalCallerException} is thrown.

Suggestion:

     * In cases where this method is called from a context where the caller is not a subclass
     * {@code ClassLoader} or there is no caller frame on the stack (e.g. when called directly
     * from a JNI attached thread), {@code IllegalCallerException} is thrown.


Should mention the non-class loader caller as well.

src/java.base/share/classes/java/lang/ClassLoader.java line 1617:

> 1615:      * @return  {@code true} if the caller is successfully registered as
> 1616:      *          parallel capable and {@code false} if otherwise.
> 1617:      * @throws IllegalCallerException if there is no caller frame on the stack.

Suggestion:

     * @throws IllegalCallerException if the caller is not a subclass of {@code ClassLoader}

src/java.base/share/classes/java/lang/ClassLoader.java line 1626:

> 1624:     protected static boolean registerAsParallelCapable() {
> 1625:         final Class<?> caller = Reflection.getCallerClass();
> 1626:         if (caller == null) {

Suggestion:

        if (caller == null || !ClassLoader.class.isAssignableFrom(caller)) {
             throw new IllegalCallerException(caller + " not a subclass of ClassLoader");
        }     


What we suggested is to throw IllegalCallerException if the caller is not a class loader and that will include null caller case.

test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/NullCallerClassLoaderTest.java line 30:

> 28:  * @summary Test uses custom launcher that starts VM using JNI that verifies
> 29:  *          ClassLoader.registerAsParallelCapable with null caller class does not throw a NullPointerException,
> 30:  *          and instead returns false.

`@summary` needs update to reflect the new change.

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

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


From mchung at openjdk.java.net  Tue Feb 15 23:23:11 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 15 Feb 2022 23:23:11 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v2]
In-Reply-To: <DAntxEnNRgB_smHgAm8npLuwjdUCvRHwD-4wh6KWThA=.81058dba-bf3c-43d2-9b04-8c40e5266511@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
 <jeJEXPXL4KjlYVozlKhQFZqAN4NmJm7Lt-EaOgDFPfc=.89a38b6a-c8a6-4c4d-9cf8-b9e8613bd0dd@github.com>
 <DAntxEnNRgB_smHgAm8npLuwjdUCvRHwD-4wh6KWThA=.81058dba-bf3c-43d2-9b04-8c40e5266511@github.com>
Message-ID: <VahC7NMFliva0zIdaJ1YpI_JSLTjJrmpY93a7M4_Y98=.25a9fdb3-2574-4776-ab09-41fd6efb91c7@github.com>

On Tue, 15 Feb 2022 23:05:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes from feedback.
>>   
>>   - Copyright dates fixed
>>   - IllegalCallerException thrown for no caller frame, and associated
>>   javadoc changes
>>   - test changed to look for IllegalCallerException thrown.
>
> src/java.base/share/classes/java/lang/ClassLoader.java line 1626:
> 
>> 1624:     protected static boolean registerAsParallelCapable() {
>> 1625:         final Class<?> caller = Reflection.getCallerClass();
>> 1626:         if (caller == null) {
> 
> Suggestion:
> 
>         if (caller == null || !ClassLoader.class.isAssignableFrom(caller)) {
>              throw new IllegalCallerException(caller + " not a subclass of ClassLoader");
>         }     
> 
> 
> What we suggested is to throw IllegalCallerException if the caller is not a class loader and that will include null caller case.

This also needs a test case for non-class loader caller.

I looked at the existing tests testing `registerAsParallelCapable` but I can't find a good one to add the new test case.   The closest one could be `test/jdk/java/lang/ClassLoader/IsParallelCapable.java`.   I'm okay to include a new test case in `IsParallelCapable.java` to verify `IllegalCallerException` if called by a non-class loader.

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

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


From ihse at openjdk.java.net  Wed Feb 16 12:33:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 12:33:43 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v7]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <xOiKVqPpqz6jsGFAHsDxcgAJB_XttiFWiS57vKKRVpo=.7262f97f-12f6-490a-bd51-a66593c15f0a@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Make sure install-hsdis also copies to image

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/47cf9a1b..467e1bb1

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

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

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


From ihse at openjdk.java.net  Wed Feb 16 14:39:49 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 14:39:49 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v8]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <0tGSY9Iutr4jkP2idAqvi3yM3Qon120-JCD6fGxZobg=.fb6e4549-44e1-42eb-a51b-166c3912c37b@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Add section on using LLVM
 - Allow override of LLVM location using --with-llvm

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/467e1bb1..5ea9bc0d

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

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

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


From duke at openjdk.java.net  Wed Feb 16 16:18:14 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 16 Feb 2022 16:18:14 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
Message-ID: <0SQe2dMc-7PQPHB6tpYRY1YyrVMTPVZWbA0rHUhjCsE=.a7043db1-9378-446b-8ba1-df1213a03ce5@github.com>

On Mon, 14 Feb 2022 23:44:40 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 eight commits:
> 
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - 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 very much to the many reviewers who helped make this PR happen. Your support is very much appreciated ? 

I suggest these we /integrate these changes.

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

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


From duke at openjdk.java.net  Wed Feb 16 17:38:01 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 16 Feb 2022 17:38:01 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v3]
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <7UJHcb3yr4qdq33PtAfOc8TmmFAqvbfGgMcgmQXXFWM=.f2b198f2-66c7-4d73-95a5-3a155942611d@github.com>

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

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

  More changes from feedback.
  
  The javadoc is improved to reflect InvalidCallerException is thrown with
  a caller that can't be assigned to a ClassLoader as well as a null
  caller frame.  Added a test IsParallelCapableBadCaller that uses
  reflection hackery to create a case where called with an invalid caller
  on the call stack.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/fa66af15..d67bbb16

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

  Stats: 85 lines in 3 files changed: 74 ins; 5 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448

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


From duke at openjdk.java.net  Wed Feb 16 17:54:42 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 16 Feb 2022 17:54:42 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v4]
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <4Ro7V9aiXs_6yecVuneFzWKFbAygPHl8UM9irXuiaeU=.78523a6c-76e5-4bab-8217-0cabd5d6c333@github.com>

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

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

  fix copyright date

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/d67bbb16..533a0660

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

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

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


From duke at openjdk.java.net  Wed Feb 16 17:55:55 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 16 Feb 2022 17:55:55 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null [v5]
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <PA_srNx3Rw8J-bUjZEaJqlXpKCDNQoT9LgzSQqEMaUc=.77f3ae88-f1f8-4aff-a669-72e1b0e5b611@github.com>

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

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

  fix copyright date

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7447/files
  - new: https://git.openjdk.java.net/jdk/pull/7447/files/7d1b97fe..ecfd125f

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

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

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


From alanb at openjdk.java.net  Wed Feb 16 18:42:10 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Feb 2022 18:42:10 GMT
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null [v5]
In-Reply-To: <PA_srNx3Rw8J-bUjZEaJqlXpKCDNQoT9LgzSQqEMaUc=.77f3ae88-f1f8-4aff-a669-72e1b0e5b611@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
 <PA_srNx3Rw8J-bUjZEaJqlXpKCDNQoT9LgzSQqEMaUc=.77f3ae88-f1f8-4aff-a669-72e1b0e5b611@github.com>
Message-ID: <QdGhLuJ37-PC1BAGQ1lcYFJU0E0cfIfWGXvX64PX-as=.56a11c22-0f23-4118-b246-e528616ad629@github.com>

On Wed, 16 Feb 2022 17:55:55 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright date

Marked as reviewed by alanb (Reviewer).

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

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


From duke at openjdk.java.net  Wed Feb 16 19:08:56 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 16 Feb 2022 19:08:56 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v5]
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <Dy4ikzPptW3NwEcqy8UDHTR7PDO050KdPa_aSwBxIPk=.1b2bf4d5-15d0-4c12-8db1-c35a9fbe7b2d@github.com>

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

Tim Prinzing has updated the pull request incrementally with three additional commits since the last revision:

 - reformat test summary
 - reformat test summary
 - improve test name and remove experimental test code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/533a0660..a449acdc

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

  Stats: 129 lines in 3 files changed: 58 ins; 70 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448

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


From duke at openjdk.java.net  Wed Feb 16 20:13:13 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 16 Feb 2022 20:13:13 GMT
Subject: Integrated: JDK-8281003 - MethodHandles::lookup throws NPE if caller
 is null
In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com>
Message-ID: <djkVqO-mkBODPl0otwZbWtzOmlyqKy-1-hwQUh8dXqY=.857b085a-df5a-41a8-bc28-b9e6e0fcff81@github.com>

On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

This pull request has now been integrated.

Changeset: 67763df4
Author:    Tim Prinzing <tim.prinzing at oracle.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/67763df4dce387da33da6d93d0f5d80e54cf8e5b
Stats:     160 lines in 4 files changed: 158 ins; 0 del; 2 mod

8281003: MethodHandles::lookup throws NPE if caller is null

Reviewed-by: ihse, mchung, jrose, alanb

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

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


From duke at openjdk.java.net  Wed Feb 16 21:13:34 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 16 Feb 2022 21:13:34 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v6]
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <qvgSgcee1T2TyNGqApXKjTKeSqss2Mynrt_SIzUkfsE=.9a98ac9e-9489-4fce-bd3c-6b75ba72ffe2@github.com>

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

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

  fix test breakage from rename

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/a449acdc..977162db

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

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

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


From duke at openjdk.java.net  Wed Feb 16 21:39:20 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 16 Feb 2022 21:39:20 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v7]
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <CZT6CkVyNWQKAppEk0roJeCi47qg79jpx2n8nJNRkQ0=.dfafd723-645e-4f9c-80d3-5952b9894884@github.com>

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge master
 - fix test breakage from rename
 - reformat test summary
 - reformat test summary
 - improve test name and remove experimental test code
 - fix copyright date
 - More changes from feedback.
   
   The javadoc is improved to reflect InvalidCallerException is thrown with
   a caller that can't be assigned to a ClassLoader as well as a null
   caller frame.  Added a test IsParallelCapableBadCaller that uses
   reflection hackery to create a case where called with an invalid caller
   on the call stack.
 - Changes from feedback.
   
   - Copyright dates fixed
   - IllegalCallerException thrown for no caller frame, and associated
   javadoc changes
   - test changed to look for IllegalCallerException thrown.
 - Merge branch 'master' into JDK-8281000
 - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

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

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

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


From mchung at openjdk.java.net  Wed Feb 16 21:45:05 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 16 Feb 2022 21:45:05 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v7]
In-Reply-To: <CZT6CkVyNWQKAppEk0roJeCi47qg79jpx2n8nJNRkQ0=.dfafd723-645e-4f9c-80d3-5952b9894884@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
 <CZT6CkVyNWQKAppEk0roJeCi47qg79jpx2n8nJNRkQ0=.dfafd723-645e-4f9c-80d3-5952b9894884@github.com>
Message-ID: <UWWLO07QBWio9fGcXzA9_6Pu8sUlu5WBaxl1t2hS2sQ=.3b0dcbd6-fb38-4e2a-93ea-14402f071ce2@github.com>

On Wed, 16 Feb 2022 21:39:20 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge master
>  - fix test breakage from rename
>  - reformat test summary
>  - reformat test summary
>  - improve test name and remove experimental test code
>  - fix copyright date
>  - More changes from feedback.
>    
>    The javadoc is improved to reflect InvalidCallerException is thrown with
>    a caller that can't be assigned to a ClassLoader as well as a null
>    caller frame.  Added a test IsParallelCapableBadCaller that uses
>    reflection hackery to create a case where called with an invalid caller
>    on the call stack.
>  - Changes from feedback.
>    
>    - Copyright dates fixed
>    - IllegalCallerException thrown for no caller frame, and associated
>    javadoc changes
>    - test changed to look for IllegalCallerException thrown.
>  - Merge branch 'master' into JDK-8281000
>  - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

Looks good.

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

Marked as reviewed by mchung (Reviewer).

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


From ihse at openjdk.java.net  Wed Feb 16 21:54:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 21:54:10 GMT
Subject: Withdrawn: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <h8xE-snG3LGVVsswWAN5NdmArFbB2QRnLCclK6Cz4vA=.9298fe8d-2907-4ef2-abb8-dff18a87c8a5@github.com>

On Wed, 13 Oct 2021 00:00:22 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.

This pull request has been closed without being integrated.

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

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


From ihse at openjdk.java.net  Wed Feb 16 21:54:09 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 21:54:09 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v8]
In-Reply-To: <0tGSY9Iutr4jkP2idAqvi3yM3Qon120-JCD6fGxZobg=.fb6e4549-44e1-42eb-a51b-166c3912c37b@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
 <0tGSY9Iutr4jkP2idAqvi3yM3Qon120-JCD6fGxZobg=.fb6e4549-44e1-42eb-a51b-166c3912c37b@github.com>
Message-ID: <G6ygxtT-4QTB-Yv2fRy7MMkjr483M_8SaRrj8h4yQks=.be0bd661-5e00-4cf1-a376-319f0bbb8e09@github.com>

On Wed, 16 Feb 2022 14:39:49 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.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add section on using LLVM
>  - Allow override of LLVM location using --with-llvm

This PR has just gotten too messy. :-( I'll close this one for now, focus on getting the (much simpler) Capstone backend integrated, and then I can come back and revisit this functionality, but in a fresh new PR.

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

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


From ihse at openjdk.java.net  Wed Feb 16 22:20:33 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 22:20:33 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis
Message-ID: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>

The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 

This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).

The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.

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

Commit messages:
 - Fix whitespace error (thanks, jcheck!)
 - Minor fixes
 - The pandoc-style copyright header looks bad on Github...
 - Turn the README into markdown format. Add documentation on building Capstone.
 - Fix capstone on Windows
 - Add capstone as hsdis backend

Changes: https://git.openjdk.java.net/jdk/pull/7506/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7506&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8188073
  Stats: 517 lines in 9 files changed: 346 ins; 136 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7506.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7506/head:pull/7506

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


From bchristi at openjdk.java.net  Wed Feb 16 22:37:04 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 16 Feb 2022 22:37:04 GMT
Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE
 if caller is null [v7]
In-Reply-To: <CZT6CkVyNWQKAppEk0roJeCi47qg79jpx2n8nJNRkQ0=.dfafd723-645e-4f9c-80d3-5952b9894884@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
 <CZT6CkVyNWQKAppEk0roJeCi47qg79jpx2n8nJNRkQ0=.dfafd723-645e-4f9c-80d3-5952b9894884@github.com>
Message-ID: <qI2LsEAUBtxK9P8TxOxSmIygS3YewDExT8S89OmsHkA=.bb1f7d78-a641-466b-b374-77673649de23@github.com>

On Wed, 16 Feb 2022 21:39:20 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge master
>  - fix test breakage from rename
>  - reformat test summary
>  - reformat test summary
>  - improve test name and remove experimental test code
>  - fix copyright date
>  - More changes from feedback.
>    
>    The javadoc is improved to reflect InvalidCallerException is thrown with
>    a caller that can't be assigned to a ClassLoader as well as a null
>    caller frame.  Added a test IsParallelCapableBadCaller that uses
>    reflection hackery to create a case where called with an invalid caller
>    on the call stack.
>  - Changes from feedback.
>    
>    - Copyright dates fixed
>    - IllegalCallerException thrown for no caller frame, and associated
>    javadoc changes
>    - test changed to look for IllegalCallerException thrown.
>  - Merge branch 'master' into JDK-8281000
>  - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

Looks fine.

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

Marked as reviewed by bchristi (Reviewer).

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


From duke at openjdk.java.net  Thu Feb 17 08:53:18 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 17 Feb 2022 08:53:18 GMT
Subject: Integrated: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder)
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <duKbwvxYFB-YMRPrPRX8ffBwNVqiWRouRFIXqfS8dNY=.31d60e36-5d16-4c3a-b0a2-5f66e4432b26@github.com>

On Fri, 17 Dec 2021 19:07:54 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.

This pull request has now been integrated.

Changeset: c0275e18
Author:    Tyler Steele <tyler.steele at ibm.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0275e18b7cb4a01385b79ced46560322aeacc97
Stats:     1230 lines in 10 files changed: 461 ins; 502 del; 267 mod

8203290: [AIX] Check functionality of JDK-8199712 (Flight Recorder)

Implements JFR for AIX

Reviewed-by: erikj, mdoerr, mgronlun, stuefe, ihse

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

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


From erikj at openjdk.java.net  Thu Feb 17 14:19:06 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 17 Feb 2022 14:19:06 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis
In-Reply-To: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
Message-ID: <X-c1F8n3rLyKzCQ9ydgOI-PjonSQ-DirPAmZXFSMCU4=.e816cdad-7b93-4484-bc1b-8bd0f0e50f12@github.com>

On Wed, 16 Feb 2022 21:55:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 
> 
> This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).
> 
> The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.

One style nit.

make/Hsdis.gmk line 157:

> 155: 
> 156: $(INSTALLED_HSDIS): $(BUILD_HSDIS_TARGET)
> 157: ifeq ($(HSDIS_BACKEND), binutils)

Don't we usually indent conditionals to the recipe level using spaces?

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

Marked as reviewed by erikj (Reviewer).

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


From ihse at openjdk.java.net  Thu Feb 17 15:16:41 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Feb 2022 15:16:41 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis [v2]
In-Reply-To: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
Message-ID: <9WqRK6V2GVcRAXUWYNa9irzLZ_0xxTyuv0WzDNZBXg0=.509d399d-fc43-40e9-8a20-12a0f9ffe9d2@github.com>

> The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 
> 
> This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).
> 
> The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7506/files
  - new: https://git.openjdk.java.net/jdk/pull/7506/files/03974854..05c19820

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

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

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


From ihse at openjdk.java.net  Thu Feb 17 15:16:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Feb 2022 15:16:43 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis [v2]
In-Reply-To: <X-c1F8n3rLyKzCQ9ydgOI-PjonSQ-DirPAmZXFSMCU4=.e816cdad-7b93-4484-bc1b-8bd0f0e50f12@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
 <X-c1F8n3rLyKzCQ9ydgOI-PjonSQ-DirPAmZXFSMCU4=.e816cdad-7b93-4484-bc1b-8bd0f0e50f12@github.com>
Message-ID: <sbK6NxgYkbpbGfDVIBqzEL27vk6vz4Mu_pPRw2mybvQ=.db340a61-2235-4c7c-9e1d-ee21dc2a8813@github.com>

On Thu, 17 Feb 2022 14:11:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indentation
>
> make/Hsdis.gmk line 157:
> 
>> 155: 
>> 156: $(INSTALLED_HSDIS): $(BUILD_HSDIS_TARGET)
>> 157: ifeq ($(HSDIS_BACKEND), binutils)
> 
> Don't we usually indent conditionals to the recipe level using spaces?

Yes we do. Embarrassing. ?

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

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


From erikj at openjdk.java.net  Thu Feb 17 17:13:13 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 17 Feb 2022 17:13:13 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis [v2]
In-Reply-To: <9WqRK6V2GVcRAXUWYNa9irzLZ_0xxTyuv0WzDNZBXg0=.509d399d-fc43-40e9-8a20-12a0f9ffe9d2@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
 <9WqRK6V2GVcRAXUWYNa9irzLZ_0xxTyuv0WzDNZBXg0=.509d399d-fc43-40e9-8a20-12a0f9ffe9d2@github.com>
Message-ID: <TYi6jfqo8VI56YWmTU-y0nI_FrUR4WbIxCCRLHnUGAc=.0f999038-58b0-4fdc-8701-2f9a3d9dc44e@github.com>

On Thu, 17 Feb 2022 15:16:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 
>> 
>> This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).
>> 
>> The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Marked as reviewed by erikj (Reviewer).

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

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


From duke at openjdk.java.net  Thu Feb 17 17:38:09 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 17 Feb 2022 17:38:09 GMT
Subject: Integrated: JDK-8281000 ClassLoader::registerAsParallelCapable throws
 NPE if caller is null
In-Reply-To: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
References: <EAZbf1K3Yich0aNFOmgf-d4Np2H6Q9fb-3kj5p7LCSo=.8e4eecc9-b6b2-45bf-8241-5931d99eb446@github.com>
Message-ID: <NIZl6rlCBTkj4leuq53BCVd-eIIAY2eoBGSR2PEykCw=.12d0d611-5667-4ce2-9597-5c1443b9c512@github.com>

On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

This pull request has now been integrated.

Changeset: a6f8a386
Author:    Tim Prinzing <tim.prinzing at oracle.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6f8a386efa7af162f4b815951287f0a9bc1f396
Stats:     216 lines in 5 files changed: 216 ins; 0 del; 0 mod

8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null

Reviewed-by: erikj, ihse, mchung, bchristi

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

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


From ihse at openjdk.java.net  Thu Feb 17 21:22:15 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Feb 2022 21:22:15 GMT
Subject: Integrated: 8188073: Add Capstone as backend for hsdis
In-Reply-To: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
Message-ID: <wtMdLcHOKBaOPWL5UfdBdv10t-EbRj2oJUFzjNVE2Yw=.c64dc810-42d5-421d-8b14-a7cb04a9f5b4@github.com>

On Wed, 16 Feb 2022 21:55:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 
> 
> This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).
> 
> The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.

This pull request has now been integrated.

Changeset: f830cbec
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f830cbec909b91ad0f00f46a3496d83ecb5912ed
Stats:     499 lines in 9 files changed: 328 ins; 118 del; 53 mod

8188073: Add Capstone as backend for hsdis

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Reviewed-by: erikj

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

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


From yinyuting at fulan.com.cn  Mon Feb 14 03:24:18 2022
From: yinyuting at fulan.com.cn (=?gb2312?B?0vPT8ebD?=)
Date: Mon, 14 Feb 2022 03:24:18 +0000
Subject: macro expansion producing 'defined' has undefined behavior
Message-ID: <2446044F-3D75-42F7-AAAE-BC9EF1B4958B@fulan.com.cn>

Hi,

When I ran
make images in my local computer to compile the openjdk9u by guideline <<Understanding the JVM >>, I encountered the following problems:
Compiling 61 files for BUILD_INTERIM_jdk.jdeps
Compiling 457 files for BUILD_INTERIM_jdk.javadoc
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:33:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1ConcurrentMark.hpp:31:
/Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
    ^
/Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
                                     ^
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
/Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
    ^
/Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
                                     ^
2 errors generated.
make[3]: *** [/Users/simmias/java/github/openjdk/jdk9u-master/build/macosx-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/test_freeRegionList.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [hotspot-server-libs] Error 2
make[2]: *** Waiting for unfinished jobs....
?: ???????????????? API?
?: ??????, ??? -Xlint:deprecation ?????

ERROR: Build failed for target 'images' in configuration 'macosx-x86_64-normal-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_gtest_objs_test_freeRegionList.o:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:33:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1ConcurrentMark.hpp:31:
/Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
    ^
/Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
                                     ^
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
   ... (rest of output omitted)

* All command lines available in /Users/simmias/java/github/openjdk/jdk9u-master/build/macosx-x86_64-normal-server-release/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See common/doc/building.html#troubleshooting for assistance.

make[1]: *** [main] Error 2
make: *** [images] Error 2

I tried the ways on the internet which added the env(CGO_CPPFLAGS), but it did not work.
I am really looking forward to your reply.
Thanks

Local env:
os: mac 11.5.2
xcode version: 13.2.1
xcode-select version:  2384
planning compile jdk version : openjdk 9u
bootstrap jdk version: openjdk 8

Best Regards
Simmias




From tiwachan1 at gmail.com  Thu Feb 17 22:33:24 2022
From: tiwachan1 at gmail.com (Thiwa Chantarangkul)
Date: Fri, 18 Feb 2022 05:33:24 +0700
Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is
 null
Message-ID: <CAN0BaoKRomMX0Wh6LjVqJ5iPgKbQ3nnFeTh9VxTGfjf4uatHqQ@mail.gmail.com>




From david.holmes at oracle.com  Fri Feb 18 02:58:37 2022
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Feb 2022 12:58:37 +1000
Subject: macro expansion producing 'defined' has undefined behavior
In-Reply-To: <2446044F-3D75-42F7-AAAE-BC9EF1B4958B@fulan.com.cn>
References: <2446044F-3D75-42F7-AAAE-BC9EF1B4958B@fulan.com.cn>
Message-ID: <668a4e29-c27a-1704-ee3d-457fb7adaefb@oracle.com>

Hi Simmias,

On 14/02/2022 1:24 pm, ??? wrote:
> Hi,
> 
> When I ran
> make images in my local computer to compile the openjdk9u by guideline <<Understanding the JVM >>, I encountered the following problems:

9u is not expected to be built by recent Xcode, it was a much older 
release (not sure if anyone is actually updating it at all):

https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms

You either need to downgrade your build tools, or else upgrade the 
OpenJDK version you want to build.

Cheers,
David

> Compiling 61 files for BUILD_INTERIM_jdk.jdeps
> Compiling 457 files for BUILD_INTERIM_jdk.javadoc
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:33:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1ConcurrentMark.hpp:31:
> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
> #if HEAP_REGION_SET_FORCE_VERIFY
>      ^
> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>                                       ^
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
> #if HEAP_REGION_SET_FORCE_VERIFY
>      ^
> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>                                       ^
> 2 errors generated.
> make[3]: *** [/Users/simmias/java/github/openjdk/jdk9u-master/build/macosx-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/test_freeRegionList.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [hotspot-server-libs] Error 2
> make[2]: *** Waiting for unfinished jobs....
> ?: ???????????????? API?
> ?: ??????, ??? -Xlint:deprecation ?????
> 
> ERROR: Build failed for target 'images' in configuration 'macosx-x86_64-normal-server-release' (exit code 2)
> 
> === Output from failing command(s) repeated here ===
> * For target hotspot_variant-server_libjvm_gtest_objs_test_freeRegionList.o:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:33:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1ConcurrentMark.hpp:31:
> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
> #if HEAP_REGION_SET_FORCE_VERIFY
>      ^
> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>                                       ^
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
>     ... (rest of output omitted)
> 
> * All command lines available in /Users/simmias/java/github/openjdk/jdk9u-master/build/macosx-x86_64-normal-server-release/make-support/failure-logs.
> === End of repeated output ===
> 
> No indication of failed target found.
> Hint: Try searching the build log for '] Error'.
> Hint: See common/doc/building.html#troubleshooting for assistance.
> 
> make[1]: *** [main] Error 2
> make: *** [images] Error 2
> 
> I tried the ways on the internet which added the env(CGO_CPPFLAGS), but it did not work.
> I am really looking forward to your reply.
> Thanks
> 
> Local env:
> os: mac 11.5.2
> xcode version: 13.2.1
> xcode-select version:  2384
> planning compile jdk version : openjdk 9u
> bootstrap jdk version: openjdk 8
> 
> Best Regards
> Simmias
> 
> 
> 


From ihse at openjdk.java.net  Fri Feb 18 08:54:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 18 Feb 2022 08:54:10 GMT
Subject: RFR: 8282086: Update jib profile to not set build to 0
Message-ID: <ufgPpQtgYPOg1mIylbctetmf-L38dulL6dmJCAApl4s=.779da231-ed78-44f6-b193-593d60cf19c4@github.com>

The jib profile definition does not play well with [JDK-8274980](https://bugs.openjdk.java.net/browse/JDK-8274980). When using 0 as a marker for "no build number", we should not pass that on to configure, since it will trigger a warning.

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

Commit messages:
 - 8282086: Update jib profile to not set build to 0

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

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


From yinyuting at fulan.com.cn  Fri Feb 18 09:21:35 2022
From: yinyuting at fulan.com.cn (=?utf-8?B?5q63546J5am3?=)
Date: Fri, 18 Feb 2022 09:21:35 +0000
Subject: macro expansion producing 'defined' has undefined behavior
In-Reply-To: <668a4e29-c27a-1704-ee3d-457fb7adaefb@oracle.com>
References: <2446044F-3D75-42F7-AAAE-BC9EF1B4958B@fulan.com.cn>
 <668a4e29-c27a-1704-ee3d-457fb7adaefb@oracle.com>
Message-ID: <CA5EE791-EBE3-4C62-8B06-E56E8B5897BA@fulan.com.cn>

Thanks a lot.
It  worked when I upgraded the openjdk version to 12.
 

> 2022?2?18? 10:58?David Holmes <david.holmes at oracle.com> ???
> 
> Hi Simmias,
> 
> On 14/02/2022 1:24 pm, ??? wrote:
>> Hi,
>> When I ran
>> make images in my local computer to compile the openjdk9u by guideline <<Understanding the JVM >>, I encountered the following problems:
> 
> 9u is not expected to be built by recent Xcode, it was a much older release (not sure if anyone is actually updating it at all):
> 
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
> 
> You either need to downgrade your build tools, or else upgrade the OpenJDK version you want to build.
> 
> Cheers,
> David
> 
>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps
>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:33:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1ConcurrentMark.hpp:31:
>> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
>> #if HEAP_REGION_SET_FORCE_VERIFY
>>     ^
>> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
>> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>>                                      ^
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
>> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
>> #if HEAP_REGION_SET_FORCE_VERIFY
>>     ^
>> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
>> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>>                                      ^
>> 2 errors generated.
>> make[3]: *** [/Users/simmias/java/github/openjdk/jdk9u-master/build/macosx-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/test_freeRegionList.o] Error 1
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [hotspot-server-libs] Error 2
>> make[2]: *** Waiting for unfinished jobs....
>> ?: ???????????????? API?
>> ?: ??????, ??? -Xlint:deprecation ?????
>> ERROR: Build failed for target 'images' in configuration 'macosx-x86_64-normal-server-release' (exit code 2)
>> === Output from failing command(s) repeated here ===
>> * For target hotspot_variant-server_libjvm_gtest_objs_test_freeRegionList.o:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:33:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1ConcurrentMark.hpp:31:
>> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
>> #if HEAP_REGION_SET_FORCE_VERIFY
>>     ^
>> /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
>> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>>                                      ^
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
>> In file included from /Users/simmias/java/github/openjdk/jdk9u-master/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
>>    ... (rest of output omitted)
>> * All command lines available in /Users/simmias/java/github/openjdk/jdk9u-master/build/macosx-x86_64-normal-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> No indication of failed target found.
>> Hint: Try searching the build log for '] Error'.
>> Hint: See common/doc/building.html#troubleshooting for assistance.
>> make[1]: *** [main] Error 2
>> make: *** [images] Error 2
>> I tried the ways on the internet which added the env(CGO_CPPFLAGS), but it did not work.
>> I am really looking forward to your reply.
>> Thanks
>> Local env:
>> os: mac 11.5.2
>> xcode version: 13.2.1
>> xcode-select version:  2384
>> planning compile jdk version : openjdk 9u
>> bootstrap jdk version: openjdk 8
>> Best Regards
>> Simmias


From ihse at openjdk.java.net  Fri Feb 18 11:51:30 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 18 Feb 2022 11:51:30 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
Message-ID: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>

Third time's a charm! After the two previous closed PRs for this issue, I think this functionality is finally ready to enter mainline. :)

This code is at it's core the same as the previous PR. The main C++ hsdis implementation is still the one @luhenry wrote, with some changes. As in the previous PR, I extracted the LLVM-specific part into a separate file. In addition to the last PR, I have also fixed a warning, and added a patch inspired by @nick-arm for getting past instructions unknown to LLVM.

Thanks to the prototype written by @JornVernee (and his graciously providing me with a working version of LLVM build for Windows), this PR now has full support for LLVM on Windows (as well as Linux and macOS).

Finally, I have cleaned up the integration in autoconf and Hsdis.gmk, and written a thorough guide in the README on how to build witth LLVM, on Windows and on saner platforms. :)

I'm pretty sure this means that all comments and criticism in the previous PR has been addressed.

Huge thanks to everyone who has helped me with getting this PR in place. I have a hard time remember a feature that has been so tricky to get in place, for something to seemingly simple...

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

Commit messages:
 - Update description on runtime requirements for LLVM
 - Fix warning on Windows (as opposed to hiding it)
 - Add LLVM backend to hsdis. Portions of this patch contributed by luhenry, jvernee and ngasson.

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

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


From erikj at openjdk.java.net  Fri Feb 18 13:32:51 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 18 Feb 2022 13:32:51 GMT
Subject: RFR: 8282086: Update jib profile to not set build to 0
In-Reply-To: <ufgPpQtgYPOg1mIylbctetmf-L38dulL6dmJCAApl4s=.779da231-ed78-44f6-b193-593d60cf19c4@github.com>
References: <ufgPpQtgYPOg1mIylbctetmf-L38dulL6dmJCAApl4s=.779da231-ed78-44f6-b193-593d60cf19c4@github.com>
Message-ID: <9hQHDQqHtwKMCFODdfv8oiqHENbhrWx7T2M3BxTrBus=.d0fe39ed-c691-4922-89c6-abc33930c05a@github.com>

On Fri, 18 Feb 2022 08:46:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The jib profile definition does not play well with [JDK-8274980](https://bugs.openjdk.java.net/browse/JDK-8274980). When using 0 as a marker for "no build number", we should not pass that on to configure, since it will trigger a warning.

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.java.net  Fri Feb 18 13:46:46 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 18 Feb 2022 13:46:46 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
References: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
Message-ID: <5pnm3YtLsoPyrNQgaN_CWS5w4g-namVs355AygUSReI=.802a2f65-8962-4166-b3f9-94b97b0ce407@github.com>

On Fri, 18 Feb 2022 11:44:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Third time's a charm! After the two previous closed PRs for this issue, I think this functionality is finally ready to enter mainline. :)
> 
> This code is at it's core the same as the previous PR. The main C++ hsdis implementation is still the one @luhenry wrote, with some changes. As in the previous PR, I extracted the LLVM-specific part into a separate file. In addition to the last PR, I have also fixed a warning, and added a patch inspired by @nick-arm for getting past instructions unknown to LLVM.
> 
> Thanks to the prototype written by @JornVernee (and his graciously providing me with a working version of LLVM build for Windows), this PR now has full support for LLVM on Windows (as well as Linux and macOS).
> 
> Finally, I have cleaned up the integration in autoconf and Hsdis.gmk, and written a thorough guide in the README on how to build witth LLVM, on Windows and on saner platforms. :)
> 
> I'm pretty sure this means that all comments and criticism in the previous PR has been addressed.
> 
> Huge thanks to everyone who has helped me with getting this PR in place. I have a hard time remember a feature that has been so tricky to get in place, for something to seemingly simple...

Build changes look good. I can't comment on the hsdis implementation.

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

Marked as reviewed by erikj (Reviewer).

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


From luhenry at openjdk.java.net  Fri Feb 18 14:18:59 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Fri, 18 Feb 2022 14:18:59 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
References: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
Message-ID: <t8aDmngJN57Y9RpCbGGSiRiQDGqCvpncuZoiEsDaL1M=.7046707e-eff6-4672-8ddc-99d1b744e540@github.com>

On Fri, 18 Feb 2022 11:44:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Third time's a charm! After the two previous closed PRs for this issue, I think this functionality is finally ready to enter mainline. :)
> 
> This code is at it's core the same as the previous PR. The main C++ hsdis implementation is still the one @luhenry wrote, with some changes. As in the previous PR, I extracted the LLVM-specific part into a separate file. In addition to the last PR, I have also fixed a warning, and added a patch inspired by @nick-arm for getting past instructions unknown to LLVM.
> 
> Thanks to the prototype written by @JornVernee (and his graciously providing me with a working version of LLVM build for Windows), this PR now has full support for LLVM on Windows (as well as Linux and macOS).
> 
> Finally, I have cleaned up the integration in autoconf and Hsdis.gmk, and written a thorough guide in the README on how to build witth LLVM, on Windows and on saner platforms. :)
> 
> I'm pretty sure this means that all comments and criticism in the previous PR has been addressed.
> 
> Huge thanks to everyone who has helped me with getting this PR in place. I have a hard time remember a feature that has been so tricky to get in place, for something to seemingly simple...

Marked as reviewed by luhenry (Author).

Thanks again for pushing that forward! It's always good to have an alternative especially for porting to new platforms and architectures.

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

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


From ihse at openjdk.java.net  Fri Feb 18 14:52:52 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 18 Feb 2022 14:52:52 GMT
Subject: Integrated: 8282086: Update jib profile to not set build to 0
In-Reply-To: <ufgPpQtgYPOg1mIylbctetmf-L38dulL6dmJCAApl4s=.779da231-ed78-44f6-b193-593d60cf19c4@github.com>
References: <ufgPpQtgYPOg1mIylbctetmf-L38dulL6dmJCAApl4s=.779da231-ed78-44f6-b193-593d60cf19c4@github.com>
Message-ID: <yIN2Aax0-WAzJ9y_zW-iOLyS0pw5ZnP-goTwCkWMPrQ=.bd481167-b536-4d60-89c7-c1085b62efff@github.com>

On Fri, 18 Feb 2022 08:46:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The jib profile definition does not play well with [JDK-8274980](https://bugs.openjdk.java.net/browse/JDK-8274980). When using 0 as a marker for "no build number", we should not pass that on to configure, since it will trigger a warning.

This pull request has now been integrated.

Changeset: cf6984dd
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cf6984ddaa5668e78d590c8ad1f2aec0632f0b28
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8282086: Update jib profile to not set build to 0

Reviewed-by: erikj

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

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


From ihse at openjdk.java.net  Mon Feb 21 10:41:59 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Feb 2022 10:41:59 GMT
Subject: Integrated: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
References: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
Message-ID: <O-41ikmMP5XpbRaSQQvNfmjLqk-5eu2jUDOI0ev_CgA=.27596f74-be1d-4550-b487-cf6afa2592c9@github.com>

On Fri, 18 Feb 2022 11:44:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Third time's a charm! After the two previous closed PRs for this issue, I think this functionality is finally ready to enter mainline. :)
> 
> This code is at it's core the same as the previous PR. The main C++ hsdis implementation is still the one @luhenry wrote, with some changes. As in the previous PR, I extracted the LLVM-specific part into a separate file. In addition to the last PR, I have also fixed a warning, and added a patch inspired by @nick-arm for getting past instructions unknown to LLVM.
> 
> Thanks to the prototype written by @JornVernee (and his graciously providing me with a working version of LLVM build for Windows), this PR now has full support for LLVM on Windows (as well as Linux and macOS).
> 
> Finally, I have cleaned up the integration in autoconf and Hsdis.gmk, and written a thorough guide in the README on how to build witth LLVM, on Windows and on saner platforms. :)
> 
> I'm pretty sure this means that all comments and criticism in the previous PR has been addressed.
> 
> Huge thanks to everyone who has helped me with getting this PR in place. I have a hard time remember a feature that has been so tricky to get in place, for something to seemingly simple...

This pull request has now been integrated.

Changeset: d7a706a5
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d7a706a54076109b1a600a4d963df54b6d3f86de
Stats:     495 lines in 4 files changed: 490 ins; 0 del; 5 mod

8253757: Add LLVM-based backend for hsdis

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Nick Gasson <ngasson at openjdk.org>
Reviewed-by: erikj, luhenry

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

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


From duke at openjdk.java.net  Mon Feb 21 12:25:46 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 21 Feb 2022 12:25:46 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v22]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <i7E_Cqk8kOTOTUCUa3xVrU-uExS432J-F726-ejQenI=.971577c8-bf85-4cad-be11-6ae24e1a0b38@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:

  Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/2062cce7..7f80f289

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

  Stats: 3 lines in 1 file changed: 3 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 Feb 21 17:20:57 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Mon, 21 Feb 2022 17:20:57 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v23]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <SufqvjvqcDFFVxVGTHmlj9g0iuTfiJWewbNak_RlHf0=.e10b2ed4-4d67-4dc3-aa04-ca2b55dbdf25@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:

  Merge master

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/7f80f289..f9882ff1

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

  Stats: 39689 lines in 1308 files changed: 27145 ins; 6944 del; 5600 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 djelinski at openjdk.java.net  Tue Feb 22 07:16:13 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 07:16:13 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
Message-ID: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>

Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.

This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).

The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.

I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

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

Commit messages:
 - Strict strings

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

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


From shade at openjdk.java.net  Tue Feb 22 08:03:02 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 22 Feb 2022 08:03:02 GMT
Subject: RFR: 8282225: GHA: Allow one concurrent run per PR only
Message-ID: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>

Since last year, GHA allows concurrency control over GHA runs:
 https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
 https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency

Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.

I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.

Additional testing:
 - [x] Verified queued run gets cancelled on new commit
 - [x] Verified in-progress run gets cancelled on new commit
 - [x] Verified in-progress run gets cancelled on merge
 - [x] Verified in-progress run gets cancelled on rebase + force-push

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

Commit messages:
 - Fix

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

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


From ihse at openjdk.java.net  Tue Feb 22 11:26:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 11:26:43 GMT
Subject: RFR: 8282225: GHA: Allow one concurrent run per PR only
In-Reply-To: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
References: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
Message-ID: <rPk1C40YIcDBaFc-vaOq1ycD_g1FyVlVpA6h1QEX7_w=.a2804d5d-e2ff-40a0-b424-dd26f0d3fc42@github.com>

On Tue, 22 Feb 2022 07:05:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Since last year, GHA allows concurrency control over GHA runs:
>  https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>  https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
> 
> Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.
> 
> I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.
> 
> Additional testing:
>  - [x] Verified queued run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on merge
>  - [x] Verified in-progress run gets cancelled on rebase + force-push

Looks good.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Tue Feb 22 11:36:52 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 11:36:52 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

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

> 134:       CFLAGS_WARNINGS_ARE_ERRORS="-WX"
> 135: 
> 136:       WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"

This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK.

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

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


From tschatzl at openjdk.java.net  Tue Feb 22 11:42:55 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 22 Feb 2022 11:42:55 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v4]
In-Reply-To: <PESchU9s7SJ30uIlIhCkZZZb84bvppiRwBPMFBNJvs0=.1308e4f4-a4af-427b-b2db-f13f2a05be3a@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <PESchU9s7SJ30uIlIhCkZZZb84bvppiRwBPMFBNJvs0=.1308e4f4-a4af-427b-b2db-f13f2a05be3a@github.com>
Message-ID: <ZTggm8ZVeipDBUrgoc_wPQNBHKTkO9HmIIQ1-6mFZDY=.d076d6b2-c6a8-423c-8f84-83a4c43f9a3f@github.com>

On Tue, 8 Feb 2022 08:17:17 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 one additional commit since the last revision:
> 
>   Make dwarf tag NOT_PRODUCT

First pass, did not dive into details of the state machine yet.

src/hotspot/share/utilities/elfFile.cpp line 319:

> 317:     }
> 318:     log_develop_info(dwarf)("No separate .debuginfo file for library %s. It already contains the required DWARF sections.", _filepath);
> 319:     _dwarf_file = new (std::nothrow) DwarfFile(_filepath);

Would it be useful to explicitly bail out on a `nullptr` value here to avoid crashes below?

src/hotspot/share/utilities/elfFile.cpp line 357:

> 355:   }
> 356: 
> 357:   strcpy(debug_pathname, _filepath);

I'm always a bit uneasy using "raw" `strcpy` instead of `strncpy` and friends. The code seems to be correct though.

src/hotspot/share/utilities/elfFile.cpp line 358:

> 356: 
> 357:   strcpy(debug_pathname, _filepath);
> 358:   char* last_slash = strrchr(debug_pathname, '/');

It's probably no big issue hardcoding the forward slash here instead of using `os::file_separator()` in this method.

src/hotspot/share/utilities/elfFile.cpp line 407:

> 405: bool ElfFile::load_dwarf_file_from_env_path_folder(const char* env_path, const char* folder, const char* debug_filename, const uint32_t crc) {
> 406:   char* debug_pathname = NEW_RESOURCE_ARRAY(char, strlen(env_path) + strlen(folder) + strlen(debug_filename) + 2);
> 407:   strcpy(debug_pathname, env_path);

Similar to other resource allocations, this should bail out if the result is `nullptr`.

src/hotspot/share/utilities/elfFile.cpp line 566:

> 564: // http://sourceware.org/gdb/current/onlinedocs/gdb/Separate-Debug-Files.html#Separate-Debug-Files.
> 565: uint32_t ElfFile::gnu_debuglink_crc32(uint32_t crc, uint8_t* buf, const size_t len) {
> 566:   crc = ~crc & 0xffffffff;

The masks are unnecessary here but don't hurt. Feel free to keep.

src/hotspot/share/utilities/elfFile.cpp line 576:

> 574:   log_develop_info(dwarf)("Open DWARF file: %s", filepath);
> 575:   _dwarf_file = new (std::nothrow) DwarfFile(filepath);
> 576:   if (!_dwarf_file->is_valid_dwarf_file()) {

This should bail out if the `new` returned a `nullptr`.

src/hotspot/share/utilities/elfFile.cpp line 686:

> 684:   }
> 685: 
> 686:   // We must align to twice the address size.

Since alignment is based on address size? I.e. above, at the check whether addresses are correct, define address size and then multiply by 2 here.
This would also make the condition above look nicer, i.e. move the `[NOT_]LP64` outside of the condition.

src/hotspot/share/utilities/elfFile.cpp line 784:

> 782:   }
> 783: 
> 784:   if (!_reader.read_byte(&_header._address_size) || NOT_LP64(_header._address_size != 4)  LP64_ONLY( _header._address_size != 8)) {

Since this is the second time for the clause `|| NOT_LP64(_header._address_size != 4) LP64_ONLY( _header._address_size != 8)` maybe it is useful to make a constant out of the accepted address size somewhere instead of repeating this over and over.
It's value could even be something like `sizeof(intptr_t)` or so.

src/hotspot/share/utilities/elfFile.cpp line 814:

> 812:   log_develop_trace(dwarf)("Series of declarations [code, tag]:");
> 813:   AbbreviationDeclaration declaration;
> 814:   bool found_matching_declaration = false;

This variable is never used. Remove.

src/hotspot/share/utilities/elfFile.cpp line 944:

> 942: #else
> 943:       _reader.move_position(8);
> 944: #endif

Use `AddressSize` or similar here instead of the `#ifdef`.

src/hotspot/share/utilities/elfFile.cpp line 1026:

> 1024:         break;
> 1025:       } else {
> 1026:         if (!_reader.move_position(4)) {

Instead of hardcoding the `4` for lineptr/loclistptr/macptr/rangelistptr it would be nice to have a "DwarfOffset` constant of that value, since we only support 32 bit DWARF.

src/hotspot/share/utilities/elfFile.cpp line 1070:

> 1068:     // reason, GCC is currently using version 3 as specified in the DWARF 3 spec for the line number program even though GCC should
> 1069:     // be using version 4 for DWARF 4 as it emits DWARF 4 by default.
> 1070:     return false;

According to the specification (pg112):

> `version (uhalf)`
> A version number (see Appendix F). This number is specific to the line number information
> and is independent of the DWARF version number.

So this is just fine - actually things may break if the code accepted version 4 here assuming that there are breaking differences.
On the other hand Appendix F mentions that DWARF4 contains .debug_line information in version 4.

src/hotspot/share/utilities/elfFile.cpp line 1121:

> 1119:   // _debug_line_offset + 10 (=sizeof(_unit_length) + sizeof(_version) + sizeof(_header_length)) + _header_length.
> 1120:   _header._file_names_offset = _reader.get_position();
> 1121:   if (!_reader.set_position(shdr.sh_offset + _debug_line_offset + 10 + _header._header_length)) {

I would prefer a constant for this magic `10`. Thank you for the documentation.

src/hotspot/share/utilities/elfFile.hpp line 211:

> 209: 
> 210:   // Load the DWARF file (.debuginfo) that belongs to this file.
> 211:   bool load_dwarf_file();

It would be nice to summarize from which places this methods tries to load the debug info to prevent the need for digging for it in the method implementation.

src/hotspot/share/utilities/elfFile.hpp line 300:

> 298:  *  - debug: Prints the results of the steps (1) - (4) together with the generated line information matrix.
> 299:  *  - trace: Full logging information for intermediate states/results when parsing the DWARF file.
> 300:  */

Maybe add a comment that log output is only supported in non-product builds and the reason.

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

Changes requested by tschatzl (Reviewer).

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


From chagedorn at openjdk.java.net  Tue Feb 22 12:22:52 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 22 Feb 2022 12:22:52 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v4]
In-Reply-To: <PESchU9s7SJ30uIlIhCkZZZb84bvppiRwBPMFBNJvs0=.1308e4f4-a4af-427b-b2db-f13f2a05be3a@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <PESchU9s7SJ30uIlIhCkZZZb84bvppiRwBPMFBNJvs0=.1308e4f4-a4af-427b-b2db-f13f2a05be3a@github.com>
Message-ID: <m56oWeFW871GjB8qxlFUNJRiVR7uQnpkW4AnzjMGSsA=.782e16f6-6d91-4d62-accb-65c7878801ad@github.com>

On Tue, 8 Feb 2022 08:17:17 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 one additional commit since the last revision:
> 
>   Make dwarf tag NOT_PRODUCT

Thank you Thomas for your first pass! I will probably get back to your comments on Monday as I'm taking the rest of the week off.

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

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


From dholmes at openjdk.java.net  Tue Feb 22 12:26:52 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Feb 2022 12:26:52 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <A8KEg03nvghZ-WFGi41gJfE7cU85FxVY8Kiw7Gfw7YQ=.bd064695-e381-4933-a274-6e9751ea63c9@github.com>

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

Hi Daniel,

Hotspot changes look fine.

Some of the casts in other code look odd to me, but I'll leave that for the security-libs folk to comment on.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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


From duke at openjdk.java.net  Tue Feb 22 14:05:22 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Tue, 22 Feb 2022 14:05:22 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v24]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <3qZYWOySJyCqIHpvp9zg-Co3mBJt19hO5HwTK8NJjIE=.5d70fbfe-16db-45dc-92c0-058b50cb2955@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:

  Merge master

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6334/files
  - new: https://git.openjdk.java.net/jdk/pull/6334/files/f9882ff1..97ae934b

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

  Stats: 274 lines in 17 files changed: 176 ins; 69 del; 29 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 djelinski at openjdk.java.net  Tue Feb 22 14:16:49 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 14:16:49 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
In-Reply-To: <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
Message-ID: <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>

On Tue, 22 Feb 2022 11:33:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> make/autoconf/flags-cflags.m4 line 136:
> 
>> 134:       CFLAGS_WARNINGS_ARE_ERRORS="-WX"
>> 135: 
>> 136:       WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"
> 
> This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK.

Done

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

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


From duke at openjdk.java.net  Tue Feb 22 14:35:19 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Tue, 22 Feb 2022 14:35:19 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@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 34 commits:

 - Merge master
 - Merge master
 - Merge master
 - Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret
 - Add comments to enter calls
 - Set PreserveFramePointer if use_rop_protection is set
 - Merge enter_subframe into enter
 - Review fixups
 - Documentation updates
 - Update copyrights to 2022
 - ... and 24 more: https://git.openjdk.java.net/jdk/compare/022d8070...c4e0ee31

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

Changes: https://git.openjdk.java.net/jdk/pull/6334/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6334&range=24
  Stats: 1481 lines in 35 files changed: 574 ins; 32 del; 875 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 ihse at openjdk.java.net  Tue Feb 22 15:53:20 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 15:53:20 GMT
Subject: RFR: 8244593: Clean up GNM/NM after JEP 381
Message-ID: <MAFADojw_920bpG9yL0XHA-5vzafSzBCCG9rL7oZW8E=.ed76aa3c-5563-4782-9b3e-67a6dfeac3ec@github.com>

Long overdue follow-up bug from JEP 381 (removal of Solaris support). We used to make a difference between gnm (GNU nm) and nm (GNU nm on all platforms except Solaris, where it were Solaris nm), but this does not make sense anymore, and the code is just schizophrenic wrt nm/gnm.

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

Commit messages:
 - 8244593: Clean up GNM/NM after JEP 381

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

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


From erikj at openjdk.java.net  Tue Feb 22 15:59:05 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 22 Feb 2022 15:59:05 GMT
Subject: RFR: 8244593: Clean up GNM/NM after JEP 381
In-Reply-To: <MAFADojw_920bpG9yL0XHA-5vzafSzBCCG9rL7oZW8E=.ed76aa3c-5563-4782-9b3e-67a6dfeac3ec@github.com>
References: <MAFADojw_920bpG9yL0XHA-5vzafSzBCCG9rL7oZW8E=.ed76aa3c-5563-4782-9b3e-67a6dfeac3ec@github.com>
Message-ID: <zkz03jkZ2GcyUnxQsyOb6gFAvY1d_psDHRxXnvVksfs=.ec333f16-ecef-4d00-ba53-96ce64689c1e@github.com>

On Tue, 22 Feb 2022 15:47:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Long overdue follow-up bug from JEP 381 (removal of Solaris support). We used to make a difference between gnm (GNU nm) and nm (GNU nm on all platforms except Solaris, where it were Solaris nm), but this does not make sense anymore, and the code is just schizophrenic wrt nm/gnm.

Marked as reviewed by erikj (Reviewer).

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

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


From ihse at openjdk.java.net  Tue Feb 22 16:10:53 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 16:10:53 GMT
Subject: Integrated: 8244593: Clean up GNM/NM after JEP 381
In-Reply-To: <MAFADojw_920bpG9yL0XHA-5vzafSzBCCG9rL7oZW8E=.ed76aa3c-5563-4782-9b3e-67a6dfeac3ec@github.com>
References: <MAFADojw_920bpG9yL0XHA-5vzafSzBCCG9rL7oZW8E=.ed76aa3c-5563-4782-9b3e-67a6dfeac3ec@github.com>
Message-ID: <8vBY73c8VoAE5W3qO97i8nyIam99aEake7cEnc-Rzi8=.2a55ff8b-cf47-44a6-ba44-157a6b0c49a9@github.com>

On Tue, 22 Feb 2022 15:47:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Long overdue follow-up bug from JEP 381 (removal of Solaris support). We used to make a difference between gnm (GNU nm) and nm (GNU nm on all platforms except Solaris, where it were Solaris nm), but this does not make sense anymore, and the code is just schizophrenic wrt nm/gnm.

This pull request has now been integrated.

Changeset: e44d0670
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e44d0670a69a641b82a0ca50e06e85d807b473ea
Stats:     4 lines in 3 files changed: 0 ins; 3 del; 1 mod

8244593: Clean up GNM/NM after JEP 381

Reviewed-by: erikj

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

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


From shade at openjdk.java.net  Tue Feb 22 16:18:24 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 22 Feb 2022 16:18:24 GMT
Subject: RFR: 8282225: GHA: Allow one concurrent run per PR only [v2]
In-Reply-To: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
References: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
Message-ID: <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>

> Since last year, GHA allows concurrency control over GHA runs:
>  https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>  https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
> 
> Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.
> 
> I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.
> 
> Additional testing:
>  - [x] Verified queued run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on merge
>  - [x] Verified in-progress run gets cancelled on rebase + force-push

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

  Also specialize by workflow

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7570/files
  - new: https://git.openjdk.java.net/jdk/pull/7570/files/2fcf52fa..d64ad2ac

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

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

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


From shade at openjdk.java.net  Tue Feb 22 16:18:25 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 22 Feb 2022 16:18:25 GMT
Subject: RFR: 8282225: GHA: Allow one concurrent run per PR only
In-Reply-To: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
References: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
Message-ID: <oxi7QjWdXu_-kayAOU3Ccq4BFYK0RzWR_wqEiIv7sY4=.c85f8177-7c8a-4a80-929a-eb8f016bc39c@github.com>

On Tue, 22 Feb 2022 07:05:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Since last year, GHA allows concurrency control over GHA runs:
>  https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>  https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
> 
> Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.
> 
> I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.
> 
> Additional testing:
>  - [x] Verified queued run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on merge
>  - [x] Verified in-progress run gets cancelled on rebase + force-push

I realized that we would be better off specializing by workflow name as well. While we only have one workflow in the upstream repo, others might have more than one referenced by the same concurrency key. To avoid surprises, we can should also mix in `github.workflow`.

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

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


From ihse at openjdk.java.net  Tue Feb 22 16:19:17 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 16:19:17 GMT
Subject: RFR: 8209784: Include hsdis in the JDK
Message-ID: <cCfX5vLO2fbtDV6Xmu2xcYZ51UHL1K1g-v2-jglEBko=.7648db91-559c-4d6a-ba32-22a576993d49@github.com>

This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK.

The PR also includes a refactoring of the hsdis handling in autoconf, breaking it out to a separate file `lib-hsdis.gmk`, and breaking the functionality up in separate functions per backend.

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

Commit messages:
 - Add bundling of hsdis with java.base
 - Refactor lib-hsdis.gmk by breaking out each backend in a separate function
 - Break out hsdis setup to separate file

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

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


From ihse at openjdk.java.net  Tue Feb 22 16:29:51 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 16:29:51 GMT
Subject: RFR: 8282225: GHA: Allow one concurrent run per PR only [v2]
In-Reply-To: <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
References: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
 <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
Message-ID: <SKSpODl7_F_96EJJiKlytxUem0kE1Jn-VP0TW_KZ0-k=.bd78f28b-3bbd-4fc8-beb1-4781b80fcf88@github.com>

On Tue, 22 Feb 2022 16:18:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since last year, GHA allows concurrency control over GHA runs:
>>  https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>>  https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
>> 
>> Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.
>> 
>> I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.
>> 
>> Additional testing:
>>  - [x] Verified queued run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on merge
>>  - [x] Verified in-progress run gets cancelled on rebase + force-push
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also specialize by workflow

Marked as reviewed by ihse (Reviewer).

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

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


From erikj at openjdk.java.net  Tue Feb 22 16:41:41 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 22 Feb 2022 16:41:41 GMT
Subject: RFR: 8209784: Include hsdis in the JDK
In-Reply-To: <cCfX5vLO2fbtDV6Xmu2xcYZ51UHL1K1g-v2-jglEBko=.7648db91-559c-4d6a-ba32-22a576993d49@github.com>
References: <cCfX5vLO2fbtDV6Xmu2xcYZ51UHL1K1g-v2-jglEBko=.7648db91-559c-4d6a-ba32-22a576993d49@github.com>
Message-ID: <2FFpuurf7bTp2lmeLBnJtenZNGEjVJBgVnIYW27MqZk=.326d64f6-78fa-47d6-a51a-5d5d2d173130@github.com>

On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK.
> 
> The PR also includes a refactoring of the hsdis handling in autoconf, breaking it out to a separate file `lib-hsdis.gmk`, and breaking the functionality up in separate functions per backend.

Marked as reviewed by erikj (Reviewer).

make/Hsdis.gmk line 186:

> 184:     $(install-file)
> 185: 
> 186:   $(INSTALLED_HSDIS_IMAGE): $(BUILT_HSDIS_LIB)

This slipped past me earlier, but the install-hsdis target at the top level does not have any prereq. I believe it needs to depend on jdk-image for installation to the image to work. Otherwise it will just get deleted if the jdk-image target is built after.

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

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


From djelinski at openjdk.java.net  Tue Feb 22 16:43:28 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 16:43:28 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

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

  Move strictStrings to toolchain_cflags

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7565/files
  - new: https://git.openjdk.java.net/jdk/pull/7565/files/fe18b41d..0cfbb165

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

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

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


From ihse at openjdk.java.net  Tue Feb 22 16:43:30 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 16:43:30 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
 <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>
Message-ID: <Zs7aKh_SdESd32qIE2JRDRmbuEIfHnpvnbQ7OJZgyiE=.6b7f1d75-696d-440d-bfe3-0c49a4db8cc5@github.com>

On Tue, 22 Feb 2022 14:13:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 136:
>> 
>>> 134:       CFLAGS_WARNINGS_ARE_ERRORS="-WX"
>>> 135: 
>>> 136:       WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"
>> 
>> This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK.
>
> Done

Did you forget to push the fix?

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

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


From djelinski at openjdk.java.net  Tue Feb 22 16:43:31 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 16:43:31 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <Zs7aKh_SdESd32qIE2JRDRmbuEIfHnpvnbQ7OJZgyiE=.6b7f1d75-696d-440d-bfe3-0c49a4db8cc5@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
 <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>
 <Zs7aKh_SdESd32qIE2JRDRmbuEIfHnpvnbQ7OJZgyiE=.6b7f1d75-696d-440d-bfe3-0c49a4db8cc5@github.com>
Message-ID: <2SOr0Aam68G8M26cjL1kFsz9YEWRr2lNfIsu_9rq-i8=.94d1aba2-a323-4e2d-9916-253dce6c98e7@github.com>

On Tue, 22 Feb 2022 16:35:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Done
>
> Did you forget to push the fix?

Push works better when connected... this time it's pushed for real.

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

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


From aph at openjdk.java.net  Tue Feb 22 16:57:48 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 22 Feb 2022 16:57:48 GMT
Subject: RFR: 8209784: Include hsdis in the JDK
In-Reply-To: <cCfX5vLO2fbtDV6Xmu2xcYZ51UHL1K1g-v2-jglEBko=.7648db91-559c-4d6a-ba32-22a576993d49@github.com>
References: <cCfX5vLO2fbtDV6Xmu2xcYZ51UHL1K1g-v2-jglEBko=.7648db91-559c-4d6a-ba32-22a576993d49@github.com>
Message-ID: <cdEBTnns-HYf_4enap1I7Qqwul_-Y4YxYhkBlMOQdK8=.88d370cf-a439-44c2-a363-8a124b9343f6@github.com>

On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK.

Maybe I missed it, but are there instructions somewhere about how to build this, and what should be downloaded?

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

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


From ihse at openjdk.java.net  Tue Feb 22 17:15:50 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 17:15:50 GMT
Subject: RFR: 8209784: Include hsdis in the JDK
In-Reply-To: <cdEBTnns-HYf_4enap1I7Qqwul_-Y4YxYhkBlMOQdK8=.88d370cf-a439-44c2-a363-8a124b9343f6@github.com>
References: <cCfX5vLO2fbtDV6Xmu2xcYZ51UHL1K1g-v2-jglEBko=.7648db91-559c-4d6a-ba32-22a576993d49@github.com>
 <cdEBTnns-HYf_4enap1I7Qqwul_-Y4YxYhkBlMOQdK8=.88d370cf-a439-44c2-a363-8a124b9343f6@github.com>
Message-ID: <IpVCDzs3AC6BnerigrHz8XVS-vzGlbVDW7MXDU0i3-0=.8ade0caa-ba14-4ea1-a9ff-ed680cbca7f6@github.com>

On Tue, 22 Feb 2022 16:54:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Maybe I missed it, but are there instructions somewhere about how to build this, and what should be downloaded?

See https://github.com/openjdk/jdk/blob/master/src/utils/hsdis/README.md

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

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


From ihse at openjdk.java.net  Tue Feb 22 17:16:51 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 17:16:51 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
Message-ID: <eMkXSbGRNHp_sQ1TsvgmlRGbI2YXvI74nE2HAFEqwrE=.b2d6048e-3557-4933-8302-bcb466ae6079@github.com>

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move strictStrings to toolchain_cflags

Now the build changes look good. Thanks!

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

Marked as reviewed by ihse (Reviewer).

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


From shade at openjdk.java.net  Wed Feb 23 07:54:52 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Feb 2022 07:54:52 GMT
Subject: RFR: 8282225: GHA: Allow one concurrent run per PR only [v2]
In-Reply-To: <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
References: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
 <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
Message-ID: <Sl7BydjZuxfzkKKr7KhRtEGuSNwG0ylv9NVPHQIyvqM=.f5ee35b0-ca14-40e5-a368-edbb4585398c@github.com>

On Tue, 22 Feb 2022 16:18:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since last year, GHA allows concurrency control over GHA runs:
>>  https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>>  https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
>> 
>> Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.
>> 
>> I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.
>> 
>> Additional testing:
>>  - [x] Verified queued run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on merge
>>  - [x] Verified in-progress run gets cancelled on rebase + force-push
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also specialize by workflow

I think this is pretty simple, so I shall be integrating with one review. Or anyone else may put stamp their review on it :)

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

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


From ihse at openjdk.java.net  Wed Feb 23 12:36:54 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Feb 2022 12:36:54 GMT
Subject: RFR: 8282225: GHA: Allow one concurrent run per PR only [v2]
In-Reply-To: <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
References: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
 <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
Message-ID: <ql5PdydhRtRNlV8H_EJotVeiIC1QiBIHFJ71B0JN6Ig=.fa043e72-dd36-4dbd-9fda-4a973ce9a631@github.com>

On Tue, 22 Feb 2022 16:18:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since last year, GHA allows concurrency control over GHA runs:
>>  https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>>  https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
>> 
>> Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.
>> 
>> I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.
>> 
>> Additional testing:
>>  - [x] Verified queued run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on merge
>>  - [x] Verified in-progress run gets cancelled on rebase + force-push
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also specialize by workflow

The two reviewer rule is specific to hotspot code. In build code, we're okay with a single reviewer and no 24h waiting (with the risk of having to amend the fix later), since so few people are available to review build code.

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

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


From shade at openjdk.java.net  Wed Feb 23 12:36:54 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Feb 2022 12:36:54 GMT
Subject: RFR: 8282225: GHA: Allow one concurrent run per PR only [v2]
In-Reply-To: <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
References: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
 <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
Message-ID: <FspyquWrfbhVzMLw1Ztcb8ytUlCfl58LBvn2HI7yfGk=.c61dafee-c503-4c15-b8e5-b5e511c874bd@github.com>

On Tue, 22 Feb 2022 16:18:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since last year, GHA allows concurrency control over GHA runs:
>>  https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>>  https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
>> 
>> Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.
>> 
>> I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.
>> 
>> Additional testing:
>>  - [x] Verified queued run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on merge
>>  - [x] Verified in-progress run gets cancelled on rebase + force-push
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also specialize by workflow

The more reviewers the merrier, though! But I get your point.

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

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


From shade at openjdk.java.net  Wed Feb 23 12:36:55 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Feb 2022 12:36:55 GMT
Subject: Integrated: 8282225: GHA: Allow one concurrent run per PR only
In-Reply-To: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
References: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
Message-ID: <kwA5pEUQdsCVjGMhH-rVrxJw-MvNvotIR-PTSOO2dvc=.d25de531-c79f-4d79-9c17-7c056b1b1869@github.com>

On Tue, 22 Feb 2022 07:05:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Since last year, GHA allows concurrency control over GHA runs:
>  https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>  https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
> 
> Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.
> 
> I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.
> 
> Additional testing:
>  - [x] Verified queued run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on merge
>  - [x] Verified in-progress run gets cancelled on rebase + force-push

This pull request has now been integrated.

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

8282225: GHA: Allow one concurrent run per PR only

Reviewed-by: ihse

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

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


From ihse at openjdk.java.net  Wed Feb 23 12:46:53 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Feb 2022 12:46:53 GMT
Subject: RFR: 8282225: GHA: Allow one concurrent run per PR only [v2]
In-Reply-To: <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
References: <AjneVmSLoyhPtmmfMzCsNvrVAalzRr3_kYPO-ryZ6uk=.d25efef5-5592-4b5c-93d1-51b9f5402834@github.com>
 <yqfczt0vSxoNP3VWyNT4ikMzG-5eYocemdM-yky7ljg=.c1dbfdf3-49ce-4c62-a4a6-61f203d6cf5c@github.com>
Message-ID: <JZIPd9wYWbWJPpiA0CCbhrRcvqY-ETwV9yO0ET5l_x4=.437aa36a-3e7f-41e9-9789-c4494dc8fca1@github.com>

On Tue, 22 Feb 2022 16:18:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since last year, GHA allows concurrency control over GHA runs:
>>  https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>>  https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
>> 
>> Our GHA workflows trigger on every PR update, sometimes doing multiple runs per PR. This is seldom useful and wastes resources with our very large jobs. For example, one can push a commit, quickly realize there is a mistake, push another commit, and this would do *two* GHA runs, both taking many hours.
>> 
>> I think we can say that only one run per branch is good, and all running/pending runs should be cancelled when a new run starts.
>> 
>> Additional testing:
>>  - [x] Verified queued run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on new commit
>>  - [x] Verified in-progress run gets cancelled on merge
>>  - [x] Verified in-progress run gets cancelled on rebase + force-push
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also specialize by workflow

Of course, the more the merrier. :-) Especially if you are making a big or controversial change, it's good to wait for more reviewers. It's also good to wait for reviewers from the build group (sometimes developers from other teams approve build changes, but they might miss subtleties). But if you think that one reviewer is enough, you don't really need to ask permission to integrate with just one reviewer.

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

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


From duke at openjdk.java.net  Wed Feb 23 13:45:00 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Wed, 23 Feb 2022 13:45:00 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
Message-ID: <8puP07DM-ldrOlaYyU7ex_gpFMjSbRWjfuObimo-XPQ=.fa443055-bf97-4602-a177-4d62682f1f95@github.com>

On Tue, 22 Feb 2022 14:35:19 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 34 commits:
> 
>  - Merge master
>  - Merge master
>  - Merge master
>  - Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret
>  - Add comments to enter calls
>  - Set PreserveFramePointer if use_rop_protection is set
>  - Merge enter_subframe into enter
>  - Review fixups
>  - Documentation updates
>  - Update copyrights to 2022
>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/022d8070...c4e0ee31

I did another full jteg run, and everything looks fine.
Think that's all the review comments resolved now too.

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

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


From duke at openjdk.java.net  Thu Feb 24 10:55:28 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 24 Feb 2022 10:55:28 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
Message-ID: <0Ob4kezo_Q0ro0eF_OeEABrzYeZCNmoaD5KQUcBpZRc=.6c772f45-c70c-4983-880a-8878e281d04b@github.com>

On Tue, 22 Feb 2022 14:35:19 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 34 commits:
> 
>  - Merge master
>  - Merge master
>  - Merge master
>  - Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret
>  - Add comments to enter calls
>  - Set PreserveFramePointer if use_rop_protection is set
>  - Merge enter_subframe into enter
>  - Review fixups
>  - Documentation updates
>  - Update copyrights to 2022
>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/022d8070...c4e0ee31

Any more comments? Otherwise I'll integrate later

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

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


From duke at openjdk.java.net  Thu Feb 24 16:43:14 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Thu, 24 Feb 2022 16:43:14 GMT
Subject: Integrated: 8277204: Implement PAC-RET branch protection on
 Linux/AArch64
In-Reply-To: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
Message-ID: <XOJax9CYOxkQqo_L7t5Fm-95bDAKfOm2g4iqBHCXV1Y=.869e892e-055f-43bf-84c1-e6e41814941b@github.com>

On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

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

This pull request has now been integrated.

Changeset: 6fab8a2d
Author:    Alan Hayward <alan.hayward at arm.com>
Committer: Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6fab8a2d6a97dbd2ffceca275716d020cb9f1eea
Stats:     1481 lines in 35 files changed: 574 ins; 32 del; 875 mod

8277204: Implement PAC-RET branch protection on Linux/AArch64

Reviewed-by: erikj, ihse, adinn, ngasson

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

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


From adinn at openjdk.java.net  Thu Feb 24 16:40:16 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 24 Feb 2022 16:40:16 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
Message-ID: <Z4KBz1q522P9E4-eLyNOx2KIunHSeGU5Wkas1wUszWo=.ca074bd0-eade-4380-b4c6-f3f29e92ccd6@github.com>

On Tue, 22 Feb 2022 14:35:19 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 34 commits:
> 
>  - Merge master
>  - Merge master
>  - Merge master
>  - Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret
>  - Add comments to enter calls
>  - Set PreserveFramePointer if use_rop_protection is set
>  - Merge enter_subframe into enter
>  - Review fixups
>  - Documentation updates
>  - Update copyrights to 2022
>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/022d8070...c4e0ee31

Yup this looks good to me. I will sponsor.

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

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


From weijun at openjdk.java.net  Thu Feb 24 17:51:07 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 24 Feb 2022 17:51:07 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
Message-ID: <xvKE6mKQqjoRcQ2vEzfSEZ9GAmuzYDaoSnkylfTno-c=.f32adddb-5b97-4f42-8c80-583db1f2cdd5@github.com>

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move strictStrings to toolchain_cflags

I'm the original author of `sspi.cpp`. All changes look fine to me. Thanks a lot for the enhancement.

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

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


From djelinski at openjdk.java.net  Thu Feb 24 17:56:05 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Feb 2022 17:56:05 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
Message-ID: <dT9-STWdBmnXf6mFXNslesrmFvyLrLZMflRbNWjslIM=.a2d6dc98-41e4-4fce-a198-293bbb4ae650@github.com>

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move strictStrings to toolchain_cflags

Great, thanks all for reviewing!

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

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


From djelinski at openjdk.java.net  Thu Feb 24 18:23:06 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Feb 2022 18:23:06 GMT
Subject: Integrated: 8281525: Enable Zc:strictStrings flag in Visual Studio
 build
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <MF2IUkKV8ihC_zd8yRpJJPfPJ_Idc0_QU4crXs_1Zng=.fa781f16-8c29-4e73-9412-dfe7ec2e2aaa@github.com>

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

This pull request has now been integrated.

Changeset: 23995f82
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/23995f822e540d799eb4bbc969229422257fbb08
Stats:     23 lines in 6 files changed: 0 ins; 0 del; 23 mod

8281525: Enable Zc:strictStrings flag in Visual Studio build

Reviewed-by: dholmes, ihse

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

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


From dholmes at openjdk.java.net  Fri Feb 25 13:12:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Feb 2022 13:12:04 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <0Ob4kezo_Q0ro0eF_OeEABrzYeZCNmoaD5KQUcBpZRc=.6c772f45-c70c-4983-880a-8878e281d04b@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
 <0Ob4kezo_Q0ro0eF_OeEABrzYeZCNmoaD5KQUcBpZRc=.6c772f45-c70c-4983-880a-8878e281d04b@github.com>
Message-ID: <YaH2-5pWHVhcBA15WqN4tDBuWG-lG2GKhoe9WibbW2s=.23a1d4cf-cee9-4006-9b11-f1917cb74cfc@github.com>

On Thu, 24 Feb 2022 10:52:00 GMT, Alan Hayward <duke at openjdk.java.net> wrote:

>> Alan Hayward has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge master
>>  - Merge master
>>  - Merge master
>>  - Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret
>>  - Add comments to enter calls
>>  - Set PreserveFramePointer if use_rop_protection is set
>>  - Merge enter_subframe into enter
>>  - Review fixups
>>  - Documentation updates
>>  - Update copyrights to 2022
>>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/022d8070...c4e0ee31
>
> Any more comments? Otherwise I'll integrate later

@a74nh this seems to have broken the Zero build:

src/hotspot/share/gc/shared/barrierSetNMethod.cpp:58:33: error: 'pauth_strip_pointer' was not declared in this scope
 58 |   AARCH64_ONLY(return_address = pauth_strip_pointer(return_address));

I'm guessing a missing include file.

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

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


From aph-open at littlepinkcloud.com  Fri Feb 25 13:22:53 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 25 Feb 2022 13:22:53 +0000
Subject: RFR: 8277204: Implement PAC-RET branch protection on
 Linux/AArch64 [v25]
In-Reply-To: <YaH2-5pWHVhcBA15WqN4tDBuWG-lG2GKhoe9WibbW2s=.23a1d4cf-cee9-4006-9b11-f1917cb74cfc@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
 <0Ob4kezo_Q0ro0eF_OeEABrzYeZCNmoaD5KQUcBpZRc=.6c772f45-c70c-4983-880a-8878e281d04b@github.com>
 <YaH2-5pWHVhcBA15WqN4tDBuWG-lG2GKhoe9WibbW2s=.23a1d4cf-cee9-4006-9b11-f1917cb74cfc@github.com>
Message-ID: <07f0cf30-9f2c-ee09-4a5c-45439cc83393@littlepinkcloud.com>

On 2/25/22 13:12, David Holmes wrote:
> the Zero build

Zero on AArch64? I wonder if we need a better way of handling this than

AARCH64_ONLY(NOT_ZERO(

Maybe AARCH64_PORT_ONLY would be a Good Thing.

-- 
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 duke at openjdk.java.net  Fri Feb 25 15:20:04 2022
From: duke at openjdk.java.net (Alan Hayward)
Date: Fri, 25 Feb 2022 15:20:04 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
Message-ID: <ArmGs6Cgh0Btoy5bQPD2tbMGsh54co0X66oWBYrHhWg=.1cc128d0-9a74-4de5-a1b1-28aea6c7a2ad@github.com>

On Tue, 22 Feb 2022 14:35:19 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 34 commits:
> 
>  - Merge master
>  - Merge master
>  - Merge master
>  - Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret
>  - Add comments to enter calls
>  - Set PreserveFramePointer if use_rop_protection is set
>  - Merge enter_subframe into enter
>  - Review fixups
>  - Documentation updates
>  - Update copyrights to 2022
>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/022d8070...c4e0ee31

Yes, we spotted this today too. https://bugs.openjdk.java.net/browse/JDK-8282392

My initial thought was that I needed to add a pauth header file with stub functions to linux_zero/. Which does feel a little awkward.

AARCH64_PORT_ONLY does sound like a better option.

Thankfully there is no need for full pac support in zero too.... :)

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

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


From chagedorn at openjdk.java.net  Mon Feb 28 16:22:31 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 28 Feb 2022 16:22:31 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v4]
In-Reply-To: <ZTggm8ZVeipDBUrgoc_wPQNBHKTkO9HmIIQ1-6mFZDY=.d076d6b2-c6a8-423c-8f84-83a4c43f9a3f@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <PESchU9s7SJ30uIlIhCkZZZb84bvppiRwBPMFBNJvs0=.1308e4f4-a4af-427b-b2db-f13f2a05be3a@github.com>
 <ZTggm8ZVeipDBUrgoc_wPQNBHKTkO9HmIIQ1-6mFZDY=.d076d6b2-c6a8-423c-8f84-83a4c43f9a3f@github.com>
Message-ID: <5YeksetlUoja6cRgWtaorVsXCDLEQRw8s7B9W5UJOUE=.22f23a33-8877-4c3a-9b6d-f648fb1c4fc3@github.com>

On Tue, 22 Feb 2022 09:59:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make dwarf tag NOT_PRODUCT
>
> src/hotspot/share/utilities/elfFile.cpp line 319:
> 
>> 317:     }
>> 318:     log_develop_info(dwarf)("No separate .debuginfo file for library %s. It already contains the required DWARF sections.", _filepath);
>> 319:     _dwarf_file = new (std::nothrow) DwarfFile(_filepath);
> 
> Would it be useful to explicitly bail out on a `nullptr` value here to avoid crashes below?

Yes, I think that's the right way. I changed other allocations as well to bail out.

> src/hotspot/share/utilities/elfFile.cpp line 357:
> 
>> 355:   }
>> 356: 
>> 357:   strcpy(debug_pathname, _filepath);
> 
> I'm always a bit uneasy using "raw" `strcpy` instead of `strncpy` and friends. The code seems to be correct though.

Yes that's true. I updated usages while introducing a new helper class `DwarfFilePath`.

> src/hotspot/share/utilities/elfFile.cpp line 784:
> 
>> 782:   }
>> 783: 
>> 784:   if (!_reader.read_byte(&_header._address_size) || NOT_LP64(_header._address_size != 4)  LP64_ONLY( _header._address_size != 8)) {
> 
> Since this is the second time for the clause `|| NOT_LP64(_header._address_size != 4) LP64_ONLY( _header._address_size != 8)` maybe it is useful to make a constant out of the accepted address size somewhere instead of repeating this over and over.
> It's value could even be something like `sizeof(intptr_t)` or so.

I agree, I introduced a new constant `DwarfFile::ADDRESS_SIZE`.

> src/hotspot/share/utilities/elfFile.cpp line 1070:
> 
>> 1068:     // reason, GCC is currently using version 3 as specified in the DWARF 3 spec for the line number program even though GCC should
>> 1069:     // be using version 4 for DWARF 4 as it emits DWARF 4 by default.
>> 1070:     return false;
> 
> According to the specification (pg112):
> 
>> `version (uhalf)`
>> A version number (see Appendix F). This number is specific to the line number information
>> and is independent of the DWARF version number.
> 
> So this is just fine - actually things may break if the code accepted version 4 here assuming that there are breaking differences.
> On the other hand Appendix F mentions that DWARF4 contains .debug_line information in version 4.

The `LineNumberProgram` class should be able to handle both version 3 and 4. There are some differences (see `_dwarf_version` checks). But I found that GCC even mixes version 3 and 4:
https://github.com/chhagedorn/jdk/blob/820f0da65ab06b28ac75eec96d35269addda0246/src/hotspot/share/utilities/elfFile.cpp#L1302-L1308

> src/hotspot/share/utilities/elfFile.hpp line 211:
> 
>> 209: 
>> 210:   // Load the DWARF file (.debuginfo) that belongs to this file.
>> 211:   bool load_dwarf_file();
> 
> It would be nice to summarize from which places this methods tries to load the debug info to prevent the need for digging for it in the method implementation.

Good suggestion. I added a summary and refactored the different loading attempts into separate methods together with a new class `DwarfFilePath` which makes it easier to prepare the different paths.

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

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


From chagedorn at openjdk.java.net  Mon Feb 28 16:22:25 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 28 Feb 2022 16:22:25 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v5]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <Xk0ZAEKBg48k7SyVHxyMNTyNUVHAVEpBJi65h2DW-sY=.69ab83c8-6619-408d-bcfc-0305231e1e8c@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 with a new target base due to a merge or a rebase. The pull request now contains 54 commits:

 - Updating some comments
 - Cleanup loading dwarf file and add summary
 - Review comments of first pass by Thomas except dwarf file loading
 - Merge branch 'master' into JDK-8242181
 - Make dwarf tag NOT_PRODUCT
 - Change log_* to log_develop_* and log_warning to log_develop_info
 - 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>
 - Better formatting of trace output
 - some code move and more cleanups
 - ... and 44 more: https://git.openjdk.java.net/jdk/compare/efd3967b...5bea4841

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

Changes: https://git.openjdk.java.net/jdk/pull/7126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=04
  Stats: 2665 lines in 19 files changed: 2524 ins; 76 del; 65 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