RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v3]

[liach]

On Fri, 21 Jan 2022 23:51:02 GMT, liach <duke at openjdk.java.net> wrote:

>> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses.
>> 
>> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/)
>
> liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8261407-reflectionfactory
>  - Merge branch '8261407-reflectionfactory'
>  - Just use volatile directly to ensure read order
>  - 8261407: ReflectionFactory.checkInitted() is not thread-safe

The addition of `@Stable` seems safe. Here's a comparison for the `checkInitted` method under current patch (volatile) and the stable annotation (stable): https://gist.github.com/b6a1090872e686f31595bcd778893e82
Under this test setup: https://gist.github.com/96018d7dcaa07763d1c205017a9bd99f
Can any professional review the comparison above, as I am not as acquainted to C assembly and VM internals to confirm there is indeed no unintended side effects?

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

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