ThreadLocalRandom clinit troubles

[Bradford Wetmore]

Martin,

Thanks for filing.  I was positive there was already a bug for this, but 
for the life of me I can't find it now.  There's some other more minor 
cleanup that needs to take place, but seems like I've been in 
escalation/firefighting mode for more than a year now and it hasn't 
bubbled to the top.

Brad


On 6/21/2014 9:05 PM, Martin Buchholz wrote:
> While looking at NativePRNG, I filed
>
> https://bugs.openjdk.java.net/browse/JDK-8047769
>
> SecureRandom should be more frugal with file descriptors
>
> If I run this java program on Linux
>
> public class SecureRandoms {
>      public static void main(String[] args) throws Throwable {
>          new java.security.SecureRandom();
>      }
> }
>
> it creates 6 file descriptors for /dev/random and /dev/urandom, as shown
> by:
>
> strace -q -ff -e open java SecureRandoms |& grep /dev/
> [pid 20769] open("/dev/random", O_RDONLY) = 5
> [pid 20769] open("/dev/urandom", O_RDONLY) = 6
> [pid 20769] open("/dev/random", O_RDONLY) = 7
> [pid 20769] open("/dev/random", O_RDONLY) = 8
> [pid 20769] open("/dev/urandom", O_RDONLY) = 9
> [pid 20769] open("/dev/urandom", O_RDONLY) = 10
>
> Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java
> it looks like 2 file descriptors are created for every variant of
> NativePRNG, whether or not they are ever used. Which is wasteful. In
> fact, you only ever need at most two file descriptors, one for
> /dev/random and one for /dev/urandom.
>
> Further, it would be nice if the file descriptors were closed when idle
> and lazily re-created. Especially /dev/random should typically be used
> at startup and never thereafter.
>
>
> On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman <Alan.Bateman at oracle.com
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>     On 20/06/2014 15:02, Peter Levart wrote:
>
>
>         And, as Martin pointed out, it seems to be used for tests that
>         exercise particular responses from NameService API to test the
>         behaviour of JDK classes. It would be a shame for those tests to
>         go away.
>
>     We've been talking about removing it for many years because it has
>     been so troublesome. If we really need to having something for
>     testing then I don't think it needs to be general purpose, we can
>     get right of the lookup at least.
>
>     -Alan.
>
>