On Tue, 28 Nov 2023 08:34:21 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
>> The second sentence says what the optimizations is. > > well I was under the impression that the bulk of the optimization comes from > using modified `engineGetOutputSize` that does not allocate when isUpdate== > true and decrypting. That's not documented anywhere. It used the `engineGetOutputSize` from ChaCha20Cipher before the change. The biggest gain no doing unnecessary copying for direct bytebuffers. For a decrypt op, it would copy the bytebuffer into and array, then copy the array into the internal buffer. I try to minimize that by doing only one copy, bytebuffer -> internal buffer. >> I don't see a testing issue there, but that's better memory usage. I >> probably copied this code over from AES/GCM where it's blocksized data and >> `in` and `out` could have been different sizes. But CC20 can use this >> optimization because it's a streaming cipher. > > I was talking about the second line: > > doUpdate(in, 0, in.length, out, out.length); > > this tells the doUpdate operation to start writing to `out` at `out.length`; > that should have triggered an exception in testing. Ah yes.. that's a mistake ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1412631516 PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1412493845
