ARM docker image

Please release a native ARM docker image of fauna so developers with ARM-based computers can dev against fauna locally, without needing a network connection to the service (and using up quota).

Currently, local development against fauna is unusable on ARM-based dev machines. I have a Mac with Apple Silicon and the only way to run fauna currently is using the x64 docker image and running with the “–platform linux/amd64” flag.

When I tried using the amd64 emulation flag, I had to restart the container many times before it finally launched successfully, and eventually it has more errors and needed to be restarted (see screenshot). I think maybe rosetta has some bugs around emulating amd64 docker images or an issue with emulating JVM, not sure. Either way it’s not actually that usable.

If ARM dev machines keep growing in popularity (which is where Apple is heading and hopefully PC makers as well), then please consider making a native ARM docker image for fauna. Not only would it be more reliable to dev against but also better perf and battery life to dev against

Thank you for the feature request! This is not an item on our roadmap yet, but we might reconsider if we get enough community requests.

1 Like

Hello, I also use MacBook with M1 ARM chip and I’m unable to run Fauna in docker on my machine.

A lot of tools/languages got updated versions that are compatible with M1 on Rosetta 2 emulation. Newer version of JVM should be compatible.

Would it be possible to at least release updated Fauna image for amd64 architecture that will properly run on M1 macs using Rosetta 2?

More MacBooks Pro with ARM chips are expected this year, so there will be more users dealing with this issue.

1 Like

Adding my +1 here for this feature.
Would also like to continue development/testing without using up the quota.

Thanks.

I think the core issue here is the JDK installed isn’t compatible with the ARM architecture. So how does the image install the JDK? Looking at the image layers in the latest (at time of writing) FaunaDB Docker image the 9th layer seems to install the JDK. There is a piece of code that is interesting:

arch = "$(dpkg --print-architecture)";

case "$arch" in 'amd64')
  downloadUrl = 'https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/download/jdk-11.0.12%2B7/OpenJDK11U-jdk_x64_linux_11.0.12_7.tar.gz';
  ;;
'arm64')
  downloadUrl = 'https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/download/jdk-11.0.12%2B7/OpenJDK11U-jdk_aarch64_linux_11.0.12_7.tar.gz';
  ;;
*)
  echo > &2 "error: unsupported architecture: '$arch'";
  exit 1
  ;;
esac;

It looks like there is already support for ARM 64-bit architectures (and has been since 2.6.2). If dpkg --print-architecture returns 'arm64' then the JDK that supports ARM is downloaded and installed. So why doesn’t that happen?

I shelled into a Docker container running Fauna and ran dpkg --print-architecture on a MacBook Pro with an M1 chip. It returned amd64. This isn’t necessarily surprising given we already know an AMD compatible JDK was installed. Also we know Docker can emulate AMD machines.

I then tried to force the platform to arm64 by running docker run with the platform flag set to linux/arm64. This yielded a warning and error:

WARNING: image with reference fauna/faunadb was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64
docker: Error response from daemon: image with reference fauna/faunadb was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64.

It seems the image specifies the platform to be linux/amd64. Again, not a surprise, as far as I know that’s the default. So we need a linux/arm64 build.

As far as I can tell, there is nothing preventing this image to be ARM compatible given there is already architecture detection built-in. I think this means all Fauna needs to do is build images for ARM and this, as far as I know, could be a simple as using BuildKit with Docker and specifying the platforms. If Fauna builds images by running docker build then they’ll need to change that to docker buildx build --platform linux/amd64,linux/arm64.

I’ll caveat all the above that it’s just based on what I can observe through any references I’ve linked. It may be more complicated than I realise but if the Fauna team hasn’t done any investigation on this, hopefully it’ll kickstart things and hopefully it’ll be as simple as the above and they can implement soon.

Second caveat, I’m not sure the ARM64 JDK from AdoptOpenJDK is Mac compatible. When I set up my M1 Mac I did come across an issue where there weren’t JDKs from AdoptOpenJDK that supported M1 Macs and I had to use a build from Azul. As far as I’m aware this hasn’t changed but it may have and I’m wrong.

With M1 Macs being demonstrably more performant, more and more developers will move to them and the tools that don’t move to support this are massive blockers. I wish I could give a bigger +1 to this request.

1 Like

The latest Fauna Dev Docker image (4.4.0) now has ARM64 support. We’d appreciate it if you could try it out and let us know how it works on M1 Macs.

2 Likes

Thanks @ewan! Things look to be heading in the right direction

  • :white_check_mark: docker manifest inspect fauna/faunadb reports image for arm64 architecture is available
  • :white_check_mark: docker run --platform linux/arm64 --rm --name faunadb -p 8443:8443 -p 8084:8084 -p 8444:8444 fauna/faunadb reports no warnings or errors from Docker
  • :white_check_mark: dpkg --print-architecture reports arm64 so an arm64 compatible JDK is installed

