Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leak tracing mechanism #144

Open
whyoleg opened this issue Jun 22, 2023 · 0 comments
Open

Leak tracing mechanism #144

whyoleg opened this issue Jun 22, 2023 · 0 comments

Comments

@whyoleg
Copy link
Contributor

whyoleg commented Jun 22, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants