Apple Silicon support

[deepj]

I've just received Macbook Air with M1 as a replacement for my half-broken old Macbook Pro with Intel i5 what became very slow thanks to the bazillion security fixes for the Intel chip.

I tried to run TruffleRuby (2.1.0.0-dev) on the new Macbook and so far, so good. It's running under Rosetta 2 very well. I haven't noticed any issues yet.

So my question is, when we can expect TruffleRuby for Apple Sillicon builds? 🤓

[chrisseaton]

Blocked by oracle/graal#2666.

I'm afraid this issue needs some expert attention by the people who manage things like JVMCI and JVM builds - this is really specialised stuff needing the Oracle build farm I think and I'm not able to do it myself.

[eregon]

Regarding builds on darwin-aarch64:

• GraalVM release builds: we need Support for Apple M1 (darwin-aarch64) graal#2666
• nightly builds: the above + GitHub Actions would need to support darwin-aarch64.

Until that's done I guess using Rosetta 2 is the best solution for running TruffleRuby on Apple's M1.

[deepj]

@chrisseaton @eregon thanks both for the answers

In fact, it's already possible to build for Mac ARMs using Github Actions on the recent Mac x86_64 machines since Xcode 12.2. Already this project (https://github.com/keeweb/keeweb/releases) builds own ARM Mac builds using GA.

On GA there aren't available any Apple Silicon machines for testing builds on them though. You build own releases and test them on own bare metal machines anyway.

[eregon]

I think we'd want to have automated testing in CI before making darwin-aarch64 builds.
For instance I'm thinking for Ruby installers we should probably still pick the darwin-amd64 builds until the darwin-aarch64 builds are strictly better.

[deepj]

@eregon After almost a month spend with M1 I don't think that is a good way. It requires to use seperated Homebrew for x86_64. I already switch to Homebrew for ARM only since over 70 % of bottles are already ARM ready.

Homebrew doesn't support something like universal builds. That complicates many things while compiling 3rd dependencies. Keeping two separated Homebrew is not also easy. Just take a look at ruby-build issues with trying to build Ruby for ARM. Some people has a problem to understand they are mixing x86x_64 stuff with ARM's one.

[eregon]

Thanks for the update.
It seems the only way for now until oracle/graal#2666 is fixed and Sulong supports ARM64.

Why does it require a separate Homebrew? To install libssl?
If so, shipping TruffleRuby with libssl might be a solution.

I've seen many issues from M1 users e.g. on the FFI gem issues, it seems there is confusion, but probably some of that should be handled better by Homebrew or Apple.
My personal opinion is M1 users need to lean about some of these complications, because we cannot expect every OSS maintainer has time to port software for M1 and even has an M1 processor to test this new architecture+OS combo.
For TruffleRuby, I think we will support running on M1 natively at some point, but it will take some time.

[deepj]

@eregon Yes, the main problem is OpenSSL from Homebrew for ARM. What I remember some issues were with ARM version of PostgreSQL, pg gem and TruffleRuby (no issue under ARM version of MRI).

I understand your points. But I guess this is not only about Apple M1, I feel it's more about benefiting other ARM based CPUs generally. The changes for Apple M1 bring better SW compability e.g. for Rasberry computer. TruffleRuby/GraalVM cannot be run e.g. on Rasberry Pi yet.

[deepj]

@eregon Hello, is there any internal news if some basic support of Apple ARM's will be landed soon into GraalVM/Sulong?

[eregon]

@deepj See oracle/graal#2666 (comment), nothing can happen until upstream JDK supports darwin-arm64.

[eregon]

FWIW, linux-aarch64 is another story, for that case there are already JDK11 builds for it, and TruffleRuby can already be built there (but Sulong does not work yet on linux-aarch64).

[deepj]

