https://kotlinlang.org logo
Join Slack
Powered by
Is kotlin (specifically native) decoupled from jav...
# kotlin-native
e
Is kotlin (specifically native) decoupled from java or is it still built on top of java?
j
The compiled code is independent of Java
e
Ok
j
The compiler is still built on the JVM, though
e
Is that why it decompiles (at least in Android Studio) to java?
k
I think that's more a function of the IDE and has nothing to do really with the Kotlin compiler.
e
OK
d
I have not explored how Kotlin Native is implemented but there is a language BCPL where it is easy to look at the compiler and methods of porting. Java, C#, and a number of other languages compile to an intermediate code (a virtual machine code) which runs on its own virtual machine. BCPL used to do something very similar. All compiler do convert to an internal representation that can be converted to some form of machine code quickly. How closely that internal representation represents the language can determine how easily it can be ported to different platforms. One way of going to native execution os simply to write a compiler or convertor for that intermediate code that will enable it to execute on the real processor. That was how BCPL was often ported to new machines. I am guessing a bit now but I believe that Kotlin is compiled to the same intermediate code as Java and hence runs on the JVM. If native then takes that intermediate code and converts it to the real processor, you have native execution. The advantage of doing this in Kotlin’s case is that you can use Java libraries in native compilation. Considering I learnt compiler writing 50 years ago but have seldom been involved in writing one, I recognise that the fundamental concepts have not changed a lot. If you understand the fundamentals it is easier to determine what is likely to be happening.
e
Would it benefit anyone if they ported the kotlin compiler to a different language then java? Like C/C++?
To decouple it from the jvm
j
No. The only possible port would be to Kotlin multiplatform.
It's already written primarily in Kotlin but tied to lots of JVM-specific things
e
A compiler doesn't have to be written in the langue it compiles, I believe the original c compiler was written in asm, and I think the original asm compiler (I may be horribly wrong with this one) was written in machine language.
j
I know that, but what is the goal?
e
Speed and portablilty
Anything better then running on the jvm
Port it to turbo pascal or qbasic
j
Ah yes, two things the JVM is not famous for: speed and portability
e
Portability sure, but not fast and portable.
j
If you say so. Seems like an opinion from 15 years ago.
I'm sure JetBrains would welcome a second compiler
k
Are you gonna port gradle, too?
e
don't need to port gradle.
e
for long-running and batch operations, JVM performance is very good, generally on par with native languages (sometimes worse, sometimes better, depending on the task). it does suffer in short-lived and interactive situations, but that's not the scenario for the Kotlin compiler
e
Well, the Hotspot vm is written in c++ but the java compiler is written in java
e
the Kotlin compiler has its own IR: https://github.com/JetBrains/kotlin/tree/master/compiler/ir Kotlin/JVM, Kotlin/JS, Kotlin/Native, and Kotlin/WASM compiler backends lower from that to their target representations (there's also the pre-IR JVM and JS backends, but they're on their way out)
e
The original java compiler was written in c, but that is just boot strapping until they got it into the java language, so it would be better to have kotlin compiler written in kotlin.
e
the compiler as a whole does re-use components and patterns from IntelliJ - what else could you expect, that's what JetBrains is good at making
there's a good amount of Java usage in the compiler itself coming from that
e
Thats probably because it still uses a lot of java libraries.
s
GraalVM native image is probably to shortest path to having a native Kotlin compiler, but I have not tried it yet and don’t know how much native configuration it would require. And not sure about the use cases since gains on cold start would probably be lost on execution speed for non trivial projects. Even if it would be technically possible, Kotlin compiler compiled with Kotlin/Native would probably be too slow to be competitive. My use case for Kotlin compiler on another platform would be to compile it to Kotlin/Wasm + WASI to allow full client side IDE like https://stackblitz.com, but as said above, too much JVM libraries to make it usable for now (and too early given the level of maturity of Kotlin/Wasm).
n
Thats probably because it still uses a lot of java libraries.
Which is a good thing, why reinvent any functionality if they can use existing ones. I hope that the Kotlin Team will never spend time with such non-practical development like "to decouple it from the jvm"...
r
Put a different way, what real problem is it that you want to solve? Being coupled to the JVM isn't a root problem - whatever you implement in you'll be coupled to something (GCC or Clang or LLVM or whatever). There has to be some aspect of the JVM that is undesirable that would be fixed by migrating the toolchain to something else. Things it could be: 1. size on disk / amount to download (a JDK + gradle isn't small), though you'll need to show how much space would be saved by switching 2. memory footprint - again you'd need numbers to show that some other implementation would require less memory, and then you'd need an indication of whether it's worth the switch - how often is providing the memory the existing toolchain requires actually a problem? 3. CPU time - I could believe that in some circumstances a compilation process is sufficiently short lived that a typical JVM implementation could be outperformed by another implementation. Particularly as so much compilation occurs in CI environments where a background daemon is of little use. But by how much? Enough for the effort involved? 4. Attack surface - as Log4Shell and Text4Shell have shown one of the downsides of the size of the JDK is that for any given workload there's a ton of stuff in there that is not being used but could be abused, like the ability to download and run arbitrary classes over JNDI. But is that relevant in a compilation scenario? Just guessing, but the one I could most believe is a real benefit would be a substantially smaller on disk toolchain - in our containerised world it would be nice to have a tiny image capable of building our code. The other 3 seem likely to be marginal gains at best for a massive effort.
e
3, startup time can be alleviated by reusing the same JVM - most commonly by moving work to a daemon, as the Kotlin Gradle plugin does, but there's also ways to solve this at the JVM level, such as https://openjdk.org/projects/crac/. it may not need to be addressed by Kotlin itself
r
Doesn't really work in CI where you're generally compiling in a clean environment often in a newly started container.
e
yes I realize a daemon doesn't necessarily work there, but CRaC is definitely a possibility (it already works on other projects, see https://github.com/CRaC/docs#readme)
r
That's interesting, thanks. I seem to recall playing with some other mechanisms to try and minimise warm up by exporting the JIT'd classes at one point... can't remember what the options were.
-XX:ArchiveClassesAtExit
on a warmup run and then 
-XX:SharedArchiveFile=$shared_archive_file"
for real
And 
-Xshare:on
e
1, size on disk… Kotlin/Native (Konan) pulls in an LLVM distribution which, even in its minimal form, is larger than the JVM for me
m
AppCDS is usually about a 30% win. Compiling kotlinc with native-image would be a fun project. I tried to convince the GraalVM team to do it themselves at some point, using a daemon sucks. With EE you can match HotSpot speed but with a native binary, so it's the best of all worlds.
(except needing to buy a license to use it)
30 Views
Open in Slack
PreviousNext
Powered by