mailtoboggavarapu-coder commented on PR #19861: URL: https://github.com/apache/hudi/pull/19861#issuecomment-5611987315
Hi @voonhous, thanks for the question. This is a static analysis finding rather than a runtime crash — the leak is structural. `InflaterInputStream` wraps a `java.util.zip.Inflater` internally, and `Inflater` allocates native (off-heap) zlib memory via JNI (`inflateInit` in native code). Releasing it requires an explicit call to `Inflater.end()`, which is only invoked through `InflaterInputStream.close()`. Without that, the native memory isn't freed until the GC eventually runs the finalizer — which is non-deterministic and increasingly unreliable in modern JVMs as finalizers are deprecated (JEP 421). To observe it in practice, you can run a tight loop calling `decompress()` on a non-trivial compressed payload while monitoring native memory with: ``` -XX:NativeMemoryTracking=summary jcmd <pid> VM.native_memory summary.diff ``` The "Other" segment in native memory tracking will grow unbounded without the fix. With the fix applied, it stays flat across the same number of calls. The code-level evidence is clear: - The `Inflater` Javadoc explicitly states: *"It is also possible to free the decompressor's native resource by explicitly calling the end method"* - The sibling `compress()` method in this same class already wraps `DeflaterOutputStream` in try-with-resources — the asymmetry between the two methods is what surfaced this - `ByteArrayInputStream` (the inner stream) holds no native resources, so the leak is specifically from the `InflaterInputStream` wrapper holding the `Inflater` Happy to raise a JIRA issue with environment details if that helps track it formally. Let me know. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
