Graal: Has anyone tried GraalVM on Android?

[ghost]

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

[dougxc]

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]

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]

Thanks for the clarification Simon. Approximately how much work is it to
get those missing SVN pieces in place? As an alternative (possibly dumb)
idea, would it make any sense at all to run the Java parts on top of the
existing Android JVM. I'm most interested in the polyglot aspects of
GraalVM on Android, as opposed to performance.

One way or the other I'd like to run my polyglot GraalVM applications on
Android. Trying to find the shortest, most sensible route to that goal.

On Fri, Aug 24, 2018, 23:23 Douglas Simon [e-mail] wrote:

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.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/oracle/graal/issues/632#issuecomment-415943429, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJ6NAdih8HFuEBAloJwCmMmyWEzo9my4ks5uUO1ZgaJpZM4WH6mD
.

[sanzinger]

For reference, similar discussion was done in #373.

[bobmcwhirter]

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

[dougxc]

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]

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]

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

On Mon, Dec 3, 2018 at 5:28 AM Stefan Anzinger [e-mail]
wrote:

Hi @bobmcwhirter https://github.com/bobmcwhirter,
I have some changes pending towards getting Substrate for AArch64. I'm
trying to integrate them in the next days.
Then I 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?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/oracle/graal/issues/632#issuecomment-443661405, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAA-T0Ro7Q4U4rS1WBTbbZpg54cYbvkZks5u1Py8gaJpZM4WH6mD
.

[sanzinger]

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]

Great thanks.

I’m eager to continue working toward arm so whatever you can share or think
would be a good way to collaborate would be great.

I have signed the Oracle CLA already (via Red Hat).

My big aarch64 hardware should arrive soon to supplant my RPi.

I’d also like to support cross-compilation to aarch64 from x86 platforms at
some point.

Bob

On Mon, Dec 3, 2018 at 6:56 AM Stefan Anzinger [e-mail]
wrote:

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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/oracle/graal/issues/632#issuecomment-443685359, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAA-T2ogiVIEP42ldATekDjwgora9Eakks5u1RFqgaJpZM4WH6mD
.

[sanzinger]

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]

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]

You rock!

On Mon, Dec 3, 2018 at 3:04 PM Stefan Anzinger [e-mail]
wrote:

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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/oracle/graal/issues/632#issuecomment-443850743, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAA-TxSsncMgBXo_5feF139EZF4JBqaMks5u1YO0gaJpZM4WH6mD
.

[bobmcwhirter]

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]

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]

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

[sanzinger]

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]

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]

@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]

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

[sanzinger]

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]

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]

@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]

@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]

I just compiled ninja properly on AArch64.

I updated my branch mentioned above with the latest state. It is currently failing at:
6 fatal errors detected: 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]

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]

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

[vjovanov]

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]

Any More updates on this?

[vjovanov]

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]

This is plenty helpful, Thankyou.