JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger
Brian Burkhalter
brian.burkhalter at oracle.com
Wed Feb 26 19:55:16 UTC 2014
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.)
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) {
Thanks,
Brian
More information about the core-libs-dev
mailing list