You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TIFFDeflator calls ZipDeflateCompressor in a single chunk with a large output byte[], which makes a single call to Deflater.deflate(), whose native implementation calls GetPrimitiveArrayCritical to pin memory (openjdk source). This suspends GC until compression finishes, which can take some time, especially for larger images. In a busy multithreaded process, if younggen fills up, this can block all JVM memory allocation, which is very bad. (Explanation: https://shipilev.net/jvm/anatomy-quarks/9-jni-critical-gclocker/)
An easy solution would be to use DeflaterOutputStream instead of Deflater, which uses tiny output chunks (and by the way solves #290 and #291, and also avoids an unnecessary jumbo byte[] allocation). Unfortunately the new deflate SPI (#262) is an awkward interface for this.
TIFFDeflator calls ZipDeflateCompressor in a single chunk with a large output
byte[]
, which makes a single call toDeflater.deflate()
, whose native implementation callsGetPrimitiveArrayCritical
to pin memory (openjdk source). This suspends GC until compression finishes, which can take some time, especially for larger images. In a busy multithreaded process, if younggen fills up, this can block all JVM memory allocation, which is very bad. (Explanation: https://shipilev.net/jvm/anatomy-quarks/9-jni-critical-gclocker/)It looks like this would also be an issue with libdeflate-java: see compressor.c and LibdeflateCompressor.java.
The text was updated successfully, but these errors were encountered: