Re: [go-nuts] How the bmap structure in runtime/map.go dynamically extended during compilation?
Yes, this is exactly what I was searching for. Thank you!
On Friday, 25 March 2022 at 21:51:27 UTC+3 Ian Lance Taylor wrote:
> On Fri, Mar 25, 2022 at 11:42 AM Maksadbek wrote:
> >
> > 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 ?
>
> 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
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/3eede932-1b06-4c10-93c8-220b63bc6924n%40googlegroups.com.
Re: [go-nuts] How the bmap structure in runtime/map.go dynamically extended during compilation?
On Fri, Mar 25, 2022 at 11:42 AM Maksadbek wrote:
>
> 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 ?
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
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVSZfqQBk0r4rX7aq_VQW9BwQQ-%3D89aSZxOV20myB_JyQ%40mail.gmail.com.
[go-nuts] How the bmap structure in runtime/map.go dynamically extended during compilation?
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 ?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/08373fea-4e2b-4672-bc29-79825a1d3177n%40googlegroups.com.
