RFR: 8330108: Increase CipherInputStream buffer size

[Oli Gillespie]

On Mon, 15 Apr 2024 19:34:18 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Can you provide memory usage difference between the current and your suggested change with `-prof gc`?  With many of these situations, it's a balance between memory usage and performance.
>
>> @ascarpino here's the `-prof gc` results. Allocations per operation are very similar except for encryption for the smaller data size which is significantly increased with the higher buffer size. I think it's a good tradeoff.
>> 
> 
> Benchmark                      (dataSize)        Score        Error   Units
> == buffer size = 512 (current) ==
> encrypt:gc.alloc.rate            16384         1991.982 +-   162.581  MB/sec
> encrypt:gc.alloc.rate          1048576         1062.342 +-     4.239  MB/sec
> == buffer size = 8192 (this PR) ==
> encrypt:gc.alloc.rate            16384         4066.224 +-   338.790  MB/sec
> encrypt:gc.alloc.rate          1048576         1615.335 +-    36.420  MB/sec
> 
> 
> @olivergillespie Thanks for the data.  Any theories why encryption memory usage jumped up when the decryption are very close?

@ascarpino 

We should look at the normalized (per op) allocation data, not the total values, because otherwise higher throughput makes the allocation rate look worse, when really it's just doing more operations per time.
Looking at the normalized encrypt results, both the small and large payload size add around 23KB per op. 


Benchmark                      (dataSize)        Score        Error   Units
== buffer size = 512 (current) ==
encrypt:gc.alloc.rate.norm       16384        35584.003 +-     0.001    B/op
encrypt:gc.alloc.rate.norm     1048576      1067786.612 +-   329.146    B/op
== buffer size = 8192 (this PR) ==
encrypt:gc.alloc.rate.norm       16384        58624.003 +-     0.001    B/op
encrypt:gc.alloc.rate.norm     1048576      1090816.131 +-     0.003    B/op


Profiling data shows that this comes from:

1. Allocating `ibuffer` in `CipherInputStream.<init>`
2. Expanding `obuffer` in `CipherInputStream.ensureCapacity`
3. Allocating buffer in `GaloisCounterMode$GCMEncrypt.doUpdate`

Each is a single allocation of the increased buffer size, so an increase of 8192-512 bytes, x3, which accounts perfectly for the +23KB observed. These are done once, so they have less relative impact on larger data sizes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18763#issuecomment-2058833945