Is SharedSecrets thread-safe?

[Claes Redestad]

All the shared secrets are injected as a side effect of loading the
class the getter ensures is initialized - which should provide the
necessary constraints to ensure there is no way for a reordering to
happen where the access object returned can be observed to be null.

E.g.

     if (javaSecuritySignatureAccess == null) {
         ensureClassInitialized(Signature.class);
     }
     return javaSecuritySignatureAccess;

Signature.java:

     static {
         SharedSecrets.setJavaSecuritySignatureAccess(...);
     }

/Claes

On 2020-12-29 14:55, Johannes Kuhn wrote:
> Depends on what `initialize()` is.
> 
> If it (at least) reads a volatile field, then the compiler can't reorder 
> the second read before the first.
> 
> - Johannes
> 
> On 29-Dec-20 14:42, some-java-user-99206970363698485155 at vodafonemail.de 
> wrote:
>> Hello,
>> the class `jdk.internal.access.SharedSecrets` provides getter methods 
>> which all look similar to this:
>> ```
>> if (static_field == null) {
>>    initialize();
>> }
>> return static_field;
>> ```
>>
>> However, neither the static fields are `volatile` nor are the getter 
>> methods synchronized. So if my
>> understanding of the Java Memory Model is correct, the compiler is 
>> free to reorder the two static
>> field reads. So it is in theory possible that the first read yields a 
>> non-`null` value, but the
>> second read yields a `null` value which leads to incorrect behavior 
>> (for further reading [1]).
>>
>> It is probably rather unlikely that this actually happens because 
>> `SharedSecrets` is in most cases
>> accessed from static initializers (which are only run once) and 
>> because not many classes access the
>> same `SharedSecrets` fields.
>>
>> Is this analysis correct or did I forget to consider parts of the 
>> Memory Model logic, or is there
>> some JVM magic I am missing?
>>
>> Kind regards
>>
>> [1] 
>> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-benign-is-resilient 
>>
>>