Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
On Tue, 23 Mar 2021 16:33:50 GMT, Andrew Haley wrote: >> Marked as reviewed by luhenry (Author). > >> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 >> > > > maintainers to accept this (and few other, like jep-388, as we depend >> > > > on it) contribution. >> > > >> > > >> > > To the extent that 11u has fixed policies :) we definitely have a policy >> > > of accepting patches to keep 11u working on current hardware. So yes. >> > >> > >> > @lewurm That sounds like a green flag for you and jep-388 (with its >> > R18_RESERVED functionality) ;) >> >> Thanks, @theRealAph, and @VladimirKempik . We are on it! > > It's going to be tricky to do in a really clean way, given some of the > weirdnesses of the ABI. However, I think there's probably a need for it The JEP was targeted to JDK17. So I propose to integrate this. Thank you all for the reviews, suggestions, discussions, and support! - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v30]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 117 commits: - JDK-8261397: bsd_aarch64 part - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Merge branch 'master' into jdk-macos - JDK-8262491: bsd_aarch64 part - JDK-8263002: bsd_aarch64 part - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Wider #ifdef block - Fix most of issues in java/foreign/ tests Failures related to va_args are tracked in JDK-8263512. - Add Azul copyright - Update Oracle copyright years - ... and 107 more: https://git.openjdk.java.net/jdk/compare/b006f22f...d3629967 - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=29 Stats: 2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
[OpenJDK 2D-Dev] Integrated: 8253795: Implementation of JEP 391: macOS/AArch64 Port
On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov wrote: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) This pull request has now been integrated. Changeset: dbc9e4b5 Author:Anton Kozlov Committer: Vladimir Kempik URL: https://git.openjdk.java.net/jdk/commit/dbc9e4b5 Stats: 2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod 8253795: Implementation of JEP 391: macOS/AArch64 Port 8253816: Support macOS W^X 8253817: Support macOS Aarch64 ABI in Interpreter 8253818: Support macOS Aarch64 ABI for compiled wrappers 8253819: Implement os/cpu for macOS/AArch64 8253839: Update tests and JDK code for macOS/Aarch64 8254941: Implement Serviceability Agent for macOS/AArch64 8255776: Change build system for macOS/AArch64 8262903: [macos_aarch64] Thread::current() called on detached thread Co-authored-by: Vladimir Kempik Co-authored-by: Bernhard Urban-Forster Co-authored-by: Ludovic Henry Co-authored-by: Monica Beckwith Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
On Tue, 23 Mar 2021 12:49:34 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 115 commits: >> >> - Merge branch 'master' into jdk-macos >> - JDK-8262491: bsd_aarch64 part >> - JDK-8263002: bsd_aarch64 part >> - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos >> - Wider #ifdef block >> - Fix most of issues in java/foreign/ tests >> >>Failures related to va_args are tracked in JDK-8263512. >> - Add Azul copyright >> - Update Oracle copyright years >> - Use Thread::current_or_null_safe in SafeFetch >> - 8262903: [macos_aarch64] Thread::current() called on detached thread >> - ... and 105 more: >> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269 > > Build changes still look good. Hope you can get this done now! :) > > No, no, no! I am not suggesting you change anything else, just that > > you do not define contentless macros. You might as well define it > > to be something, and true is a reasonable default, that's all. It's > > not terribly important, it's just good practice. > > I'm quite prepared to drop this if it's holding up the port. It's a style > thing, but it's not critical. Sorry, I missed your reply. R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change. The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35 and https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137 But https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59 and https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits: - Merge branch 'master' into jdk-macos - JDK-8262491: bsd_aarch64 part - JDK-8263002: bsd_aarch64 part - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Wider #ifdef block - Fix most of issues in java/foreign/ tests Failures related to va_args are tracked in JDK-8263512. - Add Azul copyright - Update Oracle copyright years - Use Thread::current_or_null_safe in SafeFetch - 8262903: [macos_aarch64] Thread::current() called on detached thread - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269 - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=28 Stats: 2947 lines in 75 files changed: 2838 ins; 27 del; 82 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v28]
On Sat, 13 Mar 2021 05:49:53 GMT, David Holmes wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 114 commits:
>>
>> - JDK-8262491: bsd_aarch64 part
>> - JDK-8263002: bsd_aarch64 part
>> - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>> - Wider #ifdef block
>> - Fix most of issues in java/foreign/ tests
>>
>>Failures related to va_args are tracked in JDK-8263512.
>> - Add Azul copyright
>> - Update Oracle copyright years
>> - Use Thread::current_or_null_safe in SafeFetch
>> - 8262903: [macos_aarch64] Thread::current() called on detached thread
>> - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk
>> into jdk-macos
>> - ... and 104 more:
>> https://git.openjdk.java.net/jdk/compare/d825198e...806fc618
>
> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
>
>> 33: inline int SafeFetch32(int* adr, int errValue) {
>> 34: assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>> 35: Thread* thread = Thread::current_or_null_safe();
>
> Sorry but this should be MACOS_AARCH64 only. All three lines need to be
> ifdef'd if you are going to include the assertion.
>
> Thanks,
> David
Right, thanks! Fixed in
https://github.com/openjdk/jdk/pull/2200/commits/3d0f4d2342adc867eaf762fa83a9c3035d6439bd
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley wrote: >> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to >> define the value for the macro? > > Robustness, clarity, maintainability, convention. Why not? I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`). The rest of the defines in this file follows the pattern: a define without a value to be checked with `#ifdef` and define with a value to be checked with `#if`. To be consistent, I would need to add `#define R18_RESERVED false` to the `#else` clause and change every `#ifdef R18_RESERVED`/`#ifndef R18_RESERVED` to `#if R18_RESERVED`/`#if !R18_RESERVED`. I think we'll win in clarity in the long term if I will not implement the suggestion without related changes. (And related changes would introduce additional noise, which we are fighting with). - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
On Thu, 11 Mar 2021 20:27:51 GMT, Stefan Karlsson wrote: >> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block >> belongs to Thread for now. Since W^X is an attribute of any operating system >> thread, I assumed Thread to be the right place for W^X bookkeeping. >> >> In most cases, we manage W^X state of JavaThread. But sometimes a GC thread >> needs the WXWrite state, or safefetch is called from non-JavaThread. >> Probably this can be dealt with (e.g. GCThread to always have the WXWrite >> state). But such change would be much more than a simple refactoring and it >> would require a significant amount of testing. Ideally, I would like to >> investigate this as a follow-up change, or at least after other fixes to >> this PR. > > Good point about Thread vs JavaThread. Yes, this can be looked into as > follow-up cleanups. The enhancement is tracked in https://bugs.openjdk.java.net/browse/JDK-8263492 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v28]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits: - JDK-8262491: bsd_aarch64 part - JDK-8263002: bsd_aarch64 part - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Wider #ifdef block - Fix most of issues in java/foreign/ tests Failures related to va_args are tracked in JDK-8263512. - Add Azul copyright - Update Oracle copyright years - Use Thread::current_or_null_safe in SafeFetch - 8262903: [macos_aarch64] Thread::current() called on detached thread - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos - ... and 104 more: https://git.openjdk.java.net/jdk/compare/d825198e...806fc618 - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=27 Stats: 2949 lines in 75 files changed: 2839 ins; 27 del; 83 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v27]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Fix most of issues in java/foreign/ tests Failures related to va_args are tracked in JDK-8263512. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/29991c92..5bfe0f08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=26 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=25-26 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
On Thu, 11 Mar 2021 20:28:46 GMT, Stefan Karlsson wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8262903: [macos_aarch64] Thread::current() called on detached thread > > Marked as reviewed by stefank (Reviewer). > you still need to use Thread::current_or_null_safe() [for SafeFetch]. OK :) I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/fd4812e585e0528010a8863df50956a3b64a6744 @dcubed-ojdk, I also updated copyrights, this concludes fixes for the review https://github.com/openjdk/jdk/pull/2200#pullrequestreview-581784107. @theRealAph, could you elaborate on what is need to be done for https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v26]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision: - Add Azul copyright - Update Oracle copyright years - Use Thread::current_or_null_safe in SafeFetch - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/f6fb01b2..29991c92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=25 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=24-25 Stats: 83 lines in 53 files changed: 41 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8262903: [macos_aarch64] Thread::current() called on detached thread
>
> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
>
>> 33: inline int SafeFetch32(int* adr, int errValue) {
>> 34: assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>> 35: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));
>
> I think you may have to use `Thread::current_or_null_safe()` here in case
> this gets called from a signal handling context - see vmError.cpp testing for
> TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.
I'm not sure about expected behavior then. We may crash trying to execute the
generated code, since we may have no WXExec. If we switch to WXExec, we would
need to go back to a previous W^X state, but we don't know which one without
the thread.
BTW, the test passes, probably that's why it didn't get attention. All
non-trivial actions in the current implementation of
`pd_hotspot_signal_handler`
(hhttps://github.com/openjdk/jdk/pull/2200/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40R215-R324)
assume non-NULL thread. So AFAICS, we should always have a thread when the
SafeFetch is called.
Probably a fix to the https://bugs.openjdk.java.net/browse/JDK-8262903 could
just move ThreadWXEnable under the `if`. But now after
https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576is
ThreadWXEnable allows optional W^X state change, like `MutexLocker` allows
optional locking.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: 8262903: [macos_aarch64] Thread::current() called on detached thread - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/a72f6834..f6fb01b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=24 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=23-24 Stats: 13 lines in 5 files changed: 3 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
On Wed, 3 Mar 2021 15:57:13 GMT, Gerard Ziemski wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 207: >> >>> 205: // Enable WXWrite: this function is called by the signal handler at >>> arbitrary >>> 206: // point of execution. >>> 207: ThreadWXEnable wx(WXWrite, thread); >> >> Note that `thread` can be NULL here if the signal handler is running in a >> non-attached thread. If we then perform: >> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : >> _thread(thread ? thread : Thread::current()),` >> we call Thread::current() on a non-attached thread and that will >> assert/crash if we get NULL. Either avoid using WX when the thread is NULL, >> or else change to use Thread::current_or_null_safe() and ensure all uses >> have a NULL check. > >> Note that `thread` can be NULL here if the signal handler is running in a >> non-attached thread. If we then perform: >> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ? >> thread : Thread::current()),` >> we call Thread::current() on a non-attached thread and that will >> assert/crash if we get NULL. Either avoid using WX when the thread is NULL, >> or else change to use Thread::current_or_null_safe() and ensure all uses >> have a NULL check. > > https://bugs.openjdk.java.net/browse/JDK-8262903 tracks this issue. Thanks for report and analysis! I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
On Mon, 1 Mar 2021 10:31:19 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Minor fixes > > src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62: > >> 60: >> 61: #if defined(__APPLE__) || defined(_WIN64) >> 62: #define R18_RESERVED > > #define R18_RESERVED true``` We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro? - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
On Tue, 9 Feb 2021 09:23:50 GMT, Stefan Karlsson wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update signal handler part for debugger
>
> src/hotspot/share/runtime/thread.cpp line 2515:
>
>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread
>> *thread) {
>> 2514: // Enable WXWrite: called directly from interpreter native wrapper.
>> 2515: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread));
>
> FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the
> call sites increase the line-noise in the affected functions. I think I would
> have preferred a version:
> ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) {
> MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {}
> void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt.
> inline.hpp)
> With that said, I'm fine with taking this discussion as a follow-up.
The former version used no such macros. I like that now it's clear the W^X
management is relevant to macos/aarch64 only. I see the point to move the
pre-processor condition into the class implementation. But I think it will
bring a bit of inconsistency, as the rest of W^X implementation is explicitly
guarded by preprocessor conditionals. I've also tried to push macro
conditionals as far as possible down to implementation, providing a kind of
generalized W^X interface. That required a few artificial decisions, e.g. how
would we call the mode we execute on the rest of platforms with write and
execute allowed, WXWriteExec?.. I abandoned that attempt.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
On Tue, 9 Feb 2021 09:12:13 GMT, Stefan Karlsson wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update signal handler part for debugger > > src/hotspot/share/runtime/thread.hpp line 848: > >> 846: void init_wx(); >> 847: WXMode enable_wx(WXMode new_state); >> 848: #endif // __APPLE__ && AARCH64 > > Now that this is only compiled into macOS/AArch64, could this be moved over > to thread_bsd_aarch64.hpp? The same goes for the associated functions. The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits: - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos - workaround JDK-8262895 by disabling subtest - Fix typo - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp - JDK-8259937: bsd_aarch64 part - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Fix after JDK-8259539, partially revert preconditions - JDK-8260471: bsd_aarch64 part - JDK-8259539: bsd_aarch64 part - JDK-8257828: bsd_aarch64 part - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834 - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=23 Stats: 2873 lines in 73 files changed: 2787 ins; 27 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
On Tue, 9 Feb 2021 09:06:26 GMT, Stefan Karlsson wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update signal handler part for debugger > > src/hotspot/share/runtime/threadWXSetters.hpp line 28: > >> 26: #define SHARE_RUNTIME_THREADWXSETTERS_HPP >> 27: >> 28: #include "runtime/thread.inline.hpp" > > This breaks against our convention to forbid inline.hpp files from being > included from being included from .hpp files. You need to rework this by > either moving the implementation to a .cpp file, or convert this file into an > .inline.hpp > > See the Source Files section in: > https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html Thanks, I renamed the file to threadWXSetters.inline.hpp - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley wrote: > A list of the bugs that our internal testing revealed so far ... Thank you! Some of them look like test issues, but a few need more serious consideration. I want to resolve https://bugs.openjdk.java.net/browse/JDK-8262903 at least, along with a few remaining comments. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
On Thu, 4 Feb 2021 22:58:39 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >>+ minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 420: > >> 418: size_t os::Posix::_compiler_thread_min_stack_allowed = 72 * K; >> 419: size_t os::Posix::_java_thread_min_stack_allowed = 72 * K; >> 420: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 72 * K; > > Those are slightly larger than their x86_64 counter parts. Are they > conservative/aggressive values? How did we arrive at those? These values were copied from linux_aarch64. The motivation is that clang on macos/aarch64 will likely to produce stack frames for C++ functions similar to frames generates by gcc on linux/aarch64. And sizes of java stack frames should not change. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
On Fri, 12 Feb 2021 15:21:06 GMT, Vladimir Kempik wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302: >> >>> 300: const uint64_t *detail_msg_ptr >>> 301: = (uint64_t*)(pc + NativeInstruction::instruction_size); >>> 302: const char *detail_msg = (const char *)*detail_msg_ptr; >> >> Where is `detail_msg` used? > > Came from linux_arm64. was used in os_linux_aarch64.cpp on line 246 in > report_and_die > But became unused on bsd_arm64. I agree this needs to be removed It seems we have merged master branch before JDK-8259539 was integrated. It brings back use of detail_msg. I reverted details_msg as well its following use. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with five additional commits since the last revision: - Fix after JDK-8259539, partially revert preconditions - JDK-8260471: bsd_aarch64 part - JDK-8259539: bsd_aarch64 part - JDK-8257828: bsd_aarch64 part - Cleanup os_bsd_aarch64 signal handling - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/e42b82db..4c37f068 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=22 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=21-22 Stats: 31 lines in 1 file changed: 15 ins; 11 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
On Thu, 4 Feb 2021 22:34:16 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >>+ minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 237: > >> 235: os::Posix::ucontext_set_pc(uc, >> StubRoutines::continuation_for_safefetch_fault(pc)); >> 236: return true; >> 237: } > > Isn't this case already handled by `JVM_HANDLE_XXX_SIGNAL()` ? Why do we need > it here again? Good point, thanks. We are missing a few fixes in os_cpu/bsd_aarch64. This was moved out recently. I'm going to align bsd_aarch64 with the rest of platforms. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
On Thu, 4 Feb 2021 22:15:47 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>>+ minor change of placements
>> - Use macro conditionals instead of empty functions
>> - Add W^X to tests
>> - Do not require known W^X state
>> - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 322:
>
>> 320: #ifdef __APPLE__
>> 321: } else if (sig == SIGFPE && info->si_code == FPE_NOOP) {
>> 322: Unimplemented();
>
> Is there a follow up issue for this?
Thanks, this is a leftover from the development phase, it will be removed. In
macos/x86, this looks like a workaround. We've never met with this condition
and it looks recent darwin kernel should correctly report the cause in si_code:
https://github.com/apple/darwin-xnu/blob/33eb9835cd948dbbcdd8741aa52457cbe507c765/bsd/dev/arm/unix_signal.c#L436.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 23:10:17 GMT, Daniel D. Daugherty wrote: > For platform files that were copied from other ports to this port, if the > file wasn't > changed I presume the copyright years are left alone. If the file required > changes > for this port, I expect the year to be updated to 2021. How are you verifying > that > these copyright years are being properly managed on the new files? There are no exact copies, based on git -c diff.renameLimit=1000 diff --find-copies-harder -C75% --name-status upstream/master... So every file changed in the branch potentially needs the copyright update. All file diffs are not trivial, IMHO. I'll run the copyright update after we fix a few remaining issues with the PR, to avoid updating copyright and changing/reverting the actual content. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 22:47:04 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/share/prims/nativeEntryPoint.cpp line 45: > >> 43: guarantee(status == JNI_OK && !env->ExceptionOccurred(), >> 44: "register jdk.internal.invoke.NativeEntryPoint natives"); >> 45: JNI_END > > I thought that jcheck caught a missing new-line? It seems it did not https://github.com/openjdk/jdk/commit/0fb31dbf3a2adc0f7fb2f9924083908724dcde5a#diff-f39cd3f794a337734adf30863f702725ee04182fee2345b2669e59ebed17a2ccR44. Anyway I reverted this change as it is the only change in the file, thanks. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 22:18:43 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp line 43: > >> 41: assert(Thread::current() == this, "caller must be current thread"); >> 42: return pd_get_top_frame(fr_addr, ucontext, isInJava); >> 43: } > > Is AsyncGetCallTrace() being supported by this port? I assume answer to be yes (I have a little experience with AsyncGetCallTrace). This code is identical to one in bsd/x86 and linux/aarch64. After few changes in the build system, I got jtreg/serviceability/AsyncGetCallTrace test compiled and passed. I've filed JDK-8262839 to enable the test. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Fri, 12 Feb 2021 13:32:52 GMT, Vladimir Kempik wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486: >> >>> 484: } >>> 485: } >>> 486: } >> >> This appears to be a mix for Mavericks (10.9) and 10.12 >> work arounds. Is this code needed by this project? > > I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these > workaround > @gerard-ziemski, 8020753 was originally your fix, do you know if it still > needed on intel-mac ? The x86_bsd still carries the workaround https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745. It's worth having macos ports to be aligned by features. I would propose to have this workaround for now, and decide on it later for macos/x86 and macos/aarch64 at once. Sorry for chiming in so late. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Fri, 12 Feb 2021 12:40:09 GMT, Florian Weimer wrote: >> only macos comiplers > > The comment is also wrong for glibc: The AArch64 ABI requires a 64 KiB guard > region independently of page size, otherwise `-fstack-clash-protection` is > not reliable. Thanks, I deleted the comment. It describes implementation distinguishing initial and regular thread http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/548cb3b7b713#l12.7. I'm not sure why the comment was preserved for the bsd_x86, but I don't think it makes sense here. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Mon, 15 Feb 2021 17:59:54 GMT, Vladimir Kempik wrote:
>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810:
>>
>>> 808: #ifdef __APPLE__
>>> 809: // Less-than word types are stored one after another.
>>> 810: // The code unable to handle this, bailout.
>>
>> Perhaps: // The code is unable to handle this so bailout.
>
> Hello, we have updated PR, now this bailout is used only by the code which
> can handle it (native wrapper generator), for the rest it will cause
> guarantee failed if this bailout is triggered
I've fixed the spelling. Sorry for it to take so long :(
>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195:
>>
>>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>>> 194: return frame(fr->link(), fr->link(), fr->sender_pc());
>>> 195: }
>>
>> Is this file going to be built by GCC or just macOS compilers?
>
> there is no support for compiling java with gcc on macos since about jdk11,
> only clang.
> considering this and the absence of gcc for macos_m1, the answer is - just
> macOS compilers.
I've fixed the comment. Now it states `JVM compiled with
-fno-omit-frame-pointer, so RFP is saved on the stack.`
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v22]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Update comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/663cb4a1..e42b82db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=20-21 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Mon, 1 Mar 2021 10:46:34 GMT, Andrew Haley wrote: >> They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not >> there, but "Arm can assign codes that are not published in this manual. All >> values not assigned by Arm are reserved and must not be used.". I assume the >> value was obtained by digging around >> https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62 > > Anton, this paragraph looks like an excellent comment. Thanks, I've added the comment. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - Minor fixes - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/241aedee..663cb4a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=19-20 Stats: 85 lines in 5 files changed: 0 ins; 80 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v20]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #10 from VladimirKempik/pull/2200 Fix build after merge with master - Fix build after merge with master - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/74687c0b..241aedee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=18-19 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v19]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits: - Merge branch 'master' into jdk-macos - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Re-do safefetch.hpp - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos - stubRoutines.inline.hpp -> safefetch.hpp - Update copyrights - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Extract SafeFetch32/N to stubRoutines.inline.hpp - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. - ... and 79 more: https://git.openjdk.java.net/jdk/compare/d7efb4cc...74687c0b - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=18 Stats: 2953 lines in 74 files changed: 2862 ins; 27 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 22:42:22 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/share/logging/logStream.hpp line 35:
>
>> 33: class LogStream : public outputStream {
>> 34: // see test/hotspot/gtest/logging/test_logStream.cpp
>> 35: friend class LogStreamTest;
>
> It's not clear why this change is made for this port.
This was done for previous implementation of W^X, for gtests be able to access
this test. This not required anymore, this hunk was reverted.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Mon, 15 Feb 2021 16:21:53 GMT, Bernhard Urban-Forster wrote: >> This is the version of w^x on-demand switch implemented by microsoft guys. >> This is enabled only for debug builds. >> @lewurm could you comment here please > > Those values can be observed in the debugger, but aren't documented or > defined in header files. > > This mode was useful for the initial bootstrap of the platform (it helped > with missing W^X transitions), but shouldn't be required anymore today. I'm > fine with removing it altogether. OK, I'm going to remove this block. So we'll be able to revert changes in globals.hpp https://github.com/openjdk/jdk/pull/2200/files#r568986339 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 21:51:56 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 31: > >> 29: #include "asm/assembler.inline.hpp" >> 30: #include "oops/compressedOops.hpp" >> 31: #include "runtime/vm_version.hpp" > > It's not clear why this include needed to be added. Line 448 calls `VM_Version::features()`. It seems the declaration is included indirectly somehow on the rest of the platforms, through OS specific headers. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits: - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Re-do safefetch.hpp - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos - stubRoutines.inline.hpp -> safefetch.hpp - Update copyrights - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Extract SafeFetch32/N to stubRoutines.inline.hpp - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. - Merge pull request #9 from VladimirKempik/pull/2200 Removed unused variables - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=17 Stats: 2946 lines in 74 files changed: 2861 ins; 27 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v17]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #9 from VladimirKempik/pull/2200 Removed unused variables - Removed unused variables - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/419c2b1a..90e244e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=15-16 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v16]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #6 from VladimirKempik/pull/2200 Fix typo in comments - Fix typo in comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/a9452a4c..419c2b1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Wed, 3 Feb 2021 20:08:41 GMT, Anton Kozlov wrote: > I'm going to do as much refactoring as needed before this patch under > JDK-8261071 The recent merge resolves inconsitency between pass_byte/pass_short and other methods. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15]
On Sun, 31 Jan 2021 20:08:01 GMT, Vladimir Kempik wrote: >> I'm not sure it can wait. This change turns already-messy code into >> something significantly messier, to the extent that it's not really good >> enough to go into mainline. > > Hello > Does this look like something in the right direction ? > > https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49 The latest merge with JDK-8261071 should resolve the issue. Please take a look. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits: - Pull/2200 (#5) * bsd_aarch64 cleanup * remove the actual attribute too * Refactor bailing out on nativeWrapper generation * rename c_call_conv_priv function - Merge branch 'master' into jdk-macos - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos Additional work for JDK-8253817: Support macOS Aarch64 ABI in Interpreter - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Update signal handler part for debugger - Cleanup SA changes - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - support macos_aarch64 in hsdis - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - ... and 65 more: https://git.openjdk.java.net/jdk/compare/849f4c0f...a9452a4c - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=14 Stats: 3032 lines in 83 files changed: 2919 ins; 47 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v14]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits: - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos Additional work for JDK-8253817: Support macOS Aarch64 ABI in Interpreter - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Update signal handler part for debugger - Cleanup SA changes - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - support macos_aarch64 in hsdis - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header - Redo buildsys fix - ... and 63 more: https://git.openjdk.java.net/jdk/compare/40ae9937...4094f351 - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=13 Stats: 3066 lines in 84 files changed: 2954 ins; 47 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Wed, 3 Feb 2021 09:11:50 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323: >> >>> 321: str(zr, Address(rthread, JavaThread::last_Java_pc_offset())); >>> 322: >>> 323: str(zr, Address(rthread, >>> JavaFrameAnchor::saved_fp_address_offset())); >> >> I don't think this switch from `JavaThread::saved_fp_address_offset()` >> to `JavaFrameAnchor::saved_fp_address_offset()` is correct since >> `rthread` is still used and is a JavaThread*. The new code will give you: >> >> `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor >> >> The old code gave you: >> >> `rthread` + offset of the `saved_fp_address` field in the >> JavaFrameAnchor field in the JavaThread >> >> Those are not the same things. > > I agree, I don't understand why this change was made. Wow, this is scary. I don't understand how I've merged JDK-8257882 like this. I've reviewed cpu/aarch64 changes again, there is nothing suspicious besides this. Thank you very much for catching, fixed. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v13]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/0d0e9baf..ad4e4c65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 18:35:51 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93: > >> 91: CPU_MARVELL = 'V', >> 92: CPU_INTEL = 'i', >> 93: CPU_APPLE = 'a', > > The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture > profile` has 8538 pages, can we be more specific and point to the particular > section of the document where the CPU codes are defined? They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not there, but "Arm can assign codes that are not published in this manual. All values not assigned by Arm are reserved and must not be used.". I assume the value was obtained by digging around https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Wed, 3 Feb 2021 23:29:30 GMT, Gerard Ziemski wrote: >> using ` ```c ` >> https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks >> >> I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, >> x86_64: >> https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524 >> and aarch64: >> https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323 >> (What happened with the formatting here, ugh?) >> >> Your suggestion sounds good otherwise. @AntonKozlov, do you mind to >> integrate that? > > So it should be: > > #if defined(__APPLE__) > // lldb (gdb) installs both standard BSD signal handlers, and mach exception > // handlers. By replacing the existing task exception handler, we disable > lldb's mach > // exception handling, while leaving the standard BSD signal handlers > functional. > // > // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking > // EXC_MASK_ARITHMETIC needed by all architectures for div by 0 checking > // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization > kern_return_t kr; > kr = task_set_exception_ports(mach_task_self(), > EXC_MASK_BAD_ACCESS | EXC_MASK_ARITHMETIC > AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION), > MACH_PORT_NULL, > EXCEPTION_STATE_IDENTITY, > MACHINE_THREAD_STATE); > > assert(kr == KERN_SUCCESS, "could not set mach task signal handler"); > #endif Thanks! I've updated the PR with this code, with extra indentation of `AARCH64_ONLY(...)` line, since this is continuation of the first parameter. I'll fix the formatting in os_bsd_arch64.cpp along other changes to `bsd_aarch64` directory - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Update signal handler part for debugger - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/8652d21d..0d0e9baf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=10-11 Stats: 16 lines in 1 file changed: 5 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v11]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Cleanup SA changes - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/80827176..8652d21d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=09-10 Stats: 11 lines in 1 file changed: 3 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
On Mon, 25 Jan 2021 22:48:50 GMT, Chris Plummer wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin > > src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 702: > >> 700: primitiveArray = (*env)->GetLongArrayElements(env, registerArray, >> NULL); >> 701: >> 702: #undef REG_INDEX > > I'm not so sure why the #undef and subsequent #define of REG_INDEX is needed > since it seems to just get #define'd back to the same value. We've merged two implementations of SA, this change slipped in. I've cleaned this up. Thanks for noticing! - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
On Fri, 5 Feb 2021 09:57:54 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with six additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >>+ minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > Marked as reviewed by ihse (Reviewer). > I haven't got a MacOS AArch64 system right now. Is it possible to > enable W^X in Linux in order to kick the tyres? I've just got rid of asserts that fired on Linux sometime :) As for W^X like on macOS, I vaguely remember working with a Linux system with one-way transition W->X, probably provided by SELinux. But I don't think it allowed per-thread W^X state. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt wrote: > Out of curiosity, have you looked at the performance of the W^X state > transition? Earlier it was possible to disable W^X protection (unfortunately, I don't know a way to do this now). We compared Renaissance results with W^X transitions like the proposed one vs. no transitions with the protection disabled once. Results were identical for a small and large number of iterations. >From the other hand, I've used >https://github.com/AntonKozlov/macos-aarch64-transition-bench to estimate the >cost of the transition. I re-did measurements with the current implementation and on consumer hardware: testJNIthrpt 25 277997000.151 ± 4095685.956 ops/s testJniNanoTimethrpt 2517851098.010 ±119489.599 ops/s testNanoTime thrpt 2578007491.762 ±628455.971 ops/s testNothingthrpt 25 1724298829.088 ± 100537565.068 ops/s testTwoStateAndWX thrpt 2521958839.057 ±210490.755 ops/s testWX thrpt 2523299813.266 ±149837.302 ops/s There is an overhead, but it does not look like blocking the first implementation. I'm not refusing future optimizations like enabling W only when necessary. But for now, I don't have a robust and maintainable solution for this, sorry. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 22:56:55 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/share/runtime/stubRoutines.inline.hpp line 1: > >> 1: /* > > NOW I understand the reason for switching from include to inline-include. > Is there a reason that this change is part of this project and not extracted > into a separate RFE. That would reduce the number of files touched by > this project. Makes sense, thanks. I'll do this as JDK-8261075. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Wed, 3 Feb 2021 09:14:24 GMT, Andrew Haley wrote:
>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271:
>>
>>> 5269: //
>>> 5270: void MacroAssembler::get_thread(Register dst) {
>>> 5271: RegSet saved_regs = RegSet::range(r0, r1) +
>>> BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
>>
>> The comment needs to be updated, since on BSD we also seem to clobber r2,r17
>> ?
>
> Surely this should be
>
> saved_regs = RegSet::range(r0, r1) BSD_ONLY(+ RegSet::range(r2, r17)) + lr -
> dst;```
>
> Shouldn't it?
Interesting, I wonder why it has built successfully on Linux. I'm going to fix
this under as JDK-8261072
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 18:00:06 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 390: > >> 388: store_and_inc(_to, from_obj, NativeStack::intSpace); >> 389: >> 390: _num_int_args++; > > `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the > `if else` but other methods use 2 of them inside `if else` branches. > > We should be consistent. Agree. I'm going to do as much refactoring as needed before this patch under JDK-8261071 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Tue, 26 Jan 2021 12:50:22 GMT, Anton Kozlov wrote:
>> Yes, that's why I thought it should be added to the classes
>> ThreadInVMfromNative, etc like:
>> class ThreadInVMfromNative : public ThreadStateTransition {
>> ResetNoHandleMark __rnhm;
>>
>> We can look at it with cleaning up the thread transitions RFE or as a
>> follow-on. If every line of ThreadInVMfromNative has to have one of these
>> Thread::WXWriteVerifier __wx_write; people are going to miss them when
>> adding the former.
>
> Not every ThreadInVMfromNative needs this, for example JIT goes to Native
> state without changing of W^X state. But from some experience of maintaining
> this patch, I actually had a duty to add missing W^X transitions after assert
> failures. A possible solution is actually to make W^X transition a part of
> ThreadInVMfromNative (and similar), but controlled by an optional constructor
> parameter with possible values "do exec->write", "verify write"...;. So in a
> common case ThreadInVMfromNative would implicitly do the transition and still
> would allow something uncommon like verification of the state for the JIT. I
> have to think about this.
I've dropped this transition here and in similar places after state tracking
always available. As a benefit, there are few places really using the setter
and all of them are tied to VM_ENTRY macro or similar one. I expect we don't
need to do W^X management near every java thread state change.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Tue, 26 Jan 2021 12:01:30 GMT, Coleen Phillimore wrote: >> I assume a WXVerifier class that tracks W^X mode in debug mode and does >> nothing in release mode. I've considered to do this, it's relates to small >> inefficiencies, while this patch brings zero overhead (in release) for a >> platform that does not need W^X. >> * We don't need thread instance in release to call >> `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will >> require calling `Thread::current()` first and we could only hope for >> compiler to optimize this out, not sure if it will happen at all. In some >> contexts the Thread instance is available, in some it's not. >> * An instance of the empty class (as WXVerifier will be in the release) will >> occupy non-zero space in the Thread instance. >> >> If such costs are negligible, I can do as suggested. > > I really just want the minimal number of lines of code and hooks in > thread.hpp. You can still access it through the thread, just like these > lines currently. Look at HandshakeState as an example. Please take a look at the recent changes. Changes in thread.hpp were reduced: https://github.com/openjdk/jdk/pull/2200/files#diff-abdc409967d04172ecc20e3747aa55a79e755584d570b57c4d58902a9813d188 thread.inline.hpp provides definitions of accessors (non-trivial): https://github.com/openjdk/jdk/pull/2200/files#diff-3a29f7f952bf2bd936f49e97cb3b86a7324851133e879c142dec724455310b50 And new threadWXSetters.hpp defines RAII context setter: https://github.com/openjdk/jdk/pull/2200/files#diff-6424782ec43941031282f079e89adaa76d341ce340a3b78b0e9657358ec16278 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Wed, 3 Feb 2021 19:57:24 GMT, Anton Kozlov wrote:
>> For platform files that were copied from other ports to this port, if the
>> file wasn't
>> changed I presume the copyright years are left alone. If the file required
>> changes
>> for this port, I expect the year to be updated to 2021. How are you
>> verifying that
>> these copyright years are being properly managed on the new files?
>>
>> For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment
>> explaining why one was landed in a particular place would help reviewers.
>> Also see my comment about creating a new ThreadToNativeWithWXExecFromVM
>> helper.
>>
>> I'm stopping my review with all the src/hotspot files done for now.
>
> Thank you all for your comments regarding W^X implementation. I've made a
> change that reduces the footprint of the implementation, also addressing most
> of the comments. I'll revisit them individually to make sure nothing is
> forgotten.
>
> The basic principle has not changed: when we execute JVM code (owned by
> libjvm.so, starting from JVM entry function), we switch to Write state. When
> we leave JVM to execute generated or JNI code, we switch to Executable state.
> I would like to highlight that JVM code does not mean the VM state of the
> java thread. After @stefank's suggestion, I could also drop a few W^X state
> switches, so now it should be more clear that switches are tied to JVM entry
> functions.
> I wonder if this is the right choice
> ...
> ```
> OopStorageParIterPerf::~OopStorageParIterPerf() {
> ...
> ```
>
The transition in OopStorageParIterPerf was made for gtest setup to execute in
WXWrite context. For tests themselves, defining macro set WXWrite.
I've simplified the scheme and now we switch to WXWrite once at the gtest
launcher. So this transition was dropped.
I've also refreshed my memory and tried to switch to WXWrite as close as
possible to each place where we'll be writing executable memory. There are a
lot of such places! As you correctly noted, code cache contains objects, not
plain data. For example, CodeCache memory management structures,
CompiledMethod, ... are there, so we need more WXWrite switches than we have
in the current approach. I had a comparable amount of them just to run
-version, but certainly not enough to run tier1 tests.
Following your advice, I don't require a known "from" state anymore. So a few
W^X transitions were dropped, e.g. when the JVM code calls a JNI entry
function, which expects to be called from the native code. I had to switch to
WXExec just only to satisfy the expectations. After the update, we don't need
this anymore.
W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM
functions are not marked as entries for some reason, although they are called
directly from e.g. interpreter. I added W^X management to such functions.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 23:10:17 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > For platform files that were copied from other ports to this port, if the > file wasn't > changed I presume the copyright years are left alone. If the file required > changes > for this port, I expect the year to be updated to 2021. How are you verifying > that > these copyright years are being properly managed on the new files? > > For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment > explaining why one was landed in a particular place would help reviewers. > Also see my comment about creating a new ThreadToNativeWithWXExecFromVM > helper. > > I'm stopping my review with all the src/hotspot files done for now. Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten. The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - Add comments to WX transitions + minor change of placements - Use macro conditionals instead of empty functions - Add W^X to tests - Do not require known W^X state - Revert w^x in gtests - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/3c705ae5..80827176 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=08-09 Stats: 444 lines in 64 files changed: 112 ins; 278 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: support macos_aarch64 in hsdis - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/b421e0b4..3c705ae5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=07-08 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header - Redo buildsys fix - Revert harfbuzz changes, disable warnings for it - Little adjustement of SlowSignatureHandler - Partially bring previous commit - Revert "Address feedback for signature generators" This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. - Refactor CDS disabling - Redo builsys support for aarch64-darwin - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4 - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=07 Stats: 3266 lines in 114 files changed: 3164 ins; 41 del; 61 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v7]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/f1ef6240..9d8b07c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=05-06 Stats: 5 lines in 4 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Redo buildsys fix - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/b2b396fc..f1ef6240 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=04-05 Stats: 18 lines in 2 files changed: 8 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Tue, 26 Jan 2021 16:35:54 GMT, Bernhard Urban-Forster wrote: >> @lewurm This and other harfbuzz changes came from MS, could you please >> comment here ? > > This looks like a merge fix mistake: > https://github.com/openjdk/jdk/commit/051357ef977ecab77fa9b2b1e61f94f288e716f9#diff-e3815f37244d076e27feef0c778fb78a4e5691b47db9c92abcb28bb2a9c2865e I've reverted this change and disabled some warnings for libharfbuzz instead. I should be blamed, yes. Now this is consistent with other changes covered by JDK-8260402 - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Revert harfbuzz changes, disable warnings for it - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/fef36580..b2b396fc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=03-04 Stats: 5 lines in 3 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v4]
On Mon, 25 Jan 2021 10:00:20 GMT, Andrew Haley wrote: >> I like the suggestion. For the defense, new functions were made this way >> intentionally, to match existing `pass_int`, `pass_long`,.. I take your >> comment as a blessing to fix all of them. But I feel that refactoring of >> existing code should go in a separate commit. Especially after `pass_int` >> used `ldr/str` instead of `ldrw/strw`, which looks wrong. >> https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122 > > This is new code, and it should not repeat the mistakes of the past. There's > no need to refactor the similar existing code as part of this patch. Makes sense, I've reverted changes in the old code but will propose them in the separate PR shortly. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v4]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision: - Little adjustement of SlowSignatureHandler - Partially bring previous commit - Revert "Address feedback for signature generators" This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/0c2cb0a3..fef36580 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=02-03 Stats: 98 lines in 1 file changed: 74 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Mon, 25 Jan 2021 19:12:17 GMT, Coleen Phillimore wrote:
>> I've tried to do something like this initially. The idea was to use Write in
>> VM state and Exec in Java and Native states. However, for example, JIT runs
>> in the Native state and needs Write access. So instead, W^X is managed on
>> entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not
>> every JVM entry function is defined with an appropriate macro (at least for
>> now), so I had to add explicit W^X state management along with the explicit
>> java thread state, like here.
>
> Yes, that's why I thought it should be added to the classes
> ThreadInVMfromNative, etc like:
> class ThreadInVMfromNative : public ThreadStateTransition {
> ResetNoHandleMark __rnhm;
>
> We can look at it with cleaning up the thread transitions RFE or as a
> follow-on. If every line of ThreadInVMfromNative has to have one of these
> Thread::WXWriteVerifier __wx_write; people are going to miss them when
> adding the former.
Not every ThreadInVMfromNative needs this, for example JIT goes to Native state
without changing of W^X state. But from some experience of maintaining this
patch, I actually had a duty to add missing W^X transitions after assert
failures. A possible solution is actually to make W^X transition a part of
ThreadInVMfromNative (and similar), but controlled by an optional constructor
parameter with possible values "do exec->write", "verify write"...;. So in a
common case ThreadInVMfromNative would implicitly do the transition and still
would allow something uncommon like verification of the state for the JIT. I
have to think about this.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Mon, 25 Jan 2021 14:40:42 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/thread.hpp line 915: >> >>> 913: verify_wx_state(WXExec); >>> 914: } >>> 915: }; >> >> Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and >> just add the class instance as a field in thread.hpp? > > This could be a follow-up RFE. I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance. If such costs are negligible, I can do as suggested. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Refactor CDS disabling - Redo builsys support for aarch64-darwin - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/50b55f66..0c2cb0a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=01-02 Stats: 36 lines in 3 files changed: 12 ins; 15 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Mon, 25 Jan 2021 09:52:00 GMT, Andrew Haley wrote: >> Hello >> Why is it not nice ? >> linux_aarch64 uses some linux specific tls function >> _ZN10JavaThread25aarch64_get_thread_helperEv from >> hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s >> which clobbers only r0 and r1 >> macos_aarch64 has no such tls code and uses generic C-call to >> Thread::current(); >> Hence we are saving possibly clobbered regs here. > > Surely if you did as Linux does you wouldn't need to clobber all those > registers. I see how this can be done, from looking at C example with `__thread`, which involves poorly documented relocations and private libc interface invocation. But now I also wonder how much benefit would we have from this optimization. `get_thread` is called from few places and all of them are guarded by `#ifdef ASSERT`. The release build is still fine after I removed MacroAssembler::get_thread definition (as a verification). Callers of get_thread: * StubAssembler::call_RT * Runtime1::generate_patching * StubGenerator::generate_call_stub * StubGenerator::generate_catch_exception All of them are heavy-weight functions, nonoptimal get_thread is unlikely to slow them down even in fastdebug. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Mon, 25 Jan 2021 14:36:35 GMT, Coleen Phillimore wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87: > >> 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env); >> 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));; >> 87: Thread::WXWriteFromExecSetter wx_write; > > Is this on every transition to VM from Native? Would it be better to add to > ThreadInVMfromNative like the ResetNoHandleMark is? I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Sat, 23 Jan 2021 11:42:48 GMT, Andrew Haley wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address feedback for signature generators
>> - Enable -Wformat-nonliteral back
>
> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394:
>
>> 392:
>> 393: class SlowSignatureHandler
>> 394: : public NativeSignatureIterator {
>
> SlowSignatureHandler is turning into a maintenance nightmare. This isn't the
> fault of this commit so much as some nasty cut-and-paste programming in the
> code you're editing. It might well be better to rewrite this whole thing to
> use a table-driven approach, with a table that contains the increment and the
> size of each native type: then we'd have only a single routine which could
> pass data of any type, and each OS needs only supply a table of constants.
Would you like me to do something about it now? The problem is that the
functions of SlowSignatureHandler are subtly different, so it will be multiple
tables, not sure how many. Such change is another candidate for a separate code
enhancement, which I would like not to mix into the JEP implementation (it's
already not a small change :)). But if you think it would be a good thing,
please let me know. In another case, I'll add this to a queue of follow-up
enhancements.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Sat, 23 Jan 2021 11:10:17 GMT, Andrew Haley wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address feedback for signature generators
>> - Enable -Wformat-nonliteral back
>
> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86:
>
>> 84:
>> 85: switch (_num_int_args) {
>> 86: case 0:
>
> I don't think you need such a large switch statement. I think this can be
> expressed as
> if (num_int_args <= 6) {
> ldr(as_Register(num_int_args + r1.encoding()), src);
> ... etc.
I like the suggestion. For the defense, new functions were made this way
intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment
as a blessing to fix all of them. But I feel that refactoring of existing code
should go in a separate commit. Especially after `pass_int` used `ldr/str`
instead of `ldrw/strw`, which looks wrong.
https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122
-
PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
On Fri, 22 Jan 2021 20:18:51 GMT, Erik Joelsson wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > make/autoconf/flags-cflags.m4 line 169: > >> 167: WARNINGS_ENABLE_ALL="-Wall -Wextra -Wformat=2 >> $WARNINGS_ENABLE_ADDITIONAL" >> 168: >> 169: DISABLED_WARNINGS="unknown-warning-option unused-parameter unused >> format-nonliteral" > > Globally disabling a warning needs some motivation. Why is this needed? Does > it really need to be applied everywhere or is there a specific binary or > source file where this is triggered? It seems to be a leftover from the past. I tried to revert the line and the build went fine. Thanks for noticing! - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Address feedback for signature generators - Enable -Wformat-nonliteral back - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/3d4f4c23..50b55f66 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2200=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2200=00-01 Stats: 204 lines in 2 files changed: 20 ins; 138 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
[OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port
Please review the implementation of JEP 391: macOS/AArch64 Port. It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. Major changes are in: * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) - Commit messages: - Fix build - JDK-8253816: Update after recent changes - Rework gtests to always have wx_write - Revert gtest changes - Fix gtests in debug - Merge remote-tracking branch 'upstream/master' into jdk-macos - Fix windows_aarch64 - Use r18_tls instead of r18_reserved - JDK-8253742: bsd_aarch64 part - JDK-8257882: bsd_aarch64 part - ... and 40 more: https://git.openjdk.java.net/jdk/compare/82adfb32...3d4f4c23 Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2200=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253795 Stats: 3335 lines in 117 files changed: 3230 ins; 41 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
