Re: BigInteger Prime Generation

Hi Andrew,

thank you for the link, I will go through it tomorrow.

> http://www.cacr.math.uwaterloo.ca/hac/about/chap4.pdf
> 
> I won't reproduce it all here, but please have a look.
> 
>> Please don't feel bothered. It is only a technicality with no practical relevance.
> 
> Sure.  It's always worth examining one's assumptions, especially when it comes
> to security.
> 
>> BTW: I see that BigInteger attributes are non-final. Since the new memory model in
>> Java 1.5, making them final would allow to pass instances of BigInteger to other
>> threads without synchronization, so making all attributes final might be a good
>> idea.
> 
> That's an interesting point.  Curiously, they're not final in OpenJDK either.
> 

Yep, I assumed OpenJDK would use the semantics of final for all immutable objects
since it is advertised in exactly this context:
The semantics of final assure that we see the completely constructed object
if the reference is published after completion of the constructor (initialization-safety).
My statement was not accurate as we still need to synchronize in order to
make sure that the reference will be seen by the other thread. A scenario where
initialization-safety without synchronization is useful is, for instance, lazy
evaluation, but only if accidently evaluating the same expression twice is harmless:
This is the case for BigInteger and most other immutable objects.

Second, I can only speculate about the performance costs of the semantics of final:
I find it possible that the VM needs a memory fence under the hood but therefore can
compensate by always keeping cache-local copies of final attributes. Could be
that OpenJDK omitted initialization-safety here due to hidden performance issues.