RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v6]

[Sergey Bylokhov]

On Mon, 9 Jan 2023 18:38:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Please clarify that, if the field is updated on one thread under synchronized block, why we will read the correct "currentKeyID" here on another thread if no synchronization is used in this place?
>
>> Please clarify that, if the field is updated on one thread under synchronized block, why we will read the correct "currentKeyID" here on another thread if no synchronization is used in this place?
> 
> I only said that if another thread reads the new value of `currentKeyID`, the corresponding key will already be in the `keyHashMap` because that happened before updating `currentKeyID`. If another thread will read the old value of `currentKeyID` that also will be no problem as discussed before in this PR.

So it is possible to have a kind of race here, which is solved by the "synchronized" block below? - If one thread will update the `currentKeyID` and later when other threads will ask for the new key, they might get the old expired key, and to get the new one all those threads have to enter the "synchronized"  block.

Not sure if is it worth it to skip the volatile keyword or not to get some perf here. But if we cared about performance so much and skip volatile then why we cannot get rid of the `currentKeyID' completely and store the currentkey directly, to skip the map-lookup on a hotpath? The `currentKeyID` will be the id of the current key. The map will contain only expired keys.

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

PR: https://git.openjdk.org/jdk/pull/11590