Hi Martin, Thanks, i will review carefully this week and do the necessary paper work for the FC exception required for API changes and the CCC.
I found the cause of the test failure with java/util/Locale/Bug4152725.java. The constructor of VarHandle.AccessMode has some assert statements. These asserts were getting executed and causing locale-based classes to get loaded early in the startup process. I don’t yet know the why the test fails but i am guessing some form of circular dependency in charset related code results in a null value that obliterates any non-default locale data. I will replace the asserts with tests: https://bugs.openjdk.java.net/browse/JDK-8160439 <https://bugs.openjdk.java.net/browse/JDK-8160439> Paul. > On 27 Jun 2016, at 21:38, Martin Buchholz <marti...@google.com> wrote: > > jsr166 has been pervasively modified to use VarHandles, but there are some > other pending changes (that cannot be cleanly separated from VarHandle > conversion). We expect this to be the last feature integration for jdk9. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > <http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/> > > We're asking Paul to do most of the review work here, as owner of VarHandles > JEP and as Oracle employee. > We need approval for API changes in > > https://bugs.openjdk.java.net/browse/JDK-8157523 > <https://bugs.openjdk.java.net/browse/JDK-8157523> > Various improvements to ForkJoin/SubmissionPublisher code > > https://bugs.openjdk.java.net/browse/JDK-8080603 > <https://bugs.openjdk.java.net/browse/JDK-8080603> > Replace Unsafe with VarHandle in java.util.concurrent classes > > There is currently a VarHandle bootstrap problem with > ThreadLocal/AtomicInteger that causes > java/util/Locale/Bug4152725.java > to fail. Again I'm hoping that Paul will figure out what to do. In the past > rearranging the order of operations in <clinit> has worked for similar > problems. It's not surprising we have problems, since j.u.c. needs > VarHandles initialized to do work, and j.l.invoke needs j.u.c. (notably > AtomicInteger and ConcurrentHashMap) to do work. Maybe we need some very > low-level concurrency infrastructure that does not use VarHandles, only for > bootstrap?
