Description
On current moment if we will not read Buffer
fully we will have a leak of underlying Segment
(or even multiple segments). While for now Segment
has underlying ByteArray
as memory holder GC will do the job and collect it - which will increase GC pressure, but there will be no actual memory leak. In future if/when we will have other underlying memory types, they could not have such guaranties (f.e. if we leak allocated somewhere CPointer
via malloc
) or cause even more GC pressure.
It would be good to provide some mechanism to find such leaks or even automatically resolve them.
This can be resolved by tracing when objects are garbage collected, f.e.:
- in JDK there is
Cleaner
(JDK 9+) or we can implement it overReferenceQueue
- in K/Native we have
createCleaner(ref) { ... }
. - in JS we have
FinalizationRegistry
One kind of multiplatform implementation can be checked in skiko Managed
class (the main logic is in platform source sets)
We can introduce separate standalone module for such an API, like kotlinx-io-resource
(name TBD) and make core
depend on it and use it for checking leaks (implementation details TBD).
For reference:
- new JDK Panama API also uses
Cleaner
under the hood forArena
implementation (or even it's possible to do it per segment if needed) - Netty uses
Cleaner
for tracing there ownBuffer
/ByteBuf
pool leaks
Another use case is to just check for such leaks only in tests, to ensure, that library (or app) uses Buffer
s correctly and fully consumes them to reduce GC pressure. I believe it could be done in a single task - so not only to log
that something is leaked, but also to explicitly check, that there is no leaked memory (even if it will be GC-ed).
Note: this is not something, that should be available from start, but should be available some day, so Im just creating this issue pro-actively :)