Would there be interest in using a Policy provider and SecurityManager
designed for concurrency in Java 9?
Some of the issues experienced and solutions are mentioned below.
http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/org/apache/river/api/security/
Regards,
Peter.
-------- Original Message --------
Subject: Concurrency-interest Digest, Vol 113, Issue 45
Date: Mon, 30 Jun 2014 12:00:01 -0400
From: [email protected]
Reply-To: [email protected]
To: [email protected]
Send Concurrency-interest mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Concurrency-interest digest..."
Today's Topics:
1. Re: ThreadLocalRandom clinit troubles (Peter Firmstone)
2. Re: ThreadLocalRandom clinit troubles (Alan Bateman)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Jun 2014 20:02:30 +1000
From: Peter Firmstone<[email protected]>
To: Peter Levart<[email protected]>
Cc: [email protected]
Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
Message-ID:<[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
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<[email protected]<mailto:[email protected]>>
> To: Peter Levart<[email protected]
<mailto:[email protected]>>
> Cc: core-libs-dev<[email protected]
<mailto:[email protected]>>, OpenJDK
> <[email protected]
<mailto:[email protected]>>, concurrency-interest
> <[email protected]
<mailto:[email protected]>>
> Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
> Message-ID:<[email protected]
<mailto:[email protected]>>
> 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
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
------------------------------
Message: 2
Date: Mon, 30 Jun 2014 13:53:38 +0100
From: Alan Bateman<[email protected]>
To: Peter Firmstone<[email protected]>
Cc: [email protected]
Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 30/06/2014 11:02, Peter Firmstone wrote:
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:
If this code was in the JVM libraries, we wouldn't need it in our
project.
Have you considered bring some of these patches to OpenJDK?
On RFC 3986 (you mentioned this a number of times) then there were
previous attempts bring URI up to this, unfortunately had to be backed
out due to compatibility issues and other breakage. It's definitely
something that needs to be looked at again.
-Alan
------------------------------
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
End of Concurrency-interest Digest, Vol 113, Issue 45
*****************************************************
