Skip to content

Appending empty type to a struct increases its size #48651

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
navytux opened this issue Sep 27, 2021 · 3 comments
Closed

Appending empty type to a struct increases its size #48651

navytux opened this issue Sep 27, 2021 · 3 comments

Comments

@navytux
Copy link
Contributor

navytux commented Sep 27, 2021

What version of Go are you using (go version)?

$ go version
go version go1.17.1 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/kirr/.cache/go-build"
GOENV="/home/kirr/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/kirr/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/kirr/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/kirr/src/tools/go/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/kirr/src/tools/go/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.1"
GCCGO="/usr/bin/gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3103072093=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.17.1 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.17.1
uname -sr: Linux 5.10.0-8-amd64
Distributor ID:	Debian
Description:	Debian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 2.31-13) stable release version 2.31.
gdb --version: GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

What did you do?

Hello up there. I was implementing custom RangedSet class via instantiaion of custom RangedMap class with void value type. Unfortunately having that - even empty - value type in the map entry structure increases its size, as the following program demonstrates:

---- 8< ---- (https://play.golang.org/p/Ed358IA13Fd)

package main

import (
        "fmt"
        "unsafe"
)


type KeyRange struct {  // sizeof(KeyRange) == 16
        Lo int64
        Hi int64
}

type void struct{}      // sizeof(void) == 0


type Entry1 struct {    // sizeof(Entry1) == 16  == 0 + 16
        void
        KeyRange
}

type Entry2 struct {    // sizeof(Entry2) == 24  != 16 + 0
        KeyRange
        void
}


func main() {
        fmt.Printf("sizeof(KeyRange):  %d\n", unsafe.Sizeof(KeyRange{}))
        fmt.Printf("sizeof(void):      %d\n", unsafe.Sizeof(void{}))
        fmt.Printf("sizeof(Entry1):    %d\n", unsafe.Sizeof(Entry1{}))
        fmt.Printf("sizeof(Entry2):    %d\n", unsafe.Sizeof(Entry2{}))
}
kirr@deca:~/tmp/trashme$ go run zero.go 
sizeof(KeyRange):  16
sizeof(void):      0
sizeof(Entry1):    16
sizeof(Entry2):    24

What did you expect to see?

I expect that sizeof(Entry1) == sizeof(Entry2) == 16.

What did you see instead?

sizeof(Entry1) == 16, but sizeof(Entry2) == 24 for (imho) no good reason.

The issue is present in all Go versions starting from at least Go1.11, but nevertheless I believe this is a bug.


For the reference: in #40322 the topic of stride alignment being included into sizeof was raised. However in hereby case there is no any extra stride as the KeyRange type is already well aligned to be strided well out of the box.

Thanks beforehand,
Kirill

@navytux
Copy link
Contributor Author

navytux commented Sep 27, 2021

Though maybe it is due to GC, so that if &Entry2.void pointer is taken, it still always points to inside of Entry2 object...

@ianlancetaylor
Copy link
Contributor

Yes, exactly. This is intended behavior. See #9401.

@navytux
Copy link
Contributor Author

navytux commented Sep 27, 2021

Thanks for the pointer, @ianlancetaylor.

@golang golang locked and limited conversation to collaborators Sep 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants