RFR: 8276660: Scalability bottleneck in java.security.Provider.getService() [v2]

Valerie Peng valeriep at openjdk.java.net
Tue Nov 30 02:44:06 UTC 2021


On Tue, 23 Nov 2021 15:02:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use pattern matching with instanceof operator.
>
> src/java.base/share/classes/java/security/Provider.java line 832:
> 
>> 830:     // NOTE: may need extra mechanism for providers to indicate their
>> 831:     // preferred ordering of SecureRandom algorithms since registration
>> 832:     // ordering info is lost once serialized
> 
> Why is the ordering info lost once serialized? Weren't all entries re-added again in their original order?

The serialized bytes are just the mappings, i.e. key + value pairs. There are no ordering info associated with the key + value pair. IIRC, the particular thing about SecureRandom is that the first registration of SecureRandom is deemed to be the most preferred. However, if given only the serialized bytes, the entries are added based on the resulting order stored by the parent class, not necessarily the ordering of the initial insertion/add calls.

> src/java.base/share/classes/java/security/Provider.java line 901:
> 
>> 899:             legacyChanged = true;
>> 900:         }
>> 901:         return true;
> 
> Better put this "return" line into the else block.

Sure.

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

PR: https://git.openjdk.java.net/jdk/pull/6513


More information about the security-dev mailing list