You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 over ReferenceQueue
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 for Arena implementation (or even it's possible to do it per segment if needed)
Netty uses Cleaner for tracing there own Buffer/ByteBuf pool leaks
Another use case is to just check for such leaks only in tests, to ensure, that library (or app) uses Buffers 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 :)
The text was updated successfully, but these errors were encountered:
On current moment if we will not read
Buffer
fully we will have a leak of underlyingSegment
(or even multiple segments). While for nowSegment
has underlyingByteArray
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 somewhereCPointer
viamalloc
) 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.:
Cleaner
(JDK 9+) or we can implement it overReferenceQueue
createCleaner(ref) { ... }
.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 makecore
depend on it and use it for checking leaks (implementation details TBD).For reference:
Cleaner
under the hood forArena
implementation (or even it's possible to do it per segment if needed)Cleaner
for tracing there ownBuffer
/ByteBuf
pool leaksAnother 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 tolog
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 :)
The text was updated successfully, but these errors were encountered: