[concurrency-interest] ThreadLocalRandom clinit troubles

Peter Firmstone peter.firmstone at zeus.net.au
Mon Jun 30 06:02:30 EDT 2014


Hi Peter,

There are a number of bottlenecks throughout the security 
infrastructure, we have reimplemented it as follows to avoid them and 
have also addressed some long standing issues:

SecurityManager - cache previously checked AccessControlContext's  
(using a cache structure based on Cliff Click's non blocking hash map 
and Doug Lee's concurrent skip list set), to avoid repeately calling the 
policy provider (for example, you have numerous tasks in an 
ExecutorService and each has an identical AccessControlContext and all 
tasks cause a SocketPermission check).

Policy provider - replaced the built in Java policy provider.  The built 
in Java Policy provider will hold a lock while making DNS calls, 
bringing all permission checks to a grinding halt.  It will also hold 
locks while accessing the file system.

To avoid making DNS calls we've implemented our own policy provider, 
originated from Apache Harmony, but modified to use non blocking 
immutability.  It creates PermissionCollection's on demand, they're not 
shared among threads and are ordered in the most favourable order for a 
fast result.  It also supports undocumented Java file policy provider 
functionality.  Because Permission objects are immutable but lazily 
initialized, we call getActions() to ensure their state is completely 
initialized prior to publication.

The policy provider uses a strictly RFC 3986 compliant immutable URI 
class, it performs bit shift operations on ASCII strings during 
normalisation and is used by the policy provider to avoid making DNS 
calls when checking CodeBase policy file permissions.

As a result, the cost of the security infrastructure is less than 1% of 
CPU load during stress tests.

This is part of the Apache River project, JERI (Jini Extensible Remote 
Invocation) performs remote method invocations as tasks running in a 
system threadpool, each task executes concurrently on any exported service.

SecureClassLoader uses CodeSource's as keys in a Map, CodeSource uses 
URL in equals() and hashCode(), so we also have a RFC3986 compliant 
URLClassLoader to avoid making unnecessary DNS calls in SecureClassLoader.

Rather than rely on an external untrusted DNS to determine the identity 
of CodeSource's, we use RFC 3986 compliant normalisation, without making 
DNS calls.  URL's still make DNS calls when retrieving a URL.  The 
difference is, two different host names that previously resolved to an 
identical IP address will no longer be equal, but now we can use dynamic 
dns addresses and fail over replication for domain names that use a 
range of IP addresses to answer for one domain address.  Standard Java 
SecureClassLoader behaviour can be had by setting a system property

This also reduces or avoids calls to the built in java NameServiceProvider.

If this code was in the JVM libraries, we wouldn't need it in our project.

This code is freely available.

Regards,

Peter.

On 29/06/2014 7:29 PM, Peter Levart wrote:
>
> On 06/29/2014 03:53 AM, Peter Firmstone wrote:
>>
>> It does look like a good solution.
>>
>> You might wonder why we still need a custom SecurityManager?
>>
>> Concurrency.
>>
>> The ageing java security infrastructure is a huge bottleneck for 
>> multithreaded code.
>>
>> Regards,
>>
>> Peter.
>>
>
> Hi Peter,
>
> If you could identify the most critical bottleneck(s) of default 
> SecurityManager, there might be a way to fix them...
>
> Regards, Peter
>
>>
>>
>>
>>
>>
>>
>>
>> > Message: 1
>> > Date: Thu, 26 Jun 2014 19:10:22 -0400
>> > From: Doug Lea <dl at cs.oswego.edu <mailto:dl at cs.oswego.edu>>
>> > To: Peter Levart <peter.levart at gmail.com 
>> <mailto:peter.levart at gmail.com>>
>> > Cc: core-libs-dev <core-libs-dev at openjdk.java.net 
>> <mailto:core-libs-dev at openjdk.java.net>>,    OpenJDK
>> > <security-dev at openjdk.java.net 
>> <mailto:security-dev at openjdk.java.net>>,    concurrency-interest
>> > <concurrency-interest at cs.oswego.edu 
>> <mailto:concurrency-interest at cs.oswego.edu>>
>> > Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
>> > Message-ID: <53ACA85E.2030407 at cs.oswego.edu 
>> <mailto:53ACA85E.2030407 at cs.oswego.edu>>
>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >
>> >
>> > Peter: Thanks very much for attacking the shocking impact/complexity
>> > of getting a few seed bits.
>> >
>> > On 06/25/2014 01:41 PM, Peter Levart wrote:
>> > >
>> > > Peeking around in the sun.security.provider package, I found there
>> > > already is a minimal internal infrastructure for obtaining random
>> > > seed. It's encapsulated in package-private abstract class
>> > > sun.security.provider.SeedGenerator with 4 implementations. It turns
>> > > out that, besides Java-only fall-back implementation called
>> > > ThreadedSeedGenerator and generic URLSeedGenerator, there are 
>> also two
>> > > implementations of NativeSeedGenerator (one for UNIX-es which is 
>> just
>> > > an extension of URLSeedGenerator and the other for Windows which 
>> uses
>> > > MS CryptoAPI). I made a few tweaks that allow this 
>> sub-infrastructure
>> > > to be used directly in ThreadLocalRandom and SplittableRandom:
>> > >
>> > > 
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/> 
>>
>> > >
>> >
>> > This seems to be the best idea yet, assuming that people are OK
>> > with the changes to sun.security.provider.SeedGenerator and
>> > NativeSeedGenerator.java
>> >
>> > -Doug
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list