<...> the code is compiled/translated down to bytecode and then the JVM interprets(?) it down to machine code. Would this be an example of JIT(Just in time) compilation?
Yes, when targeting the JVM, Kotlin is compiled to JVM *.class files, which is a bytecode format that can later be either interpreted by a JVM, or compiled to the machine code by the JVM during the program run (JIT), or even compiled ahead-of-time (AOT) down to the machine code. Here, the Kotlin compiler doesn't need to know how exactly the bytecode will then be used.
When targeting javascript the word "transpiles" is used. What exactly is the code compiled down to and is it interpreted or compiled further down at any step?
The target format for Kotlin/JS is JavaScript source code. You can try and build any Kotlin/JS example and examine the *.js output files containing the JS source code that the Kotlin code is translated to. I believe the word transpile (translate + compile) is used here to emphasize that the target format is source code rather than binary, while the compiler still performs a lot of transformations and optimizations.
The JavaScript source code is, just as well, either interpreted or JIT-compiled, which depends on the JavaScript engine used to run the program.
When targeting native, is code compiled directly to machine code? What steps does LLVM take it through?
There are two possible target forms for Kotlin/Native:
- A
*.klib library that can be reused in another Kotlin/Native project. This is a ZIP archive containing LLVM bitcode along with some Kotlin-specific metadata.
- A platform-specific binary, in one of the numerous formats, including static and dynamic libraries and executable files. This is, indeed, the machine code for a specific target platform, which can be used for linking in case it is a library, or be run directly if it's an executable. In this case, the Kotlin compiler invokes the LLVM linker
lld to link a binary from the LLVM bitcode.
