proposal: spec: define/imply memory layout of tagged struct fields

[griesemer]

This is half-baked idea that needs more thought, written down so it doesn't get forgotten.

Currently, the spec does not specify how struct fields are laid out in memory (e.g. source order, or optimally packed, or any other order). That is, theoretically, a compiler is free to optimize the layout. However, currently all (?) compilers lay out struct fields in source order, possibly wasting significant amounts of space due to padding (struct internal fragmentation).

It is not unlikely that code depends on this property.

Instead of requiring all structs to follow source order layout of fields, we could say that structs with tagged fields are the ones that are laid out in source order. Here are some variants of the same idea:

• struct fields are laid out in source order if there's at least one field that's tagged
• struct fields are laid out in source order if all fields are tagged
• tagged struct fields are laid out in source order (relative to other tagged fields), but untagged fields are free to be where the compiler decides
• tagged fields are laid out contiguously, in source order, at the beginning (or the end) of the struct; untagged fields are in compiler-determined order at the opposite end (and the end or beginning) of the struct

[bradfitz]

I would love to have the source order (read: documentation order) and layout be totally separate, and both be under programmer's control. (the programmer might know optimal better than the compiler, if optimal means more than packing, like getting on different cache lines)

You could imagine a struct tag that declares the index position, or a magic zero-width field that declares the order for the rest:

    type S struct {
          _ struct{} `order:"A,C,B"`
          A uint8
          B int16
          C uint8
    }

[randall77]

I'd be happy to have the compiler pack the structs however it likes, unless
there is a "nopack" label somewhere (first field? any field?), in which
case it must lay out the fields in source order.

On Thu, Feb 26, 2015 at 9:42 AM, Brad Fitzpatrick notifications@github.com
wrote:

I would love to have the source order (read: documentation order) and
layout be totally separate, and both be under programmer's control. (the
programmer might know optimal better than the compiler, if optimal means
more than packing, like getting on different cache lines)

You could imagine a struct tag that declares the index position, or a
magic zero-width field that declares the order for the rest:

type S struct {
      _ struct{} `order:"A,C,B"`
      A uint8
      B int16
      C uint8
}

—
Reply to this email directly or view it on GitHub
#10014 (comment).

[dvyukov]

I'd be happy to have the compiler pack the structs however it likes, unless
there is a "nopack" label somewhere (first field? any field?), in which
case it must lay out the fields in source order.

I second this.
Are there any other options than tags? We have not yet documented any of the //go: comments, right? Otherwise //go:nopack looks nice.

However, this can break some existing code I guess (e.g. if you pass a struct to a syscall).

[nightlyone]

That would make it difficult to hunt cacheline pingpong issues in shared structs. Those can also happen in imported packages. Also handover to C, kernel API, wire-formats, etc. might become hairy and even lead to surprising bugs.

I would switch the default or make it even a new keyword, since it technically is no struct as we know it from C family languages anymore, but something else. That will be very surprising.

A struct has the following three important properties for me:

• I control memory layout down to the bit level when composing them using {u,}int{,8,16,32,64} float32, float64 and fixed sized arrays of those
• padding is zeroed on allocation
• alignment is documented in spec

But a tool like http://linux.die.net/man/1/pahole might prove to be very useful for Go.

[randall77]

I agree we probably can't make the default reorder fields for Go 1.x. But
it is something to think about for 2.0.

On Thu, Feb 26, 2015 at 10:55 AM, Ingo Oeser notifications@github.com
wrote:

That would make it difficult to hunt cacheline pingpong issues in shared
structs. Those can also happen in imported packages. Also handover to C,
kernel API, wire-formats, etc. might become hairy and even lead to
surprising bugs.

I would switch the default or make it even a new keyword, since it
technically is no struct as we know it from C family languages anymore, but
something else. That will be very surprising.

A struct has the following three important properties for me:

• I control memory layout down to the bit level when composing them
  using {u,}int{,8,16,32,64} float32, float64 and fixed sized arrays of those
• padding is zeroed on allocation
• alignment is documented in spec

But a tool like http://linux.die.net/man/1/pahole might prove to be very
useful for Go.

—
Reply to this email directly or view it on GitHub
#10014 (comment).

[nightlyone]

Even in Go 2 it would be very surprising to have random breakage of wire formats, binary formats, in process ABI, etc. when using the struct keyword. pahole and friends exist today and are used heavily by e.g. the linux kernel folks to optimize that as needed.

I also doubt the compiler knows enough about data access patterns to optimize it well enough for the general case.

I really have a strong preference for advise instead of premature compiler optimizations here. But that's just me...

[cespare]

Not offering an opinion about this proposal, but

random breakage of wire formats, binary formats, in process ABI, etc. when using the struct keyword

all imply some kind of unsafe code and depending on ordering that isn't guaranteed by the Go specification today.

[extemporalgenome]

The ordering of struct fields in memory only has semantic importance when doing something unsafe or when using reflect, the latter of which can be of guaranteed source-order independent of actual memory layout. Use of unsafe specifically has non-defined, non-guaranteed behavior, and proper use of cgo is increasingly moving toward the idea that memory cannot be shared across the language boundary.

There may have been a time when it would have been more important to define, but, as discussed above, those use cases are evaporating. Still, if we really must define it, the major implementations' current approach of source-order and non-packing should become official; it retains control we already have in practice without adding syntax or more magic comments. Tooling (rather than the compiler) can rewrite type declarations to meet user needs, and even generate packed structs (such as for use in large slice datasets) with converters to and from a well-aligned form when accessing individual elements.

[extemporalgenome]

@Jragonmiris a few things would need to happen for pointers across cgo to be safe (some of these may already be enforced):

• No mechanism can allow C to directly reference Go package globals (the only safe way to pass data, including pointers, is via the C stack).
• Goroutines blocked on C calls cannot have any of its stack-resident references moved, if the implementation has a compacting GC.
• C may not retain references into Go memory after the initial call from Go returns. Also, C may not pass references into Go memory between concurrent calls into C originating from Go (reference passing within C may behave like a tree, but may not behave like a graph).
• Pertinent to this issue, Go struct types escaping into C in the form of pointers must be detected and implicitly compiled with predictable layouts, such as source-order aligned. Alternatively, Go struct pointers may not cross the boundary at all.

[griesemer]

@Jragonmiris Please don't hijack this issue for the cgo problem of passing objects into C land. While related, this current issue is strictly about whether the language should have a way to tell the implementation that struct fields should remain in source order (independent of whether that's the de facto case now or not). Thanks.

[dvyukov]

There was an utility that detects when structs waste space on padding. Can we move that check into vet?

[dominikh]

There was an utility that detects when structs waste space on padding. Can we move that check into vet?

If you do, please don't enable it by default.