Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TIFFDeflator blocks GC due to long-held native critical section #292

Open
davispw opened this issue Sep 14, 2023 · 2 comments
Open

TIFFDeflator blocks GC due to long-held native critical section #292

davispw opened this issue Sep 14, 2023 · 2 comments

Comments

@davispw
Copy link

davispw commented Sep 14, 2023

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/)

It looks like this would also be an issue with libdeflate-java: see compressor.c and LibdeflateCompressor.java.

@davispw
Copy link
Author

davispw commented Sep 14, 2023

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.

@aaime
Copy link
Member

aaime commented Oct 18, 2023

Did you check if there are performance side effects of using the stream-based approach, rather than working against a preallocated chunk?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants