RFR 8173083: VarHandle usages in LockSupport and ThreadLocalRandom result in circularity issues

[Martin Buchholz]

Seems OK.  It would be nice to somehow get more confidence we don't have
remaining circularities.  I agree a specialized concurrent hash table to
replace ConcurrentHashMap might help.

I was surprised to see below a change in parentheses that seems to change
the behavior.

     final long nextSeed() {
         Thread t; long r; // read and update per-thread seed
-        SEED.set(t = Thread.currentThread(),
-                 (r = (long) SEED.get(t)) + GAMMA);
+        U.putLong(t = Thread.currentThread(), SEED,
+                  r = U.getLong(t, SEED) + GAMMA);
         return r;
     }



On Thu, Jan 19, 2017 at 6:52 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> Unfortunately the switch from Unsafe to VarHandle in LockSupport and
> ThreadLocalRandom caused some circularity issues (similar to those for
> AtomicInteger) that have shown up in continuous testing (but not when i
> tested explicitly using the infrastructure).
>
> The main problem is MethodType leverages ConcurrentHashMap which under
> certain conditions uses TLR [*].
>
> We know we want to replace CHM usage in MethodType with an alternative
> Peter created, which i think we can pursue post 9 and break the circularity.
>
> This patch reverts the back to Unsafe usage:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8173083-vh-
> to-unsafe-ls-tlr/webrev/index.html
>
> I did not revert the changes to Striped64 and ForkJoinWorkerThread.
>
> Thanks,
> Paul.
>
> [*]
> 1) The clinit of LockSupport creates a VarHandle;
>
> 2) a VarHandle creates MethodTypes;
>
> 3) that are stored in a CHM;
>
> 4) which on occasion uses TLR
>
> 5) that uses a VarHandle whose VarForm is being initalized in 1)
>
>
>