Investigating a OOM found with load testing on JPEG compressed TIFF images as source which was happening only when the TurboJPEG reader was enabled, I've found the following:
The actual source of the memory consumption were the usual WritableRenderedImageAdapter object wrapping BufferedImage, read in immediate mode and placed as sources of the JAI chain (this happens even without the TurboJPEG reader, unfortunately every PlanarImage subclass inherits a finalize method)
The finalizer queue was getting clogged with tons of small TJDecompressor object. Analysis showed that for each tile read from the TIFF, two instances of TJDecompressor were created and immediately destroyed, which, with the single request under test, caused 96 of these object to be created and immediately put in the finalizer queue.
The "fix" is to hold onto a TJDecompressor (the image reader is not meant to be thread safe) and reuse it for the life of the reader instead, reducing the load factor on the finalizer queue by a factor of 100.
aaime
commented
5 years ago
Investigating a OOM found with load testing on JPEG compressed TIFF images as source which was happening only when the TurboJPEG reader was enabled, I've found the following:
The "fix" is to hold onto a TJDecompressor (the image reader is not meant to be thread safe) and reuse it for the life of the reader instead, reducing the load factor on the finalizer queue by a factor of 100.