-
Bug
-
Resolution: Unresolved
-
P3
-
None
I have identified an issue with GZIPOutputStream.
For each instance of GZIPOutputStream, the zlib allocates about 250kb of native memory buffers.
This memory is not trackable by any java tools (e.g. NMT) and it's freed once GZIPOutputStream object is destroyed.
GC is not aware of that native memory as well.
So this can lead to the following situation:
lots of small (small in java heap) GZIPOutputStream objects doesn't produce any pressure on GC, hence GC is not in hurry to clean them up. but due to native memory allocations in zlib the system is having issues doing new native memory allocations resulting in OOM crashes of java.
The workaround is explicit GC (for example using jcmd).
So far I can't see any easy solution to that issue.
For each instance of GZIPOutputStream, the zlib allocates about 250kb of native memory buffers.
This memory is not trackable by any java tools (e.g. NMT) and it's freed once GZIPOutputStream object is destroyed.
GC is not aware of that native memory as well.
So this can lead to the following situation:
lots of small (small in java heap) GZIPOutputStream objects doesn't produce any pressure on GC, hence GC is not in hurry to clean them up. but due to native memory allocations in zlib the system is having issues doing new native memory allocations resulting in OOM crashes of java.
The workaround is explicit GC (for example using jcmd).
So far I can't see any easy solution to that issue.