RFR 8229958: Provider.getService() scalability issue for legacy algorithms and message digests

Yang, Letu letuyang at amazon.com
Wed Aug 21 07:32:41 UTC 2019


Hi Ivan,

You are right! I should make legacyChanged volatile as well. I will get it tested it with tier-1 and get back to you tomorrow.

Letu

On 8/21/19, 12:08 AM, "Ivan Gerasimov" <ivan.gerasimov at oracle.com> wrote:

    Hi Letu!
    
    The fix introduces a read of non-volatile variable legacyChanged outside 
    of synchronized block, which is not guaranteed to produce consistent 
    results.
    
    (Please note that in the mentioned fix for JDK-7092821 the variable 
    servicesChanged was made volatile, so that it could be accessed outside 
    the synchronized blocks.)
    
    With kind regards,
    
    Ivan
    
    On 8/20/19 10:18 PM, Yang, Letu wrote:
    > Hi,
    >
    > Please review the fix of https://bugs.openjdk.java.net/browse/JDK-8229958 where I made the change to allow majority of calls don't have to acquire the locks when checking the availability of the Provider object. Similar effort had been made in fixing https://bugs.openjdk.java.net/browse/JDK-7092821 , but it only helped the calls for new encryption algorithms. Xin had helped me to upload the CR: https://cr.openjdk.java.net/~xliu/8229958/webrev/ .
    >
    > I had run tier-1 tests, and also a JMH test to confirm its performance improvement. We have also had it running in a load test environment of an application for a couple of days, and the improvement was confirmed as well.
    >
    > Best regards,
    > Letu
    >
    -- 
    With kind regards,
    Ivan Gerasimov
    
    



More information about the core-libs-dev mailing list