BigInteger Prime Generation
ogli at ogli.de
Tue Mar 3 21:46:01 UTC 2009
thank you for the link, I will go through it tomorrow.
> 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
> 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.
More information about the Classpath