[concurrency-interest] ThreadLocalRandom clinit troubles
peter.firmstone at zeus.net.au
Mon Jun 30 06:02:30 EDT 2014
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.
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?
>> The ageing java security infrastructure is a huge bottleneck for
>> multithreaded code.
> 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
>> > > an extension of URLSeedGenerator and the other for Windows which
>> > > MS CryptoAPI). I made a few tweaks that allow this
>> > > to be used directly in ThreadLocalRandom and SplittableRandom:
>> > >
>> > >
>> > >
>> > 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
More information about the Concurrency-interest