graal
graal copied to clipboard
oracle
Support for Apple M1 (`darwin-aarch64`)
Updated on 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.
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 / https://github.com/openjdk/jdk/pull/2200
Note that macOS 11 isn't part of the issue any more Graal works fine on that.
FWIW https://github.com/openjdk/jdk/pull/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
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"
I don't think that's possible. You can run native images built for macOS/AMD64 on Apple Silicon via Rosetta 2.
@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 https://github.com/quarkusio/quarkus/issues/16225
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.
@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.
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.
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)?
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: https://github.com/oracle/graal/issues/2666#issuecomment-817834239
To restate it a bit differently, I think we need to wait the OpenJDK 17 release (2021/09/14, https://github.com/oracle/graal/issues/2666#issuecomment-817834239) 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).
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
OpenJDK 17 has been released for a while, with full support for macos/arm64. Any updates on GraalVM?
Now JDK 17 is released and has darwin-aarch64 support. The next issue is that Apple only provides mac minis with 16GB ram, and that's basically not enough to do proper CI. And without proper CI it's not really feasible to do development and testing for this architecture.
Is this required in order to build a native image to deploy on AWS Lambda?
@mutasemhidmi This is about darwin-aarch64, i.e., aarch64 on macOS. linux-aarch64 is already supported: https://www.graalvm.org/downloads/
Yeah but I mean to build it on a mac M1 in order to deploy it on Lambda. The same way it's done now in Windows laptops.
As we get sufficient hardware in our CI system to test and develop on darwin-aarch64, this will become a priority. Any help from the GraalVM community before then would of course be very welcome.
Just wanted to suggest prioritizing it as Apple has started selling Macbook Pros with their silicon.
edit: I was not aware the 2020 13" M1 was also a Pro 😅 still, the new 14"/16" machines are stronger (up to 64gb RAM etc.)
Recently started building on Apple silicon and will get help if arm64 is supported. Please advise if any traction. All new Macs are now with Apple silicon.
Nothing that we can firmly commit to but I would expect something in the first quarter of 2022.
Is there anything users with apple silicon chips can do to help here? I.e. can we help out with the testing or whatever is required?
Is there anything users with apple silicon chips can do to help here? I.e. can we help out with the testing or whatever is required?
Yes!
The steps to try are:
- Clone https://github.com/graalvm/labs-openjdk-17 and build it using the steps in the
README.md. - Set
JAVA_HOMEto the result of that build and then runmx --env ce buildin thevm/directory of the graal repo.
@dougxc First issue from the labs-openjdk-17 README's build instructions:
configure: error: unrecognized options: --enable-aot
configure exiting with result code 1
I removed that arg and am proceeding with the rest of the directions.
I had to add --java-home arg to the mx command, but then it failed like this:
$ mx --env ce --java-home $JAVA_HOME build
WARNING: The component inclusion list ('--components' or '$COMPONENTS') includes an unknown component: 'svml'
WARNING: The component inclusion list ('--components' or '$COMPONENTS') includes an unknown component: 'svml'
Downloading LLVM_ORG_SRC from ['https://lafo.ssw.uni-linz.ac.at/pub/llvm-org/llvm-src-llvmorg-12.0.1-3-g6e0a5672bc-bgf11ed69a5a.tar.gz']
134340969 bytes (100%)
WARNING: No platform-specific definition is available for project com.oracle.truffle.llvm.tests.va.native for your architecture (aarch64)
WARNING: No platform-specific definition is available for library VISUALVM_PLATFORM_SPECIFIC for your architecture (aarch64)
library VISUALVM_PLATFORM_SPECIFIC:
Library without "path" attribute must have a non-empty "urls" list attribute or "maven" attribute
It's probably best to try smaller steps.
First try building the compiler and running its unit tests:
cd compiler/
mx build
mx unittest
Then try building libgraal and running its gate:
cd vm/
mx --env libgraal build
mx --env libgraal gate -t "LibGraal"