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.fra...@oracle.com> wrote: > >> On 24 Nov 2014, at 16:36, Peter Levart <peter.lev...@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
