Bug ID: JDK-8261966 macOS M1: report in hs_err log if we are running x86 code in emulation mode (Rosetta)

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17
17 b15Fixed

During JDK-8261397 review David brought up a good point on how one can tell, from the hs_err log file, whether we are running x86 code on ARM hardware.

Currently one can infer it by looking at the "system" section and looking at the Darwin kernel version ex:

OS:uname: Darwin 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:06:51 PST 2021; root:xnu-7195.81.3~1/RELEASE_ARM64_T8101 x86_64

Here we see "RELEASE_ARM64_T8101" running "x86_64", so we can infer the code is running in emulation mode, however, we can explicitly check for that using the code provided by Apple:

https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment?language=objc#3616845

and report it in the log in a direct way.

Changeset: 4d8e9860 Author: Gerard Ziemski <gziemski@openjdk.org> Date: 2021-03-24 15:18:39 +0000 URL: https://git.openjdk.java.net/jdk/commit/4d8e9860
24-03-2021
We don't know how reliable the ".ARM64_T8101" text is. It's okay for checking crash reports today, but we want a reliable way to identify the use of emulation mode as I don't expect this to be the only bug we will encounter. The "EMULATED" wording is shared code so I'd hate to make that part macOS specific, and adding a per-platform string seems like overkill. If there is only one kind of emulation then we don't need to make any further distinction IMO.
20-02-2021
Yes it does, but it would be nice to be explicit about it, in case a user glances over that info or does not understand that it means "emulation" mode. I think adding "Rosetta emulation" somewhere might be particularly helpful for mac developers as that's how Apple refers to it in the press.
19-02-2021
Doesn't "OS:....ARM64_T8101 x86_64" give enough information that we are running inside Rosetta?
19-02-2021
We should also, at least on macOS, define VM_Version::is_cpu_emulated() so we can use it in run-time checks if needed.
19-02-2021
Typo fixed. Thanks [~dcubed]!
19-02-2021
I suggest that whereever we check/report the CPU architecture we add if it is emulated e.g.: Host: MacBookPro17,1 x86_64 2400 MHz, 8 cores, 16G, Darwin 20.3.0 becomes Host: MacBookPro17,1 x86_64 (EMULATED) 2400 MHz, 8 cores, 16G, Darwin 20.3.0 and: CPU: total 8 (initial active 8) (1 cores per cpu, 1 threads per core) family 6 model 44 stepping 0 microcode 0x0, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, aes, clmul, tsc, tscinvbit, tscinv, clflush becomes: CPU: (EMULATED) total 8 (initial active 8) (1 cores per cpu, 1 threads per core) family 6 model 44 stepping 0 microcode 0x0, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, aes, clmul, tsc, tscinvbit, tscinv, clflush
19-02-2021
> Host: MacBookPro17,1 x86_64 (EMULATED 2400 MHz, 8 cores, 16G, Darwin 20.3.0 Should there be a ')' after 'EMULATED'?
19-02-2021
This needs backporting to every release train that may run the x64 binary on ARM.
19-02-2021

Relates :	JDK-8261397 - try catch Method failing to work when dividing an integer by 0
Relates :	JDK-8264273 - macOS: zero VM is broken due to no member named 'is_cpu_emulated' after JDK-8261966