@eregon it seems Apple ARM support in OpenJDK (openjdk/jdk#2200) will be landed soon. I guess there will be some work on Graal side. Is any chance to offer some experimental builds of TruffleRuby with Apple ARM support? I want to really avoid any compilation of Graal/TruffleRuby on my system.

Of course, you have other priorities. I'm just asking :)

[chrisseaton]

I hope to get an M1 laptop when Apple take away my DTK, so may go back to working on this.

[eregon]

Once there are labsjdk JVMCI builds (oracle/graal#2666), we can look at this and share an experimental build.
We'll also need Sulong to support darwin-arm64 for C extensions, for which the related linux-arm64 support is I think in progress.

[deepj]

Support of Apple ARM's has been merged into OpenJDK (just sayin')

[deepj]

@eregon Hm, is there any internal progress in Graal to support Apple ARM since OpenJDK has it already?

[chrisseaton]

We're still blocked by oracle/graal#2666. Might be best to ask there until that issue is fixed.

[deepj]

[chrisseaton]

As it says above, we're still blocked by oracle/graal#2666.

That's the blocker. That's where you need to ask for progress.

We really appreciate your enthusiasm, but we can't do anything ourselves.

[chrisseaton]

To build and run using Rosetta on an M1 machine:

• Create a copy of Terminal, open properties, and set it to open using Rosetta
• Using this Terminal:
• Install Homebrew (again, if you've already installed it, it'll go into /usr/local/homebrew this time)
• Don't forget to now use eval "$(/usr/local/homebrew/bin/brew shellenv)" instead of what you had before
• Install cmake and openssl@1.1 (not just openssl)
• Build and run as normal

[nirvdrum]

Thanks, @chrisseaton. Those steps were very helpful. To simplify the correct Homebrew installation loading, you can use uname -m to get the current architecture. It'll be arm64 in native M1 mode and x86_64 when run in Rosetta. I've changed my shell startup to look like this:

if [ (uname -m) = "arm64" ]
  eval (/opt/homebrew/bin/brew shellenv)
else
  eval (/usr/local/homebrew/bin/brew shellenv)
end

That implies that you installed Homebrew for M1 first. If you did it the other way around, just swap the branches (or the condition). That's for the fish shell. The same basic idea should work for your shell of choice.

[chrisseaton]

if [[ $CPUTYPE == arm64 ]]
then
    eval "$(/opt/homebrew/bin/brew shellenv)"
else
    eval "$(/usr/local/homebrew/bin/brew shellenv)"
fi

[nirvdrum]

Not having to invoke another process would be preferable, but that $CPUTYPE variable looks to be a zsh thing (and it doesn't show up in env output -- odd). I don't see it set in either bash or fish.

[gimbling-away]

Not having to invoke another process would be preferable, but that $CPUTYPE variable looks to be a zsh thing (and it doesn't show up in env output -- odd). I don't see it set in either bash or fish.

@nirvdrum This shouldn't be that big of a problem since ZSH is the default shell for MacOS -- although to make it more portable, spawning a uname instance would be better. It's pretty cheap and won't affect much.

[nirvdrum]

@Yush08 Thanks. I don't use ZSH though, thus my note.

[deepj]

There are dev builds of GraalVM supporting Apple Silicon.

https://github.com/graalvm/graalvm-ce-dev-builds/releases/tag/22.1.0-dev-20220321_2332

Can we see testing builds of TruffleRuby supporting Apple Silicon in near future? :)

[eregon]

Yes, it's being worked on by @lewurm.
What we need is Sulong and TruffleRuby support for darwin-aarch64.
A large part of the work seems va_args support for Sulong.
It doesn't make much sense to add support in TruffleRuby before that (none of the C exts would work).
For TruffleRuby it's probably quite straightforward anyway, and we'll want to add CI jobs to ensure everything works well.

[chrisseaton]

https://twitter.com/ChrisGSeaton/status/1524514743209410563

[deepj]

Great work @chrisseaton and the others! I hope we can try nightly builds very soon. I can't wait to test TruffleRuby after so long time :)

[deepj]

Thank you! @eregon Is there any public nightly build is available?

[eregon]

We should be able to have GraalVM dev builds at https://github.com/graalvm/graalvm-ce-dev-builds, but those lag a few days up to 1-2 weeks behind due to using the truffleruby import in GraalVM. ruby-build truffleruby+graalvm-dev ~/.rubies/truffleruby+graalvm-dev will work then.

For the standalone dev builds (https://github.com/ruby/truffleruby-dev-builder), I don't see any way currently as GitHub-hosted runners are not available darwin-aarch64 (neither linux-aarch64), all of https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources is amd64 only.
Self-hosted runners would probably be a security/trust issue, unless owned and maintained by the ruby organization maybe.
We could potentially have internal truffleruby nightly standalone builds published like https://github.com/graalvm/graalvm-ce-dev-builds does but that is a significant effort.

[deepj]

I successfully installed a native build from https://github.com/graalvm/graalvm-ce-dev-builds on my M1 mac :)

truffleruby 22.2.0-dev-0f63df6f, like ruby 3.0.3, GraalVM CE Native [aarch64-darwin]

[eregon]

Darwin-aarch64 dev builds are now available via

ruby-build truffleruby-dev ~/.rubies/truffleruby-dev
# or
ruby-build truffleruby+graalvm-dev ~/.rubies/truffleruby+graalvm-dev

with rbenv/ruby-build#1980.
With the caveat it might be a build with a truffleruby commit ~1 week old.

Should probably add those builds to RVM too at some point.