Ktor 2.0 HttpClient connection pool memory leak fix: Is the CIO engine fully leak‑free after 2.0.1?

Goal

Determine whether the CIO engine’s connection pool in Ktor 2.0.1 eliminates all coroutine context and ByteBuffer leaks observed in 2.0.0 under high‑concurrency workloads.

Constraints

Use the default CIO engine, issue thousands of short‑lived requests, and monitor JVM heap for retained coroutine contexts and pooled ByteBuffers. The test environment must not use experimental plugins or custom engine configurations that could mask leaks.

Unresolved Questions

1. Does 2.0.1 ensure that every coroutine context released by the connection pool is fully garbage‑collectable, even when requests are aborted or time‑out?
2. Are there documented edge cases—such as large payloads or keep‑alive timeouts—where ByteBuffer instances remain referenced after the pool slot is marked free?
3. How does the introduction of the suspend‑function HttpClient.close() in 2.3.x affect the cleanup semantics for connections that were still in use when the client is closed?