RFR 4641897: Faster string conversion of large integers (original) (raw)

Dmitry Nadezhin dmitry.nadezhin at gmail.com
Sat Jun 22 04:06:10 UTC 2013

Alexey,

Each possible radix has its cacheLine in the cache.

Cache contents looks like BigInteger[][] powerCache = new BigInteger[37] { /0/ null, /1/ null, /2/ new BigInteger[] { 2, 4, 16, 256, 32768, ... }, /3/ new BigInteger[] { 3, 9, 81, ... }, /4/ new BigInteger[] { 4, 16, 256, ... } /5/ new BigInteger[] { 5, 25, 625, ... }, /6/ new BigInteger[] { 6 }, /7/ new BigInteger[] { 7 }, . . . /36/ new BigInteger[] { 36 } };

Is there an idiom for a list/array of volatile references ? I am not sure that such naive code works: volatile BigInteger[][] powerCache = ..,

-Dima

On Fri, Jun 21, 2013 at 7:36 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote:

On 06/21/2013 07:04 PM, Brian Burkhalter wrote: > > On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote: > >> One part that might need attention is getRadixConversionCache as I >> could imagine cases where the synchronization could lead to >> contention. Have you (or Alan) considered alternatives that would >> limit the synchronization to only when the powers cache needs to be >> expanded? > > I have not but will do so. I cannot speak for Alan E.

That's actually quite straight-forward. Make the list immutable, put it into the volatile reference; count the current size in volatile field. You can then try to resize the cache concurrently by generating the new list, and assigning it to the volatile reference. Since the resizes are not frequent, you don't care if you compute multiple candidates with multiple threads. -Aleksey.

More information about the core-libs-dev mailing list