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

[Paul Sandoz]

On Feb 27, 2014, at 8:02 PM, Peter Levart <peter.levart at gmail.com> wrote:

> 
> 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.
> 

Doh! i somehow missed that null check, thanks, i get it now.

Paul.