Home Features Docs Blog Support GitHub

One potential future of MOE: SubstrateVM

Feature
#1

I wrote a blog post about my progress and findings on porting MOE on top of SubstrateVM:

I’ll keep updating the blog once I’ve made any more progress.

Bare in mind this is still in very early stage and is more like an experiment instead of attempting to make a fully functional product. So finger crossed that everything could go well and eventually we could bring a bright future to MOE.

You are welcomed to join the discussion by leaving comments below, or join the Multi-OS Engine Community discord channel: https://discord.gg/m5t3qNXTWj

Multi-OS Engine Community

Docs | Blog | Discord | Github

4 Likes
#2

We already using GraalVM-11 to build iOS app, it builds and works.
However, we wrote our own ObjC layer so that interop is easy, simple and portable:
compatible with hotspot, TeaVM (C - target) and GraalVM

3 Likes
#3

Sounds interesting. Did you release the code somewhere?

#4

Im not sure it is possible.
This is property of the company. However I’m glad to answer any questions.

#5

Hi Kirill,

  • Did you use a generator or wrote the bindings by hand?
  • Do you target ObjC, Swift or both?
  • If you target Swift, how do you solve the fact that Swift is much more static (e.g. no reflection by default)
  • Which VM do you use?
  • How do you debug your Java code? Do you use the debug symbol support for GraalVM/SubstrateVM?
  • Do you use the standard SubstrateVM or have same patches?

By supporting Swift I don’t mean Swift classes with ObjC bindings, but native Swift classes without going through ObjC.

Thanks,
Gergely

#6

Hi @noisyfox,

Great stuff. Actually you no longer need to use static libraries on iOS, Dynamic libraries built as frameworks can be used as well. It just needs to be signed together with the app.

Kind regards,
Gergely

#7
  • Did you use a generator or wrote the bindings by hand?

No we dont, we do not release SDK for iOS.
We are TRULY multiplatform: our code builds for iOS (moe, graal), for Web-JS (teavm), for Android, for Desktop JVM (java, jlink), for Windows UWP (TeaVM C target).
We dont provide platform APIs, only multiplatform, so we DONT not need any generators yet.
However it is possible of course.
Please see https://edu.cospaces.io/

  • Do you target ObjC, Swift or both?

We build interop between Java and C, Java and ObjC. We dont use Swift yet. Also we trying to write more in Java so that our planform and interop layers are minimalistic.

  • Which VM do you use?

we use JVM (11+), GraalVM-11, TeaVM (master), MOE (migration to Graal is in progress).

  • How do you debug your Java code? Do you use the debug symbol support for GraalVM/SubstrateVM?

Usually we dont. We test multiplatform parts and platform parts independent. Also we write many ObjC tests for testing leaks and stability. Same time we use XCode to build app, and we can set breakpoints in C, CPP and MM in the xcode without any issues. We dont debug generated java code.
However, if crash happens, we see graalvm stack mostly well (in C crash dumps), it recognizable and human readable.

  • Do you use the standard SubstrateVM or have same patches?

Today we use release builds and dev builds without any modifications.

#8

Which libraries do you mention ?