[concurrency-interest] ThreadLocalRandom clinit troubles
peter.firmstone at zeus.net.au
Sat Jun 28 21:53:50 EDT 2014
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.
> Message: 1
> Date: Thu, 26 Jun 2014 19:10:22 -0400
> From: Doug Lea <dl at cs.oswego.edu>
> To: Peter Levart <peter.levart at gmail.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>, OpenJDK
> <security-dev at openjdk.java.net>, concurrency-interest
> <concurrency-interest at cs.oswego.edu>
> Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
> Message-ID: <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/
> This seems to be the best idea yet, assuming that people are OK
> with the changes to sun.security.provider.SeedGenerator and
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest