[cromwellian]

Kotlin methods are final by default unless marked open, and thus nonpolymorphic dispatch unless through an interface.

It sounds to me like the problem isn’t the VM it’s the insane amount of framework code you have to be initialized. This can be optimized with Java via class data sharing and snapshotting but if your code is all written in Kotlin and you toss Spring into the trash can In favor of say, Dagger or hand crafted DI, most of your problems would go away.

Besides, Kotlin/Native can compile and run without a VM.

See https://august.nagro.us/jvm-startup.html for examples of how to optimize startup without Prewarming JIT.

[NovaX]

> Kotlin methods are final by default unless marked open, and thus nonpolymorphic dispatch unless through an interface.

This is a language construct and not enforced within the byte code. There have historically been reasons to allow final to be ignored, such as serialization. Instead the JIT will optimize and deoptimize based on runtime behavior, allowing it to cover cases where overriding is designed for but not done so in the actual runtime environment. There was a nice presentation on "truly final fields" at the 2018 language summit [1].

[1] https://www.youtube.com/watch?v=2HfnaXND7-M

[cromwellian]

It may not currently be enforced, but the compiler could enforce it, depending on assumptions, the same way we enforced it on the GWT compiler (of which I'm one of the engineers who worked on it)

With GWT, we had global information, so we could promote methods to static by class hierarchy analysis.

For a Kotlin class, even with dynamic loading, if the class is not marked 'open', final methods not implementing an interface, or private methods, can be converted into static methods.

e.g.

   class A(val x: Int) {
     fun print() = x
   }

can be transformed into

   class A(val x: Int) {
     fun print() = printStatic(x)
     companion object {
       fun printStatic(self: A) = self.x
     }
   }

And any call site with access to the original signature, e.g.

   val a = A()
   println(a.print())

could be rewritten safely as

   val a = A()
   println(A.printStatic(a))

Now, the current Kotlin compiler frontend or backend may not do any of these, but it could.

There's nothing in the compiler language itself that blocks such optimizations, especially if you're willing to limit reflection (as is the case with Kotlin MPP code), or admit a LTO pass.