Unfortunately, as suspected by the second caveat in my last message and now confirmed, the arm64 compatible JDK11 from AdoptOpenJDK isn’t compatible with M1 Macs. I still get the same/similar errors from the JDK as before.

As far as I know, AdoptOpenJDK doesn’t have any JDKs that are compatible with Mac, Oracle only has support for M1 Macs from JDK17 but Azul has a build of JDK11 available for M1 Macs, available here: Java Download | Java 8, Java 11, Java 13 - Linux, Windows & macOS. The install script will have to be changed for the Azul build (for example the paths for the binaries are probably in a different place and we don’t need to manually verify the signature as they’ve been signed with Apple developer certificates (please check yourself too)).

1 Like

Hi @wing. Can you be more specific about the errors you are still receiving and what you are doing leading up to them? That way we can replicate and confirm things are better if we make changes. We are aware of others performing at least simple operations while on M1 Macbooks.

UPDATE:

We are getting more feedback from folks that the M1 build is working as expected on M1 Macs, including typical work flows like bootstrapping databases with fauna-schema-migrate, importing data, running tests etc.

My understanding is that AdoptOpenJDK does support M1 Macs, but it’s just not available through Homebrew. Provide native builds for M1 Apple Silicon (ARM) Macs in Homebrew · Issue #530 · AdoptOpenJDK/homebrew-openjdk · GitHub

I’ve confirmed that the compatible JDK version was used in the latest build of the faunadb image.

Hey @ptpaterson. I should’ve said warnings, not errors. Here are some of the things I’m seeing:

***********************************************************************************
** jamm will use sun.misc.Unsafe to compute the size of objects on heap.
** This is not safe and results in wrong assumptions of the free/occupied Java
** heap and potentially in OOMs. The implementation performs arithmetics on the
**  "cookies" returned by Unsafe.objectFieldOffset(), althought the Javadoc says:
** "Do not expect to perform any sort of arithmetic on this offset; 
** it is just a cookie which is passed to the unsafe heap memory accessors."
** The implementation does not always consider Java object layouts in under
** all circumstances for all JVMs.
**
** Solutions:
** - Use a JDK/JVM with JEP-8249196
** - Load jamm as an agent into the JVM
***********************************************************************************
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.github.jamm.MemoryMeterBase (file:/faunadb/lib/faunadb.jar) to field java.lang.String.value
WARNING: Please consider reporting this to the maintainers of org.github.jamm.MemoryMeterBase
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

They are intermittent, I haven’t nailed down any reproduction steps. Also I haven’t tested absolutely everything.

Yep, things work but then they did work to a certain extent while Docker was emulating AMD too but it’s just random things like the above. One massive improvement is there aren’t crashes from qemu anymore – because there’s no AMD emulation anymore :grinning_face_with_smiling_eyes:

My understanding that AdoptOpenJDK doesn’t have M1 support is from:

Also from my understanding: a big portion of the work for getting builds available for Linux on ARM64 is the same for getting builds available for Mac on ARM64 hence why the Linux build generally works on Mac but there are random things like the things above.

@ptpaterson: I’ve done a bit more digging. The GitHub issue you’ve linked refers to JDK 17, which does have support for M1 Macs. The OP of the issue you’ve linked, links to the issue asking for native builds for Mac and in that thread the relevant comment is:

JEP-391 was integrated into jdk17
now everyone can build 17ea for macarm

Provide native builds for ARM based Macs · Issue #1922 · adoptium/temurin-build · GitHub

JDK 11 does not have support. This is also visible when you compare the available binaries:

Search for arm64_mac. It appears in JDK 17 binaries but not JDK 11 binaries. The only arm64/aarch64 builds in JDK 11 binaries are for Linux; and as mentioned in my last message, Linux arm64 builds work in some aspects but there are issues.

Those warnings appear even when not using the ARM architecture. You can effectively ignore them. We’ll need to update JAMM at some point, but it isn’t breaking anything, currently.

The only time I’ve had Fauna Dev crash is when I’ve run a query that required more memory than I provided to the image.

Ahh interesting, ok. I did not know the root cause of those warnings so made an assumption that it was down to an incompatible JDK.

Regarding crashes, I’ve not had Fauna Dev crash but have had qemu (an emulator for AMD) crash. But since the image is now available on arm64, no emulation is required, so no crashes :grinning_face_with_smiling_eyes:

Appreciate you all so much for getting an ARM compatible Docker image out :heart:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.