> 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 use pattern matching with instanceof operator.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6513/files
  - new: https://git.openjdk.java.net/jdk/pull/6513/files/3124e14c..37dc1d9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6513&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6513&range=00-01

  Stats: 34 lines in 1 file changed: 1 ins; 0 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6513.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6513/head:pull/6513

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

Reply via email to