Re: RFR: jsr166 jdk9 integration wave 9

2016-08-12 Thread Martin Buchholz
Another way of looking at it: Machines like the types "int" and "double". Use of float instead of double in an API is almost always a mistake, except to save space for arrays of values. Similarly, it's never worth optimizing a boolean or byte value to actually take up less than 4 bytes, except wh

Re: RFR: jsr166 jdk9 integration wave 9

2016-08-12 Thread Paul Sandoz
> On 10 Aug 2016, at 18:34, Martin Buchholz wrote: > > Again, no spec changes, but larger than expected. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > Looks good. Paul.

Re: RFR: jsr166 jdk9 integration wave 9

2016-08-11 Thread Martin Buchholz
On Thu, Aug 11, 2016 at 2:12 PM, Aleksey Shipilev < aleksey.shipi...@gmail.com> wrote: > On 08/11/2016 11:56 PM, Martin Buchholz wrote: > > I can imagine a machine that has a native cas instruction, but no native > > exchange instruction, but no one ever got fired for optimizing for x86. > > ...wh

Re: RFR: jsr166 jdk9 integration wave 9

2016-08-11 Thread Aleksey Shipilev
On 08/11/2016 11:56 PM, Martin Buchholz wrote: > I can imagine a machine that has a native cas instruction, but no native > exchange instruction, but no one ever got fired for optimizing for x86. ...which would be less of an issue once we switch to proper-boolean VarHandles, not the int-simulation

Re: RFR: jsr166 jdk9 integration wave 9

2016-08-11 Thread Martin Buchholz
Thanks Aleksey, for the usual convincing benchmark result. You win! I can imagine a machine that has a native cas instruction, but no native exchange instruction, but no one ever got fired for optimizing for x86. public final boolean getAndSet(boolean newValue) { return (int)VALUE.ge

Re: RFR: jsr166 jdk9 integration wave 9

2016-08-11 Thread Aleksey Shipilev
On 08/11/2016 09:59 PM, Martin Buchholz wrote: > On Thu, Aug 11, 2016 at 10:40 AM, Aleksey Shipilev >> Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is >> hopefully intrinsified completely? > > Good question. This optimization originated in a suggestion for jdk8, > where ther

Re: RFR: jsr166 jdk9 integration wave 9

2016-08-11 Thread Martin Buchholz
On Thu, Aug 11, 2016 at 10:40 AM, Aleksey Shipilev < aleksey.shipi...@gmail.com> wrote: > On 08/11/2016 04:34 AM, Martin Buchholz wrote: > > Again, no spec changes, but larger than expected. > > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ > jsr166-jdk9-integration/ > > Why doesn't Ato

Re: RFR: jsr166 jdk9 integration wave 9

2016-08-11 Thread Aleksey Shipilev
On 08/11/2016 04:34 AM, Martin Buchholz wrote: > Again, no spec changes, but larger than expected. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is hopefully intrinsified completely? I like the

Re: RFR: jsr166 jdk9 integration wave 9

2016-08-10 Thread David Holmes
Hi Martin, On 11/08/2016 11:34 AM, Martin Buchholz wrote: Again, no spec changes, but larger than expected. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ The StampedLock functional changes look okay. Thanks, David --- Joe and Amy may be interested in http://c

RFR: jsr166 jdk9 integration wave 9

2016-08-10 Thread Martin Buchholz
Again, no spec changes, but larger than expected. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ --- Joe and Amy may be interested in http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/test-stabilization/ where we rewrite flaky tests with ne