On Wed, 26 Jan 2022 10:07:01 GMT, Sebastian Stenzel
wrote:
> Related to #411, however it turns out that for unpadded ciphers, there is no
> need to allocate `internalOutput`, if `output` provides sufficient capacity.
>
> For padded ciphers, only the unpadded cleartext is expected
gt; Test summary
> ==
>TEST TOTAL PASS FAIL ERROR
>
>jtreg:test/jdk/com/sun/crypto 141 141 0 0
>
>jtreg:test/jdk/javax/crypto 5656 0 0
>
> ==
Related to #411, however it turns out that for unpadded ciphers, there is no
need to allocate `internalOutput`, if `output` provides sufficient capacity.
For padded ciphers, only the unpadded cleartext is expected to be copied to the
output buffer. In this case, there is no way around the tempor
he old code I believe the if() for
> cipher.save() above that was suppose to include the new byte allocation and
> offset, but got missed.
>
> Feel free to fix it if you like. Let me know if you need something.
>
> Tony
>
> On 1/25/22 12:06 PM, Sebastian Stenzel wrote:
>> H
Hi all,
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.
The line in question ca
