On 06/28/2013 10:24 PM, Brian Burkhalter wrote:
http://cr.openjdk.java.net/~bpb/8017540/
Thumbs up.
-Aleksey.
N.B.: You can put me in with Reviewed-by: shade.
On 28/06/2013 19:24, Brian Burkhalter wrote:
This Request for Review is a refresh of this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018337.html
pertaining to this issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
The webrev has been updated in the
On Jul 1, 2013, at 1:27 AM, Aleksey Shipilev wrote:
On 06/28/2013 10:24 PM, Brian Burkhalter wrote:
http://cr.openjdk.java.net/~bpb/8017540/
Thumbs up.
Thanks. Now all we need is the imprimatur of an OpenJDK Reviewer.
-Aleksey.
N.B.: You can put me in with Reviewed-by: shade.
Done.
This Request for Review is a refresh of this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018337.html
pertaining to this issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
The webrev has been updated in the same location
Hi,
This version seems correct. Maybe just replace double volatile read at
length re-check with a single one:
private static BigInteger getRadixConversionCache(int radix, int
exponent) {
BigInteger[] cacheLine = powerCache[radix]; // volatile read
if (exponent
On 06/27/2013 08:37 AM, Peter Levart wrote:
Hi,
This version seems correct. Maybe just replace double volatile read at
length re-check with a single one:
private static BigInteger getRadixConversionCache(int radix, int
exponent) {
BigInteger[] cacheLine = powerCache[radix]; //
Hi,
Expanding on the idea of building single growing linked list of values
and treating the array just as index for quick access which can be
re-created at any time without synchronization or volatile publication,
here's the attempt:
private static class Node {
final BigInteger
Sorry for high frequency of messages.
This one is even better. powerCacheIndex need not be holding Nodes, but
BigIntegers instead. So no indirection on fast-path:
private static class Node {
final BigInteger value;
Node next;
Node(BigInteger value) { this.value =
On 06/27/2013 10:37 AM, Peter Levart wrote:
Hi,
This version seems correct. Maybe just replace double volatile read at
length re-check with a single one:
private static BigInteger getRadixConversionCache(int radix, int
exponent) {
BigInteger[] cacheLine = powerCache[radix];
On Jun 27, 2013, at 4:18 AM, Aleksey Shipilev wrote:
On 06/27/2013 10:37 AM, Peter Levart wrote:
Hi,
This version seems correct. Maybe just replace double volatile read at
length re-check with a single one:
private static BigInteger getRadixConversionCache(int radix, int
exponent) {
On 26.06.2013, at 7:31, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
We have two versions after private discussion with Aleksey.
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
if
We could check for the existing cacheLine.length right before installing
the new one
Do you mean something like this ?
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger[] cacheLine = powerCache[radix]; // volatile read
if (exponent cacheLine.length)
return
Yes, like that.
-Aleksey
On 26.06.2013, at 10:53, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
We could check for the existing cacheLine.length right before installing
the new one
Do you mean something like this ?
BigInteger getRadixConversionCache(int radix, int exponent) {
So do we have consensus on this version?
Thanks for the lively conversation.
Brian
On Jun 26, 2013, at 12:05 AM, Aleksey Shipilev wrote:
Yes, like that.
-Aleksey
On 26.06.2013, at 10:53, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
We could check for the existing cacheLine.length
On 06/25/2013 03:53 AM, Brian Burkhalter wrote:
http://cr.openjdk.java.net/~bpb/8017540/
Thanks! Looks good to me.
Rather minor silly nit:
cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
for (int i = oldSize; i = exponent; i++) {
...is probably more consistent as:
cacheLine =
On 25/06/2013 00:53, Brian Burkhalter wrote:
Branching off from this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html
I filed this issue (should be public tomorrow)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
for the getRadixConversionCache()
On 06/25/2013 08:29 PM, Brian Burkhalter wrote:
Hi Aleksey,
On Jun 25, 2013, at 1:40 AM, Aleksey Shipilev wrote:
Thanks! Looks good to me.
Cool!
Hold on now. Similar to what Peter suggests in the separate thread,
there is the data race between 3458 and 3466:
3455 private static
What about such code ?
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger retVal = null;
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
int oldSize = cacheLine.length;
if (exponent = oldSize) {
cacheLine =
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The trouble I'm seeing is weak enough
hardware, which will never see the updated value of cacheLine, always
falling back. Hence, I'm keen to keep
On 06/25/2013 11:36 PM, Dmitry Nadezhin wrote:
What about such code ?
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger retVal = null;
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
int oldSize = cacheLine.length;
if
On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
On 06/25/2013 11:38 PM, Peter Levart wrote:
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The trouble I'm seeing is weak enough
hardware,
On 06/26/2013 12:34 AM, Peter Levart wrote:
On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
On 06/25/2013 11:38 PM, Peter Levart wrote:
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The
On 06/25/2013 10:34 PM, Peter Levart wrote:
On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
On 06/25/2013 11:38 PM, Peter Levart wrote:
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The
On 06/26/2013 12:56 AM, Peter Levart wrote:
Sorry, you are storing back when resizing. And you are resizing for
every exponent that is bigger that previous requested (cached). This can
lead to many resizings.
Dmitry had suggested going back to square one with his approach. I'll
let him post
On Jun 25, 2013, at 1:56 PM, Peter Levart peter.lev...@gmail.com wrote:
Sorry, you are storing back when resizing. And you are resizing for every
exponent that is bigger that previous requested (cached). This can lead to
many resizings.
Hi everyone,
Apologies to butt in, and maybe this
We have two versions after private discussion with Aleksey.
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
if (exponent cacheLine.length)
return cacheLine[exponent];
int oldSize =
Branching off from this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html
I filed this issue (should be public tomorrow)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
for the getRadixConversionCache() enhancement. The patch is here
27 matches
Mail list logo
