RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93)

[Jamil Nimeh]

On Thu, 29 Apr 2021 15:58:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Yes, I’ve made a test that calculates total time spent by server to receive "N" connections. Every server handshake is performed in a separate thread
>> The client starts "T" threads. Every thread sends one initial connection and "R-1" renegotiated connections. So, the total number of connections is  "N"="T"*"R"
>> 
>> Results for the original and JDK-8241248 code are almost identical:
>> "T"=10 "R"=100
>> Original OpenJDK: 1140 ms
>> JDK-8241248 code: 1090 ms
>> 
>> "T"=50 "R"=100
>> Original OpenJDK: 1164 ms
>> JDK-8241248 code: 1108 ms
>> 
>> "T"=60 "R"=100
>> Original OpenJDK: 1461 ms
>> JDK-8241248 code: 1579 ms
>> 
>> "T"=70 "R"=100
>> Original OpenJDK: 2058 ms
>> JDK-8241248 code: 1999 ms
>> 
>> "T"=80 "R"=100
>> Original OpenJDK: 2148 ms
>> JDK-8241248 code: 2125 ms
>> 
>> "T"=90 "R"=100
>> Original OpenJDK: 2540 ms
>> JDK-8241248 code: 2514 ms
>> 
>> "T"=90 "R"=100
>> Original OpenJDK: 3011 ms
>> JDK-8241248 code: 3010 ms
>> 
>> I can confirm that the synchronization code works. Without it, I still catch exception from different threads trying to resume the same session from the cache
>
> Thank you for the update.
> 
> I also expect the code easy to read and maintain in the future.  But please go ahead for the integration if you don't want to make the update now.  We could file an enhancement later on.

There were some changes that @ascarpino did for RSA blinding to reduce lock contention within that cache.  It doesn't look like we're running into a hot lock here based on the numbers above, but it might be worth looking at his solution down the road when we move synchronization into the Cache object.

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

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