RFR 4641897: Faster string conversion of large integers

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Jun 25 18:45:43 UTC 2013


On 06/25/2013 10:13 PM, Peter Levart wrote:
> 
> On 06/22/2013 12:54 PM, Aleksey Shipilev wrote:
>>   T get(int index1, index2) {
>>      T[][] lc = cache;
>>      if (index1 >= lc.length) { // needs resizing
>>         lc = <generate_new_T[][]_of_size>((index1 << 1) + 1);
>>         cache = lc;
>>      }
>>      T[] lt = lc[*index2*];
>>      if (index2 >= lt.length) { // needs resizing
>>         lt = <generate_new_T[]_of_size>((index2 << 1) + 1);
>>         lc[index1] = lt;
>>         cache = lc; // publish
>>      }
>>      return lt[index2];
>>   }
>>
>> -Aleksey.
> 
> Hi Aleksey,
> 
> 1st I think there's a typo in above bolded part. There should be index1
> instead of index2 there, right?

Nope, lc is indexed with index2; lt is indexed with index1.

> Then I think there's a data race in above code which can de-reference
> half-constructed array and an element within it:

Damn. Good point, let's discuss that in the appropriate RFR, see 8017540.

> I have studied the constraints of powerCache and have observed:

> So the caching could be performed with no synchronization (other than
> that provided by final fields descibed above).

Yeah, we can do that with finals. Too bad you can't have the final
semantics with BigInteger[] array.

> Here is a possible variant of such caching:

Seems overcomplicated. ;) Let's instead fix the code proposed in 8017540.

Thanks,
Aleksey.



More information about the core-libs-dev mailing list