How the bmap structure in runtime/map.go dynamically extended during compilation?

[Maksadbek]

I've been reading the map internals in Go and came across into following structure in source code:

https://github.com/golang/go/blob/master/src/runtime/map.go#L150

// A bucket for a Go map.
type bmap struct {
// tophash generally contains the top byte of the hash value
// for each key in this bucket. If tophash[0] < minTopHash,
// tophash[0] is a bucket evacuation state instead.
tophash [bucketCnt]uint8
// Followed by bucketCnt keys and then bucketCnt elems.
// NOTE: packing all the keys together and then all the elems together makes the
// code a bit more complicated than alternating key/elem/key/elem/... but it allows
// us to eliminate padding which would be needed for, e.g., map[int64]int8.
// Followed by an overflow pointer.
}

But if you scroll down the file and see the usage of this structure, actually it has the following structure:

// NOT REAL

type bmap struct {

    topbits [8]uint8

    keys [8]keytype

    values [8]valuetype

    pad uintptr

    overflow uintptr

}

I can't find out the place in the source code where this structure is extended. In order to access those extra fields, authors do some pointer arithmetics:

• https://github.com/golang/go/blob/master/src/runtime/map.go#L445
• https://github.com/golang/go/blob/master/src/runtime/map.go#L501

But in order to access those memory points, they needs to be allocated. Where does the allocation happen ?

[Ian Lance Taylor]

The allocation occurs in calls to newobject in hmap.newoverflow and
calls to newarray in makeBucketArray. But you are probably asking
where the t.bucket struct is defined. That happens in the compiler in
MapBucketType in cmd/compile/internal/reflectdata/reflect.go.

Ian

[Maksadbek]

Yes, this is exactly what I was searching for. Thank you!