RFR 8160710: Enable Thread to grant VarHandle field access to ThreadLocalRandom/Striped64

Paul Sandoz paul.sandoz at oracle.com
Thu Jan 12 00:48:49 UTC 2017


Thanks.

Here is an update:

  http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/

With changes to inline expressions, remove thread group stuff from TLR, and do the following in InnocuousForkJoinWorkerThread:

 185     static final class InnocuousForkJoinWorkerThread extends ForkJoinWorkerThread {
 186         /** The ThreadGroup for all InnocuousForkJoinWorkerThreads */
 187         private static final ThreadGroup innocuousThreadGroup =
 188                 java.security.AccessController.doPrivileged(
 189                     new java.security.PrivilegedAction<>() {
 190                         public ThreadGroup run() {
 191                             ThreadGroup group = Thread.currentThread().getThreadGroup();
 192                             for (ThreadGroup p; (p = group.getParent()) != null; )
 193                                 group = p;
 194                             return new ThreadGroup(group, "InnocuousForkJoinWorkerThreadGroup");
 195                         }});

Note: the ThreadGroup constructor also performs a security permission check

Paul.

> On 11 Jan 2017, at 16:12, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> On 01/11/2017 06:39 PM, Martin Buchholz wrote:
>> Doug, please try to remember the details of the thread group code.
>> 
> 
>>    >
>>    > The threadgroup creation code that uses cheating has always seemed fishy to me.  The straightforward
>>    >
>>    >     /**
>>    >      * Returns a new group with the system ThreadGroup (the
>>    >      * topmost, parent-less group) as parent.
>>    >      */
>>    >     static final ThreadGroup createThreadGroup(String name) {
>>    >         if (name == null)
>>    >             throw new NullPointerException();
>>    >         ThreadGroup group = Thread.currentThread().getThreadGroup();
>>    >         for (ThreadGroup p; (p = group.getParent()) != null; )
>>    >             group = p;
>>    >         return new ThreadGroup(group, name);
>>    >     }
>>    >
>>    > passes all tests.  That could be wrapped in a doPrivileged, or we could add something more principled to ThreadGroup itself.  I don't know what the motivations are for the threadgroup code.
>>    >
>> 
> 
> There was a some point a problem with using doPrivileged in the
> context of FJP.commonPool initialization, so we went with the
> suggestion of using unsafe.
> 
> And at a different point, we decided to place
> all non-VarHandle-amenable code into TLR so that it could be
> replaced all at once when bootstrap problems were addressed.
> 
> And at a different point (which we hope is Now :-) we can
> replace the unnecessary prior workarounds.
> 
> -Doug
> 
> 
> 



More information about the core-libs-dev mailing list