RFR 4641897: Faster string conversion of large integers
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