New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Has anyone tried GraalVM on Android? #632

Closed
quinton-hoole opened this Issue Aug 22, 2018 · 26 comments

Comments

8 participants
@quinton-hoole
Copy link

quinton-hoole commented Aug 22, 2018

If not, is anyone aware of any specific reasons why GraalVM could not be compiled up for Android?

@dougxc

This comment has been minimized.

Copy link
Member

dougxc commented Aug 24, 2018

I have no experience developing on or for Android but one immediate limitation I can think of is that GraalVM does not have a working ARM backend (yet).

@dougxc

This comment has been minimized.

Copy link
Member

dougxc commented Aug 25, 2018

Let me clarify a little. The Graal compiler itself has a working ARM backend. However, we don't yet have all the pieces in place in SVM to build a GraalVM binary for ARM.

@quinton-hoole

This comment has been minimized.

Copy link
Author

quinton-hoole commented Aug 25, 2018

@thomaswue thomaswue added the feature label Aug 27, 2018

@thomaswue thomaswue self-assigned this Aug 27, 2018

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Aug 27, 2018

For reference, similar discussion was done in #373.

@bobmcwhirter

This comment has been minimized.

Copy link
Contributor

bobmcwhirter commented Dec 2, 2018

fwiw, I'm taking a task to impl the SubstrateVM on AArch64. (Sponsored FTE work).

@dougxc

This comment has been minimized.

Copy link
Member

dougxc commented Dec 3, 2018

Hi @bobmcwhirter , that's great to hear! @sanzinger is also working on this so it would be good to coordinate to avoid duplicated work.

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Dec 3, 2018

Hi @bobmcwhirter,
I have some changes pending towards getting Substrate for AArch64. I'm trying to integrate them in the next days.
Then we can discuss the areas where we want to go forward with/what are the missing pieces.

General question since this issue is asking for Android? Are you targeting Android or Linux?

@bobmcwhirter

This comment has been minimized.

Copy link
Contributor

bobmcwhirter commented Dec 3, 2018

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Dec 3, 2018

Hi, thank you for sharing. These things are already there on our internal branch. Let me check, if I can share the branch with you.

@bobmcwhirter

This comment has been minimized.

Copy link
Contributor

bobmcwhirter commented Dec 3, 2018

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Dec 3, 2018

Yes, crosscompilation is a thing here since the native image builder requires reasonable amount of memory for real world programs.
But for the first go we really want to get a simple hello world program running.
I am currently working to prepare the branch for sharing. I'll keep you updated later today.

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Dec 3, 2018

I have pushed the branch with the current state: https://github.com/sanzinger/graal/tree/svm/aarch64

I'll provide some instructions to it tomorrow.

@bobmcwhirter

This comment has been minimized.

Copy link
Contributor

bobmcwhirter commented Dec 4, 2018

@bobmcwhirter

This comment has been minimized.

Copy link
Contributor

bobmcwhirter commented Dec 4, 2018

So it cleanly builds here. I know I can svm.platform= to cause native-image to build for AArch64, but... is it really, if my local libraries are darwin?

I reckon at this point, until we get cross-compilation working, the full builds should occur on an AArch64 host?

Is JDK11 JVMCI sufficient on AArch64 with this branch? Should I be building JVMCI directly on the arm host?

Thanks!

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Dec 4, 2018

Yes, we need to run everything on an AArch64 host, with JDK11, nothing else for the moment. But internally we run it a bit different so I am currently investigating a way to run tests on the this branch without our internal buildsystem. This is what I am doing right now. Give me some time for bringing an update on this. As a possible target JDK we may choose https://adoptopenjdk.net/releases.html#aarch64_linux or a custom built JDK11.

@bobmcwhirter

This comment has been minimized.

Copy link
Contributor

bobmcwhirter commented Dec 6, 2018

I'm still awaiting my hardware, so not a super big rush, but any updates?

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Dec 11, 2018

I am sorry, I don't have much update so far. I was stuck in running any tests with openjdk 11 so far.

Regarding cross compilation: Cross compilation is not simple possible. We have code initialized on the platform we're compiling on (Eg File subsystem, Network subsystem classes for the OS is initialized and compiled into the native image).

However, crosscompiling on the same OS with different CPU architectures may work, allthough, we may get all the specifics for the target architecture. (We use c compiler to find out the size and offsets in c datastructures on this platform)

I'll continue on this issue probably tomorrow.

