A modern programming language that makes developers happier.

kotlinlang

*Support for kotlin-native on Linux ARM32 soft-float ABI?*

I see there was <https://kotlinlang.slack.com/archives/C3SGXARS6/p1576035209230400|a previous question on this channel> about this topic which also referenced an obsolete <https://github.com/JetBrains/kotlin-native/issues/3350|kotlin-native Github issue #3350>.
But all this happened in 2019 — have there been any updates? Are there any plans for making it happen?

We are running Java 8 SE on an IoT device with ARM926EJ-S processor (with thousands deployed) and we are looking for ways to modernise our stack. OpenJDK is too slow (well, the garbage collector pauses are already now causing issues) so ideally we would like to run a native binary. So far, the top contender is Rust (`armv5te-unknown-linux-gnueabi` target architecture) but Kotlin would be so much easier, considering that our cloud stack is all Kotlin (running on JVM).

I’m not sure how much effort would the initial development be? And the later maintenance? We might be willing hack on this in case it isn’t too hard.

As much as I understand, both Rust and Kotlin-native compilers use LLVM underneath so if it works with Rust then it should not be too hard to make it work with Kotlin-native?

Kotlin/Native uses Garbage Collection too. 

And beside changing the llvm target, you also need to check/change the Kotlin/Native runtime, and maybe also the forked llvm Kotlin uses. And you need to recompile all libraries you use as well. 

> Kotlin/Native uses Garbage Collection too.
True. But I hope to have more control over when GC is triggered and how long it will run.
Anyway, I would like to test it out. But as I understand, it is a bit of an chicken-and-egg problem — I cannot test it without putting in quite a bit of effort. And I do not know if it is worthwhile to put in that effort without testing it. Maybe that’s why nobody has bothered. :slightly_smiling_face:
Anyway, I would like to give it a try. At least I will learn quite a bit in the process.

> And beside changing the llvm target, you also need to check/change the Kotlin/Native runtime, and maybe also the forked llvm Kotlin uses. And you need to recompile all libraries you use as well.
Yes. So how do I get started? :slightly_smiling_face:

I hope there is some way I can get a proof-of-concept running with fairly small effort and then increase the scope in case the PoC results look promising.
PoC scope could be:
• Compile some fairly trivial code, nothing fancy. Create objects, discard them. Different control structures. If easy, try coroutines.
• Measure on actual hardware:
    ◦ Size of final binary (on disk)
    ◦ Memory consumption of a trivial application
    ◦ The speed of startup
    ◦ The speed of runtime execution
• See how garbage collector behaves. Experiment with different collector implementations.

As a first step, I’ll try building Kotlin-native from source for macOS (my host machine). Next step would be to build it for Linux (host and target), inside Docker. After this warm-up, I can try to switch the Linux build to the desired `armv5te-unknown-linux-gnueabi` target.

You could also explore native-image. It creates smaller, less memory intensive binaries that don't need to JIT compile and there's a consulting company that helps people use it for embedded use cases like yours

They can help customize the GC if the standard tuning mechanisms don't work

Thanks for the suggestion. We did get a quote from them but considered it too expensive.