
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">while playing around with JFR today, I stumbled upon a piece of code that causes a thousands of byte[] allocations. In fact it is responsible for 90% of the memory allocations in my application and causes GC to run without pause during decryption of large files.<br class=""><div class=""><br class=""></div><div class="">The line in question can be found here [1]. The behaviour can be triggered with a simple AES-CTR cipher as in this minimal example [2].</div><div class=""><br class=""></div><div class="">As you can see, the comments in [1] even say that this byte[] _should_ only be allocated if there is insufficient space in the provided output buffer. However some kind of conditional statement is missing.</div><div class=""><br class=""></div><div class="">There used to be a `if (getMode() != GCM_MODE || outputCapacity < estOutSize)`, before GCM has been decoupled from CipherCore. But this line seems wrong to me either.</div><div class=""><br class=""></div><div class="">I guess this should be fixed, as I'm probably not the only one affected by those allocations. I'd be volunteering, unless the behaviour is intended.</div><div class=""><br class=""></div><div class="">Cheers!</div><div class="">Sebastian</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[1] <a href="https://github.com/openjdk/jdk/blob/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752/src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java#L815-L818" class="">https://github.com/openjdk/jdk/blob/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752/src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java#L815-L818</a></div></div><div class="">[2] <a href="https://gist.github.com/overheadhunter/f3969950c0fdbaecaa77c857b2246cc5" class="">https://gist.github.com/overheadhunter/f3969950c0fdbaecaa77c857b2246cc5</a></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>