Support for Apple M1 (darwin-aarch64)

[fniephaus]

Update from 2023/02/01:

Support for Apple Silicon has landed in the 22.1 release of GraalVM. We gradually ship more GraalVM components for darwin-aarch64 machines in new releases.

The latest state can be tested with the latest GraalVM dev build. Please help testing and report bugs!

Component	Status
Compiler	experimental
Native Image	experimental
LLVM runtime	experimental
LLVM toolchain	experimental
JavaScript	experimental
Node.js	experimental
Java on Truffle	experimental
Python	experimental
Ruby	experimental
R	planned
WebAssembly	planned
VisualVM	experimental

---

Update from 2022/03/22:

Apple M1 support for @GraalVM Native Image, libgraal, JavaScript, and Espresso has landed! 🎉🚀
M1 support for Ruby has also landed now.

You can now grab a GraalVM dev build for darwin-aarch64 at: https://github.com/graalvm/graalvm-ce-dev-builds/releases/latest

Please help testing and report bugs!

---

Original Issue

Describe the solution you'd like.
Apple is transitioning to their own chips. GraalVM is already available for Linux+aarch64, we'll need macOS+aarch64/arm64 at some point too.

Describe who do you think will benefit the most.
Any future macOS user.

Describe alternatives you've considered.
I can confirm that GraalVM CE 20.1.0 for macOS+amd64 runs with Rosetta 2 on a Developer Transition Kit (DTK).

Additional context.
Apple documentation on Apple Silicon. You can apply for a DTK here.

Express whether you'd like to help contributing this feature
I'm happy to help test GraalVM on a DTK. I've tried (but failed) to compile a LabsJDK for macOS+arm64 as a starting point.

[eregon]

The first step for this is to build a JVMCI JDK on darwin-arm64.

@dougxc told me the plan is to do this as soon as support is added for the darwin-arm64 platform in the JDK:
https://bugs.openjdk.java.net/browse/JDK-8253795 / openjdk/jdk#2200

[chrisseaton]

Note that macOS 11 isn't part of the issue any more Graal works fine on that.

[eregon]

Internal issue: GR-27422

[eregon]

FWIW openjdk/jdk#2200 got merged, but that's for JDK 17, planned to be released on 2021/09/14 (https://openjdk.java.net/projects/jdk/17/).
GraalVM releases are of course based on a JDK release.
It might be backported to older JDKs, but that doesn't seem clear yet.
cc @deepj

[mutasemhidmi]

is it possible to build an image from graalvm arm64 for MacBook m1 in order to build native images. Note that I tried to do this to build a native image for Quarkus framework but it didn't work. I used this graalvm https://github.com/graalvm/container/tree/master/community in order to build my image, but eventually after running sam cli to test the lambda function I got this error msg="Init failed" InvokeID= error="fork/exec /var/task/bootstrap: no such file or directory"

[fniephaus]

I don't think that's possible. You can run native images built for macOS/AMD64 on Apple Silicon via Rosetta 2.

[mutasemhidmi]

@fniephaus I tried but the build got stuck, and I got a warning that I am using amd64 and not arm64. All the information is here
quarkusio/quarkus#16225

[fniephaus]

Are you sure you used an amd64 GraalVM for macOS to generate the native image? Can you try building it on an Intel-based Mac? Then, copy over the native image and give it a go. If that doesn't work, you may be out of luck as an early adopter of an M1 Mac. I don't think native image support for Apple Silicon has a high priority for the GraalVM team at this point and will probably take weeks if not months to implement.

[mutasemhidmi]

@fniephaus I think my case is a little different because eventually, I want to build an image that works on Linux(arm64/aarch64) since I want to deploy it on AWS Lambda. Note that I have docker desktop already downloaded, so I want to use this image to build my quarkus application Lambda function. I hope I expressed myself clearly.

[fniephaus]

Ah ok, so essentially, you want to build native image for Linux/aarch64 on your M1-powered Mac. You should just be able to do this with a Linux/aarch64 Docker container on your M1. Then just copy over the native image.

[deepj]

Is there any concrete plan to support Apple ARM's chip in GraalVM in near future since the support landed in OpenJDK (https://bugs.openjdk.java.net/browse/JDK-8253795)?

[dougxc]

Is there any concrete plan to support Apple ARM's chip in GraalVM in near future since the support landed in OpenJDK (https://bugs.openjdk.java.net/browse/JDK-8253795)?

Please see this comment above: #2666 (comment)

[eregon]

To restate it a bit differently, I think we need to wait the OpenJDK 17 release (2021/09/14, #2666 (comment)) to build a JDK with darwin-aarch64 support. Unless darwin-aarch64 support gets backported earlier than that on JDK 8 or 11 (I have no idea).

[oraluben]

I tried to build GraalVM on M1, after hard-coded some architecture checks in mx, the first main issue is the absence of some dependency libraries on darwin arm64, and this can't be resolved easily by externals. Is there any plan that Graal team will add those dependencies (before the full support)?

e.g. the first error:

WARNING: No platform-specific definition is available for library ASYNC_PROFILER_1.8.3 for your architecture (arm64)
library ASYNC_PROFILER_1.8.3:
Library without "path" attribute must have a non-empty "urls" list attribute or "maven" attribute

[azolotko]

Hi! I noticed that native-image-llvm-backend is not yet available for darwin aarch64. Could you please put a reference to a corresponding issue to follow?

[lewurm]

Hi! I noticed that native-image-llvm-backend is not yet available for darwin aarch64. Could you please put a reference to a corresponding issue to follow?

#5491 /cc @loicottet

[jackrusher]

Using OpenJDK Runtime Environment GraalVM CE 22.3.0 (build 19.0.1+10-jvmci-22.3-b08), I'm currently seeing this linker failure when trying to use native-image to compile some classes that use Project Panama's new FFI functionality on an M1 machine:

Undefined symbols for architecture arm64:
  "_Java_java_lang_invoke_MethodHandle_linkToNative", referenced from:
      ___data in ffi.o
  "_Java_jdk_internal_misc_ScopedMemoryAccess_closeScope0", referenced from:
      ___svm_version_info in ffi.o
ld: symbol(s) not found for architecture arm64

Would this be an expected part of the currently experimental status for M1? Should I open a separate ticket? Am I holding it wrong? :)

[lewurm]

@jackrusher my understanding is that the Foreign Linker API is generally not supported by GraalVM yet. So yes, please open a separate ticket 🙂

[bakkot]

I see on the docs that WebAssembly support on macOS ARM64 is listed as "Experimental", the same as the native image, JS, etc. But this issue says that it's only "planned", and I don't see anywhere to get it. Are the docs wrong?

[fniephaus]

@bakkot yes, it seems the docs are wrong. Thanks for pointing that out!

[kevgilmore]

Any update on native-image-llvm-backend support for M1?

Currently I get this when trying to install

$ gu install native-image-llvm-backend
Downloading: Component catalog from www.graalvm.org
Error: Component "native-image-llvm-backend" is not available in catalog.

and this when searching in catalog

$ gu available
Downloading: Component catalog from www.graalvm.org
ComponentId              Version             Component name                Stability                     Origin 
---------------------------------------------------------------------------------------------------------------------------------
espresso                 22.3.1              Java on Truffle               Experimental                  github.com
js                       22.3.1              Graal.js                      Experimental                  github.com
llvm                     22.3.1              LLVM Runtime Core             Experimental                  github.com
llvm-toolchain           22.3.1              LLVM.org toolchain            Experimental                  github.com
native-image             22.3.1              Native Image                  Experimental                  github.com
nodejs                   22.3.1              Graal.nodejs                  Experimental                  github.com
python                   22.3.1              GraalVM Python                Experimental                  github.com
ruby                     22.3.1              TruffleRuby                   Experimental                  github.com
visualvm                 22.3.1              VisualVM                      Experimental                  github.com

[Gedochao]

Not sure if this is the right spot to ask, but - is there any reason why the darwin-aarch64 launcher is missing from the 22.3.2 release?
https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.2

It seems to be there in 22.3.1: https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.1

[pminearo]

I asked the same question on slack. According to Alina Yurenko on Slack:
Unfortunately here won’t a be a 22.3.2 for macOS aarch64, since this component was experimental in 22.3. The available options are using 22.3.1 CPU, dev builds, or waiting for 23.0.

[headius]

I am testing some performance optimizations in JRuby and found that the latest 23.x development build (on MacOS on M1) is extremely slow to invoke a method from Ruby via Java reflection. It runs 6-7x slower than Hotspot for the following benchmark:

Runtime = java.lang.Runtime
loop {
  t = Time.new
  i = 0
  while i < 100_000_000
    i += 1
    Runtime.runtime
  end
  puts Time.now - t
}

Running as follows, comparing Hotspot and GraalVM CE:

[] jruby $ jruby -v -Xcompile.invokedynamic -e 'Runtime = java.lang.Runtime; loop { t = Time.new; i = 0; while i < 100_000_000; i += 1; Runtime.runtime; end; puts Time.now - t }' 
jruby 9.4.3.0-SNAPSHOT (3.1.0) 2023-05-09 3fd0b8fedc OpenJDK 64-Bit Server VM 20+36 on 20+36 +indy +jit [arm64-darwin]
3.6947029999999996
3.702981
3.760052
^C%                                                                                                                                                                                                       [] jruby $ JAVA_HOME=~/graalvm-community-openjdk-20+34.1/Contents/Home jruby -v -Xcompile.invokedynamic -e 'Runtime = java.lang.Runtime; loop { t = Time.new; i = 0; while i < 100_000_000; i += 1; Runtime.runtime; end; puts Time.now - t }' 
jruby 9.4.3.0-SNAPSHOT (3.1.0) 2023-05-09 3fd0b8fedc OpenJDK 64-Bit Server VM 20+34-jvmci-23.0-b10 on 20+34-jvmci-23.0-b10 +indy +jit [arm64-darwin]
21.640044
21.707385000000002
^C%

You can see here 6x-7x slower performance on GraalVM CE. Is this expected given the current status of Apple M support?

[lewurm]

@headius thanks for your report, I don't think that's expected.

I can repro the slowdown on darwin-aarch64. I tried on linux-aarch64 too, there the slow down is "only" ~2x. On darwin-amd64 (via Rosetta 2) there is no measurable slowdown. No idea why there is a slowdown on AArch64, and even less of an idea why the slowdown is so much more on darwin-aarch64.

I've opened another issue to track it: #6600

[headius]

I've opened another issue to track it: #6600

Thank you!

[lewurm]

This is generally "fixed" 🙂 Please open new issues if you encounter any problems on this platform from now on. Thank you!