On Fri, 12 Apr 2024 15:34:01 GMT, Oli Gillespie wrote:
> Increase buffer size in CipherInputStream from 512 bytes to 8192 bytes.
>
> I have seen applications where this small buffer size significantly reduces
> throughput, and I've even seen applications which use reflection
On Fri, 12 Apr 2024 16:19:56 GMT, Sean Mullan wrote:
> Please don't integrate until a Reviewer from the Security Group has reviewed
> this. Thanks.
@seanjmullan are you okay for me to integrate now?
-
PR Comment: https://git.openjdk.org/jdk/pull/18763#issuecomment-2071793073
On Fri, 12 Apr 2024 15:34:01 GMT, Oli Gillespie wrote:
> Increase buffer size in CipherInputStream from 512 bytes to 8192 bytes.
>
> I have seen applications where this small buffer size significantly reduces
> throughput, and I've even seen applications which use reflection
On Mon, 15 Apr 2024 19:34:18 GMT, Anthony Scarpino
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` r
On Fri, 12 Apr 2024 15:34:01 GMT, Oli Gillespie wrote:
> Increase buffer size in CipherInputStream from 512 bytes to 8192 bytes.
>
> I have seen applications where this small buffer size significantly reduces
> throughput, and I've even seen applications which use reflection
On Fri, 12 Apr 2024 16:49:49 GMT, Anthony Scarpino
wrote:
>> Increase buffer size in CipherInputStream from 512 bytes to 8192 bytes.
>>
>> I have seen applications where this small buffer size significantly reduces
>> throughput, and I've even seen applications which use reflection to modify
Increase buffer size in CipherInputStream from 512 bytes to 8192 bytes.
I have seen applications where this small buffer size significantly reduces
throughput, and I've even seen applications which use reflection to modify the
buffer size to work around the issue.
Using the existing `AESGCMCiph
On Wed, 24 Jan 2024 15:25:28 GMT, Oli Gillespie wrote:
> Avoid expensive `Class.forName` call when constructing Providers such as
> `SecureRandom` which take constructor parameters. This can easily be cached
> in EngineDescription (this cache already existed before, it was removed i
On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie wrote:
> A typical call to `new SecureRandom()` is slowed down by looking for a
> constructor in NativePRNG which takes `java.security.SecureRandomParameters`.
> NativePRNG does not have such a constructor, so the search fails
>
On Tue, 6 Feb 2024 13:52:09 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before,
On Wed, 7 Feb 2024 09:49:10 GMT, Oli Gillespie wrote:
>> A typical call to `new SecureRandom()` is slowed down by looking for a
>> constructor in NativePRNG which takes
>> `java.security.SecureRandomParameters`. NativePRNG does not have such a
>> constructor, so th
On Tue, 6 Feb 2024 18:46:30 GMT, Valerie Peng wrote:
>> Oli Gillespie has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year
>
> src/java.base/unix/classes/sun/security/provider/Nativ
chmark from https://github.com/openjdk/jdk/pull/17559 shows around 80%
> reduction in time taken to create a new SecureRandom with NativePRNG (default
> on my machine).
>
>
> Before
> SecureRandomBench.newSecureRandom avgt 2930 ± 50 ns/op
>
> After
> SecureRandomB
chmark from https://github.com/openjdk/jdk/pull/17559 shows around 80%
> reduction in time taken to create a new SecureRandom with NativePRNG (default
> on my machine).
>
>
> Before
> SecureRandomBench.newSecureRandom avgt 2930 ± 50 ns/op
>
> After
> SecureRandomB
kup - see
> [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>
>
> Before
> newSecureRandom avgt 2930 ± 50 ns/op
>
> After
> newSecureRandom avgt 2400 ± 33 ns/op
>
>
> I have seen multiple real-world applications which call `new SecureRandom()`
&
On Thu, 1 Feb 2024 10:39:27 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before,
On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie wrote:
> A typical call to `new SecureRandom()` is slowed down by looking for a
> constructor in NativePRNG which takes `java.security.SecureRandomParameters`.
> NativePRNG does not have such a constructor, so the search fails
>
chmark from https://github.com/openjdk/jdk/pull/17559 shows around 80%
> reduction in time taken to create a new SecureRandom with NativePRNG (default
> on my machine).
>
>
> Before
> SecureRandomBench.newSecureRandom avgt 2930 ± 50 ns/op
>
> After
> SecureRandomB
On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie wrote:
> A typical call to `new SecureRandom()` is slowed down by looking for a
> constructor in NativePRNG which takes `java.security.SecureRandomParameters`.
> NativePRNG does not have such a constructor, so the search fails
>
On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before,
kup - see
> [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>
>
> Before
> newSecureRandom avgt 2930 ± 50 ns/op
>
> After
> newSecureRandom avgt 2400 ± 33 ns/op
>
>
> I have seen multiple real-world applications which call `new SecureRandom()`
&
On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before,
On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie wrote:
> A typical call to `new SecureRandom()` is slowed down by looking for a
> constructor in NativePRNG which takes `java.security.SecureRandomParameters`.
> NativePRNG does not have such a constructor, so the search fails
>
On Wed, 31 Jan 2024 17:23:42 GMT, Weijun Wang wrote:
> How about just using class literals? There is no need to call
> `Class.forName`, at least not now since they are all inside `java.base`.
Thanks :). That seems sensible if writing from scratch, but that part I'm just
reviving from [JDK-8280
On Wed, 24 Jan 2024 19:50:55 GMT, Chen Liang wrote:
> I see that the existing caller code has a check for `ctorParamClass`. Why
> must we declare `SecureRandomParameters.class` as the `ctorParamClass` for
> these 3 randoms instead of using `null`?
>From [lookup
>code](https://github.com/openj
On Wed, 24 Jan 2024 20:09:12 GMT, Roger Riggs wrote:
>> I don't disagree in principle but it was like this before the revert, and is
>> still like this in 17.
>
> Is volatile really needed? And there is some performance penalty and in
> practice the value will be the same even if recomputed.
S
kup - see
> [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>
>
> Before
> newSecureRandom avgt 2930 ± 50 ns/op
>
> After
> newSecureRandom avgt 2400 ± 33 ns/op
>
>
> I have seen multiple real-world applications which call `new SecureRandom()`
&
On Wed, 24 Jan 2024 17:45:06 GMT, Aleksey Shipilev wrote:
>> Oli Gillespie has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Rename newSecureRandom -> create
>> - Add copyright header to new file
>
A typical call to `new SecureRandom()` is slowed down by looking for a
constructor in NativePRNG which takes `java.security.SecureRandomParameters`.
NativePRNG does not have such a constructor, so the search fails
[here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java
Avoid expensive `Class.forName` call when constructing Providers such as
`SecureRandom` which take constructor parameters. This can easily be cached in
EngineDescription (this cache already existed before, it was removed in
[JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'
30 matches
Mail list logo
