On Wed, 8 Dec 2021 00:18:44 GMT, Valerie Peng <valer...@openjdk.org> wrote:
>> It is observed that when running crypto benchmark with large number of
>> threads, a lot of time is spent on the synchronized block inside the
>> Provider.getService() method. The cause for this is that
>> Provider.getService() method first uses the 'serviceMap' field to find the
>> requested service. However, when the requested service is not supported by
>> this provider, e.g. requesting Cipher.RSA from SUN provider, the impl
>> continues to try searching the legacy registrations whose processing is
>> guarded by the "synchronized" keyword. When apps use getInstance() calls
>> without the provider argument, Provider class has to iterate through
>> existing providers trying to find one that supports the requested service.
>>
>> Now that the parent class of Provider no longer synchronizes all of its
>> methods, Provider class should follow suit and de-synchronize its methods.
>> Parsing of the legacy registration is done eagerly (at the time of put(...)
>> calls) instead of lazily (at the time of getService(...) calls). This also
>> makes "legacyStrings" redundant as the registration is parsed and stored
>> directly into "legacyMap".
>>
>> The bug reporter has confirmed that the changes resolve the performance
>> bottleneck and all regression tests pass.
>>
>> Please review and thanks in advance,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updated to address review comments.
src/java.base/share/classes/java/security/Provider.java line 1276:
> 1274: }
> 1275: if (serviceSet == null) {
> 1276: ensureLegacyParsed();
Hi @valeriepeng! I believe that with this change, `getServices()` will return
invalid legacy services. Before we called `ensureLegacyParsed()`, which
eventually called `removeInvalidServices()`. In `getService(String, String)`,
we are now explicitly checking for `isValid()` to keep the old behavior.
Shouldn't we do something similar here as well? Am I missing something or is
this an intended change?
-------------
PR: https://git.openjdk.org/jdk/pull/6513
