RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]

[Valerie Peng]

On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie <ogillespie at openjdk.org> 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 in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - 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 the hot path, so I believe efficiency here is important.
>
> 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

I still prefer class literals as it's cleaner and more straight forward than the pre-existing approach. Why having two fields when one is enough. In most if not all aspects, class literals seems a better solution... Backport should be doable as the scope of change is limited.

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1919737803