RFR: jsr166 jdk9 integration wave 7

[Paul Sandoz]

Hi Peter,

Thanks, that’s interesting. I am uncertain if our 166 fellows will be reluctant or not to pull in a dependency on jdk.internal.misc.SharedSecrets. But i note the A*FUs already have a dependency on jdk.internal.reflect.Reflection.getCallerClass().

I like the laziness aspect, but i have a preference for Thread to grant it’s lookup to TLR and Striped64, a white list if you like. The pro being Thread’s fields are not exposed to all within java.base the con being that TLR and Striped64 must guard that lookup as they would their own.

There is also another use-case here for the A*FUs, which probably less of a priority. What we need is to somehow get the lookup of the caller, perhaps injected as an argument into the caller sensitive method newUpdater methods.

Paul.

> On 30 Jun 2016, at 14:41, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi,
> 
> I noticed that in ThreadLocalRandom and Striped64, Unsafe remains for the sole purpose of accessing 3 fields in java.lang.Thread class. Now that there are VarHandle(s), they could be combined with SharedSecrets to get rid of Unsafe access in those two classes. For example, in Striped64:
> 
>     http://cr.openjdk.java.net/~plevart/misc/JavaLangThreadAccess/webrev.Striped64/
> 
> This has the added benefit that IDE(s) can search for usages of JavaLangThreadAccess.xxx methods to quickly find all the usages. Note that even though Thread is one of primordial classes, obtaining VarHandle(s) for its fields is lazy and works without problems...
> 
> Regards, Peter
> 
> On 06/30/2016 01:20 PM, Martin Buchholz wrote:
>> Webrev regenerated with updates.
>> Lots of rework for the atomic VarHandle specs.
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
>> 
>> In the unlikely case you want the old webrev, it's at
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration.2016-06-29/
>