2014-07-16 15:16:19 -06:00
|
|
|
// Copyright 2014 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
package runtime
|
|
|
|
|
|
|
|
// This file contains the implementation of Go's map type.
|
|
|
|
//
|
2016-03-01 16:21:55 -07:00
|
|
|
// A map is just a hash table. The data is arranged
|
|
|
|
// into an array of buckets. Each bucket contains up to
|
|
|
|
// 8 key/value pairs. The low-order bits of the hash are
|
|
|
|
// used to select a bucket. Each bucket contains a few
|
2014-07-16 15:16:19 -06:00
|
|
|
// high-order bits of each hash to distinguish the entries
|
|
|
|
// within a single bucket.
|
|
|
|
//
|
|
|
|
// If more than 8 keys hash to a bucket, we chain on
|
|
|
|
// extra buckets.
|
|
|
|
//
|
|
|
|
// When the hashtable grows, we allocate a new array
|
2016-03-01 16:21:55 -07:00
|
|
|
// of buckets twice as big. Buckets are incrementally
|
2014-07-16 15:16:19 -06:00
|
|
|
// copied from the old bucket array to the new bucket array.
|
|
|
|
//
|
|
|
|
// Map iterators walk through the array of buckets and
|
|
|
|
// return the keys in walk order (bucket #, then overflow
|
|
|
|
// chain order, then bucket index). To maintain iteration
|
|
|
|
// semantics, we never move keys within their bucket (if
|
|
|
|
// we did, keys might be returned 0 or 2 times). When
|
|
|
|
// growing the table, iterators remain iterating through the
|
|
|
|
// old table and must check the new table if the bucket
|
|
|
|
// they are iterating through has been moved ("evacuated")
|
|
|
|
// to the new table.
|
|
|
|
|
|
|
|
// Picking loadFactor: too large and we have lots of overflow
|
2016-03-01 16:21:55 -07:00
|
|
|
// buckets, too small and we waste a lot of space. I wrote
|
2014-07-16 15:16:19 -06:00
|
|
|
// a simple program to check some stats for different loads:
|
|
|
|
// (64-bit, 8 byte keys and values)
|
|
|
|
// loadFactor %overflow bytes/entry hitprobe missprobe
|
|
|
|
// 4.00 2.13 20.77 3.00 4.00
|
|
|
|
// 4.50 4.05 17.30 3.25 4.50
|
|
|
|
// 5.00 6.85 14.77 3.50 5.00
|
|
|
|
// 5.50 10.55 12.94 3.75 5.50
|
|
|
|
// 6.00 15.27 11.67 4.00 6.00
|
|
|
|
// 6.50 20.90 10.79 4.25 6.50
|
|
|
|
// 7.00 27.14 10.15 4.50 7.00
|
|
|
|
// 7.50 34.03 9.73 4.75 7.50
|
|
|
|
// 8.00 41.10 9.40 5.00 8.00
|
|
|
|
//
|
|
|
|
// %overflow = percentage of buckets which have an overflow bucket
|
|
|
|
// bytes/entry = overhead bytes used per key/value pair
|
|
|
|
// hitprobe = # of entries to check when looking up a present key
|
|
|
|
// missprobe = # of entries to check when looking up an absent key
|
|
|
|
//
|
|
|
|
// Keep in mind this data is for maximally loaded tables, i.e. just
|
2016-03-01 16:21:55 -07:00
|
|
|
// before the table grows. Typical tables will be somewhat less loaded.
|
2014-07-16 15:16:19 -06:00
|
|
|
|
|
|
|
import (
|
2015-11-02 12:09:24 -07:00
|
|
|
"runtime/internal/atomic"
|
2015-11-11 10:39:30 -07:00
|
|
|
"runtime/internal/sys"
|
2014-07-16 15:16:19 -06:00
|
|
|
"unsafe"
|
|
|
|
)
|
|
|
|
|
|
|
|
const (
|
|
|
|
// Maximum number of key/value pairs a bucket can hold.
|
2014-09-09 15:22:58 -06:00
|
|
|
bucketCntBits = 3
|
|
|
|
bucketCnt = 1 << bucketCntBits
|
2014-07-16 15:16:19 -06:00
|
|
|
|
|
|
|
// Maximum average load of a bucket that triggers growth.
|
|
|
|
loadFactor = 6.5
|
|
|
|
|
|
|
|
// Maximum key or value size to keep inline (instead of mallocing per element).
|
|
|
|
// Must fit in a uint8.
|
|
|
|
// Fast versions cannot handle big values - the cutoff size for
|
2015-03-11 13:58:47 -06:00
|
|
|
// fast versions in ../../cmd/internal/gc/walk.go must be at most this value.
|
2014-07-16 15:16:19 -06:00
|
|
|
maxKeySize = 128
|
|
|
|
maxValueSize = 128
|
|
|
|
|
|
|
|
// data offset should be the size of the bmap struct, but needs to be
|
2016-03-01 16:21:55 -07:00
|
|
|
// aligned correctly. For amd64p32 this means 64-bit alignment
|
2014-07-16 15:16:19 -06:00
|
|
|
// even though pointers are 32 bit.
|
|
|
|
dataOffset = unsafe.Offsetof(struct {
|
|
|
|
b bmap
|
|
|
|
v int64
|
|
|
|
}{}.v)
|
|
|
|
|
2016-03-01 16:21:55 -07:00
|
|
|
// Possible tophash values. We reserve a few possibilities for special marks.
|
2014-07-16 15:16:19 -06:00
|
|
|
// Each bucket (including its overflow buckets, if any) will have either all or none of its
|
|
|
|
// entries in the evacuated* states (except during the evacuate() method, which only happens
|
|
|
|
// during map writes and thus no one else can observe the map during that time).
|
|
|
|
empty = 0 // cell is empty
|
|
|
|
evacuatedEmpty = 1 // cell is empty, bucket is evacuated.
|
|
|
|
evacuatedX = 2 // key/value is valid. Entry has been evacuated to first half of larger table.
|
|
|
|
evacuatedY = 3 // same as above, but evacuated to second half of larger table.
|
|
|
|
minTopHash = 4 // minimum tophash for a normal filled cell.
|
|
|
|
|
|
|
|
// flags
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
iterator = 1 // there may be an iterator using buckets
|
|
|
|
oldIterator = 2 // there may be an iterator using oldbuckets
|
|
|
|
hashWriting = 4 // a goroutine is writing to the map
|
|
|
|
sameSizeGrow = 8 // the current map growth is to a new map of the same size
|
2014-07-16 15:16:19 -06:00
|
|
|
|
|
|
|
// sentinel bucket ID for iterator checks
|
2015-11-11 10:39:30 -07:00
|
|
|
noCheck = 1<<(8*sys.PtrSize) - 1
|
2014-07-16 15:16:19 -06:00
|
|
|
)
|
|
|
|
|
|
|
|
// A header for a Go map.
|
|
|
|
type hmap struct {
|
2015-03-11 13:58:47 -06:00
|
|
|
// Note: the format of the Hmap is encoded in ../../cmd/internal/gc/reflect.go and
|
2016-03-01 16:21:55 -07:00
|
|
|
// ../reflect/type.go. Don't change this structure without also changing that code!
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
count int // # live cells == size of map. Must be first (used by len() builtin)
|
|
|
|
flags uint8
|
|
|
|
B uint8 // log_2 of # of buckets (can hold up to loadFactor * 2^B items)
|
|
|
|
noverflow uint16 // approximate number of overflow buckets; see incrnoverflow for details
|
|
|
|
hash0 uint32 // hash seed
|
2014-07-16 15:16:19 -06:00
|
|
|
|
|
|
|
buckets unsafe.Pointer // array of 2^B Buckets. may be nil if count==0.
|
|
|
|
oldbuckets unsafe.Pointer // previous bucket array of half the size, non-nil only when growing
|
|
|
|
nevacuate uintptr // progress counter for evacuation (buckets less than this have been evacuated)
|
2015-01-26 11:04:41 -07:00
|
|
|
|
2015-02-14 06:10:06 -07:00
|
|
|
// If both key and value do not contain pointers and are inline, then we mark bucket
|
2015-01-26 11:04:41 -07:00
|
|
|
// type as containing no pointers. This avoids scanning such maps.
|
|
|
|
// However, bmap.overflow is a pointer. In order to keep overflow buckets
|
|
|
|
// alive, we store pointers to all overflow buckets in hmap.overflow.
|
|
|
|
// Overflow is used only if key and value do not contain pointers.
|
|
|
|
// overflow[0] contains overflow buckets for hmap.buckets.
|
|
|
|
// overflow[1] contains overflow buckets for hmap.oldbuckets.
|
|
|
|
// The first indirection allows us to reduce static size of hmap.
|
|
|
|
// The second indirection allows to store a pointer to the slice in hiter.
|
|
|
|
overflow *[2]*[]*bmap
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// A bucket for a Go map.
|
|
|
|
type bmap struct {
|
2016-09-26 11:10:41 -06:00
|
|
|
// 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.
|
2014-12-25 19:44:55 -07:00
|
|
|
tophash [bucketCnt]uint8
|
2014-07-16 15:16:19 -06:00
|
|
|
// Followed by bucketCnt keys and then bucketCnt values.
|
|
|
|
// NOTE: packing all the keys together and then all the values together makes the
|
|
|
|
// code a bit more complicated than alternating key/value/key/value/... but it allows
|
|
|
|
// us to eliminate padding which would be needed for, e.g., map[int64]int8.
|
2014-12-19 21:44:18 -07:00
|
|
|
// Followed by an overflow pointer.
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// A hash iteration structure.
|
2016-02-23 00:46:01 -07:00
|
|
|
// If you modify hiter, also change cmd/internal/gc/reflect.go to indicate
|
|
|
|
// the layout of this structure.
|
2014-07-16 15:16:19 -06:00
|
|
|
type hiter struct {
|
2016-02-23 00:46:01 -07:00
|
|
|
key unsafe.Pointer // Must be in first position. Write nil to indicate iteration end (see cmd/internal/gc/range.go).
|
|
|
|
value unsafe.Pointer // Must be in second position (see cmd/internal/gc/range.go).
|
2014-07-16 15:16:19 -06:00
|
|
|
t *maptype
|
|
|
|
h *hmap
|
|
|
|
buckets unsafe.Pointer // bucket ptr at hash_iter initialization time
|
|
|
|
bptr *bmap // current bucket
|
2015-01-26 11:04:41 -07:00
|
|
|
overflow [2]*[]*bmap // keeps overflow buckets alive
|
2014-09-08 18:42:21 -06:00
|
|
|
startBucket uintptr // bucket iteration started at
|
2014-07-16 15:16:19 -06:00
|
|
|
offset uint8 // intra-bucket offset to start from during iteration (should be big enough to hold bucketCnt-1)
|
2014-09-08 18:42:21 -06:00
|
|
|
wrapped bool // already wrapped around from end of bucket array to beginning
|
2014-07-16 15:16:19 -06:00
|
|
|
B uint8
|
2014-09-09 15:22:58 -06:00
|
|
|
i uint8
|
2014-07-16 15:16:19 -06:00
|
|
|
bucket uintptr
|
|
|
|
checkBucket uintptr
|
|
|
|
}
|
|
|
|
|
|
|
|
func evacuated(b *bmap) bool {
|
|
|
|
h := b.tophash[0]
|
|
|
|
return h > empty && h < minTopHash
|
|
|
|
}
|
|
|
|
|
2014-12-19 21:44:18 -07:00
|
|
|
func (b *bmap) overflow(t *maptype) *bmap {
|
2015-11-11 10:39:30 -07:00
|
|
|
return *(**bmap)(add(unsafe.Pointer(b), uintptr(t.bucketsize)-sys.PtrSize))
|
2014-12-19 21:44:18 -07:00
|
|
|
}
|
2015-01-26 11:04:41 -07:00
|
|
|
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
// incrnoverflow increments h.noverflow.
|
|
|
|
// noverflow counts the number of overflow buckets.
|
|
|
|
// This is used to trigger same-size map growth.
|
|
|
|
// See also tooManyOverflowBuckets.
|
|
|
|
// To keep hmap small, noverflow is a uint16.
|
|
|
|
// When there are few buckets, noverflow is an exact count.
|
|
|
|
// When there are many buckets, noverflow is an approximate count.
|
|
|
|
func (h *hmap) incrnoverflow() {
|
|
|
|
// We trigger same-size map growth if there are
|
|
|
|
// as many overflow buckets as buckets.
|
|
|
|
// We need to be able to count to 1<<h.B.
|
|
|
|
if h.B < 16 {
|
|
|
|
h.noverflow++
|
|
|
|
return
|
|
|
|
}
|
|
|
|
// Increment with probability 1/(1<<(h.B-15)).
|
|
|
|
// When we reach 1<<15 - 1, we will have approximately
|
|
|
|
// as many overflow buckets as buckets.
|
|
|
|
mask := uint32(1)<<(h.B-15) - 1
|
|
|
|
// Example: if h.B == 18, then mask == 7,
|
|
|
|
// and fastrand & 7 == 0 with probability 1/8.
|
|
|
|
if fastrand()&mask == 0 {
|
|
|
|
h.noverflow++
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-26 11:04:41 -07:00
|
|
|
func (h *hmap) setoverflow(t *maptype, b, ovf *bmap) {
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
h.incrnoverflow()
|
2015-01-26 11:04:41 -07:00
|
|
|
if t.bucket.kind&kindNoPointers != 0 {
|
|
|
|
h.createOverflow()
|
|
|
|
*h.overflow[0] = append(*h.overflow[0], ovf)
|
|
|
|
}
|
2015-11-11 10:39:30 -07:00
|
|
|
*(**bmap)(add(unsafe.Pointer(b), uintptr(t.bucketsize)-sys.PtrSize)) = ovf
|
2014-12-19 21:44:18 -07:00
|
|
|
}
|
|
|
|
|
2015-01-26 11:04:41 -07:00
|
|
|
func (h *hmap) createOverflow() {
|
|
|
|
if h.overflow == nil {
|
|
|
|
h.overflow = new([2]*[]*bmap)
|
|
|
|
}
|
|
|
|
if h.overflow[0] == nil {
|
|
|
|
h.overflow[0] = new([]*bmap)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-29 09:40:02 -07:00
|
|
|
// makemap implements a Go map creation make(map[k]v, hint)
|
|
|
|
// If the compiler has determined that the map or the first bucket
|
|
|
|
// can be created on the stack, h and/or bucket may be non-nil.
|
|
|
|
// If h != nil, the map can be created directly in h.
|
|
|
|
// If bucket != nil, bucket can be used as the first bucket.
|
|
|
|
func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer) *hmap {
|
2016-02-29 16:01:00 -07:00
|
|
|
if sz := unsafe.Sizeof(hmap{}); sz > 48 || sz != t.hmap.size {
|
2016-02-23 00:46:01 -07:00
|
|
|
println("runtime: sizeof(hmap) =", sz, ", t.hmap.size =", t.hmap.size)
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("bad hmap size")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2016-02-23 00:46:01 -07:00
|
|
|
|
2014-07-16 15:16:19 -06:00
|
|
|
if hint < 0 || int64(int32(hint)) != hint {
|
2016-03-27 18:29:53 -06:00
|
|
|
panic(plainError("makemap: size out of range"))
|
2014-07-16 15:16:19 -06:00
|
|
|
// TODO: make hint an int, then none of this nonsense
|
|
|
|
}
|
|
|
|
|
|
|
|
if !ismapkey(t.key) {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("runtime.makemap: unsupported map key type")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
2014-08-01 15:38:56 -06:00
|
|
|
// check compiler's and reflect's math
|
2015-11-11 10:39:30 -07:00
|
|
|
if t.key.size > maxKeySize && (!t.indirectkey || t.keysize != uint8(sys.PtrSize)) ||
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
t.key.size <= maxKeySize && (t.indirectkey || t.keysize != uint8(t.key.size)) {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("key size wrong")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2015-11-11 10:39:30 -07:00
|
|
|
if t.elem.size > maxValueSize && (!t.indirectvalue || t.valuesize != uint8(sys.PtrSize)) ||
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
t.elem.size <= maxValueSize && (t.indirectvalue || t.valuesize != uint8(t.elem.size)) {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("value size wrong")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
2016-03-01 16:21:55 -07:00
|
|
|
// invariants we depend on. We should probably check these at compile time
|
2014-07-16 15:16:19 -06:00
|
|
|
// somewhere, but for now we'll do it here.
|
|
|
|
if t.key.align > bucketCnt {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("key align too big")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
if t.elem.align > bucketCnt {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("value align too big")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2016-02-29 16:01:00 -07:00
|
|
|
if t.key.size%uintptr(t.key.align) != 0 {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("key size not a multiple of key align")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2016-02-29 16:01:00 -07:00
|
|
|
if t.elem.size%uintptr(t.elem.align) != 0 {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("value size not a multiple of value align")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
if bucketCnt < 8 {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("bucketsize too small for proper alignment")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
if dataOffset%uintptr(t.key.align) != 0 {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("need padding in bucket (key)")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
if dataOffset%uintptr(t.elem.align) != 0 {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("need padding in bucket (value)")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// find size parameter which will hold the requested # of elements
|
|
|
|
B := uint8(0)
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
for ; overLoadFactor(hint, B); B++ {
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// allocate initial hash table
|
|
|
|
// if B == 0, the buckets field is allocated lazily later (in mapassign)
|
|
|
|
// If hint is large zeroing this memory could take a while.
|
2015-01-29 09:40:02 -07:00
|
|
|
buckets := bucket
|
2014-07-16 15:16:19 -06:00
|
|
|
if B != 0 {
|
2016-04-20 10:00:52 -06:00
|
|
|
buckets = newarray(t.bucket, 1<<B)
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// initialize Hmap
|
2015-01-29 09:40:02 -07:00
|
|
|
if h == nil {
|
2016-02-23 00:46:01 -07:00
|
|
|
h = (*hmap)(newobject(t.hmap))
|
2015-01-29 09:40:02 -07:00
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
h.count = 0
|
|
|
|
h.B = B
|
2014-08-01 15:38:56 -06:00
|
|
|
h.flags = 0
|
2016-06-28 10:22:46 -06:00
|
|
|
h.hash0 = fastrand()
|
2014-07-16 15:16:19 -06:00
|
|
|
h.buckets = buckets
|
|
|
|
h.oldbuckets = nil
|
|
|
|
h.nevacuate = 0
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
h.noverflow = 0
|
2014-07-16 15:16:19 -06:00
|
|
|
|
|
|
|
return h
|
|
|
|
}
|
|
|
|
|
|
|
|
// mapaccess1 returns a pointer to h[key]. Never returns nil, instead
|
|
|
|
// it will return a reference to the zero object for the value type if
|
|
|
|
// the key is not in the map.
|
|
|
|
// NOTE: The returned pointer may keep the whole map live, so don't
|
|
|
|
// hold onto it for very long.
|
|
|
|
func mapaccess1(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
|
|
|
|
if raceenabled && h != nil {
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
callerpc := getcallerpc(unsafe.Pointer(&t))
|
2014-09-03 09:10:38 -06:00
|
|
|
pc := funcPC(mapaccess1)
|
2014-07-16 15:16:19 -06:00
|
|
|
racereadpc(unsafe.Pointer(h), callerpc, pc)
|
|
|
|
raceReadObjectPC(t.key, key, callerpc, pc)
|
|
|
|
}
|
2015-10-21 12:04:42 -06:00
|
|
|
if msanenabled && h != nil {
|
|
|
|
msanread(key, t.key.size)
|
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
if h == nil || h.count == 0 {
|
2016-04-19 09:31:04 -06:00
|
|
|
return unsafe.Pointer(&zeroVal[0])
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2015-12-07 12:22:08 -07:00
|
|
|
if h.flags&hashWriting != 0 {
|
|
|
|
throw("concurrent map read and map write")
|
|
|
|
}
|
2014-12-27 21:32:11 -07:00
|
|
|
alg := t.key.alg
|
2015-01-06 17:42:48 -07:00
|
|
|
hash := alg.hash(key, uintptr(h.hash0))
|
2014-07-16 15:16:19 -06:00
|
|
|
m := uintptr(1)<<h.B - 1
|
2014-08-01 15:38:56 -06:00
|
|
|
b := (*bmap)(add(h.buckets, (hash&m)*uintptr(t.bucketsize)))
|
2014-07-16 15:16:19 -06:00
|
|
|
if c := h.oldbuckets; c != nil {
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
if !h.sameSizeGrow() {
|
|
|
|
// There used to be half as many buckets; mask down one more power of two.
|
|
|
|
m >>= 1
|
|
|
|
}
|
|
|
|
oldb := (*bmap)(add(c, (hash&m)*uintptr(t.bucketsize)))
|
2014-07-16 15:16:19 -06:00
|
|
|
if !evacuated(oldb) {
|
|
|
|
b = oldb
|
|
|
|
}
|
|
|
|
}
|
2015-11-11 10:39:30 -07:00
|
|
|
top := uint8(hash >> (sys.PtrSize*8 - 8))
|
2014-07-16 15:16:19 -06:00
|
|
|
if top < minTopHash {
|
|
|
|
top += minTopHash
|
|
|
|
}
|
|
|
|
for {
|
|
|
|
for i := uintptr(0); i < bucketCnt; i++ {
|
|
|
|
if b.tophash[i] != top {
|
|
|
|
continue
|
|
|
|
}
|
2014-08-01 15:38:56 -06:00
|
|
|
k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
k = *((*unsafe.Pointer)(k))
|
|
|
|
}
|
2015-01-06 17:42:48 -07:00
|
|
|
if alg.equal(key, k) {
|
2014-08-01 15:38:56 -06:00
|
|
|
v := add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.valuesize))
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectvalue {
|
2014-07-16 15:16:19 -06:00
|
|
|
v = *((*unsafe.Pointer)(v))
|
|
|
|
}
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
}
|
2014-12-19 21:44:18 -07:00
|
|
|
b = b.overflow(t)
|
2014-07-16 15:16:19 -06:00
|
|
|
if b == nil {
|
2016-04-19 09:31:04 -06:00
|
|
|
return unsafe.Pointer(&zeroVal[0])
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func mapaccess2(t *maptype, h *hmap, key unsafe.Pointer) (unsafe.Pointer, bool) {
|
|
|
|
if raceenabled && h != nil {
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
callerpc := getcallerpc(unsafe.Pointer(&t))
|
2014-09-03 09:10:38 -06:00
|
|
|
pc := funcPC(mapaccess2)
|
2014-07-16 15:16:19 -06:00
|
|
|
racereadpc(unsafe.Pointer(h), callerpc, pc)
|
|
|
|
raceReadObjectPC(t.key, key, callerpc, pc)
|
|
|
|
}
|
2015-10-21 12:04:42 -06:00
|
|
|
if msanenabled && h != nil {
|
|
|
|
msanread(key, t.key.size)
|
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
if h == nil || h.count == 0 {
|
2016-04-19 09:31:04 -06:00
|
|
|
return unsafe.Pointer(&zeroVal[0]), false
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2015-12-07 12:22:08 -07:00
|
|
|
if h.flags&hashWriting != 0 {
|
|
|
|
throw("concurrent map read and map write")
|
|
|
|
}
|
2014-12-27 21:32:11 -07:00
|
|
|
alg := t.key.alg
|
2015-01-06 17:42:48 -07:00
|
|
|
hash := alg.hash(key, uintptr(h.hash0))
|
2014-07-16 15:16:19 -06:00
|
|
|
m := uintptr(1)<<h.B - 1
|
2014-08-01 15:38:56 -06:00
|
|
|
b := (*bmap)(unsafe.Pointer(uintptr(h.buckets) + (hash&m)*uintptr(t.bucketsize)))
|
2014-07-16 15:16:19 -06:00
|
|
|
if c := h.oldbuckets; c != nil {
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
if !h.sameSizeGrow() {
|
|
|
|
// There used to be half as many buckets; mask down one more power of two.
|
|
|
|
m >>= 1
|
|
|
|
}
|
|
|
|
oldb := (*bmap)(unsafe.Pointer(uintptr(c) + (hash&m)*uintptr(t.bucketsize)))
|
2014-07-16 15:16:19 -06:00
|
|
|
if !evacuated(oldb) {
|
|
|
|
b = oldb
|
|
|
|
}
|
|
|
|
}
|
2015-11-11 10:39:30 -07:00
|
|
|
top := uint8(hash >> (sys.PtrSize*8 - 8))
|
2014-07-16 15:16:19 -06:00
|
|
|
if top < minTopHash {
|
|
|
|
top += minTopHash
|
|
|
|
}
|
|
|
|
for {
|
|
|
|
for i := uintptr(0); i < bucketCnt; i++ {
|
|
|
|
if b.tophash[i] != top {
|
|
|
|
continue
|
|
|
|
}
|
2014-08-01 15:38:56 -06:00
|
|
|
k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
k = *((*unsafe.Pointer)(k))
|
|
|
|
}
|
2015-01-06 17:42:48 -07:00
|
|
|
if alg.equal(key, k) {
|
2014-08-01 15:38:56 -06:00
|
|
|
v := add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.valuesize))
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectvalue {
|
2014-07-16 15:16:19 -06:00
|
|
|
v = *((*unsafe.Pointer)(v))
|
|
|
|
}
|
|
|
|
return v, true
|
|
|
|
}
|
|
|
|
}
|
2014-12-19 21:44:18 -07:00
|
|
|
b = b.overflow(t)
|
2014-07-16 15:16:19 -06:00
|
|
|
if b == nil {
|
2016-04-19 09:31:04 -06:00
|
|
|
return unsafe.Pointer(&zeroVal[0]), false
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-01 16:21:55 -07:00
|
|
|
// returns both key and value. Used by map iterator
|
2014-07-16 15:16:19 -06:00
|
|
|
func mapaccessK(t *maptype, h *hmap, key unsafe.Pointer) (unsafe.Pointer, unsafe.Pointer) {
|
|
|
|
if h == nil || h.count == 0 {
|
|
|
|
return nil, nil
|
|
|
|
}
|
2014-12-27 21:32:11 -07:00
|
|
|
alg := t.key.alg
|
2015-01-06 17:42:48 -07:00
|
|
|
hash := alg.hash(key, uintptr(h.hash0))
|
2014-07-16 15:16:19 -06:00
|
|
|
m := uintptr(1)<<h.B - 1
|
2014-08-01 15:38:56 -06:00
|
|
|
b := (*bmap)(unsafe.Pointer(uintptr(h.buckets) + (hash&m)*uintptr(t.bucketsize)))
|
2014-07-16 15:16:19 -06:00
|
|
|
if c := h.oldbuckets; c != nil {
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
if !h.sameSizeGrow() {
|
|
|
|
// There used to be half as many buckets; mask down one more power of two.
|
|
|
|
m >>= 1
|
|
|
|
}
|
|
|
|
oldb := (*bmap)(unsafe.Pointer(uintptr(c) + (hash&m)*uintptr(t.bucketsize)))
|
2014-07-16 15:16:19 -06:00
|
|
|
if !evacuated(oldb) {
|
|
|
|
b = oldb
|
|
|
|
}
|
|
|
|
}
|
2015-11-11 10:39:30 -07:00
|
|
|
top := uint8(hash >> (sys.PtrSize*8 - 8))
|
2014-07-16 15:16:19 -06:00
|
|
|
if top < minTopHash {
|
|
|
|
top += minTopHash
|
|
|
|
}
|
|
|
|
for {
|
|
|
|
for i := uintptr(0); i < bucketCnt; i++ {
|
|
|
|
if b.tophash[i] != top {
|
|
|
|
continue
|
|
|
|
}
|
2014-08-01 15:38:56 -06:00
|
|
|
k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
k = *((*unsafe.Pointer)(k))
|
|
|
|
}
|
2015-01-06 17:42:48 -07:00
|
|
|
if alg.equal(key, k) {
|
2014-08-01 15:38:56 -06:00
|
|
|
v := add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.valuesize))
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectvalue {
|
2014-07-16 15:16:19 -06:00
|
|
|
v = *((*unsafe.Pointer)(v))
|
|
|
|
}
|
|
|
|
return k, v
|
|
|
|
}
|
|
|
|
}
|
2014-12-19 21:44:18 -07:00
|
|
|
b = b.overflow(t)
|
2014-07-16 15:16:19 -06:00
|
|
|
if b == nil {
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-19 09:31:04 -06:00
|
|
|
func mapaccess1_fat(t *maptype, h *hmap, key, zero unsafe.Pointer) unsafe.Pointer {
|
|
|
|
v := mapaccess1(t, h, key)
|
|
|
|
if v == unsafe.Pointer(&zeroVal[0]) {
|
|
|
|
return zero
|
|
|
|
}
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
|
|
|
|
func mapaccess2_fat(t *maptype, h *hmap, key, zero unsafe.Pointer) (unsafe.Pointer, bool) {
|
|
|
|
v := mapaccess1(t, h, key)
|
|
|
|
if v == unsafe.Pointer(&zeroVal[0]) {
|
|
|
|
return zero, false
|
|
|
|
}
|
|
|
|
return v, true
|
|
|
|
}
|
|
|
|
|
2016-10-11 09:36:38 -06:00
|
|
|
// Like mapaccess, but allocates a slot for the key if it is not present in the map.
|
|
|
|
func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
|
2014-07-16 15:16:19 -06:00
|
|
|
if h == nil {
|
2016-03-27 18:29:53 -06:00
|
|
|
panic(plainError("assignment to entry in nil map"))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
if raceenabled {
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
callerpc := getcallerpc(unsafe.Pointer(&t))
|
2016-10-11 09:36:38 -06:00
|
|
|
pc := funcPC(mapassign)
|
2014-07-16 15:16:19 -06:00
|
|
|
racewritepc(unsafe.Pointer(h), callerpc, pc)
|
|
|
|
raceReadObjectPC(t.key, key, callerpc, pc)
|
|
|
|
}
|
2015-10-21 12:04:42 -06:00
|
|
|
if msanenabled {
|
|
|
|
msanread(key, t.key.size)
|
|
|
|
}
|
2015-12-07 12:22:08 -07:00
|
|
|
if h.flags&hashWriting != 0 {
|
|
|
|
throw("concurrent map writes")
|
|
|
|
}
|
|
|
|
h.flags |= hashWriting
|
2014-07-16 15:16:19 -06:00
|
|
|
|
2014-12-27 21:32:11 -07:00
|
|
|
alg := t.key.alg
|
2015-01-06 17:42:48 -07:00
|
|
|
hash := alg.hash(key, uintptr(h.hash0))
|
2014-07-16 15:16:19 -06:00
|
|
|
|
|
|
|
if h.buckets == nil {
|
2014-07-30 10:01:52 -06:00
|
|
|
h.buckets = newarray(t.bucket, 1)
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
again:
|
|
|
|
bucket := hash & (uintptr(1)<<h.B - 1)
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
if h.growing() {
|
2014-07-16 15:16:19 -06:00
|
|
|
growWork(t, h, bucket)
|
|
|
|
}
|
2014-08-01 15:38:56 -06:00
|
|
|
b := (*bmap)(unsafe.Pointer(uintptr(h.buckets) + bucket*uintptr(t.bucketsize)))
|
2015-11-11 10:39:30 -07:00
|
|
|
top := uint8(hash >> (sys.PtrSize*8 - 8))
|
2014-07-16 15:16:19 -06:00
|
|
|
if top < minTopHash {
|
|
|
|
top += minTopHash
|
|
|
|
}
|
|
|
|
|
|
|
|
var inserti *uint8
|
|
|
|
var insertk unsafe.Pointer
|
2016-10-11 09:36:38 -06:00
|
|
|
var val unsafe.Pointer
|
2014-07-16 15:16:19 -06:00
|
|
|
for {
|
|
|
|
for i := uintptr(0); i < bucketCnt; i++ {
|
|
|
|
if b.tophash[i] != top {
|
|
|
|
if b.tophash[i] == empty && inserti == nil {
|
|
|
|
inserti = &b.tophash[i]
|
2014-08-01 15:38:56 -06:00
|
|
|
insertk = add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
|
2016-10-11 09:36:38 -06:00
|
|
|
val = add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.valuesize))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
continue
|
|
|
|
}
|
2014-08-01 15:38:56 -06:00
|
|
|
k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2016-10-11 09:36:38 -06:00
|
|
|
k = *((*unsafe.Pointer)(k))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2016-10-11 09:36:38 -06:00
|
|
|
if !alg.equal(key, k) {
|
2014-07-16 15:16:19 -06:00
|
|
|
continue
|
|
|
|
}
|
2016-03-01 16:21:55 -07:00
|
|
|
// already have a mapping for key. Update it.
|
2015-06-08 09:42:28 -06:00
|
|
|
if t.needkeyupdate {
|
2016-10-11 09:36:38 -06:00
|
|
|
typedmemmove(t.key, k, key)
|
2015-06-08 09:42:28 -06:00
|
|
|
}
|
2016-10-11 09:36:38 -06:00
|
|
|
val = add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.valuesize))
|
2015-12-07 12:22:08 -07:00
|
|
|
goto done
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2014-12-19 21:44:18 -07:00
|
|
|
ovf := b.overflow(t)
|
|
|
|
if ovf == nil {
|
2014-07-16 15:16:19 -06:00
|
|
|
break
|
|
|
|
}
|
2014-12-19 21:44:18 -07:00
|
|
|
b = ovf
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
// Did not find mapping for key. Allocate new cell & add entry.
|
|
|
|
|
|
|
|
// If we hit the max load factor or we have too many overflow buckets,
|
|
|
|
// and we're not already in the middle of growing, start growing.
|
|
|
|
if !h.growing() && (overLoadFactor(int64(h.count), h.B) || tooManyOverflowBuckets(h.noverflow, h.B)) {
|
2014-07-16 15:16:19 -06:00
|
|
|
hashGrow(t, h)
|
|
|
|
goto again // Growing the table invalidates everything, so try again
|
|
|
|
}
|
|
|
|
|
|
|
|
if inserti == nil {
|
|
|
|
// all current buckets are full, allocate a new one.
|
2014-07-30 10:01:52 -06:00
|
|
|
newb := (*bmap)(newobject(t.bucket))
|
2015-01-26 11:04:41 -07:00
|
|
|
h.setoverflow(t, b, newb)
|
2014-07-16 15:16:19 -06:00
|
|
|
inserti = &newb.tophash[0]
|
|
|
|
insertk = add(unsafe.Pointer(newb), dataOffset)
|
2016-10-11 09:36:38 -06:00
|
|
|
val = add(insertk, bucketCnt*uintptr(t.keysize))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// store new key/value at insert position
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-30 10:01:52 -06:00
|
|
|
kmem := newobject(t.key)
|
2014-07-16 15:16:19 -06:00
|
|
|
*(*unsafe.Pointer)(insertk) = kmem
|
|
|
|
insertk = kmem
|
|
|
|
}
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectvalue {
|
2014-07-30 10:01:52 -06:00
|
|
|
vmem := newobject(t.elem)
|
2016-10-11 09:36:38 -06:00
|
|
|
*(*unsafe.Pointer)(val) = vmem
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2014-12-29 08:07:47 -07:00
|
|
|
typedmemmove(t.key, insertk, key)
|
2014-07-16 15:16:19 -06:00
|
|
|
*inserti = top
|
|
|
|
h.count++
|
2015-12-07 12:22:08 -07:00
|
|
|
|
|
|
|
done:
|
|
|
|
if h.flags&hashWriting == 0 {
|
|
|
|
throw("concurrent map writes")
|
|
|
|
}
|
|
|
|
h.flags &^= hashWriting
|
2016-10-11 09:36:38 -06:00
|
|
|
if t.indirectvalue {
|
|
|
|
val = *((*unsafe.Pointer)(val))
|
|
|
|
}
|
|
|
|
return val
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func mapdelete(t *maptype, h *hmap, key unsafe.Pointer) {
|
|
|
|
if raceenabled && h != nil {
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
callerpc := getcallerpc(unsafe.Pointer(&t))
|
2014-09-03 09:10:38 -06:00
|
|
|
pc := funcPC(mapdelete)
|
2014-07-16 15:16:19 -06:00
|
|
|
racewritepc(unsafe.Pointer(h), callerpc, pc)
|
|
|
|
raceReadObjectPC(t.key, key, callerpc, pc)
|
|
|
|
}
|
2015-10-21 12:04:42 -06:00
|
|
|
if msanenabled && h != nil {
|
|
|
|
msanread(key, t.key.size)
|
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
if h == nil || h.count == 0 {
|
|
|
|
return
|
|
|
|
}
|
2015-12-07 12:22:08 -07:00
|
|
|
if h.flags&hashWriting != 0 {
|
|
|
|
throw("concurrent map writes")
|
|
|
|
}
|
|
|
|
h.flags |= hashWriting
|
|
|
|
|
2014-12-27 21:32:11 -07:00
|
|
|
alg := t.key.alg
|
2015-01-06 17:42:48 -07:00
|
|
|
hash := alg.hash(key, uintptr(h.hash0))
|
2014-07-16 15:16:19 -06:00
|
|
|
bucket := hash & (uintptr(1)<<h.B - 1)
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
if h.growing() {
|
2014-07-16 15:16:19 -06:00
|
|
|
growWork(t, h, bucket)
|
|
|
|
}
|
2014-08-01 15:38:56 -06:00
|
|
|
b := (*bmap)(unsafe.Pointer(uintptr(h.buckets) + bucket*uintptr(t.bucketsize)))
|
2015-11-11 10:39:30 -07:00
|
|
|
top := uint8(hash >> (sys.PtrSize*8 - 8))
|
2014-07-16 15:16:19 -06:00
|
|
|
if top < minTopHash {
|
|
|
|
top += minTopHash
|
|
|
|
}
|
|
|
|
for {
|
|
|
|
for i := uintptr(0); i < bucketCnt; i++ {
|
|
|
|
if b.tophash[i] != top {
|
|
|
|
continue
|
|
|
|
}
|
2014-08-01 15:38:56 -06:00
|
|
|
k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
|
2014-07-16 15:16:19 -06:00
|
|
|
k2 := k
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
k2 = *((*unsafe.Pointer)(k2))
|
|
|
|
}
|
2015-01-06 17:42:48 -07:00
|
|
|
if !alg.equal(key, k2) {
|
2014-07-16 15:16:19 -06:00
|
|
|
continue
|
|
|
|
}
|
2016-10-17 15:00:05 -06:00
|
|
|
if t.indirectkey {
|
|
|
|
*(*unsafe.Pointer)(k) = nil
|
|
|
|
} else {
|
|
|
|
typedmemclr(t.key, k)
|
|
|
|
}
|
2014-08-01 15:38:56 -06:00
|
|
|
v := unsafe.Pointer(uintptr(unsafe.Pointer(b)) + dataOffset + bucketCnt*uintptr(t.keysize) + i*uintptr(t.valuesize))
|
2016-10-17 15:00:05 -06:00
|
|
|
if t.indirectvalue {
|
|
|
|
*(*unsafe.Pointer)(v) = nil
|
|
|
|
} else {
|
|
|
|
typedmemclr(t.elem, v)
|
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
b.tophash[i] = empty
|
|
|
|
h.count--
|
2015-12-07 12:22:08 -07:00
|
|
|
goto done
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2014-12-19 21:44:18 -07:00
|
|
|
b = b.overflow(t)
|
2014-07-16 15:16:19 -06:00
|
|
|
if b == nil {
|
2015-12-07 12:22:08 -07:00
|
|
|
goto done
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
}
|
2015-12-07 12:22:08 -07:00
|
|
|
|
|
|
|
done:
|
|
|
|
if h.flags&hashWriting == 0 {
|
|
|
|
throw("concurrent map writes")
|
|
|
|
}
|
|
|
|
h.flags &^= hashWriting
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func mapiterinit(t *maptype, h *hmap, it *hiter) {
|
|
|
|
// Clear pointer fields so garbage collector does not complain.
|
|
|
|
it.key = nil
|
|
|
|
it.value = nil
|
|
|
|
it.t = nil
|
|
|
|
it.h = nil
|
|
|
|
it.buckets = nil
|
|
|
|
it.bptr = nil
|
2015-01-26 11:04:41 -07:00
|
|
|
it.overflow[0] = nil
|
|
|
|
it.overflow[1] = nil
|
2014-07-16 15:16:19 -06:00
|
|
|
|
|
|
|
if raceenabled && h != nil {
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
callerpc := getcallerpc(unsafe.Pointer(&t))
|
2014-09-03 09:10:38 -06:00
|
|
|
racereadpc(unsafe.Pointer(h), callerpc, funcPC(mapiterinit))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
if h == nil || h.count == 0 {
|
|
|
|
it.key = nil
|
|
|
|
it.value = nil
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2015-11-11 10:39:30 -07:00
|
|
|
if unsafe.Sizeof(hiter{})/sys.PtrSize != 12 {
|
2015-03-11 13:58:47 -06:00
|
|
|
throw("hash_iter size incorrect") // see ../../cmd/internal/gc/reflect.go
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
it.t = t
|
|
|
|
it.h = h
|
|
|
|
|
|
|
|
// grab snapshot of bucket state
|
|
|
|
it.B = h.B
|
|
|
|
it.buckets = h.buckets
|
2015-01-26 11:04:41 -07:00
|
|
|
if t.bucket.kind&kindNoPointers != 0 {
|
|
|
|
// Allocate the current slice and remember pointers to both current and old.
|
|
|
|
// This preserves all relevant overflow buckets alive even if
|
|
|
|
// the table grows and/or overflow buckets are added to the table
|
|
|
|
// while we are iterating.
|
|
|
|
h.createOverflow()
|
|
|
|
it.overflow = *h.overflow
|
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
|
2014-09-08 18:42:21 -06:00
|
|
|
// decide where to start
|
2016-06-28 10:22:46 -06:00
|
|
|
r := uintptr(fastrand())
|
2014-09-09 15:22:58 -06:00
|
|
|
if h.B > 31-bucketCntBits {
|
2016-06-28 10:22:46 -06:00
|
|
|
r += uintptr(fastrand()) << 31
|
2014-09-08 18:42:21 -06:00
|
|
|
}
|
2014-09-09 15:22:58 -06:00
|
|
|
it.startBucket = r & (uintptr(1)<<h.B - 1)
|
|
|
|
it.offset = uint8(r >> h.B & (bucketCnt - 1))
|
2014-09-08 18:42:21 -06:00
|
|
|
|
2014-07-16 15:16:19 -06:00
|
|
|
// iterator state
|
2014-09-08 18:42:21 -06:00
|
|
|
it.bucket = it.startBucket
|
|
|
|
it.wrapped = false
|
2014-07-16 15:16:19 -06:00
|
|
|
it.bptr = nil
|
|
|
|
|
|
|
|
// Remember we have an iterator.
|
|
|
|
// Can run concurrently with another hash_iter_init().
|
2015-01-26 11:04:41 -07:00
|
|
|
if old := h.flags; old&(iterator|oldIterator) != iterator|oldIterator {
|
2015-11-02 12:09:24 -07:00
|
|
|
atomic.Or8(&h.flags, iterator|oldIterator)
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
mapiternext(it)
|
|
|
|
}
|
|
|
|
|
|
|
|
func mapiternext(it *hiter) {
|
|
|
|
h := it.h
|
|
|
|
if raceenabled {
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
callerpc := getcallerpc(unsafe.Pointer(&it))
|
2014-09-03 09:10:38 -06:00
|
|
|
racereadpc(unsafe.Pointer(h), callerpc, funcPC(mapiternext))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
2016-07-06 16:02:49 -06:00
|
|
|
if h.flags&hashWriting != 0 {
|
|
|
|
throw("concurrent map iteration and map write")
|
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
t := it.t
|
|
|
|
bucket := it.bucket
|
|
|
|
b := it.bptr
|
|
|
|
i := it.i
|
|
|
|
checkBucket := it.checkBucket
|
2014-12-27 21:32:11 -07:00
|
|
|
alg := t.key.alg
|
2014-07-16 15:16:19 -06:00
|
|
|
|
|
|
|
next:
|
|
|
|
if b == nil {
|
2014-09-08 18:42:21 -06:00
|
|
|
if bucket == it.startBucket && it.wrapped {
|
2014-07-16 15:16:19 -06:00
|
|
|
// end of iteration
|
|
|
|
it.key = nil
|
|
|
|
it.value = nil
|
|
|
|
return
|
|
|
|
}
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
if h.growing() && it.B == h.B {
|
2014-07-16 15:16:19 -06:00
|
|
|
// Iterator was started in the middle of a grow, and the grow isn't done yet.
|
|
|
|
// If the bucket we're looking at hasn't been filled in yet (i.e. the old
|
|
|
|
// bucket hasn't been evacuated) then we need to iterate through the old
|
|
|
|
// bucket and only return the ones that will be migrated to this bucket.
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
oldbucket := bucket & it.h.oldbucketmask()
|
2014-08-01 15:38:56 -06:00
|
|
|
b = (*bmap)(add(h.oldbuckets, oldbucket*uintptr(t.bucketsize)))
|
2014-07-16 15:16:19 -06:00
|
|
|
if !evacuated(b) {
|
|
|
|
checkBucket = bucket
|
|
|
|
} else {
|
2014-08-01 15:38:56 -06:00
|
|
|
b = (*bmap)(add(it.buckets, bucket*uintptr(t.bucketsize)))
|
2014-07-16 15:16:19 -06:00
|
|
|
checkBucket = noCheck
|
|
|
|
}
|
|
|
|
} else {
|
2014-08-01 15:38:56 -06:00
|
|
|
b = (*bmap)(add(it.buckets, bucket*uintptr(t.bucketsize)))
|
2014-07-16 15:16:19 -06:00
|
|
|
checkBucket = noCheck
|
|
|
|
}
|
|
|
|
bucket++
|
|
|
|
if bucket == uintptr(1)<<it.B {
|
|
|
|
bucket = 0
|
2014-09-08 18:42:21 -06:00
|
|
|
it.wrapped = true
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
i = 0
|
|
|
|
}
|
|
|
|
for ; i < bucketCnt; i++ {
|
2014-09-08 18:42:21 -06:00
|
|
|
offi := (i + it.offset) & (bucketCnt - 1)
|
|
|
|
k := add(unsafe.Pointer(b), dataOffset+uintptr(offi)*uintptr(t.keysize))
|
|
|
|
v := add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+uintptr(offi)*uintptr(t.valuesize))
|
2014-07-16 15:16:19 -06:00
|
|
|
if b.tophash[offi] != empty && b.tophash[offi] != evacuatedEmpty {
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
if checkBucket != noCheck && !h.sameSizeGrow() {
|
|
|
|
// Special case: iterator was started during a grow to a larger size
|
|
|
|
// and the grow is not done yet. We're working on a bucket whose
|
2016-03-01 16:21:55 -07:00
|
|
|
// oldbucket has not been evacuated yet. Or at least, it wasn't
|
|
|
|
// evacuated when we started the bucket. So we're iterating
|
2014-07-16 15:16:19 -06:00
|
|
|
// through the oldbucket, skipping any keys that will go
|
|
|
|
// to the other new bucket (each oldbucket expands to two
|
|
|
|
// buckets during a grow).
|
|
|
|
k2 := k
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
k2 = *((*unsafe.Pointer)(k2))
|
|
|
|
}
|
2015-01-06 17:42:48 -07:00
|
|
|
if t.reflexivekey || alg.equal(k2, k2) {
|
2014-07-16 15:16:19 -06:00
|
|
|
// If the item in the oldbucket is not destined for
|
|
|
|
// the current new bucket in the iteration, skip it.
|
2015-01-06 17:42:48 -07:00
|
|
|
hash := alg.hash(k2, uintptr(h.hash0))
|
2014-07-16 15:16:19 -06:00
|
|
|
if hash&(uintptr(1)<<it.B-1) != checkBucket {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// Hash isn't repeatable if k != k (NaNs). We need a
|
|
|
|
// repeatable and randomish choice of which direction
|
2016-03-01 16:21:55 -07:00
|
|
|
// to send NaNs during evacuation. We'll use the low
|
2014-07-16 15:16:19 -06:00
|
|
|
// bit of tophash to decide which way NaNs go.
|
|
|
|
// NOTE: this case is why we need two evacuate tophash
|
|
|
|
// values, evacuatedX and evacuatedY, that differ in
|
|
|
|
// their low bit.
|
|
|
|
if checkBucket>>(it.B-1) != uintptr(b.tophash[offi]&1) {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if b.tophash[offi] != evacuatedX && b.tophash[offi] != evacuatedY {
|
|
|
|
// this is the golden data, we can return it.
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
k = *((*unsafe.Pointer)(k))
|
|
|
|
}
|
|
|
|
it.key = k
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectvalue {
|
2014-07-16 15:16:19 -06:00
|
|
|
v = *((*unsafe.Pointer)(v))
|
|
|
|
}
|
|
|
|
it.value = v
|
|
|
|
} else {
|
|
|
|
// The hash table has grown since the iterator was started.
|
|
|
|
// The golden data for this key is now somewhere else.
|
|
|
|
k2 := k
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
k2 = *((*unsafe.Pointer)(k2))
|
|
|
|
}
|
2015-01-06 17:42:48 -07:00
|
|
|
if t.reflexivekey || alg.equal(k2, k2) {
|
2014-07-16 15:16:19 -06:00
|
|
|
// Check the current hash table for the data.
|
|
|
|
// This code handles the case where the key
|
|
|
|
// has been deleted, updated, or deleted and reinserted.
|
|
|
|
// NOTE: we need to regrab the key as it has potentially been
|
|
|
|
// updated to an equal() but not identical key (e.g. +0.0 vs -0.0).
|
|
|
|
rk, rv := mapaccessK(t, h, k2)
|
|
|
|
if rk == nil {
|
|
|
|
continue // key has been deleted
|
|
|
|
}
|
|
|
|
it.key = rk
|
|
|
|
it.value = rv
|
|
|
|
} else {
|
|
|
|
// if key!=key then the entry can't be deleted or
|
2016-03-01 16:21:55 -07:00
|
|
|
// updated, so we can just return it. That's lucky for
|
2014-07-16 15:16:19 -06:00
|
|
|
// us because when key!=key we can't look it up
|
|
|
|
// successfully in the current table.
|
|
|
|
it.key = k2
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectvalue {
|
2014-07-16 15:16:19 -06:00
|
|
|
v = *((*unsafe.Pointer)(v))
|
|
|
|
}
|
|
|
|
it.value = v
|
|
|
|
}
|
|
|
|
}
|
|
|
|
it.bucket = bucket
|
2016-04-10 11:43:04 -06:00
|
|
|
if it.bptr != b { // avoid unnecessary write barrier; see issue 14921
|
|
|
|
it.bptr = b
|
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
it.i = i + 1
|
|
|
|
it.checkBucket = checkBucket
|
|
|
|
return
|
|
|
|
}
|
|
|
|
}
|
2014-12-19 21:44:18 -07:00
|
|
|
b = b.overflow(t)
|
2014-07-16 15:16:19 -06:00
|
|
|
i = 0
|
|
|
|
goto next
|
|
|
|
}
|
|
|
|
|
|
|
|
func hashGrow(t *maptype, h *hmap) {
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
// If we've hit the load factor, get bigger.
|
|
|
|
// Otherwise, there are too many overflow buckets,
|
|
|
|
// so keep the same number of buckets and "grow" laterally.
|
|
|
|
bigger := uint8(1)
|
|
|
|
if !overLoadFactor(int64(h.count), h.B) {
|
|
|
|
bigger = 0
|
|
|
|
h.flags |= sameSizeGrow
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
oldbuckets := h.buckets
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
newbuckets := newarray(t.bucket, 1<<(h.B+bigger))
|
2014-07-16 15:16:19 -06:00
|
|
|
flags := h.flags &^ (iterator | oldIterator)
|
|
|
|
if h.flags&iterator != 0 {
|
|
|
|
flags |= oldIterator
|
|
|
|
}
|
|
|
|
// commit the grow (atomic wrt gc)
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
h.B += bigger
|
2014-07-16 15:16:19 -06:00
|
|
|
h.flags = flags
|
|
|
|
h.oldbuckets = oldbuckets
|
|
|
|
h.buckets = newbuckets
|
|
|
|
h.nevacuate = 0
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
h.noverflow = 0
|
2014-07-16 15:16:19 -06:00
|
|
|
|
2015-01-26 11:04:41 -07:00
|
|
|
if h.overflow != nil {
|
|
|
|
// Promote current overflow buckets to the old generation.
|
|
|
|
if h.overflow[1] != nil {
|
|
|
|
throw("overflow is not nil")
|
|
|
|
}
|
|
|
|
h.overflow[1] = h.overflow[0]
|
|
|
|
h.overflow[0] = nil
|
|
|
|
}
|
|
|
|
|
2014-07-16 15:16:19 -06:00
|
|
|
// the actual copying of the hash table data is done incrementally
|
|
|
|
// by growWork() and evacuate().
|
|
|
|
}
|
|
|
|
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
// overLoadFactor reports whether count items placed in 1<<B buckets is over loadFactor.
|
|
|
|
func overLoadFactor(count int64, B uint8) bool {
|
|
|
|
// TODO: rewrite to use integer math and comparison?
|
|
|
|
return count >= bucketCnt && float32(count) >= loadFactor*float32((uintptr(1)<<B))
|
|
|
|
}
|
|
|
|
|
|
|
|
// tooManyOverflowBuckets reports whether noverflow buckets is too many for a map with 1<<B buckets.
|
|
|
|
// Note that most of these overflow buckets must be in sparse use;
|
|
|
|
// if use was dense, then we'd have already triggered regular map growth.
|
|
|
|
func tooManyOverflowBuckets(noverflow uint16, B uint8) bool {
|
|
|
|
// If the threshold is too low, we do extraneous work.
|
|
|
|
// If the threshold is too high, maps that grow and shrink can hold on to lots of unused memory.
|
|
|
|
// "too many" means (approximately) as many overflow buckets as regular buckets.
|
|
|
|
// See incrnoverflow for more details.
|
|
|
|
if B < 16 {
|
|
|
|
return noverflow >= uint16(1)<<B
|
|
|
|
}
|
|
|
|
return noverflow >= 1<<15
|
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
// growing reports whether h is growing. The growth may be to the same size or bigger.
|
|
|
|
func (h *hmap) growing() bool {
|
|
|
|
return h.oldbuckets != nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// sameSizeGrow reports whether the current growth is to a map of the same size.
|
|
|
|
func (h *hmap) sameSizeGrow() bool {
|
|
|
|
return h.flags&sameSizeGrow != 0
|
|
|
|
}
|
|
|
|
|
|
|
|
// noldbuckets calculates the number of buckets prior to the current map growth.
|
|
|
|
func (h *hmap) noldbuckets() uintptr {
|
|
|
|
oldB := h.B
|
|
|
|
if !h.sameSizeGrow() {
|
|
|
|
oldB--
|
|
|
|
}
|
|
|
|
return uintptr(1) << oldB
|
|
|
|
}
|
|
|
|
|
|
|
|
// oldbucketmask provides a mask that can be applied to calculate n % noldbuckets().
|
|
|
|
func (h *hmap) oldbucketmask() uintptr {
|
|
|
|
return h.noldbuckets() - 1
|
|
|
|
}
|
|
|
|
|
|
|
|
func growWork(t *maptype, h *hmap, bucket uintptr) {
|
2014-07-16 15:16:19 -06:00
|
|
|
// make sure we evacuate the oldbucket corresponding
|
|
|
|
// to the bucket we're about to use
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
evacuate(t, h, bucket&h.oldbucketmask())
|
2014-07-16 15:16:19 -06:00
|
|
|
|
|
|
|
// evacuate one more oldbucket to make progress on growing
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
if h.growing() {
|
2014-07-16 15:16:19 -06:00
|
|
|
evacuate(t, h, h.nevacuate)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func evacuate(t *maptype, h *hmap, oldbucket uintptr) {
|
2014-08-01 15:38:56 -06:00
|
|
|
b := (*bmap)(add(h.oldbuckets, oldbucket*uintptr(t.bucketsize)))
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
newbit := h.noldbuckets()
|
2014-12-27 21:32:11 -07:00
|
|
|
alg := t.key.alg
|
2014-07-16 15:16:19 -06:00
|
|
|
if !evacuated(b) {
|
|
|
|
// TODO: reuse overflow buckets instead of using new ones, if there
|
|
|
|
// is no iterator using the old buckets. (If !oldIterator.)
|
|
|
|
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
var (
|
|
|
|
x, y *bmap // current low/high buckets in new map
|
|
|
|
xi, yi int // key/val indices into x and y
|
|
|
|
xk, yk unsafe.Pointer // pointers to current x and y key storage
|
|
|
|
xv, yv unsafe.Pointer // pointers to current x and y value storage
|
|
|
|
)
|
|
|
|
x = (*bmap)(add(h.buckets, oldbucket*uintptr(t.bucketsize)))
|
|
|
|
xi = 0
|
|
|
|
xk = add(unsafe.Pointer(x), dataOffset)
|
|
|
|
xv = add(xk, bucketCnt*uintptr(t.keysize))
|
|
|
|
if !h.sameSizeGrow() {
|
|
|
|
// Only calculate y pointers if we're growing bigger.
|
|
|
|
// Otherwise GC can see bad pointers.
|
|
|
|
y = (*bmap)(add(h.buckets, (oldbucket+newbit)*uintptr(t.bucketsize)))
|
|
|
|
yi = 0
|
|
|
|
yk = add(unsafe.Pointer(y), dataOffset)
|
|
|
|
yv = add(yk, bucketCnt*uintptr(t.keysize))
|
|
|
|
}
|
2014-12-19 21:44:18 -07:00
|
|
|
for ; b != nil; b = b.overflow(t) {
|
2014-07-16 15:16:19 -06:00
|
|
|
k := add(unsafe.Pointer(b), dataOffset)
|
2014-08-01 15:38:56 -06:00
|
|
|
v := add(k, bucketCnt*uintptr(t.keysize))
|
|
|
|
for i := 0; i < bucketCnt; i, k, v = i+1, add(k, uintptr(t.keysize)), add(v, uintptr(t.valuesize)) {
|
2014-07-16 15:16:19 -06:00
|
|
|
top := b.tophash[i]
|
|
|
|
if top == empty {
|
|
|
|
b.tophash[i] = evacuatedEmpty
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if top < minTopHash {
|
2014-12-27 21:58:00 -07:00
|
|
|
throw("bad map state")
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
k2 := k
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
k2 = *((*unsafe.Pointer)(k2))
|
|
|
|
}
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
useX := true
|
|
|
|
if !h.sameSizeGrow() {
|
|
|
|
// Compute hash to make our evacuation decision (whether we need
|
|
|
|
// to send this key/value to bucket x or bucket y).
|
|
|
|
hash := alg.hash(k2, uintptr(h.hash0))
|
|
|
|
if h.flags&iterator != 0 {
|
|
|
|
if !t.reflexivekey && !alg.equal(k2, k2) {
|
|
|
|
// If key != key (NaNs), then the hash could be (and probably
|
|
|
|
// will be) entirely different from the old hash. Moreover,
|
|
|
|
// it isn't reproducible. Reproducibility is required in the
|
|
|
|
// presence of iterators, as our evacuation decision must
|
|
|
|
// match whatever decision the iterator made.
|
|
|
|
// Fortunately, we have the freedom to send these keys either
|
|
|
|
// way. Also, tophash is meaningless for these kinds of keys.
|
|
|
|
// We let the low bit of tophash drive the evacuation decision.
|
|
|
|
// We recompute a new random tophash for the next level so
|
|
|
|
// these keys will get evenly distributed across all buckets
|
|
|
|
// after multiple grows.
|
|
|
|
if top&1 != 0 {
|
|
|
|
hash |= newbit
|
|
|
|
} else {
|
|
|
|
hash &^= newbit
|
|
|
|
}
|
|
|
|
top = uint8(hash >> (sys.PtrSize*8 - 8))
|
|
|
|
if top < minTopHash {
|
|
|
|
top += minTopHash
|
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
}
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
useX = hash&newbit == 0
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
if useX {
|
2014-07-16 15:16:19 -06:00
|
|
|
b.tophash[i] = evacuatedX
|
|
|
|
if xi == bucketCnt {
|
2014-07-30 10:01:52 -06:00
|
|
|
newx := (*bmap)(newobject(t.bucket))
|
2015-01-26 11:04:41 -07:00
|
|
|
h.setoverflow(t, x, newx)
|
2014-07-16 15:16:19 -06:00
|
|
|
x = newx
|
|
|
|
xi = 0
|
|
|
|
xk = add(unsafe.Pointer(x), dataOffset)
|
2014-08-01 15:38:56 -06:00
|
|
|
xv = add(xk, bucketCnt*uintptr(t.keysize))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
x.tophash[xi] = top
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
*(*unsafe.Pointer)(xk) = k2 // copy pointer
|
|
|
|
} else {
|
2014-12-29 08:07:47 -07:00
|
|
|
typedmemmove(t.key, xk, k) // copy value
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectvalue {
|
2014-07-16 15:16:19 -06:00
|
|
|
*(*unsafe.Pointer)(xv) = *(*unsafe.Pointer)(v)
|
|
|
|
} else {
|
2014-12-29 08:07:47 -07:00
|
|
|
typedmemmove(t.elem, xv, v)
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
xi++
|
2014-08-01 15:38:56 -06:00
|
|
|
xk = add(xk, uintptr(t.keysize))
|
|
|
|
xv = add(xv, uintptr(t.valuesize))
|
2014-07-16 15:16:19 -06:00
|
|
|
} else {
|
|
|
|
b.tophash[i] = evacuatedY
|
|
|
|
if yi == bucketCnt {
|
2014-07-30 10:01:52 -06:00
|
|
|
newy := (*bmap)(newobject(t.bucket))
|
2015-01-26 11:04:41 -07:00
|
|
|
h.setoverflow(t, y, newy)
|
2014-07-16 15:16:19 -06:00
|
|
|
y = newy
|
|
|
|
yi = 0
|
|
|
|
yk = add(unsafe.Pointer(y), dataOffset)
|
2014-08-01 15:38:56 -06:00
|
|
|
yv = add(yk, bucketCnt*uintptr(t.keysize))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
y.tophash[yi] = top
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectkey {
|
2014-07-16 15:16:19 -06:00
|
|
|
*(*unsafe.Pointer)(yk) = k2
|
|
|
|
} else {
|
2014-12-29 08:07:47 -07:00
|
|
|
typedmemmove(t.key, yk, k)
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
if t.indirectvalue {
|
2014-07-16 15:16:19 -06:00
|
|
|
*(*unsafe.Pointer)(yv) = *(*unsafe.Pointer)(v)
|
|
|
|
} else {
|
2014-12-29 08:07:47 -07:00
|
|
|
typedmemmove(t.elem, yv, v)
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
yi++
|
2014-08-01 15:38:56 -06:00
|
|
|
yk = add(yk, uintptr(t.keysize))
|
|
|
|
yv = add(yv, uintptr(t.valuesize))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// Unlink the overflow buckets & clear key/value to help GC.
|
|
|
|
if h.flags&oldIterator == 0 {
|
2014-08-01 15:38:56 -06:00
|
|
|
b = (*bmap)(add(h.oldbuckets, oldbucket*uintptr(t.bucketsize)))
|
2016-09-26 11:10:41 -06:00
|
|
|
// Preserve b.tophash because the evacuation
|
|
|
|
// state is maintained there.
|
2016-10-17 15:00:05 -06:00
|
|
|
if t.bucket.kind&kindNoPointers == 0 {
|
|
|
|
memclrHasPointers(add(unsafe.Pointer(b), dataOffset), uintptr(t.bucketsize)-dataOffset)
|
|
|
|
} else {
|
2016-10-17 16:41:56 -06:00
|
|
|
memclrNoHeapPointers(add(unsafe.Pointer(b), dataOffset), uintptr(t.bucketsize)-dataOffset)
|
2016-10-17 15:00:05 -06:00
|
|
|
}
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Advance evacuation mark
|
|
|
|
if oldbucket == h.nevacuate {
|
|
|
|
h.nevacuate = oldbucket + 1
|
|
|
|
if oldbucket+1 == newbit { // newbit == # of oldbuckets
|
2016-03-01 16:21:55 -07:00
|
|
|
// Growing is all done. Free old main bucket array.
|
2014-07-16 15:16:19 -06:00
|
|
|
h.oldbuckets = nil
|
2015-01-26 11:04:41 -07:00
|
|
|
// Can discard old overflow buckets as well.
|
|
|
|
// If they are still referenced by an iterator,
|
|
|
|
// then the iterator holds a pointers to the slice.
|
|
|
|
if h.overflow != nil {
|
|
|
|
h.overflow[1] = nil
|
|
|
|
}
|
runtime: limit the number of map overflow buckets
Consider repeatedly adding many items to a map
and then deleting them all, as in #16070. The map
itself doesn't need to grow above the high water
mark of number of items. However, due to random
collisions, the map can accumulate overflow
buckets.
Prior to this CL, those overflow buckets were
never removed, which led to a slow memory leak.
The problem with removing overflow buckets is
iterators. The obvious approach is to repack
keys and values and eliminate unused overflow
buckets. However, keys, values, and overflow
buckets cannot be manipulated without disrupting
iterators.
This CL takes a different approach, which is to
reuse the existing map growth mechanism,
which is well established, well tested, and
safe in the presence of iterators.
When a map has accumulated enough overflow buckets
we trigger map growth, but grow into a map of the
same size as before. The old overflow buckets will
be left behind for garbage collection.
For the code in #16070, instead of climbing
(very slowly) forever, memory usage now cycles
between 264mb and 483mb every 15 minutes or so.
To avoid increasing the size of maps,
the overflow bucket counter is only 16 bits.
For large maps, the counter is incremented
stochastically.
Fixes #16070
Change-Id: If551d77613ec6836907efca58bda3deee304297e
Reviewed-on: https://go-review.googlesource.com/25049
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2016-07-19 12:47:53 -06:00
|
|
|
h.flags &^= sameSizeGrow
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func ismapkey(t *_type) bool {
|
2014-12-27 21:32:11 -07:00
|
|
|
return t.alg.hash != nil
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
2016-03-01 16:21:55 -07:00
|
|
|
// Reflect stubs. Called from ../reflect/asm_*.s
|
2014-07-16 15:16:19 -06:00
|
|
|
|
2014-12-22 11:27:53 -07:00
|
|
|
//go:linkname reflect_makemap reflect.makemap
|
2014-07-16 15:16:19 -06:00
|
|
|
func reflect_makemap(t *maptype) *hmap {
|
2015-01-29 09:40:02 -07:00
|
|
|
return makemap(t, 0, nil, nil)
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
2014-12-22 11:27:53 -07:00
|
|
|
//go:linkname reflect_mapaccess reflect.mapaccess
|
2014-07-16 15:16:19 -06:00
|
|
|
func reflect_mapaccess(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
|
|
|
|
val, ok := mapaccess2(t, h, key)
|
|
|
|
if !ok {
|
|
|
|
// reflect wants nil for a missing element
|
|
|
|
val = nil
|
|
|
|
}
|
|
|
|
return val
|
|
|
|
}
|
|
|
|
|
2014-12-22 11:27:53 -07:00
|
|
|
//go:linkname reflect_mapassign reflect.mapassign
|
2014-07-16 15:16:19 -06:00
|
|
|
func reflect_mapassign(t *maptype, h *hmap, key unsafe.Pointer, val unsafe.Pointer) {
|
2016-10-11 09:36:38 -06:00
|
|
|
p := mapassign(t, h, key)
|
|
|
|
typedmemmove(t.elem, p, val)
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
|
2014-12-22 11:27:53 -07:00
|
|
|
//go:linkname reflect_mapdelete reflect.mapdelete
|
2014-07-16 15:16:19 -06:00
|
|
|
func reflect_mapdelete(t *maptype, h *hmap, key unsafe.Pointer) {
|
|
|
|
mapdelete(t, h, key)
|
|
|
|
}
|
|
|
|
|
2014-12-22 11:27:53 -07:00
|
|
|
//go:linkname reflect_mapiterinit reflect.mapiterinit
|
2014-07-16 15:16:19 -06:00
|
|
|
func reflect_mapiterinit(t *maptype, h *hmap) *hiter {
|
|
|
|
it := new(hiter)
|
|
|
|
mapiterinit(t, h, it)
|
|
|
|
return it
|
|
|
|
}
|
|
|
|
|
2014-12-22 11:27:53 -07:00
|
|
|
//go:linkname reflect_mapiternext reflect.mapiternext
|
2014-07-16 15:16:19 -06:00
|
|
|
func reflect_mapiternext(it *hiter) {
|
|
|
|
mapiternext(it)
|
|
|
|
}
|
|
|
|
|
2014-12-22 11:27:53 -07:00
|
|
|
//go:linkname reflect_mapiterkey reflect.mapiterkey
|
2014-07-16 15:16:19 -06:00
|
|
|
func reflect_mapiterkey(it *hiter) unsafe.Pointer {
|
|
|
|
return it.key
|
|
|
|
}
|
|
|
|
|
2014-12-22 11:27:53 -07:00
|
|
|
//go:linkname reflect_maplen reflect.maplen
|
2014-07-16 15:16:19 -06:00
|
|
|
func reflect_maplen(h *hmap) int {
|
|
|
|
if h == nil {
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
if raceenabled {
|
cmd/cc, runtime: preserve C runtime type names in generated Go
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
2014-08-27 19:59:49 -06:00
|
|
|
callerpc := getcallerpc(unsafe.Pointer(&h))
|
2014-09-03 09:10:38 -06:00
|
|
|
racereadpc(unsafe.Pointer(h), callerpc, funcPC(reflect_maplen))
|
2014-07-16 15:16:19 -06:00
|
|
|
}
|
|
|
|
return h.count
|
|
|
|
}
|
|
|
|
|
2014-12-22 11:27:53 -07:00
|
|
|
//go:linkname reflect_ismapkey reflect.ismapkey
|
2014-07-16 15:16:19 -06:00
|
|
|
func reflect_ismapkey(t *_type) bool {
|
|
|
|
return ismapkey(t)
|
|
|
|
}
|
2015-05-14 15:27:04 -06:00
|
|
|
|
2016-04-19 09:31:04 -06:00
|
|
|
const maxZero = 1024 // must match value in ../cmd/compile/internal/gc/walk.go
|
|
|
|
var zeroVal [maxZero]byte
|