Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2033654 | 1.4.0 | Zhenghua Li | P3 | Resolved | Fixed | beta |
The zip_util interface has the calls ZIP_Open, ZIP_FindEntry, ZIP_ReadEntry, etc., which access zip files on behalf of the system class loader. These utility functions use the zlib library to read zip files. I believe the hotspot VM uses these functions, as well as the "classic" VM.
The routine responsible for reading in individual zip entries, ZIP_ReadEntry(), uses the 'inflate' portion of the zlib library through a call to InflateFully(). InflateFully calls out to inflateInit2 to initialize the inflater, and inflate() to do the decompression. However, it does not call inflateEnd after this process, and so the zlib library does not release the extra memory it has used. I have observed a memory leak around 40k _per class-file accessed_ out of a compressed zip.
The solution is simple: add inflateEnd() to the error case and the successful completion case of InflateFully(), and the leak goes away.
nedim.fresko@Eng 2000-04-24
The routine responsible for reading in individual zip entries, ZIP_ReadEntry(), uses the 'inflate' portion of the zlib library through a call to InflateFully(). InflateFully calls out to inflateInit2 to initialize the inflater, and inflate() to do the decompression. However, it does not call inflateEnd after this process, and so the zlib library does not release the extra memory it has used. I have observed a memory leak around 40k _per class-file accessed_ out of a compressed zip.
The solution is simple: add inflateEnd() to the error case and the successful completion case of InflateFully(), and the leak goes away.
nedim.fresko@Eng 2000-04-24
- backported by
-
JDK-2033654 Memory leak in classloading due to leaking InflateFully() function
-
- Resolved
-