RFR: 8065172: More core reflection final and volatile annotations
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.
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