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

[Valerie Peng]

On Tue, 30 Nov 2021 13:59:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> 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.
>
> I see. How about serializing `prngAlgos` as a list?

That's one way to address this particular issue. However, it also breaks the serialization compatibility and we are somewhat bound to having 'prngAlgos' as part of the serialized fields. Since no one reported this as being an issue (yet), I wonder if it's worthwhile to address it this way and break the serialization compatibility. There are other possible approaches such as defining an alias or attribute for default SecureRandom algorithm/impl, so I just add a note here instead of serializing 'prngAlgos'.

>> Do you mean simply wipe out the legacyMap and just do ADD instead of REPLACE?
>
> Yes, since you are simply iterating through all the entries instead of only the changed ones.

Ok, will do.

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

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