
Extending Kotlin/Multiplatform with native programming capabilities.
This library provides features including but not limited to:
- Unmanaged memory API (
Allocator
,Memory
andMemoryStack
) - Foreign function API for calling native functions by address (
FFI
) - Shared library API for loading shared objects (
SharedLibrary
) - Native size types (
NInt
,NUInt
andNFloat
) - Native function types (
CFn<F>
) - Type safe pointers with constness (
@Const
andPtr
) - Calling convention modifiers for function pointers (
@CDecl
,@ThisCall
,@StdCall
and@FastCall
) - Structure types (
Struct
) - Auto generated memory stack scopes (using
MemoryStack
) - Auto generated interop using
@SharedImport
, similar toDllImport
in C# - Basic metaprogramming (
@ValueType
andtypeOf<T>()
) - Function templates with monomorphization (
@Template
) - Memory access optimizations based on target platform
- Function call optimizations based on target platform
- Standalone ABI library for parsing and demangling kWire symbol data
This library does not support JS/WASM targets, and there is no plans on supporting it in the future. If you know how to do it, feel free to contribute 🙂
The ABI part of the library is shared between the runtime and compiler plugin.
It implements shared type definitions and mechanisms for properly handling kWire symbols
which are embedded in the module data of the module being compiled with the kWire compiler plugin.
-
On the JVM, the runtime implements/wraps around the Panama API available with Java 21+.
This allows easy interaction with platform-specific JVM code and a lot of opportunity for optimizations which directly tie into the JIT compiler -
On Android, the Panama API is not available out of the box.
For this reason, kWire uses a port of Project Panama to Android to substitute the missing standard APIs -
Special features like pinning on the JVM are implemented in the kWire Platform Binaries as handwritten JNI intrinsics, since Panama doesn’t offer any alternatives.
-
On native targets, kWire uses a custom implementation built in Kotlin/Native and using libffi for dispatching calls at runtime in an efficient manner, giving very acceptable performance to builtin C-function calls in Kotlin/Native
The compiler plugin is mainly responsible for lowering code.
This means transforming some higher-level concepts and calls into their actual implementation,
which is usually directly emitted in Kotlin (F)IR.
This allows kWire to implement features otherwise not possible due to limitations of the Kotlin compiler.
The Gradle plugin simply exists to inject the compiler plugin into the Kotlin compiler (daemon),
however it is planned to be extended with code generation capabilities similar to kotlinx.cinterop.
Project Name | License | Author |
---|---|---|
kotlinx.coroutines | Apache-2.0 | JetBrains |
kotlinx.serialization | Apache-2.0 | JetBrains |
kotlinx.io | Apache-2.0 | JetBrains |
AutoService | Apache-2.0 | |
Stately | Apache-2.0 | Touchlab |
LWJGL 3 | BSD-3-Clause | Ioannis Tsakpinis |
OSHI | MIT | Daniel Widdis |
PanamaPort | GPL2 | Vladimir Kozelkov |
libffi | MIT | Anthony Green |
ANTLR Kotlin | Apache-2.0, BSD-3-Clause | Strumenta |
Special thanks to everyone involved in providing the libraries and tools
this project so heavily relies on, and for pouring countless hours of their
time into these projects.

Leave a Reply