RFR: 8065172: More core reflection final and volatile annotations

[Martin Buchholz]

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/

On Mon, Nov 24, 2014 at 12:25 PM, Joel Borggrén-Franck
<joel.franck at oracle.com> wrote:
>
>> On 24 Nov 2014, at 16:36, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> On 11/24/2014 04:04 PM, Joel Borggrén-Franck wrote:
>>>
>>> Btw, has anyone seen the assert for upper/lower bounds == null fail in the wild?
>>>
>>> private FieldTypeSignature[] getUpperBoundASTs() {
>>>     // check that upper bounds were not evaluated yet
>>>     assert(upperBounds == null);
>>>     return upperBoundASTs;
>>> }
>>>
>>> shouldn’t it happen once in a while:
>>>
>>> public Type[] getUpperBounds() {
>>>     // lazily initialize bounds if necessary
>>>     if (upperBounds == null) {
>>>
>>>      // thread gets preempted here, other thread completes init, upperBounds are != null
>>>
>>>         FieldTypeSignature[] fts = getUpperBoundASTs(); // get AST
>>>
>>>
>>> Is the current code only working because most run without esa?
>>
>> ...or because races that would trigger this are very rare, since two consecutive "loads" of upperBounds happen one after the other, so the 2nd load and check might even be optimized away.
>>
>
> I was thinking along the lines of warming up in the interpreter + large search engine infrastructure scale.
>
> cheers
> /Joel