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

[Joel Borggrén-Franck]

Hi,

> On 14 Nov 2014, at 22:48, Martin Buchholz <martinrb at google.com> wrote:
> 
> On Fri, Nov 14, 2014 at 9:32 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi Martin,
>> 
>> I dont know if you saw https://bugs.openjdk.java.net/browse/JDK-8064517 (a
>> followup to your fix for final fields). It would be best to merge those
>> fixes, what do you think?
> 
> I've deliberately ignored those changes for now, so that this when
> this change goes in, all the jdk releases will have the same fixes
> applied.
> 
> I agree there is more work to do.
> 
>> Otherwise I think that making all lazily initialized fields volatile is not
>> necessary. Since you have made the Type implementations
>> unsafe-publication-tolerable (by making their fields final), the only fields
>> that need to be volatile are those that are used to lazily publish arrays.
>> 
>> Am I right?
> 
> You may be right, but it's risky - it's hard to tell whether every
> single Type implementation has exclusively final fields.  We'd have to
> write yet another test that examines every single Class in the
> bootclasspath to be sure.  (How does one do this in a jigsaw'ed
> world??)

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.

> 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?

> I'm not (yet) claiming to be an OWNER of java/reflect.  Who is the real OWNER?


Define OWNER. Joe I think, but most of the work is done by Mandy, Peter (!) or I depending on where you look.

cheers
/Joel