[concurrency-interest] ThreadLocalRandom.nextSecondarySeed() re-initializes TLR's seed

[Martin Buchholz]

On Fri, Jun 20, 2014 at 1:42 AM, Peter Levart <peter.levart at gmail.com>
wrote:

>
> This pertains to the other thread (ThreadLocalRandom clinit troubles)
> started by Martin Buchholz, right? He's making a valid point. The "seeder"
> static field is still uninitialized during either NetworkInterface class
> initialization (as a result of NetworkInterface.getNetworkInterfaces()
> call) or during SecureRandom.getSeed() call. Either of which can execute
> user code in some configurations which might in turn use ThreadLocalRandom.
> If this happens, TLR.current() throws a NPE. I proposed a re-arrangement of
> class initialization that allows TLR to be fully functional even during
> it's initialization, albeit with a less randomized seed, and does not
> change the behaviour otherwise (since it triggers re-initialization at the
> end). See the proposed patch in the other thread.
>

I tried this same approach, and found that:

yes, we see some previously failing tests that start passing when the TLR
is functional even while executing its own clinit method, BUT there are
other tests that still fail, and only start passing when the network init
code is removed ... for unknown reasons.  We could debug them, but the
fundamental danger remains - TLR may be invoked very early during JDK
startup, and it is simply too risky to load higher-level libraries so
early, possibly invoking foreign code that might do anything.  Which is why
I keep trying to minimize TLR's external dependencies.

Whatever we decide to do here, the same changes should be made to
SplittableRandom.  Maybe there's scope for some refactoring/sharing, both
of code and of file system access at runtime.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20140622/fb66d0ed/attachment.html>