RFR: 8064846: Lazy-init thread safety problems in core reflection

[Martin Buchholz]

On Mon, Nov 17, 2014 at 1:15 PM, Joel Borggrén-Franck
<joel.franck at oracle.com> wrote:

> IIRC The jdk contains 4 subtypes of Type. I think Peter is right here, but on the other hand aren't uncontended volatile reads kind of cheap? Unless someone comes back with reports of measurable slowdown I think safe publication is ok. We can always revisit this later.

I am OK with lazy non-volatile publication of immutable objects as
long as we have a (reflective) test that proves we've kept all
implementations correct.

>> For safety's sake, I'd also like us to use CAS with our lazy-init
>> fields.  Perhaps use Atomic field updaters throughout the reflection
>> codebase, for jdk9.
>>
>
> What is the problem you would be solving?

It's a safety thing. It's "probably" OK if a very rare race causes 2
invocations of an API to return different objects when normally the
same object is returned.  But it's simply safer to not do so, by
CAS-ing from null to the newly computed value instead of
unconditionally storing the new value.

As we've seen, reflection is under-maintained and under-tested.