Nice find!

In general, they do not take space. E.g., this program prints 4:

package main

import (
    "fmt"
    "unsafe"
)

func main() {
    fmt.Println(unsafe.Sizeof(struct {
        _ struct{}
        x int32
    }{}))
}

The change to pad out structs that have a final zero-size field was to fix issue #9401. I think this is working as intended.

So we should change

type ProgInfo struct {
        Flags    uint32   // flag bits                                                                             
        Reguse   uint64   // registers implicitly used by this instruction                                         
        Regset   uint64   // registers implicitly set by this instruction                                          
        Regindex uint64   // registers used by addressing mode                                                     
        _        struct{} // to prevent unkeyed literals                                                           
}

to

type ProgInfo struct {
        _        struct{} // to prevent unkeyed literals                                                           
        Flags    uint32   // flag bits                                                                             
        Reguse   uint64   // registers implicitly used by this instruction                                         
        Regset   uint64   // registers implicitly set by this instruction                                          
        Regindex uint64   // registers used by addressing mode                                                     
}

... I guess?

That should work to avoid the padding.

Moving the _ field to the top of the struct SGTM.

On Fri, 9 Oct 2015 11:10 Minux Ma notifications@github.com wrote:

ahh, I forgot about that trailing zero-sized field issue entirely.
thanks for pointing it out.

precise GC and zero-sized fields are subtle.

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

Perhaps instead of moving the _ field, augmenting the comment to mention
that zero sized fields consume 1 byte of space, however that allocation is
subsumed into the padding for the int32.

However on 32 bit platforms, leaving the zero sized field at the end will
cause it to consume 4 bytes, so maybe it does need to move to the top of
the struct.

On Fri, 9 Oct 2015 11:12 Dave Cheney dave@cheney.net wrote:

Moving the _ field to the top of the struct SGTM.

On Fri, 9 Oct 2015 11:10 Minux Ma notifications@github.com wrote:

ahh, I forgot about that trailing zero-sized field issue entirely.
thanks for pointing it out.

precise GC and zero-sized fields are subtle.

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

It won't take any space at the start of the struct.

CL https://golang.org/cl/15660 mentions this issue.

In case anyone's interested in investigating more structs that might benefit from reordering their fields, I put together github.com/mdempsky/maligned as a quick program to calculate struct sizes using cmd/compile's field layout rules, and compare against what they would be if the fields were sorted.

Example:

$ maligned cmd/internal/obj
/usr/local/google/home/mdempsky/wd/go/src/cmd/internal/obj/link.go:249:15: struct of size 40 could be 32
/usr/local/google/home/mdempsky/wd/go/src/cmd/internal/obj/link.go:476:11: struct of size 584 could be 568

@minux @mdempsky

ahh, I forgot about that trailing zero-sized field issue entirely.
thanks for pointing it out.

How can one take the address of an unnamed field in a struct, zero sized or not ? In #9401 the type in question was

type T struct {
    A int
    Y struct{}
}

But in the example above the field is unnamed and inaccessible.

It's possible at least via package reflect: http://play.golang.org/p/esuSUoKomT

@mdempsky, yes of course, thank you for explaining to me.

See also: https://go-review.googlesource.com/#/c/2179/