RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port

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

RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port

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)

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

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&pr=2200&range=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
Reply | Threaded
Open this post in threaded view
|

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

Coleen Phillimore-3
On Sun, 24 Jan 2021 15:32:59 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 two additional commits since the last revision:
>
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

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?

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

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 [v2]

Coleen Phillimore-3
On Mon, 25 Jan 2021 14:40:09 GMT, Coleen Phillimore <[hidden email]> 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/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.

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

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 [v2]

Bernhard Urban-Forster-2
In reply to this post by Anton Kozlov-2
On Mon, 25 Jan 2021 13:30:55 GMT, Vladimir Kempik <[hidden email]> wrote:

>> make/modules/jdk.hotspot.agent/Lib.gmk line 34:
>>
>>> 32:
>>> 33: else ifeq ($(call isTargetOs, macosx), true)
>>> 34:   SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
>>
>> Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons).
>
> @luhenry , could you please check this comment, I think SA-agent was MS's job here.

The target is identified by the header file now:
https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41

Do you think there is any problem with this approach?

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

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 [v2]

Phil Race
In reply to this post by Anton Kozlov-2
On Sun, 24 Jan 2021 15:32:59 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 two additional commits since the last revision:
>
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

Changes requested by prr (Reviewer).

src/java.desktop/share/native/libharfbuzz/hb-common.h line 113:

> 111:
> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF)))
> 113: #define HB_UNTAG(tag)   (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF)

I need a robust explanation of these changes.
They are not mentioned, nor are they in upstream harfbuzz.
Likely these should be pushed to upstream first if there is a reason for them.

src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 193:

> 191:    * crbug.com/549610 */
> 192:   // 0x00070000 stands for "kCTVersionNumber10_10", see CoreText.h
> 193: #if TARGET_OS_OSX && MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_10

I need a robust explanation of these changes.
They are not mentioned, nor are they in upstream harfbuzz.
Likely these should be pushed to upstream first if there is a reason for them.

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

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 [v3]

Vladimir Kempik-3
In reply to this post by Anton Kozlov-2
On Mon, 25 Jan 2021 19:42:41 GMT, Phil Race <[hidden email]> 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
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
>
>> 571:     EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>> 572:     WARNINGS_AS_ERRORS_xlc := false, \
>> 573:     DISABLED_WARNINGS_clang := deprecated-declarations, \
>
> I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things.
> I've built JDK using Xcode 12.3 and not had any need for this.

Hello
I believe it was a workaround for issues with xcode 12.2 in early beta days.
Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds.

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

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 [v3]

Vladimir Kempik-3
On Mon, 25 Jan 2021 20:54:38 GMT, Vladimir Kempik <[hidden email]> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
>>
>>> 571:     EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>>> 572:     WARNINGS_AS_ERRORS_xlc := false, \
>>> 573:     DISABLED_WARNINGS_clang := deprecated-declarations, \
>>
>> I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things.
>> I've built JDK using Xcode 12.3 and not had any need for this.
>
> Hello
> I believe it was a workaround for issues with xcode 12.2 in early beta days.
> Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds.

It seems these workarounds are still needed:

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations]
                        bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat
                                      ^~~~~~~~~~~~~~~~~~~~~~~~
                                      NSBitmapFormatAlphaFirst

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations]
                      styleMask: NSBorderlessWindowMask
                                 ^~~~~~~~~~~~~~~~~~~~~~
                                 NSWindowStyleMaskBorderless

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

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 [v3]

Vladimir Kempik-3
On Mon, 25 Jan 2021 22:22:06 GMT, Phil Race <[hidden email]> wrote:

>> It seems these workarounds are still needed:
>>
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations]
>>                         bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat
>>                                       ^~~~~~~~~~~~~~~~~~~~~~~~
>>                                       NSBitmapFormatAlphaFirst
>>
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations]
>>                       styleMask: NSBorderlessWindowMask
>>                                  ^~~~~~~~~~~~~~~~~~~~~~
>>                                  NSWindowStyleMaskBorderless
>
> Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem.
> I think we currently target a macOS 10.9 and if you are changing that it would need discussion.
> If you are changing it only for Mac ARM that may make more sense ..
>
> And these appear to be just API churn by Apple
> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst
>
> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc
>
> NSBorderlessWindowMask is replaced by NSWindowStyleMask
>
> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ

Min_macos version is changed to 11.0 for macos_aarch64

https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136

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

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 [v3]

Phil Race
On Mon, 25 Jan 2021 22:25:48 GMT, Vladimir Kempik <[hidden email]> wrote:

>> Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem.
>> I think we currently target a macOS 10.9 and if you are changing that it would need discussion.
>> If you are changing it only for Mac ARM that may make more sense ..
>>
>> And these appear to be just API churn by Apple
>> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst
>>
>> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc
>>
>> NSBorderlessWindowMask is replaced by NSWindowStyleMask
>>
>> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ
>
> Min_macos version is changed to 11.0 for macos_aarch64
>
> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136

1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
2) So maybe rather than the deprecation suppression  you could change both constants to the new ones.
Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ...

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

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 [v3]

Vladimir Kempik-3
On Mon, 25 Jan 2021 22:42:40 GMT, Phil Race <[hidden email]> wrote:

>> Min_macos version is changed to 11.0 for macos_aarch64
>>
>> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136
>
> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
> 2) So maybe rather than the deprecation suppression  you could change both constants to the new ones.
> Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ...

that sounds good to me, I am just afraid to break intel mac on older macos versions with this change.

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

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 [v3]

Chris Plummer-2
In reply to this post by Anton Kozlov-2
On Mon, 25 Jan 2021 19:38:16 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 two additional commits since the last revision:
>
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

JDI changes also look good.

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

Marked as reviewed by cjplummer (Reviewer).

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

Re: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

Andrew Haley
In reply to this post by Anton Kozlov-2
On 1/25/21 5:45 PM, Anton Kozlov wrote:
> 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.

OK, so perhaps it's not worth doing. Withdrawn.

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

Reply | Threaded
Open this post in threaded view
|

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

Alan Hayward-2
In reply to this post by Anton Kozlov-2
On Tue, 26 Jan 2021 09:23:23 GMT, Magnus Ihse Bursie <[hidden email]> 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
>
> Changes requested by ihse (Reviewer).

AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
ie:
`
--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'
`

Otherwise there will be missing _JNFNative* functions.

Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?

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

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 [v8]

Vladimir Kempik-3
In reply to this post by Anton Kozlov-2
On Mon, 25 Jan 2021 09:48:46 GMT, Andrew Haley <[hidden email]> wrote:

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

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

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 [v6]

Alan Hayward-2
In reply to this post by Anton Kozlov-2
On Wed, 27 Jan 2021 14:58:27 GMT, Vladimir Kempik <[hidden email]> wrote:

>> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR.
>
>> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR.
>
> I believe it's better be done under separate PR/bugfix, so it can be completely reverted once JNF removed.

You need add macos arm64 to hsdis. Having it working is fairly essential for debugging.

Inside src/utils/hsdis, After cloning binutils
make; make demo; ./build/macosx-arm64/hsdis-demo
Results in:
Hello, world!
...And now for something completely different:

Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual
hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform
hsdis output options:

I fixed it by changing the makefile to force the build flags:
ARCH=aarch64
CFLAGS/aarch64    += -m64
Resulting in:
Hello, world!
...And now for something completely different:

Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual
Decoding for CPU 'aarch64'
main:
 0x10012719c sub sp, sp, #0x60
 0x1001271a0 stp x29, x30, [sp, #80]
...etc

Putting the library in the right place then made disassembly in java work for me.

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

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 [v6]

Vladimir Kempik-3
On Mon, 1 Feb 2021 09:31:31 GMT, Alan Hayward <[hidden email]> wrote:

> You need add macos arm64 to hsdis. Having it working is fairly essential for debugging.
>
> Inside src/utils/hsdis, After cloning binutils
>
> ```
> make; make demo; ./build/macosx-arm64/hsdis-demo
> ```
>
> Results in:
>
> ```
> Hello, world!
> ...And now for something completely different:
>
> Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual
> hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform
> hsdis output options:
> ```
>
> I fixed it by changing the makefile to force the build flags:
>
> ```
> ARCH=aarch64
> CFLAGS/aarch64    += -m64
> ```
>
> Resulting in:
>
> ```
> Hello, world!
> ...And now for something completely different:
>
> Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual
> Decoding for CPU 'aarch64'
> main:
>  0x10012719c sub sp, sp, #0x60
>  0x1001271a0 stp x29, x30, [sp, #80]
> ...etc
> ```
>
> Putting the library in the right place then made disassembly in java work for me.

Hello, hsdis is a separate out-of-tree project and is not part of this jep.
support for looking for proper hsdis dylib library was added as part of this jep.

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

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 [v9]

Gerard Ziemski-2
In reply to this post by Anton Kozlov-2
On Tue, 2 Feb 2021 18:52:29 GMT, Gerard Ziemski <[hidden email]> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   support macos_aarch64 in hsdis
>
> Changes requested by gziemski (Committer).

There were bunch of assembly code that I couldn't review. I also shallow reviewed the brand new files that were copies of the existing BSD x86_64 files - I hope I can get back to those when I figure out how to build/run these changes.

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

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 [v9]

Bernhard Urban-Forster-2
In reply to this post by Anton Kozlov-2
On Tue, 2 Feb 2021 18:23:04 GMT, Gerard Ziemski <[hidden email]> 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/posix/signals_posix.cpp line 1297:
>
>> 1295:   kern_return_t kr;
>> 1296:   kr = task_set_exception_ports(mach_task_self(),
>> 1297:                                 EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC,
>
> Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here?

See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`.

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

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 [v2]

Anton Kozlov-2
In reply to this post by Anton Kozlov-2
On Tue, 26 Jan 2021 12:50:22 GMT, Anton Kozlov <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Anton Kozlov-2
In reply to this post by Anton Kozlov-2
On Tue, 2 Feb 2021 23:03:45 GMT, Daniel D. Daugherty <[hidden email]> 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/thread.cpp line 3991:
>
>> 3989:       JavaThread* thread = JavaThread::current();
>> 3990:       ThreadToNativeFromVM ttn(thread);
>> 3991:       Thread::WXExecFromWriteSetter wx_exec;
>
> I saw somewhere in this review a comment about why this new
> WXExecFromWriteSetter helper isn't folded into ThreadToNativeFromVM
> and I understand that not every current ThreadToNativeFromVM needs
> the new helper. If the vast majority of the ThreadToNativeFromVM
> locations need WXExecFromWriteSetter, then perhaps those locations
> that currently have a ThreadToNativeFromVM followed by the new
> WXExecFromWriteSetter should use a new helper:
>
>     ThreadToNativeWithWXExecFromVM
>
> so we'll see changes from:
>
>     ThreadToNativeFromVM -> ThreadToNativeWithWXExecFromVM
>
> where we need them and hopefully a short comment can be added
> at the same time to explain the need for WXExec. This will allow us
> to easily distinguish ThreadToNativeFromVM locations that DO NOT
> need WXExec from those that DO need it.

With a small overhead for tracking the current W^X state, I avoided WXExecFromWriteSetter near ThreadToNativeFromVM at all. New ThreadWXEnable(WXExec) is used only to call a generated function. More common ThreadWXEnable(WXWrite) is tied to JVM entry functions. I added comments for functions that are not clear to be entries, although they are. Thank you for the suggestion!

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

PR: https://git.openjdk.java.net/jdk/pull/2200
12