Skip to content
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
ghost opened this issue Aug 22, 2018 · 34 comments
Closed

Has anyone tried GraalVM on Android? #632

ghost opened this issue Aug 22, 2018 · 34 comments
Assignees
Labels

Comments

@ghost
Copy link

ghost commented Aug 22, 2018

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

@dougxc
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
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.

@ghost
Copy link
Author

ghost commented Aug 25, 2018 via email

@thomaswue thomaswue self-assigned this Aug 27, 2018
@sanzinger
Copy link
Contributor

For reference, similar discussion was done in #373.

@bobmcwhirter
Copy link
Contributor

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

@dougxc
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
Copy link
Contributor

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
Copy link
Contributor

bobmcwhirter commented Dec 3, 2018 via email

@sanzinger
Copy link
Contributor

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
Copy link
Contributor

bobmcwhirter commented Dec 3, 2018 via email

@sanzinger
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

bobmcwhirter commented Dec 4, 2018 via email

@bobmcwhirter
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
Copy link
Contributor

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
Copy link
Contributor

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

@sanzinger
Copy link
Contributor

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
Copy link
Contributor

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
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
Copy link
Contributor

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

@sanzinger
Copy link
Contributor

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
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
Copy link
Contributor

@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
Copy link

@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
Copy link
Contributor

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 self-assigned this Jan 14, 2019
@sanzinger
Copy link
Contributor

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.

@divs1210
Copy link

Looks like #910 has been merged. We seem to be getting closer!

@vjovanov
Copy link
Member

We have been running on Android with both the LLVM and AArch64 backends. Build tools for deploying apps to iOS and Android are just around the corner. Stay tuned...

@metacritical
Copy link

Any More updates on this?

@vjovanov
Copy link
Member

vjovanov commented Jun 14, 2020

We support both Android and iOS through the tool called Substrate. We are already running quite big projects on the devices.
A good example is GraalREPL. You can find many examples here.

@metacritical
Copy link

This is plenty helpful, Thankyou.

@insinfo
Copy link

insinfo commented May 2, 2022

is it already possible to compile a native shared library written in java for Android with GraalVM?

@benayat
Copy link

benayat commented Feb 20, 2023

@vjovanov can any of this examples help me create a native executable for running spring boot backend on termux/android?

@vjovanov
Copy link
Member

I would start at

https://github.com/gluonhq/gluon-samples

and also ask further questions there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests