Hello rsc (cc: brad, dfc, dvyukov, golang-codereviews@googlegroups.com, iant,
khr, minux, rlh),

I'd like you to review this change to the dev.cc branch of
https://code.google.com/p/go

I tested this on solaris/amd64, linux/amd64 and linux/386.

i'll try something different tomorrow and send a counterproposal.

Note that if we make the code a little more complicated, we can gain another
three bits from the lsb. Then we can have 15+3=18bits for ABA counter which is
definitely enough to have common code base for all amd64 platforms.

Unrelated -- I'm slightly concerned about lfstack code when amd64 gets more than
48 bits.

On Fri, Nov 14, 2014 at 2:49 AM, <aram@mgk.ro> wrote:

> Unrelated -- I'm slightly concerned about lfstack code when amd64 gets
> more than 48 bits.
>

I'm sure there is other code doing things like this. Operating systems will
have to let programs require virtual addresses that aren't in the original
48-bit space, the same way that we have MAP_32BIT on 64-bit systems.

I don't actually understand why you are worried. It's going to be a while
before 140 TB of virtual address space (assuming the kernel keeps the other
140 TB) is not enough.

Russ

On Fri, Nov 14, 2014 at 10:49 AM,  <aram@mgk.ro> wrote:
> Note that if we make the code a little more complicated, we can gain
> another three bits from the lsb. Then we can have 15+3=18bits for ABA
> counter which is definitely enough to have common code base for all
> amd64 platforms.
>
> Unrelated -- I'm slightly concerned about lfstack code when amd64 gets
> more than 48 bits.

All that systems will have CMPXCHG16B.

Cleaner fix at CL 177750043.

R=close

I'd be happy to take a sparc64 file, but it has to use more than 3 bits. If
there are no hardware limitations, find out what the current OS limitations are.

On Sat, Nov 15, 2014 at 5:31 AM,  <rsc@golang.org> wrote:
> I'd be happy to take a sparc64 file, but it has to use more than 3 bits.
> If there are no hardware limitations, find out what the current OS
> limitations are.

I miss the context, but sparc64, on Solaris at least, has 20bits of
free MSB, which must be all equal to either 0 on 1 (like amd64).

-- 
Aram Hăvărneanu

On Sat, Nov 15, 2014 at 5:41 AM, Aram Hăvărneanu <aram@mgk.ro> wrote:

> On Sat, Nov 15, 2014 at 5:31 AM,  <rsc@golang.org> wrote:
> > I'd be happy to take a sparc64 file, but it has to use more than 3 bits.
> > If there are no hardware limitations, find out what the current OS
> > limitations are.
>
> I miss the context, but sparc64, on Solaris at least, has 20bits of
> free MSB, which must be all equal to either 0 on 1 (like amd64).
>

I was thinking about this code, and I thought that you were trying to
support sparc64 with it. I can't actually tell.

#ifdef _64BIT
#ifdef GOOS_solaris
// SPARC64 and Solaris on AMD64 uses all 64 bits of virtual addresses.
// Use low-order three bits as ABA counter.
//
http://docs.oracle.com/cd/E19120-01/open.solaris/816-5138/6mba6ua5p/index.html
#undef PTR_BITS
#undef CNT_MASK
#undef PTR_MASK
#define PTR_BITS 0
#define CNT_MASK 7
#define PTR_MASK ((0ull-1)<<3)
#endif
#endif

Russ

On Sat, Nov 15, 2014 at 1:45 PM, Russ Cox <rsc@golang.org> wrote:
> I was thinking about this code, and I thought that you were trying to
> support sparc64 with it. I can't actually tell.

Ah, it originated from gccgo, which does support sparc64. I'm not sure
if we need to do anything in gc. In gccgo Ian can adapt
lfstack_amd64.go to lfstack_sparc64.go. Adding lfstack_sparc64.go is
problematic because cmd/go doesn't understand GOARCH=sparc64 and we
can't test it anyway.

-- 
Aram Hăvărneanu