Map internals - explanation of how it works and some questions [complicated]

[JOhn_Stuart (Les Way)]

Please correct me: when a bucket has 8 items, a new one will be created and changed to this full one. This does not trigger the recalculation of all the hascodes of the elements in the map.

However, when in average each bucket has more than 6.5 elements, the risze will get triggered.

Questions:

• 1. if a map has 10 buckets and 4 of these have an extra chained one, for a total of 14 buckets - then the map will resize and allocate an array of 28 buckets ?
• 2. if map has 9 buckets, only 8 are in the bucket array and one is chained, if it needs to resize now, will not the new bucket array be the smallest power of 2 that can accomodate the needed bucket count ? namely 32 buckets instead of 19 ?
• 3. if I want to read/write an element, its hash function decides it belongs to bucket B, and bucket B has another chained one, will go runtime iterate through the 2 buckets(their corresponding hash arrays) until it finds my element/a free position ?
• 4. when the decision to resize is made, it will only allocate new memory, and the actual copy and recomputation of the hashcodes, is done in each future read/write ? Like each new read/write copies a new bucket (or a single entry) - and this moving of buckets is not done all at once, in the initial read/write operation that determined the map needs to be resized ?
• 5. will a resize be triggered only when each bucket has on average more than 6.5 element, does this count the chained buckets (when computing exisitng bucket count) or just the size of the bucket array without caring about chain buckets count ?
• 6. will resizes be triggered by other factors ? Here are examples from a blog:
     LOAD 6.50
     %overflow 20.90
     bytes/entry 10.79
     hitprobe 4.25
     missprobe. 6.50
     So if elements count/ bucket count is less than 6.5, but the hitprobe is larger than 4.2 , will that trigger a resize as well ?
• 7. How does a bucket store the key value pairs in the same []byte. Is it to avoid adress aligment paddings just for the Key/Value types, bu also for the fields inside the key/value ? Namely if inside the key there is some padding, will that padding also be in this byte slice where the bucket stores its 8 keys and values ?
• 8. For a new element, its hash function is computed. The resulting hash code is split into two parts, the high order bits and low order bits. The low order bits will decide in what bucket it will be placed. In that given bucket, the high order bits are stored into an array, and when retrieving the element (having computed the hash code of this new key), this high order bits array is traversed to look for a match. Whan happens when 2 elements have the same hash code ? will this high order bits array contain duplicate values ?

Please advice me. I have already looked at the blogs and a bit at the code (https://github.com/golang/go/blob/master/src/runtime/map.go) but it is still not clear to me.