ThreadLocalRandom clinit troubles

Martin Buchholz martinrb at google.com
Sun Jun 22 04:05:23 UTC 2014


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>
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20140621/223c1506/attachment.html>


More information about the security-dev mailing list