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

[David Holmes]

On Mon, 20 Feb 2023 17:03:33 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> We don't fear calling the factory twice for benign races, as the distinct constructor factory instances are behaviorally the same.
>> 
>> The true issue lies in the double getfield operations: Java memory model doesn't require the second read to happen-after a write reflected in the first read, so return this.genericInfo may return null while this.genericInfo == null evaluates to false, in case genericInfo is initialized lazily by another thread. See https://bugs.openjdk.org/browse/JDK-8261404
>
> Hi @liach,
> 
> I think @dholmes-ora is worried about the fields in the object being returned by the getGenericInfo() method and similar. In above case this means fields in class ConstructorRepository.
> I checked it and the entire hierarchy based on sun.reflect.generics.repository.AbstractRepository with subclasses including ConstructorRepository is modeled such that all fields are either:
> - volatile and lazily initialized; or
> - final and initialized in constructor
> 
> Such objects may be published via data race and still be seen consistent on the accepting side.

Thanks @plevart  that was exactly my concern but I didn't have time to check whether the returned object could be safely published regardless of any race condition. Is it specified that way, or just a fortuitous occurrence?

I would also be concerned about the guarantee of idempotency from the factory method - I hope its requirements in that area are clearly documented.

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

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