RFR: 8065172: More core reflection final and volatile annotations

Paul Sandoz paul.sandoz at oracle.com
Tue Dec 2 09:49:30 UTC 2014

On Nov 25, 2014, at 3:06 AM, Martin Buchholz <martinrb at google.com> wrote:

> I tried to address all the known problems in sun/reflect (except for
> the performance ones), including the ones in Peter's webrev (although
> it now looks quite different).
> I broke down and switched to using AtomicReferenceFieldUpdaters for
> all lazily initialized operations,
> like I had been thinking of doing.
> For the weird classes where we need to lazily switch the
> implementation of bounds, I store in an Object[] and cas to update.
> Now that we're using atomic updaters, it's hard to have any relaxed
> operations unless we also introduce Unsafe.  My current thinking is
> this code is not performance critical enough to do that sort of
> brittle thing.  Volatile reads are either already very cheap or are
> likely to get cheaper over time.  The code using updaters seems
> robust, efficient, and deadlock free, unlike some other code in the
> JDK.  Using updaters means there will never be an extremely rare bug
> due to different objects being returned from a reflection method.
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/

I am not convinced about the use of CAS. If we can get away with just volatile fields I think the code is simpler. Are you concerned there are cases of identity and mutability?

All other aspects look good.


More information about the core-libs-dev mailing list