Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]

Anton Kozlov-2
> 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&pr=2200&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=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
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]

Stefan Karlsson-3
On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov <[hidden email]> 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)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>
>   Update signal handler part for debugger

Thanks for cleaning out WXWriteFromExecSetter.

src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 52:

> 50:
> 51: int BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr) {
> 52:   // Enable WXWrite: the function is called direclty from nmethod_entry_barrier

direclty -> directly

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

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.

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.

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

Changes requested by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]

Anton Kozlov-2
On Tue, 9 Feb 2021 09:12:13 GMT, Stefan Karlsson <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]

Anton Kozlov-2
In reply to this post by Stefan Karlsson-3
On Tue, 9 Feb 2021 09:23:50 GMT, Stefan Karlsson <[hidden email]> 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