Hi, > On 14 Nov 2014, at 22:48, Martin Buchholz <marti...@google.com> wrote: > > On Fri, Nov 14, 2014 at 9:32 AM, Peter Levart <peter.lev...@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