@bobmcwhirter

This comment has been minimized.

Copy link
Contributor

bobmcwhirter commented Dec 20, 2018

So I got my aarch64 hardware, and attempting a simple build on your branch results in:

[bob@linux vm]$  mx --dynamicimports /substratevm build
WARNING:   File "/home/bob/repos/graal-aarch64/truffle/mx.truffle/suite.py", line 269 in definition of com.oracle.truffle.dsl.processor.jdk9:
Cannot specify both "checkstyle and "checkstyleVersion" attribute
WARNING: No platform-specific definition is available for distribution POLYGLOT_NATIVE_API_SUPPORT for your architecture (aarch64)
GraalVM requires a JDK8 as base-JDK, while the selected JDK ('/usr/lib/jvm/java-11-openjdk-11.0.1.13-4.fc29.aarch64/.') is '11.0.1':
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode, sharing)
Please check the value of the 'JAVA_HOME' environment variable, your mx 'env' files, and the documentation of this suite.

This is on Fedora-29 using the F29 openjdk11.

@olpaw

This comment has been minimized.

Copy link
Member

olpaw commented Dec 21, 2018

@bobmcwhirter if you build from the vm subdirectory mx will try to build a whole graalvm release for your architecture. At this point, this likely not what you want. Head over to the substratevm sibling directory and run mx build from there. For more info consult the SubstrateVM README.md.

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Dec 21, 2018

Have you had any luck? I just came back to it. I am going to rebase the branch and push it later.

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Dec 21, 2018

I have update the branch on my repository. However I could not get it running on AArch64 since ninja is not available on this platform and I ran out of time building it myself.

@waffletower

This comment has been minimized.

Copy link

waffletower commented Dec 26, 2018

Starting with LINUX_AARCH64. IOS would be my next goal but that’s just a personal goal. Can you push a branch we could collaborate on? I’ve got my stubs here (started Friday): https://github.com/bobmcwhirter/graal/tree/aarch64-platform?files=1

iOS binary build capability would be a most excellent goal

@bobmcwhirter

This comment has been minimized.

Copy link
Contributor

bobmcwhirter commented Jan 2, 2019

@olpaw -- Yah, I'm used to building from vm on my mac. Now I've moved to the substratevm dir and building, with verbose, to find why g++ is unhappy. I've having to add ignore warnings are errors due to deprecations.

@sanzinger I managed to get ninja installed, but I'm also running Fedora29 on this machine, instead of the Suse or whatever softiron ships on it.

Also, I'm cherry-picking/copy-pasting from your bits against master#HEAD so that hopefully there's less divergence than from October's commits of yours, and so I understand all the moving parts and deltas.

@Prashanth-BC

This comment has been minimized.

Copy link

Prashanth-BC commented Jan 7, 2019

@bobmcwhirter and @sanzinger : I was able to build the repo on docker (aarch64).But build a native image using mx native-image eventually failed :(.
I guess graal is using llvm and gcc to build the native image. Cant we just pass the march argument to the compiler specifying the target processor architecture?

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Jan 11, 2019

I just compiled ninja properly on AArch64.

I updated my branch mentioned above with the latest state. It is currently failing at:

fatal error: com.oracle.svm.core.util.VMError$HostedError: currently only implemented on AMD64
	at com.oracle.svm.core.util.VMError.guarantee(VMError.java:85)
	at com.oracle.svm.jni.hosted.JNICallTrampolineMethod.lambda$createCustomCompileFunction$1(JNICallTrampolineMethod.java:111)
	at com.oracle.svm.hosted.code.CompileQueue.doCompile(CompileQueue.java:883)
	at com.oracle.svm.hosted.code.CompileQueue$CompileTask.run(CompileQueue.java:259)
	at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$execute$0(CompletionExecutor.java:174)
	at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)

I am going to continue next week on this.
@bobmcwhirter do you have any progress?

@sanzinger sanzinger assigned sanzinger and unassigned thomaswue Jan 14, 2019

@sanzinger

This comment has been minimized.

Copy link
Member

sanzinger commented Jan 14, 2019

We should move the discussion over to an explicit PR which deals with Substrate on AArch64 (PR #910).
This issue was opened to ask for Substrate Support on Android. Current state for Substrate on AArch64 is, that we first want to support Linux on AArch64. Support for Android from us is not decided yet.

I hope this answers the original question.

@sanzinger sanzinger closed this Jan 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment