Skip to content

Leak tracing mechanism #144

Open
Open
@whyoleg

Description

@whyoleg

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 :)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions