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

[Peter Levart]

On 02/27/2014 04:06 PM, Paul Sandoz wrote:
>> >Back then I presented an alternative solution which solves that:
>> >
>> >http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018457.html
>> >
>> >...and as can be seen, does not use volatile read/write to publish BigIntegers - that's why it is important that internal implementation of such immutable classes like BigInteger is tolerant to unsafe publication...
>> >
> Interesting, nice use of a linked list. Not sure that is safe publication of cacheLine into powerCache, the last element in a line could be observed as null, plus although it is unlikely, the compiler could shuffle up the array element store?

Hi Paul,

Any element of powerCacheIndex array of arrays and/or any element of 
it's BigInteger[] sub-arrays can be observed as null and the code 
accounts for that. You can view the scheme as two-level cache. The 1st 
level is 'powerCacheIndex' where BigInteger[]s and BigIntegers are 
published unsafely. If non-null values are observed, they are correct, 
if null values are observed, the code looks through into the 2nd level 
'powerCache' array of linked-lists which is a properly synchronized 
lazily initialized cache of values where each is calculated at most once.

Regards, Peter