https://kotlinlang.org logo
Join Slack
Powered by
It's happening <https://blog.jetbrains.com/kotlin/...
# kotlin-native
m
k
it had to
j
I got curious to what this means wrt frozen state going forward. I get that there will be a backwards compatibility story but what about green field applications, will these be able to skip the 'frozen learning curve'?
j
Any idea what this means for inclusion of native-mt version of kotlinx coroutines for Kotlin 1.4 (and use in libraries like ktor)?
k
it's still unclear, from following the original multithreaded coroutines issue
my takeaway is that there's still some rather fundamental shifts in progress on K/N, which tells me we're not going to see GA for some time
k
I have a little response post coming. Summary, yes, if you want to write kotlin native anytime in the near future, you need to understand frozen. The MT coroutines should be supported. GA, with these changes, will be quite a while for sure.
ktor is an open question, though
There was work on it, but not sure where that’s at
j
What's GA?
k
Stable production, basically
k
general availability
j
Thanks
e
Coroutines will be supported. New memory manager will take time to write. For now, doing multithreading in Kotlin will mean freezing objects.
👍 9
😌 1
k
big step forward none-the-less
n
What implications does the new memory manager have on Linux platforms (incl x64 and ARM v7/v8)?
Will the new memory manager work with native GUI toolkits which aren't mobile based (eg GTK - https://developer.gnome.org/gdk3/stable/gdk3-Threads.html )?
s
All I really want to know is what design the new memory manager is going to have (i.e. what type of GC, a rough idea of what the semantics will look like, will it be similar to the JVM's memory management, etc). The article mentions the problem with the current implementation, but doesn't address any of these questions.
n
One large concern is the impact on memory usage if a GC is used instead of ARC. Using a GTK based text editor as an example the program running on a linuxX64 target reserves around 5.5 MB of RAM (RES memory) with Kotlin Native's current memory management system. Keep in mind that memory usage with Kotlin Native hasn't been heavily optimised yet, and GTK uses manual memory management even though ARC is widely emulated ( http://liacs.leidenuniv.nl/~stefanovtp/courses/StudentenSeminarium/Papers/OS/IMMG.pdf ) throughout the library via Glib ( https://developer.gnome.org/glib/stable/glib-Reference-counting.html ).
e
We study different implementation options. They all have different tradeoffs in terms of throughput, peak memory consumption, etc. We’ll update you as a specific choice is worked out.
👍 4
n
Which ever memory management system is used it will need to be a good fit in multiple areas of software development (backend, desktop, mobile etc). Basically any software development area where Kotlin Native is used. Also the memory management system has to fit in with all deployment platforms supported by Kotlin Native (Linux, iOS, Windows etc).
e
We might end up having multiple domain-specific memory manager choices, so that you can select the one fitting a specific domain better when linking your binary.
👍 8
n
Does that include being able to choose a memory model (ARC, Tracing GC etc) from a range that is supported by the memory manager, or is the memory model determined by the memory manager that is used?
What impact will the memory manager choices have on interop between Kotlin libraries/programs?
What guidance will be given to Kotlin library authors on managing memory?
Would be good to see a high level overview of the memory management system (as a diagram) after all the key details have been figured out.
e
An Apple-style ARC is definitely out of the question for Kotlin. Kotlin memory manager has to be fully automatic like the one we have now, but we’ll also have to lift limitations on concurrency. The choice will impact an overhead while working with references, throughput, memory usage, and how promptly objects are reclaimed when they are no longer used. It will not change how you write the code per se.
n
What measures will be taken to offset the increased memory overhead with the GC's that are available as options?
Are Real Time (RT) GC's being considered as options? There are some RT GC's around like Metronome for example (refer to pages 15, 186-217 in the PDF: https://assets.ctfassets.net/oxjq45e8ilak/3d22xuJ2HeQkoAesWkKic0/1ee2d740edcc5ebaf1602ae16a680267/CharlieGracie_DeepDiveIntoTheEclipseOpenJ9Technologies.pdf )
A low latency GC with low memory overhead is needed as an option for client orientated programs (CLI, desktop etc).
What memory management options do the Kotlin Native team have in mind for the following application types: • Server (traditional, and micro services) • Serverless • Infrastructure • CLI (eg command line tools/utilities) • Desktop • Mobile • Embedded • IoT Backend • Service (eg Unix/Linux Daemons)
s
memory manager, how does that work? runtime? what's gonna be the overhead? tbh this sounds like they'll overengineer their stuff yet again
go simple please!
mobiles can't afford having memory manager that scan heap constantly, what about battery life?
they need to replicate what swift does, it's perfect and easy to work with
e
If it were perfect there would have been dozens other languages doing it. But there are none. It is only Objective-C and Swift. That, by itself, tells a lot.
➕ 1
👌 4
s
that is why android apps requires 2x more ressources than iOS apps, that by itself tells a lot too
i see 2 models that works nice, swift's arc, and rust's ownership
4 Views
Open in Slack
PreviousNext
Powered by