RFR: 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe [v2]

[liach]

On Wed, 15 Mar 2023 02:37:05 GMT, liach <duke at openjdk.org> wrote:

>> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
>
> 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:
> 
>  - Make the repositories volatile like in Class
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into generic-info-thread-safe
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into generic-info-thread-safe
>  - 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

I've updated the fields to be volatile.

> > I would also be concerned about the guarantee of idempotency from the factory method - I hope its requirements in that area are clearly documented.
> 
> The spec for the getGenericXXX methods are "Return a" rather than "Return the" so there shouldn't be any expectation on identity. The question about idempotency might be worth checking into as the underlying factory for reflective generic type objects does interact with the defining class loader.

These objects should always be resolving types with the class loader of the declaring class in [CoreReflectionsFctory::getDeclsLoader](https://github.com/openjdk/jdk/blob/065d3e0d58c96b8a84f3c02bb8704fab6459eaa7/src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java#L61), so the resolved Class instances should be always the same. As far as I see, Type instances are otherwise compared by equals instead of identity, so returning distinct but equal type instances should be safe.

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

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