RFR: jsr166 jdk9 integration wave 7

[Paul Sandoz]

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 <martinrb at 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?