I am the CTO of Migeran and the Project Lead of the Multi-OS Engine (MOE) project. At Migeran, we developed Migeran for iOS, the original product that was acquired by Intel and its technology used in MOE.
TL;DR: I see a lot of opportunities for cooperation with Kotlin Native. Feel free to contact me directly, if you are interested as well.
I assume, that Kotlin Native (while including special support for Kotlin specific features), will be a generic AOT compilation based VM capable running any AOT compatible JVM app. I don’t see the use case for a VM that can only run code written in Kotlin directly.
First, a few notes about MOE:
For MOE 2.0 we developed a completely new LLVM backend for ART. It is based on Android N. For those, who remember the early days of ART, this new backend has no relation to the original “portable” backend. It is essentially a new backend for ART’s optimizing compiler. Our backend is already functional, we are working on cleaning the code before releasing the first alpha.
MOE of course runs Kotlin apps just fine (including any language that would run on Android ART).
I am not opposed to the idea to add new, Kotlin specific runtime features to MOE. The benefit would be, that you don’t have to start everything from scratch. The tradeoff is, that a lot of design decisions are already made in ART, although a lot of those assumptions can be changed (and we already changed some of them in MOE 2.0).
I can also understand why you (Kotlin Native developers) would think, that starting from scratch will yield better results for your use cases. VM design is a complex topic, with lots of different design options along the way. A nice example of this is comparing MOE with RoboVM. The high level view is that both projects solve the same problem: a working JVM for iOS. But when you look closer, in almost every design decision the projects went in a different direction. Just a few examples:
- RoboVM started from scratch, we started from the Android VM (first Dalvik, then moved to ART when it was first released by Google)
- RoboVM created a VM specific ObjC binding framework (Bro), we created Nat/J on top of JNI, so it works with any Java VM. (Side note: This also means, that if Kotlin Native will be JNI compatible, it can reuse MOE’s iOS bindings.)
- RoboVM is full AOT, MOE (ART) includes an interpreter. It is used during class initialisation and debugging: methods containing breakpoints or methods that are being stepped through execute on the interpreter. (This also means that MOE can theoretically load new classes (in dex format) at runtime. These will run on the interpreter, we don’t recommend or support it, but should work. A valid use case for this could be a development framework where code can be created and pushed into a running Playground type app on the fly. Think Kotlin REPL running on an iOS device or IoT)
I see multiple areas where we could cooperate. These areas are pretty much independent from each other.
Turning ART into a true Kotlin Native environment
If you think that you could live with re-using ART, it could be extended / refactored into a very nice generic VM platform, where its components are runtime exchangeable through a plugin API. This would make it possible to load Kotlin specific VM extensions at runtime, and (if Google plays along), this could also benefit any Kotlin app running on Android.
For other platforms, MOE’s LLVM backend can be used to provide superb performance, and it can be optimized to handle Kotlin workloads even better by using the Kotlin specific extensions in the VM directly.
I saw in a Kotlin Native document, that you are considering optional support for ARC / reference counting based memory management. I would also very much like to see support for this in a JVM, so ideally the plugin interface of ART would make the implementation of different memory management strategies possible. Classes could opt-in for a specific memory management model using the right ClassLoader.
Unified Java Runtime library
The biggest issue in the JVM world is that the runtime library versions are very fragmented. There are 2 big players (as you all know): Android and Oracle Java.
Android 7 propelled the platform compatibility level from the distant, obsolete past of (almost) Java 7 to the not so distant and soon to be obsolete past with adding limited Java 8 support. Their approach with the Jack toolchain is currently being reconsidered (I am being diplomatic here ). They realized, that reimplementing the Java 8 API is technically, financially and probably legally is just not feasible. So they did the right thing, and moved to use OpenJDK as the basis. But they did it in a way that effectively forks OpenJDK in the ugliest possible manner. I won’t go into detail here, check out the ojluni module in AOSP if you dare.
Oracle has its own problems. The release was pushed back multiple times already (especially the module framework seems to be hard to get right - which is understandable). The world is now mostly using Java 8, but there are still lots of people stuck in the dark ages of Java 6 or 7 due to legacy environments.
This level of fragmentation is hurting the Java / JVM ecosystem. My proposal is, that ART (and any other VM) should move to the Java / OpenJDK 9 library as soon as possible. Changes on top of the Java 9 runtime library should be kept as a minimum, and each project should track Java 9 development head as closely as possible.
I also propose, that a new base module of the runtime library is defined for AOT VMs. Note, that Oracle is also working in this space with a VM called the GraalVM and with AOT support for HotSpot, so they might be willing to accept these changes into the mainline. Even if Oracle does not accept these changes, the different VMs (including stock Android, if Google plays along) should be able to share their runtime library repositories in a common project and reduce the synchronization and maintenance burden on each project.
Kotlin iOS bindings
As I already mentioned, MOE has a fairly complete, automatically generated binding for iOS. It is compatible with any JNI compatible VM. The generator is using the Objective-C headers, but it does not yet use the extra attributes that were added for Swift. It is following the original ObjC APIs very closely (e.g. uses
alloc().init*() based 2 phase construction).
It is on our roadmap to move to a more modern binding, modelled after the Swift bindings. We are considering to move to Kotlin for the next version of the API bindings. There are features in ObjC / Swift, that cannot be easily / nicely reflected in Java (e.g. extension classes), Kotlin would make this easier. This would also mean that Kotlin Native would have access to high quality, Kotlin native bindings for iOS, tvOS and (potentially) WatchOS.
This could be also an area, where we could share our efforts.
To summarize: I see a lot of opportunities for cooperation, and I would be happy to discuss these topics further.
Feel free to reach out to me here, or contact me directly.