Farther afield: the "Holder" idiom for thread-safe lazy initialization
is one that we could now replace with invokedynamic (since a
ConstantCallSize acts as a lazily initialize cache), if there were only
a way to actually express the indy code from Java. This would let us
replace a class with a call site.
On 5/10/2012 7:11 PM, Mike Duigou wrote:
Hello all;
A benign but potentially expensive race condition was discovered in
java.util.UUID. The initialization of numberGenerator may cause the creation of
a number of SecureRandom instances if multiple threads are attempting to
initialize the field at the same time. This can happen because creation of the
SecureRandom instances, depending upon system configuration and state, may take
a significant amount of time.
Using a shared SecureRandom instance for the numberGenerator is an
optimization--nothing bad happens as a result of each thread using it's own
instance. However, creation of multiple SecureRandom instances, especially
during system startup, may be expensive or have high latency if no previous
SecureRandom instances have been created.
Accordingly, a holder class is used to ensure that only a single SecureRandom
instance is created. The holder also serves to defer initialization of
numberGenerator until randomUUID() is first called.
Webrev:
http://cr.openjdk.java.net/~mduigou/7071826/0/webrev/
This issue will be proposed for backport to Java 7u6 once integrated into Java 8
Thanks,
Mike
