JDK-8160710 : Enable Thread to grant VarHandle field access to ThreadLocalRandom/Striped64
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-07-01
  • Updated: 2017-02-09
  • Resolved: 2017-01-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 9
10Fixed 9 b154Fixed
Related Reports
Relates :  
JDK-8169069 - Module system implementation refresh (11/2016)
Description
The work to replace Unsafe with VarHandles with JDK-8080603 has resulted in good consolidation of the remaining Unsafe dependencies, specifically those where Thread's fields need to be accessed by ThreadLocalRandom and Striped64.

Aa Peter Levert shows it's possible to leverage SharedSecrets:

http://cr.openjdk.java.net/~plevart/misc/JavaLangThreadAccess/webrev.Striped64/

which exposes VarHandles to the Thread's appropriate fields. AN alternative is to expose Thread's Lookup in controlled manner to specific classes.

A concern is this approach may cause start-up circularities so should be investigated and tested carefully.
Comments
MethodHandles.privateLookupIn can be utilized by ThreadLocalRandom etc to obtain access to Thread's fields.
05-12-2016
Ash shown here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042227.html ...there are no initialization concerns with SharedSecrets approach when applied to Striped64 class. There are however initialization concerns if this is applied to ThreadLocalRandom because TLR is used from ConcurrentHashMap which can't yet be migrated to VarHandle(s) because it is used in java.lang.invoke infrastructure. But that's a separate issue. An alternative, as Paul Sandoz says, is to "expose Thread's Lookup in controlled manner to specific classes". Here's a possible way to do that with an internal @Friends annotation: http://cr.openjdk.java.net/~plevart/misc/Friends/webrev.Striped64/
21-07-2016