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

[Paul Sandoz]

On Feb 26, 2014, at 8:55 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> On Feb 26, 2014, at 5:38 AM, Paul Sandoz wrote:
> 
>>>> Not sure the static powerCache field, in the original code, needs to be volatile either:
>>>> 
>>>> 1137     private static volatile BigInteger[][] powerCache;
>>> 
>>> Is there consensus on whether "volatile" is necessary here?
>>> 
>> 
>> Looking back at the discussions i believe it was made volatile to ensure threads don't observe a partially updated and published cache lines.
>> 
>> Since we are already using Unsafe for deserialization I think it might be possible to do the following instead (warning: not tested!):
> 
> Thanks for the suggestion, Paul. Assuming it is correct, in what way would this be a better approach? (I apologize for being obtuse.)
> 

IMHO it is a simpler solution. It's a cache line that requires updating not the cache line*s*, as the current approach can potentially knock out cache lines for other radixes.


> If it looks worth doing, I'll file another issue to track the idea. I already have it on my list anyway to follow up on Alan Eliasen's comment in the BigInteger code:
> 
>     * This could be changed to a more complicated caching method using
>     * {@code Future}.
>     */
>    private static BigInteger getRadixConversionCache(int radix, int exponent) {
> 

Not quite sure what that would entail.

Paul.