Hi Brian,
On 20/02/2014 7:44 AM, Brian Burkhalter wrote:
This patch concerns cleaning up some ugly internal deprecations.
Issue: https://bugs.openjdk.java.net/browse/JDK-8035279
Webrev: http://cr.openjdk.java.net/~bpb/8035279/webrev.00/
All JTREG BigInteger tests pass, and the serialized form has been unaltered as
verified by bidirectional read-write testing between Java 7 and this version.
I would appreciate scrutiny of the arithmetic to make sure that I've made no silly
errors. Also I would be interested in opinions as to whether the "volatile"
keyword should in fact be used for the affected instance variables.
re: volatile
The basic approach being taken with these primitive fields is lazy
initialization to a value that will always be the same if recomputed. If
the variables are not volatile then in the worst-case (this is
theoretical only) they will be recomputed by each thread that accesses
them. If they are volatile then they will only be recomputed by threads
that truly race on the initialization logic, but you will thereafter pay
the price of a volatile read on each access.
Either way you will be functionally correct so it all comes down to
performance. Practically speaking I would expect you to be better off
overall without the volatile.
As Paul notes the powerCache array does not need to be volatile as it is
initialized as part of class initialization.
Cheers,
David
Thank you for your comments.
Brian
