[1/5] RFR (L) 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck

[David Alvarez]

I understand.

This has been included into 8u271. Is the idea to wait or will this 
change be left out permanently of openjdk8u?

David

On 2020-09-22 20:29, Andrew Hughes wrote:
> On 16:48 Tue 22 Sep     , David Alvarez wrote:
>> Hi,
>>
>> I've been working on a set of patches for 8u282. In total, there are 6
>> patches:
>>
>> * [1] 7092821: java.security.Provider.getService() is synchronized and
>> became scalability bottleneck
>> - [2] 8228613: java.security.Provider#getServices order is no longer
>> deterministic
>> - [3] 8246613: Choose the default SecureRandom algo based on registration
>> ordering
>> - [4] 8248505: Unexpected NoSuchAlgorithmException when using secure random
>> impl from BCFIPS provider
>> - [5] 8231387: java.security.Provider.getService returns random result due
>> to race condition with mutating methods in the same class
>> - [6] 8250787: Provider.put no longer registering aliases in FIPS env
>>
>> All these patches are related and should be pushed together. [1] to [5] are
>> backports from tip. For [6] there is no equivalent on tip, but it is the
>> same patch I have submitted for 11.0.9. Only one of them is a clean
>> backport, [5], so the rest will be requiring RFRs. Given that [1] is fairly
>> big, and that the rest don't really make sense without it, I will wait to
>> send the rest until it gets approved.
>>
>> The patch changes how Provider.getService works. It also changes how all
>> default services are registered to make use of putService instead of the old
>> put, so there are plenty of changes.
>>
>> David
>> --
>> [1] https://bugs.openjdk.java.net/browse/JDK-7092821
>> [2] https://bugs.openjdk.java.net/browse/JDK-8228613
>> [3] https://bugs.openjdk.java.net/browse/JDK-8246613
>> [4] https://bugs.openjdk.java.net/browse/JDK-8248505
>> [5] https://bugs.openjdk.java.net/browse/JDK-8231387
>> [6] https://bugs.openjdk.java.net/browse/JDK-8250787
>>
>>
> 
> I'm familiar with this from 11u. I think it's too risky for 8u.
> 
> Thanks,
>