JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

[David Holmes]

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
>