On 12/03/2015 02:40 PM, e...@zusammenkunft.net wrote:
Hello,
That buffer sizing/expiring is a bit strange (the dynmic version
stranger than the old one), I do not understand the need for it. The
requests should not varry so much in size. Just reading something
like 64bytes at a time (possibly nonblocking) should be fine. No need
to look at the age of that buffer...
Admittedly I'm keeping the buffer expiring only for the possibility
someone could watch the array to predict what an application could
receive in random data. I have no proof this can happen, but I have to
assume that was a concern given it was its original designed. If I
could be sure that was not a concern, I'd eliminate it.
In cases where a large amount of random data was needed from many
threads, like the end to end TLS perf testing, the larger buffer size
eliminated the overheads of reading the device.
The dynamic nature of the buffer size was that I didn't feel it was best
for java to consume so many random bytes, like 64K worth, if the
application only consumed a few at intervals that were just beyond the
expiration time. Therefore I ended up with this, a dynamic buffer that
could grow and shrink as needed.
A cool implementation would be an actual single periodic refresher
thread which does not block reading (until buffer is empty)... but
that might change the semantic a bit (and could be better used with
the new DRNG api for block-free reseeding).
The locking was a big thing here. For example, in
NativePRNG.implNextBytes() the cost of copying the array and doing the
xor outside the the synchronized block was quicker for multithreaded
performance than not doing the copy and xor'ing inside the synchronized
block. I had thought about a refresher thread, but I felt the more
threads competing for the buffer would make it worse.
Bernd
