8264273: macOS: zero VM is broken due to no member named 'is_cpu_emulated' after JDK-8261966

[DamonFool]

Hi all,

Zero VM on macOS is broken after JDK-8261966.
Let's fix it.

Thanks.
Best regards,
Jie

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8264273: macOS: zero VM is broken due to no member named 'is_cpu_emulated' after JDK-8261966

Reviewers

• Ioi Lam (@iklam - Reviewer)

Download

To checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3216/head:pull/3216
$ git checkout pull/3216

To update a local copy of the PR:
$ git checkout pull/3216
$ git pull https://git.openjdk.java.net/jdk pull/3216/head

[DamonFool]

/issue add JDK-8261966
/test
/label add hotspot-runtime
/cc hotspot-runtime

[bridgekeeper]

👋 Welcome back jiefu! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@DamonFool
Adding additional issue to issue list: 8261966: macOS M1: report in hs_err log if we are running x86 code in emulation mode (Rosetta).

[openjdk]

@DamonFool
The hotspot-runtime label was successfully added.

[openjdk]

@DamonFool The hotspot-runtime label was already applied.

[DamonFool]

/issue remove JDK-8261966

[openjdk]

@DamonFool
Removing additional issue from issue list: 8261966.

[mlbridge]

Webrevs

• 00: Full (6cba1e4)

[iklam]

LGTM.

[openjdk]

@DamonFool This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8264273: macOS: zero VM is broken due to no member named 'is_cpu_emulated' after JDK-8261966

Reviewed-by: iklam

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 9 new commits pushed to the master branch:

• 7284f01: 8262110: DST starts from incorrect time in 2038
• 3a28dc8: 8264178: Unused method Threads::nmethods_do
• 33c94ff: 8263376: CTW (Shenandoah): assert(mems <= 1) failed: No node right after call if multiple mem projections
• 4e74de4: 8264111: (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write
• 57115fa: 8189198: Add "forRemoval = true" to Applet API deprecations
• b8122d6: 8264220: jdk/javadoc/doclet/testRelatedPackages/TestRelatedPackages.java fails to compile
• 507b690: 8264126: Remove TRAPS/THREAD parameter for class loading functions
• f3eed05: 8263928: Add JAWT test files for mac
• 4fbb7c2: 8263472: Specification of JComponent::updateUI should document that the default implementation does nothing

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[VladimirKempik]

looks good and won't conflict with similar fix in just integrated jep-391

[DamonFool]

Thanks @iklam and @VladimirKempik for your review.
/integrate

[openjdk]

@DamonFool Since your change was applied there have been 13 commits pushed to the master branch:

• c9d2d02: 8263632: Improve exception handling of APIs in classLoader.cpp
• 59ed1fa: 8264087: Use the blessed modifier order in jdk.jconsole
• 054e0a4: 8264017: Correctly report inlined frame in JFR sampling
• d6bb153: 8264240: [macos_aarch64] enable appcds support after JDK-8263002
• 7284f01: 8262110: DST starts from incorrect time in 2038
• 3a28dc8: 8264178: Unused method Threads::nmethods_do
• 33c94ff: 8263376: CTW (Shenandoah): assert(mems <= 1) failed: No node right after call if multiple mem projections
• 4e74de4: 8264111: (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write
• 57115fa: 8189198: Add "forRemoval = true" to Applet API deprecations
• b8122d6: 8264220: jdk/javadoc/doclet/testRelatedPackages/TestRelatedPackages.java fails to compile
• ... and 3 more: https://git.openjdk.java.net/jdk/compare/e47dfb8e28ed2973da1346c3898f9386a7fa1fd3...master

Your commit was automatically rebased without conflicts.

Pushed as commit 38e0a58.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

[dholmes-ora]

Why is the member missing under a Zero build? Whether or not the CPU is emulated is a feature of the OS and the binary - the compiler/interpreter mode is not relevant. This looks like the wrong fix to me.

[DamonFool]

Why is the member missing under a Zero build? Whether or not the CPU is emulated is a feature of the OS and the binary - the compiler/interpreter mode is not relevant. This looks like the wrong fix to me.

VM_Version::is_cpu_emulated() seems to be also CPU-dependent since its implementations of x86 and aarch64 are different.

Did you mean we should copy the aarch64's implementation for bsd_zero build?
Thanks.

[mlbridge]

Mailing list message from David Holmes on hotspot-runtime-dev:

On 29/03/2021 4:36 pm, Jie Fu wrote:

On Mon, 29 Mar 2021 05:17:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

Why is the member missing under a Zero build? Whether or not the CPU is emulated is a feature of the OS and the binary - the compiler/interpreter mode is not relevant. This looks like the wrong fix to me.

VM_Version::is_cpu_emulated() seems to be also CPU-dependent since its implementations of x86 and aarch64 are different.

Whether a given CPU is emulated is a feature of the actual OS and CPU,
depending on the binary you execute. For example, if you try to execute
an x64 binary on a macOS Aarch64 system, then that system will emulate
the x64 CPU to run that binary.

Did you mean we should copy the aarch64's implementation for bsd_zero build?

Hmmm. So zero pretends to be a CPU because it is CPU-agnostic when it
comes to interpreted code. But a zero x64 binary should still be able to
run on macos Aarch64 in emulation mode. But to do that VM_Version code
has to be the x64 implementation of VM_Version. I don't see any easy fix
for this.

So the build problem is resolved, but you can't run a zero x64 binary in
emulated mode.

Thanks,
David