2014-07-31 12:43:40 -07:00
|
|
|
// Copyright 2009 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
|
|
|
|
|
|
|
|
|
|
import (
|
2021-05-21 13:37:19 -04:00
|
|
|
"internal/abi"
|
2021-06-17 19:10:18 +00:00
|
|
|
"internal/goarch"
|
cmd/compile: introduce alias analysis and automatically free non-aliased memory after growslice
This CL is part of a set of CLs that attempt to reduce how much work the
GC must do. See the design in https://go.dev/design/74299-runtime-freegc
This CL updates the compiler to examine append calls to prove
whether or not the slice is aliased.
If proven unaliased, the compiler automatically inserts a call to a new
runtime function introduced with this CL, runtime.growsliceNoAlias,
which frees the old backing memory immediately after slice growth is
complete and the old storage is logically dead.
Two append benchmarks below show promising results, executing up to
~2x faster and up to factor of ~3 memory reduction with this CL.
The approach works with multiple append calls for the same slice,
including inside loops, and the final slice memory can be escaping,
such as in a classic pattern of returning a slice from a function
after the slice is built. (The final slice memory is never freed with
this CL, though we have other work that tackles that.)
An example target for this CL is we automatically free the
intermediate memory for the appends in the loop in this function:
func f1(input []int) []int {
var s []int
for _, x := range input {
s = append(s, g(x)) // s cannot be aliased here
if h(x) {
s = append(s, x) // s cannot be aliased here
}
}
return s // slice escapes at end
}
In this case, the compiler and the runtime collaborate so that
the heap allocated backing memory for s is automatically freed after
a successful grow. (For the first grow, there is nothing to free,
but for the second and subsequent growths, the old heap memory is
freed automatically.)
The new runtime.growsliceNoAlias is primarily implemented
by calling runtime.freegc, which we introduced in CL 673695.
The high-level approach here is we step through the IR starting
from a slice declaration and look for any operations that either
alias the slice or might do so, and treat any IR construct we
don't specifically handle as a potential alias (and therefore
conservatively fall back to treating the slice as aliased when
encountering something not understood).
For loops, some additional care is required. We arrange the analysis
so that an alias in the body of a loop causes all the appends in that
same loop body to be marked aliased, even if the aliasing occurs after
the append in the IR:
func f2() {
var s []int
for i := range 10 {
s = append(s, i) // aliased due to next line
alias = s
}
}
For nested loops, we analyse the nesting appropriately so that
for example this append is still proven as non-aliased in the
inner loop even though it aliased for the outer loop:
func f3() {
for range 10 {
var s []int
for i := range 10 {
s = append(s, i) // append using non-aliased slice
}
alias = s
}
}
A good starting point is the beginning of the test/escape_alias.go file,
which starts with ~10 introductory examples with brief comments that
attempt to illustrate the high-level approach.
For more details, see the new .../internal/escape/alias.go file,
especially the (*aliasAnalysis).analyze method.
In the first benchmark, an append in a loop builds up a slice from
nothing, where the slice elements are each 64 bytes. In the table below,
'count' is the number of appends. With 1 append, there is no opportunity
for this CL to free memory. Once there are 2 appends, the growth from
1 element to 2 elements means the compiler-inserted growsliceNoAlias
frees the 1-element array, and we see a ~33% reduction in memory use
and a small reported speed improvement.
As the number of appends increases for example to 5, we are at
a ~20% speed improvement and ~45% memory reduction, and so on until
we reach ~40% faster and ~50% less memory allocated at the end of
the table.
There can be variation in the reported numbers based on -randlayout, so
this table is for 30 different values of -randlayout with a total
n=150. (Even so, there is still some variation, so we probably should
not read too much into small changes.) This is with GOAMD64=v3 on
a VM that gcc reports is cascadelake.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
Append64Bytes/count=1-4 31.09n ± 2% 31.69n ± 1% +1.95% (n=150)
Append64Bytes/count=2-4 73.31n ± 1% 70.27n ± 0% -4.15% (n=150)
Append64Bytes/count=3-4 142.7n ± 1% 124.6n ± 1% -12.68% (n=150)
Append64Bytes/count=4-4 149.6n ± 1% 127.7n ± 0% -14.64% (n=150)
Append64Bytes/count=5-4 277.1n ± 1% 213.6n ± 0% -22.90% (n=150)
Append64Bytes/count=6-4 280.7n ± 1% 216.5n ± 1% -22.87% (n=150)
Append64Bytes/count=10-4 544.3n ± 1% 386.6n ± 0% -28.97% (n=150)
Append64Bytes/count=20-4 1058.5n ± 1% 715.6n ± 1% -32.39% (n=150)
Append64Bytes/count=50-4 2.121µ ± 1% 1.404µ ± 1% -33.83% (n=150)
Append64Bytes/count=100-4 4.152µ ± 1% 2.736µ ± 1% -34.11% (n=150)
Append64Bytes/count=200-4 7.753µ ± 1% 4.882µ ± 1% -37.03% (n=150)
Append64Bytes/count=400-4 15.163µ ± 2% 9.273µ ± 1% -38.84% (n=150)
geomean 601.8n 455.0n -24.39%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
Append64Bytes/count=1-4 64.00 ± 0% 64.00 ± 0% ~ (n=150)
Append64Bytes/count=2-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
Append64Bytes/count=3-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=4-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=5-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=6-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=10-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
Append64Bytes/count=20-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
Append64Bytes/count=50-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
Append64Bytes/count=100-4 15.938Ki ± 0% 8.021Ki ± 0% -49.67% (n=150)
Append64Bytes/count=200-4 31.94Ki ± 0% 16.08Ki ± 0% -49.64% (n=150)
Append64Bytes/count=400-4 63.94Ki ± 0% 32.33Ki ± 0% -49.44% (n=150)
geomean 1.991Ki 1.124Ki -43.54%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
Append64Bytes/count=1-4 1.000 ± 0% 1.000 ± 0% ~ (n=150)
Append64Bytes/count=2-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
Append64Bytes/count=3-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=4-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=5-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=6-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=10-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
Append64Bytes/count=20-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
Append64Bytes/count=50-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
Append64Bytes/count=100-4 8.000 ± 0% 1.000 ± 0% -87.50% (n=150)
Append64Bytes/count=200-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
Append64Bytes/count=400-4 10.000 ± 0% 1.000 ± 0% -90.00% (n=150)
geomean 4.331 1.000 -76.91%
The second benchmark is similar, but instead uses an 8-byte integer
for the slice element. The first 4 appends in the loop never call into
the runtime thanks to the excellent CL 664299 introduced by Keith in
Go 1.25 that allows some <= 32 byte dynamically-sized slices to be on
the stack, so this CL is neutral for <= 32 bytes. Once the 5th append
occurs at count=5, a grow happens via the runtime and heap allocates
as normal, but freegc does not yet have anything to free, so we see
a small ~1.4ns penalty reported there. But once the second growth
happens, the older heap memory is now automatically freed by freegc,
so we start to see some benefit in memory reductions and speed
improvements, starting at a tiny speed improvement (close to a wash,
or maybe noise) by the second growth before count=10, and building up to
~2x faster with ~68% fewer allocated bytes reported.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
AppendInt/count=1-4 2.978n ± 0% 2.969n ± 0% -0.30% (p=0.000 n=150)
AppendInt/count=4-4 4.292n ± 3% 4.163n ± 3% ~ (p=0.528 n=150)
AppendInt/count=5-4 33.50n ± 0% 34.93n ± 0% +4.25% (p=0.000 n=150)
AppendInt/count=10-4 76.21n ± 1% 75.67n ± 0% -0.72% (p=0.000 n=150)
AppendInt/count=20-4 150.6n ± 1% 133.0n ± 0% -11.65% (n=150)
AppendInt/count=50-4 284.1n ± 1% 225.6n ± 0% -20.59% (n=150)
AppendInt/count=100-4 544.2n ± 1% 392.4n ± 1% -27.89% (n=150)
AppendInt/count=200-4 1051.5n ± 1% 702.3n ± 0% -33.21% (n=150)
AppendInt/count=400-4 2.041µ ± 1% 1.312µ ± 1% -35.70% (n=150)
AppendInt/count=1000-4 5.224µ ± 2% 2.851µ ± 1% -45.43% (n=150)
AppendInt/count=2000-4 11.770µ ± 1% 6.010µ ± 1% -48.94% (n=150)
AppendInt/count=3000-4 17.747µ ± 2% 8.264µ ± 1% -53.44% (n=150)
geomean 331.8n 246.4n -25.72%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 64.00 ± 0% 64.00 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
AppendInt/count=20-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
AppendInt/count=50-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
AppendInt/count=100-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
AppendInt/count=200-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
AppendInt/count=400-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
AppendInt/count=1000-4 24.56Ki ± 0% 10.05Ki ± 0% -59.07% (n=150)
AppendInt/count=2000-4 58.56Ki ± 0% 20.31Ki ± 0% -65.32% (n=150)
AppendInt/count=3000-4 85.19Ki ± 0% 27.30Ki ± 0% -67.95% (n=150)
geomean ² -42.81%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
AppendInt/count=20-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
AppendInt/count=50-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
AppendInt/count=100-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
AppendInt/count=200-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
AppendInt/count=400-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
AppendInt/count=1000-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
AppendInt/count=2000-4 11.000 ± 0% 1.000 ± 0% -90.91% (n=150)
AppendInt/count=3000-4 12.000 ± 0% 1.000 ± 0% -91.67% (n=150)
geomean ² -72.76% ²
Of course, these are just microbenchmarks, but likely indicate
there are some opportunities here.
The immediately following CL 712422 tackles inlining and is able to get
runtime.freegc working automatically with iterators such as used by
slices.Collect, which becomes able to automatically free the
intermediate memory from its repeated appends (which earlier
in this work required a temporary hand edit to the slices package).
For now, we only use the NoAlias version for element types without
pointers while waiting on additional runtime support in CL 698515.
Updates #74299
Change-Id: I1b9d286aa97c170dcc2e203ec0f8ca72d84e8221
Reviewed-on: https://go-review.googlesource.com/c/go/+/710015
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
2025-11-25 09:57:50 -05:00
|
|
|
"internal/goexperiment"
|
2024-07-23 11:18:08 -04:00
|
|
|
"internal/runtime/math"
|
2024-07-23 11:43:23 -04:00
|
|
|
"internal/runtime/sys"
|
2014-07-31 12:43:40 -07:00
|
|
|
"unsafe"
|
|
|
|
|
)
|
|
|
|
|
|
2015-04-11 10:01:54 +12:00
|
|
|
type slice struct {
|
2014-07-31 12:43:40 -07:00
|
|
|
array unsafe.Pointer
|
|
|
|
|
len int
|
|
|
|
|
cap int
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-23 11:43:23 -04:00
|
|
|
// A notInHeapSlice is a slice backed by internal/runtime/sys.NotInHeap memory.
|
2017-10-25 13:46:54 -04:00
|
|
|
type notInHeapSlice struct {
|
|
|
|
|
array *notInHeap
|
|
|
|
|
len int
|
|
|
|
|
cap int
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-26 18:30:11 +02:00
|
|
|
func panicmakeslicelen() {
|
|
|
|
|
panic(errorString("makeslice: len out of range"))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func panicmakeslicecap() {
|
|
|
|
|
panic(errorString("makeslice: cap out of range"))
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-23 13:50:07 +02:00
|
|
|
// makeslicecopy allocates a slice of "tolen" elements of type "et",
|
|
|
|
|
// then copies "fromlen" elements of type "et" into that new allocation from "from".
|
|
|
|
|
func makeslicecopy(et *_type, tolen int, fromlen int, from unsafe.Pointer) unsafe.Pointer {
|
|
|
|
|
var tomem, copymem uintptr
|
|
|
|
|
if uintptr(tolen) > uintptr(fromlen) {
|
|
|
|
|
var overflow bool
|
2023-01-20 16:41:57 -05:00
|
|
|
tomem, overflow = math.MulUintptr(et.Size_, uintptr(tolen))
|
2018-10-23 13:50:07 +02:00
|
|
|
if overflow || tomem > maxAlloc || tolen < 0 {
|
|
|
|
|
panicmakeslicelen()
|
|
|
|
|
}
|
2023-01-20 16:41:57 -05:00
|
|
|
copymem = et.Size_ * uintptr(fromlen)
|
2018-10-23 13:50:07 +02:00
|
|
|
} else {
|
|
|
|
|
// fromlen is a known good length providing and equal or greater than tolen,
|
|
|
|
|
// thereby making tolen a good slice length too as from and to slices have the
|
|
|
|
|
// same element width.
|
2023-01-20 16:41:57 -05:00
|
|
|
tomem = et.Size_ * uintptr(tolen)
|
2018-10-23 13:50:07 +02:00
|
|
|
copymem = tomem
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var to unsafe.Pointer
|
2024-02-27 21:51:31 +00:00
|
|
|
if !et.Pointers() {
|
2018-10-23 13:50:07 +02:00
|
|
|
to = mallocgc(tomem, nil, false)
|
|
|
|
|
if copymem < tomem {
|
|
|
|
|
memclrNoHeapPointers(add(to, copymem), tomem-copymem)
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
// Note: can't use rawmem (which avoids zeroing of memory), because then GC can scan uninitialized memory.
|
|
|
|
|
to = mallocgc(tomem, et, true)
|
2020-05-07 23:43:22 +02:00
|
|
|
if copymem > 0 && writeBarrier.enabled {
|
2018-10-23 13:50:07 +02:00
|
|
|
// Only shade the pointers in old.array since we know the destination slice to
|
|
|
|
|
// only contains nil pointers because it has been cleared during alloc.
|
2023-11-14 22:05:53 +00:00
|
|
|
//
|
|
|
|
|
// It's safe to pass a type to this function as an optimization because
|
|
|
|
|
// from and to only ever refer to memory representing whole values of
|
|
|
|
|
// type et. See the comment on bulkBarrierPreWrite.
|
|
|
|
|
bulkBarrierPreWriteSrcOnly(uintptr(to), uintptr(from), copymem, et)
|
2018-10-23 13:50:07 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if raceenabled {
|
2024-09-16 14:07:43 -04:00
|
|
|
callerpc := sys.GetCallerPC()
|
2021-05-21 13:37:19 -04:00
|
|
|
pc := abi.FuncPCABIInternal(makeslicecopy)
|
2018-10-23 13:50:07 +02:00
|
|
|
racereadrangepc(from, copymem, callerpc, pc)
|
|
|
|
|
}
|
|
|
|
|
if msanenabled {
|
|
|
|
|
msanread(from, copymem)
|
|
|
|
|
}
|
2021-01-05 17:52:43 +08:00
|
|
|
if asanenabled {
|
|
|
|
|
asanread(from, copymem)
|
|
|
|
|
}
|
2018-10-23 13:50:07 +02:00
|
|
|
|
|
|
|
|
memmove(to, from, copymem)
|
|
|
|
|
|
|
|
|
|
return to
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-21 23:24:47 -04:00
|
|
|
// makeslice should be an internal detail,
|
|
|
|
|
// but widely used packages access it using linkname.
|
|
|
|
|
// Notable members of the hall of shame include:
|
|
|
|
|
// - github.com/bytedance/sonic
|
|
|
|
|
//
|
|
|
|
|
// Do not remove or change the type signature.
|
|
|
|
|
// See go.dev/issue/67401.
|
|
|
|
|
//
|
|
|
|
|
//go:linkname makeslice
|
2018-10-14 22:28:58 +02:00
|
|
|
func makeslice(et *_type, len, cap int) unsafe.Pointer {
|
2023-01-20 16:41:57 -05:00
|
|
|
mem, overflow := math.MulUintptr(et.Size_, uintptr(cap))
|
2018-10-16 00:27:42 +02:00
|
|
|
if overflow || mem > maxAlloc || len < 0 || len > cap {
|
|
|
|
|
// NOTE: Produce a 'len out of range' error instead of a
|
|
|
|
|
// 'cap out of range' error when someone does make([]T, bignumber).
|
|
|
|
|
// 'cap out of range' is true too, but since the cap is only being
|
|
|
|
|
// supplied implicitly, saying len is clearer.
|
|
|
|
|
// See golang.org/issue/4085.
|
2023-01-20 16:41:57 -05:00
|
|
|
mem, overflow := math.MulUintptr(et.Size_, uintptr(len))
|
2018-10-16 00:27:42 +02:00
|
|
|
if overflow || mem > maxAlloc || len < 0 {
|
|
|
|
|
panicmakeslicelen()
|
|
|
|
|
}
|
2018-04-26 18:30:11 +02:00
|
|
|
panicmakeslicecap()
|
2014-07-31 12:43:40 -07:00
|
|
|
}
|
2016-04-10 17:32:35 +02:00
|
|
|
|
2018-10-14 22:28:58 +02:00
|
|
|
return mallocgc(mem, et, true)
|
2014-07-31 12:43:40 -07:00
|
|
|
}
|
|
|
|
|
|
2018-10-14 22:28:58 +02:00
|
|
|
func makeslice64(et *_type, len64, cap64 int64) unsafe.Pointer {
|
2016-08-25 14:17:52 +02:00
|
|
|
len := int(len64)
|
|
|
|
|
if int64(len) != len64 {
|
2018-04-26 18:30:11 +02:00
|
|
|
panicmakeslicelen()
|
2016-08-25 14:17:52 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cap := int(cap64)
|
|
|
|
|
if int64(cap) != cap64 {
|
2018-04-26 18:30:11 +02:00
|
|
|
panicmakeslicecap()
|
2016-08-25 14:17:52 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return makeslice(et, len, cap)
|
|
|
|
|
}
|
|
|
|
|
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
// growslice allocates new backing store for a slice.
|
|
|
|
|
//
|
|
|
|
|
// arguments:
|
2022-03-02 13:01:48 -08:00
|
|
|
//
|
|
|
|
|
// oldPtr = pointer to the slice's backing array
|
|
|
|
|
// newLen = new length (= oldLen + num)
|
|
|
|
|
// oldCap = original slice's capacity.
|
|
|
|
|
// num = number of elements being added
|
|
|
|
|
// et = element type
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
//
|
|
|
|
|
// return values:
|
2022-03-02 13:01:48 -08:00
|
|
|
//
|
|
|
|
|
// newPtr = pointer to the new backing store
|
|
|
|
|
// newLen = same value as the argument
|
|
|
|
|
// newCap = capacity of the new backing store
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
//
|
|
|
|
|
// Requires that uint(newLen) > uint(oldCap).
|
|
|
|
|
// Assumes the original slice length is newLen - num
|
|
|
|
|
//
|
|
|
|
|
// A new backing store is allocated with space for at least newLen elements.
|
|
|
|
|
// Existing entries [0, oldLen) are copied over to the new backing store.
|
|
|
|
|
// Added entries [oldLen, newLen) are not initialized by growslice
|
|
|
|
|
// (although for pointer-containing element types, they are zeroed). They
|
|
|
|
|
// must be initialized by the caller.
|
|
|
|
|
// Trailing entries [newLen, newCap) are zeroed.
|
|
|
|
|
//
|
|
|
|
|
// growslice's odd calling convention makes the generated code that calls
|
|
|
|
|
// this function simpler. In particular, it accepts and returns the
|
|
|
|
|
// new length so that the old length is not live (does not need to be
|
|
|
|
|
// spilled/restored) and the new length is returned (also does not need
|
|
|
|
|
// to be spilled/restored).
|
2024-05-21 23:02:51 -04:00
|
|
|
//
|
|
|
|
|
// growslice should be an internal detail,
|
|
|
|
|
// but widely used packages access it using linkname.
|
|
|
|
|
// Notable members of the hall of shame include:
|
2024-05-21 23:24:47 -04:00
|
|
|
// - github.com/bytedance/sonic
|
2024-05-22 15:46:02 -04:00
|
|
|
// - github.com/chenzhuoyu/iasm
|
2024-05-22 17:09:02 -04:00
|
|
|
// - github.com/cloudwego/dynamicgo
|
2024-05-21 23:02:51 -04:00
|
|
|
// - github.com/ugorji/go/codec
|
|
|
|
|
//
|
|
|
|
|
// Do not remove or change the type signature.
|
|
|
|
|
// See go.dev/issue/67401.
|
|
|
|
|
//
|
|
|
|
|
//go:linkname growslice
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
func growslice(oldPtr unsafe.Pointer, newLen, oldCap, num int, et *_type) slice {
|
|
|
|
|
oldLen := newLen - num
|
2014-07-31 12:43:40 -07:00
|
|
|
if raceenabled {
|
2024-09-16 14:07:43 -04:00
|
|
|
callerpc := sys.GetCallerPC()
|
2023-01-20 16:41:57 -05:00
|
|
|
racereadrangepc(oldPtr, uintptr(oldLen*int(et.Size_)), callerpc, abi.FuncPCABIInternal(growslice))
|
2014-07-31 12:43:40 -07:00
|
|
|
}
|
2015-10-21 11:04:42 -07:00
|
|
|
if msanenabled {
|
2023-01-20 16:41:57 -05:00
|
|
|
msanread(oldPtr, uintptr(oldLen*int(et.Size_)))
|
2015-10-21 11:04:42 -07:00
|
|
|
}
|
2021-01-05 17:52:43 +08:00
|
|
|
if asanenabled {
|
2023-01-20 16:41:57 -05:00
|
|
|
asanread(oldPtr, uintptr(oldLen*int(et.Size_)))
|
2021-01-05 17:52:43 +08:00
|
|
|
}
|
2014-07-31 12:43:40 -07:00
|
|
|
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
if newLen < 0 {
|
2022-07-18 11:47:19 -07:00
|
|
|
panic(errorString("growslice: len out of range"))
|
2018-10-22 20:22:55 +02:00
|
|
|
}
|
|
|
|
|
|
2023-01-20 16:41:57 -05:00
|
|
|
if et.Size_ == 0 {
|
2015-03-11 12:07:50 -04:00
|
|
|
// append should not create a slice with nil pointer but non-zero len.
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
// We assume that append doesn't need to preserve oldPtr in this case.
|
|
|
|
|
return slice{unsafe.Pointer(&zerobase), newLen, newLen}
|
2014-07-31 12:43:40 -07:00
|
|
|
}
|
|
|
|
|
|
2023-05-17 17:33:15 +03:00
|
|
|
newcap := nextslicecap(newLen, oldCap)
|
2016-03-13 18:58:17 +01:00
|
|
|
|
2017-08-12 17:37:13 +02:00
|
|
|
var overflow bool
|
2016-10-03 12:45:12 -07:00
|
|
|
var lenmem, newlenmem, capmem uintptr
|
2023-01-20 16:41:57 -05:00
|
|
|
// Specialize for common values of et.Size.
|
2018-03-23 15:45:03 -05:00
|
|
|
// For 1 we don't need any division/multiplication.
|
2022-02-04 21:14:13 -08:00
|
|
|
// For goarch.PtrSize, compiler will optimize division/multiplication into a shift by a constant.
|
2018-03-23 15:45:03 -05:00
|
|
|
// For powers of 2, use a variable shift.
|
2024-02-27 21:51:31 +00:00
|
|
|
noscan := !et.Pointers()
|
2018-03-23 15:45:03 -05:00
|
|
|
switch {
|
2023-01-20 16:41:57 -05:00
|
|
|
case et.Size_ == 1:
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
lenmem = uintptr(oldLen)
|
|
|
|
|
newlenmem = uintptr(newLen)
|
runtime: implement experiment to replace heap bitmap with alloc headers
This change replaces the 1-bit-per-word heap bitmap for most size
classes with allocation headers for objects that contain pointers. The
header consists of a single pointer to a type. All allocations with
headers are treated as implicitly containing one or more instances of
the type in the header.
As the name implies, headers are usually stored as the first word of an
object. There are two additional exceptions to where headers are stored
and how they're used.
Objects smaller than 512 bytes do not have headers. Instead, a heap
bitmap is reserved at the end of spans for objects of this size. A full
word of overhead is too much for these small objects. The bitmap is of
the same format of the old bitmap, minus the noMorePtrs bits which are
unnecessary. All the objects <512 bytes have a bitmap less than a
pointer-word in size, and that was the granularity at which noMorePtrs
could stop scanning early anyway.
Objects that are larger than 32 KiB (which have their own span) have
their headers stored directly in the span, to allow power-of-two-sized
allocations to not spill over into an extra page.
The full implementation is behind GOEXPERIMENT=allocheaders.
The purpose of this change is performance. First and foremost, with
headers we no longer have to unroll pointer/scalar data at allocation
time for most size classes. Small size classes still need some
unrolling, but their bitmaps are small so we can optimize that case
fairly well. Larger objects effectively have their pointer/scalar data
unrolled on-demand from type data, which is much more compactly
represented and results in less TLB pressure. Furthermore, since the
headers are usually right next to the object and where we're about to
start scanning, we get an additional temporal locality benefit in the
data cache when looking up type metadata. The pointer/scalar data is
now effectively unrolled on-demand, but it's also simpler to unroll than
before; that unrolled data is never written anywhere, and for arrays we
get the benefit of retreading the same data per element, as opposed to
looking it up from scratch for each pointer-word of bitmap. Lastly,
because we no longer have a heap bitmap that spans the entire heap,
there's a flat 1.5% memory use reduction. This is balanced slightly by
some objects possibly being bumped up a size class, but most objects are
not tightly optimized to size class sizes so there's some memory to
spare, making the header basically free in those cases.
See the follow-up CL which turns on this experiment by default for
benchmark results. (CL 538217.)
Change-Id: I4c9034ee200650d06d8bdecd579d5f7c1bbf1fc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/437955
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2022-09-11 04:07:41 +00:00
|
|
|
capmem = roundupsize(uintptr(newcap), noscan)
|
2018-01-01 21:51:47 -05:00
|
|
|
overflow = uintptr(newcap) > maxAlloc
|
2016-03-13 18:58:17 +01:00
|
|
|
newcap = int(capmem)
|
2023-01-20 16:41:57 -05:00
|
|
|
case et.Size_ == goarch.PtrSize:
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
lenmem = uintptr(oldLen) * goarch.PtrSize
|
|
|
|
|
newlenmem = uintptr(newLen) * goarch.PtrSize
|
runtime: implement experiment to replace heap bitmap with alloc headers
This change replaces the 1-bit-per-word heap bitmap for most size
classes with allocation headers for objects that contain pointers. The
header consists of a single pointer to a type. All allocations with
headers are treated as implicitly containing one or more instances of
the type in the header.
As the name implies, headers are usually stored as the first word of an
object. There are two additional exceptions to where headers are stored
and how they're used.
Objects smaller than 512 bytes do not have headers. Instead, a heap
bitmap is reserved at the end of spans for objects of this size. A full
word of overhead is too much for these small objects. The bitmap is of
the same format of the old bitmap, minus the noMorePtrs bits which are
unnecessary. All the objects <512 bytes have a bitmap less than a
pointer-word in size, and that was the granularity at which noMorePtrs
could stop scanning early anyway.
Objects that are larger than 32 KiB (which have their own span) have
their headers stored directly in the span, to allow power-of-two-sized
allocations to not spill over into an extra page.
The full implementation is behind GOEXPERIMENT=allocheaders.
The purpose of this change is performance. First and foremost, with
headers we no longer have to unroll pointer/scalar data at allocation
time for most size classes. Small size classes still need some
unrolling, but their bitmaps are small so we can optimize that case
fairly well. Larger objects effectively have their pointer/scalar data
unrolled on-demand from type data, which is much more compactly
represented and results in less TLB pressure. Furthermore, since the
headers are usually right next to the object and where we're about to
start scanning, we get an additional temporal locality benefit in the
data cache when looking up type metadata. The pointer/scalar data is
now effectively unrolled on-demand, but it's also simpler to unroll than
before; that unrolled data is never written anywhere, and for arrays we
get the benefit of retreading the same data per element, as opposed to
looking it up from scratch for each pointer-word of bitmap. Lastly,
because we no longer have a heap bitmap that spans the entire heap,
there's a flat 1.5% memory use reduction. This is balanced slightly by
some objects possibly being bumped up a size class, but most objects are
not tightly optimized to size class sizes so there's some memory to
spare, making the header basically free in those cases.
See the follow-up CL which turns on this experiment by default for
benchmark results. (CL 538217.)
Change-Id: I4c9034ee200650d06d8bdecd579d5f7c1bbf1fc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/437955
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2022-09-11 04:07:41 +00:00
|
|
|
capmem = roundupsize(uintptr(newcap)*goarch.PtrSize, noscan)
|
2021-06-16 23:05:44 +00:00
|
|
|
overflow = uintptr(newcap) > maxAlloc/goarch.PtrSize
|
|
|
|
|
newcap = int(capmem / goarch.PtrSize)
|
2023-01-20 16:41:57 -05:00
|
|
|
case isPowerOfTwo(et.Size_):
|
2018-03-23 15:45:03 -05:00
|
|
|
var shift uintptr
|
2021-06-16 23:05:44 +00:00
|
|
|
if goarch.PtrSize == 8 {
|
2018-03-23 15:45:03 -05:00
|
|
|
// Mask shift for better code generation.
|
2023-01-20 16:41:57 -05:00
|
|
|
shift = uintptr(sys.TrailingZeros64(uint64(et.Size_))) & 63
|
2018-03-23 15:45:03 -05:00
|
|
|
} else {
|
2023-01-20 16:41:57 -05:00
|
|
|
shift = uintptr(sys.TrailingZeros32(uint32(et.Size_))) & 31
|
2018-03-23 15:45:03 -05:00
|
|
|
}
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
lenmem = uintptr(oldLen) << shift
|
|
|
|
|
newlenmem = uintptr(newLen) << shift
|
runtime: implement experiment to replace heap bitmap with alloc headers
This change replaces the 1-bit-per-word heap bitmap for most size
classes with allocation headers for objects that contain pointers. The
header consists of a single pointer to a type. All allocations with
headers are treated as implicitly containing one or more instances of
the type in the header.
As the name implies, headers are usually stored as the first word of an
object. There are two additional exceptions to where headers are stored
and how they're used.
Objects smaller than 512 bytes do not have headers. Instead, a heap
bitmap is reserved at the end of spans for objects of this size. A full
word of overhead is too much for these small objects. The bitmap is of
the same format of the old bitmap, minus the noMorePtrs bits which are
unnecessary. All the objects <512 bytes have a bitmap less than a
pointer-word in size, and that was the granularity at which noMorePtrs
could stop scanning early anyway.
Objects that are larger than 32 KiB (which have their own span) have
their headers stored directly in the span, to allow power-of-two-sized
allocations to not spill over into an extra page.
The full implementation is behind GOEXPERIMENT=allocheaders.
The purpose of this change is performance. First and foremost, with
headers we no longer have to unroll pointer/scalar data at allocation
time for most size classes. Small size classes still need some
unrolling, but their bitmaps are small so we can optimize that case
fairly well. Larger objects effectively have their pointer/scalar data
unrolled on-demand from type data, which is much more compactly
represented and results in less TLB pressure. Furthermore, since the
headers are usually right next to the object and where we're about to
start scanning, we get an additional temporal locality benefit in the
data cache when looking up type metadata. The pointer/scalar data is
now effectively unrolled on-demand, but it's also simpler to unroll than
before; that unrolled data is never written anywhere, and for arrays we
get the benefit of retreading the same data per element, as opposed to
looking it up from scratch for each pointer-word of bitmap. Lastly,
because we no longer have a heap bitmap that spans the entire heap,
there's a flat 1.5% memory use reduction. This is balanced slightly by
some objects possibly being bumped up a size class, but most objects are
not tightly optimized to size class sizes so there's some memory to
spare, making the header basically free in those cases.
See the follow-up CL which turns on this experiment by default for
benchmark results. (CL 538217.)
Change-Id: I4c9034ee200650d06d8bdecd579d5f7c1bbf1fc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/437955
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2022-09-11 04:07:41 +00:00
|
|
|
capmem = roundupsize(uintptr(newcap)<<shift, noscan)
|
2018-03-23 15:45:03 -05:00
|
|
|
overflow = uintptr(newcap) > (maxAlloc >> shift)
|
|
|
|
|
newcap = int(capmem >> shift)
|
2022-04-29 13:21:44 -07:00
|
|
|
capmem = uintptr(newcap) << shift
|
2016-03-24 17:42:01 +01:00
|
|
|
default:
|
2023-01-20 16:41:57 -05:00
|
|
|
lenmem = uintptr(oldLen) * et.Size_
|
|
|
|
|
newlenmem = uintptr(newLen) * et.Size_
|
|
|
|
|
capmem, overflow = math.MulUintptr(et.Size_, uintptr(newcap))
|
runtime: implement experiment to replace heap bitmap with alloc headers
This change replaces the 1-bit-per-word heap bitmap for most size
classes with allocation headers for objects that contain pointers. The
header consists of a single pointer to a type. All allocations with
headers are treated as implicitly containing one or more instances of
the type in the header.
As the name implies, headers are usually stored as the first word of an
object. There are two additional exceptions to where headers are stored
and how they're used.
Objects smaller than 512 bytes do not have headers. Instead, a heap
bitmap is reserved at the end of spans for objects of this size. A full
word of overhead is too much for these small objects. The bitmap is of
the same format of the old bitmap, minus the noMorePtrs bits which are
unnecessary. All the objects <512 bytes have a bitmap less than a
pointer-word in size, and that was the granularity at which noMorePtrs
could stop scanning early anyway.
Objects that are larger than 32 KiB (which have their own span) have
their headers stored directly in the span, to allow power-of-two-sized
allocations to not spill over into an extra page.
The full implementation is behind GOEXPERIMENT=allocheaders.
The purpose of this change is performance. First and foremost, with
headers we no longer have to unroll pointer/scalar data at allocation
time for most size classes. Small size classes still need some
unrolling, but their bitmaps are small so we can optimize that case
fairly well. Larger objects effectively have their pointer/scalar data
unrolled on-demand from type data, which is much more compactly
represented and results in less TLB pressure. Furthermore, since the
headers are usually right next to the object and where we're about to
start scanning, we get an additional temporal locality benefit in the
data cache when looking up type metadata. The pointer/scalar data is
now effectively unrolled on-demand, but it's also simpler to unroll than
before; that unrolled data is never written anywhere, and for arrays we
get the benefit of retreading the same data per element, as opposed to
looking it up from scratch for each pointer-word of bitmap. Lastly,
because we no longer have a heap bitmap that spans the entire heap,
there's a flat 1.5% memory use reduction. This is balanced slightly by
some objects possibly being bumped up a size class, but most objects are
not tightly optimized to size class sizes so there's some memory to
spare, making the header basically free in those cases.
See the follow-up CL which turns on this experiment by default for
benchmark results. (CL 538217.)
Change-Id: I4c9034ee200650d06d8bdecd579d5f7c1bbf1fc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/437955
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2022-09-11 04:07:41 +00:00
|
|
|
capmem = roundupsize(capmem, noscan)
|
2023-01-20 16:41:57 -05:00
|
|
|
newcap = int(capmem / et.Size_)
|
|
|
|
|
capmem = uintptr(newcap) * et.Size_
|
2016-03-24 17:42:01 +01:00
|
|
|
}
|
|
|
|
|
|
2018-10-22 20:22:55 +02:00
|
|
|
// The check of overflow in addition to capmem > maxAlloc is needed
|
|
|
|
|
// to prevent an overflow which can be used to trigger a segfault
|
|
|
|
|
// on 32bit architectures with this example program:
|
2017-08-12 17:37:13 +02:00
|
|
|
//
|
|
|
|
|
// type T [1<<27 + 1]int64
|
|
|
|
|
//
|
|
|
|
|
// var d T
|
|
|
|
|
// var s []T
|
|
|
|
|
//
|
|
|
|
|
// func main() {
|
|
|
|
|
// s = append(s, d, d, d, d)
|
|
|
|
|
// print(len(s), "\n")
|
|
|
|
|
// }
|
2018-10-22 20:22:55 +02:00
|
|
|
if overflow || capmem > maxAlloc {
|
2022-07-18 11:47:19 -07:00
|
|
|
panic(errorString("growslice: len out of range"))
|
2016-03-13 18:58:17 +01:00
|
|
|
}
|
|
|
|
|
|
2014-07-31 12:43:40 -07:00
|
|
|
var p unsafe.Pointer
|
2024-02-27 21:51:31 +00:00
|
|
|
if !et.Pointers() {
|
2016-04-19 19:35:10 -07:00
|
|
|
p = mallocgc(capmem, nil, false)
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
// The append() that calls growslice is going to overwrite from oldLen to newLen.
|
2016-10-03 12:45:12 -07:00
|
|
|
// Only clear the part that will not be overwritten.
|
2022-03-02 13:01:48 -08:00
|
|
|
// The reflect_growslice() that calls growslice will manually clear
|
|
|
|
|
// the region not cleared here.
|
2016-10-17 18:41:56 -04:00
|
|
|
memclrNoHeapPointers(add(p, newlenmem), capmem-newlenmem)
|
2014-07-31 12:43:40 -07:00
|
|
|
} else {
|
2015-06-11 16:49:38 +03:00
|
|
|
// Note: can't use rawmem (which avoids zeroing of memory), because then GC can scan uninitialized memory.
|
2016-04-19 19:35:10 -07:00
|
|
|
p = mallocgc(capmem, et, true)
|
2019-03-22 14:51:33 -07:00
|
|
|
if lenmem > 0 && writeBarrier.enabled {
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
// Only shade the pointers in oldPtr since we know the destination slice p
|
2018-06-03 13:00:19 +02:00
|
|
|
// only contains nil pointers because it has been cleared during alloc.
|
2023-11-14 22:05:53 +00:00
|
|
|
//
|
|
|
|
|
// It's safe to pass a type to this function as an optimization because
|
|
|
|
|
// from and to only ever refer to memory representing whole values of
|
|
|
|
|
// type et. See the comment on bulkBarrierPreWrite.
|
|
|
|
|
bulkBarrierPreWriteSrcOnly(uintptr(p), uintptr(oldPtr), lenmem-et.Size_+et.PtrBytes, et)
|
2014-12-22 22:42:05 -05:00
|
|
|
}
|
2014-07-31 12:43:40 -07:00
|
|
|
}
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
memmove(p, oldPtr, lenmem)
|
2014-07-31 12:43:40 -07:00
|
|
|
|
cmd/compile,runtime: redo growslice calling convention
Instead of passing the original length and the new length, pass
the new length and the length increment. Also use the new length
in all the post-growslice calculations so that the original length
is dead and does not need to be spilled/restored around the growslice.
old: growslice(typ, oldPtr, oldLen, oldCap, newLen) (newPtr, newLen, newCap)
new: growslice(oldPtr, newLen, oldCap, inc, typ) (newPtr, newLen, newCap)
where inc = # of elements added = newLen-oldLen
Also move the element type to the end of the call. This makes register
allocation more efficient, as oldPtr and newPtr can often be in the
same register (e.g. AX on amd64) and thus the phi takes no instructions.
Makes the go binary 0.3% smaller.
Change-Id: I7295a60227dbbeecec2bf039eeef2950a72df760
Reviewed-on: https://go-review.googlesource.com/c/go/+/418554
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-07-13 20:22:53 -07:00
|
|
|
return slice{p, newLen, newcap}
|
2014-07-31 12:43:40 -07:00
|
|
|
}
|
|
|
|
|
|
cmd/compile: introduce alias analysis and automatically free non-aliased memory after growslice
This CL is part of a set of CLs that attempt to reduce how much work the
GC must do. See the design in https://go.dev/design/74299-runtime-freegc
This CL updates the compiler to examine append calls to prove
whether or not the slice is aliased.
If proven unaliased, the compiler automatically inserts a call to a new
runtime function introduced with this CL, runtime.growsliceNoAlias,
which frees the old backing memory immediately after slice growth is
complete and the old storage is logically dead.
Two append benchmarks below show promising results, executing up to
~2x faster and up to factor of ~3 memory reduction with this CL.
The approach works with multiple append calls for the same slice,
including inside loops, and the final slice memory can be escaping,
such as in a classic pattern of returning a slice from a function
after the slice is built. (The final slice memory is never freed with
this CL, though we have other work that tackles that.)
An example target for this CL is we automatically free the
intermediate memory for the appends in the loop in this function:
func f1(input []int) []int {
var s []int
for _, x := range input {
s = append(s, g(x)) // s cannot be aliased here
if h(x) {
s = append(s, x) // s cannot be aliased here
}
}
return s // slice escapes at end
}
In this case, the compiler and the runtime collaborate so that
the heap allocated backing memory for s is automatically freed after
a successful grow. (For the first grow, there is nothing to free,
but for the second and subsequent growths, the old heap memory is
freed automatically.)
The new runtime.growsliceNoAlias is primarily implemented
by calling runtime.freegc, which we introduced in CL 673695.
The high-level approach here is we step through the IR starting
from a slice declaration and look for any operations that either
alias the slice or might do so, and treat any IR construct we
don't specifically handle as a potential alias (and therefore
conservatively fall back to treating the slice as aliased when
encountering something not understood).
For loops, some additional care is required. We arrange the analysis
so that an alias in the body of a loop causes all the appends in that
same loop body to be marked aliased, even if the aliasing occurs after
the append in the IR:
func f2() {
var s []int
for i := range 10 {
s = append(s, i) // aliased due to next line
alias = s
}
}
For nested loops, we analyse the nesting appropriately so that
for example this append is still proven as non-aliased in the
inner loop even though it aliased for the outer loop:
func f3() {
for range 10 {
var s []int
for i := range 10 {
s = append(s, i) // append using non-aliased slice
}
alias = s
}
}
A good starting point is the beginning of the test/escape_alias.go file,
which starts with ~10 introductory examples with brief comments that
attempt to illustrate the high-level approach.
For more details, see the new .../internal/escape/alias.go file,
especially the (*aliasAnalysis).analyze method.
In the first benchmark, an append in a loop builds up a slice from
nothing, where the slice elements are each 64 bytes. In the table below,
'count' is the number of appends. With 1 append, there is no opportunity
for this CL to free memory. Once there are 2 appends, the growth from
1 element to 2 elements means the compiler-inserted growsliceNoAlias
frees the 1-element array, and we see a ~33% reduction in memory use
and a small reported speed improvement.
As the number of appends increases for example to 5, we are at
a ~20% speed improvement and ~45% memory reduction, and so on until
we reach ~40% faster and ~50% less memory allocated at the end of
the table.
There can be variation in the reported numbers based on -randlayout, so
this table is for 30 different values of -randlayout with a total
n=150. (Even so, there is still some variation, so we probably should
not read too much into small changes.) This is with GOAMD64=v3 on
a VM that gcc reports is cascadelake.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
Append64Bytes/count=1-4 31.09n ± 2% 31.69n ± 1% +1.95% (n=150)
Append64Bytes/count=2-4 73.31n ± 1% 70.27n ± 0% -4.15% (n=150)
Append64Bytes/count=3-4 142.7n ± 1% 124.6n ± 1% -12.68% (n=150)
Append64Bytes/count=4-4 149.6n ± 1% 127.7n ± 0% -14.64% (n=150)
Append64Bytes/count=5-4 277.1n ± 1% 213.6n ± 0% -22.90% (n=150)
Append64Bytes/count=6-4 280.7n ± 1% 216.5n ± 1% -22.87% (n=150)
Append64Bytes/count=10-4 544.3n ± 1% 386.6n ± 0% -28.97% (n=150)
Append64Bytes/count=20-4 1058.5n ± 1% 715.6n ± 1% -32.39% (n=150)
Append64Bytes/count=50-4 2.121µ ± 1% 1.404µ ± 1% -33.83% (n=150)
Append64Bytes/count=100-4 4.152µ ± 1% 2.736µ ± 1% -34.11% (n=150)
Append64Bytes/count=200-4 7.753µ ± 1% 4.882µ ± 1% -37.03% (n=150)
Append64Bytes/count=400-4 15.163µ ± 2% 9.273µ ± 1% -38.84% (n=150)
geomean 601.8n 455.0n -24.39%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
Append64Bytes/count=1-4 64.00 ± 0% 64.00 ± 0% ~ (n=150)
Append64Bytes/count=2-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
Append64Bytes/count=3-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=4-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=5-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=6-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=10-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
Append64Bytes/count=20-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
Append64Bytes/count=50-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
Append64Bytes/count=100-4 15.938Ki ± 0% 8.021Ki ± 0% -49.67% (n=150)
Append64Bytes/count=200-4 31.94Ki ± 0% 16.08Ki ± 0% -49.64% (n=150)
Append64Bytes/count=400-4 63.94Ki ± 0% 32.33Ki ± 0% -49.44% (n=150)
geomean 1.991Ki 1.124Ki -43.54%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
Append64Bytes/count=1-4 1.000 ± 0% 1.000 ± 0% ~ (n=150)
Append64Bytes/count=2-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
Append64Bytes/count=3-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=4-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=5-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=6-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=10-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
Append64Bytes/count=20-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
Append64Bytes/count=50-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
Append64Bytes/count=100-4 8.000 ± 0% 1.000 ± 0% -87.50% (n=150)
Append64Bytes/count=200-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
Append64Bytes/count=400-4 10.000 ± 0% 1.000 ± 0% -90.00% (n=150)
geomean 4.331 1.000 -76.91%
The second benchmark is similar, but instead uses an 8-byte integer
for the slice element. The first 4 appends in the loop never call into
the runtime thanks to the excellent CL 664299 introduced by Keith in
Go 1.25 that allows some <= 32 byte dynamically-sized slices to be on
the stack, so this CL is neutral for <= 32 bytes. Once the 5th append
occurs at count=5, a grow happens via the runtime and heap allocates
as normal, but freegc does not yet have anything to free, so we see
a small ~1.4ns penalty reported there. But once the second growth
happens, the older heap memory is now automatically freed by freegc,
so we start to see some benefit in memory reductions and speed
improvements, starting at a tiny speed improvement (close to a wash,
or maybe noise) by the second growth before count=10, and building up to
~2x faster with ~68% fewer allocated bytes reported.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
AppendInt/count=1-4 2.978n ± 0% 2.969n ± 0% -0.30% (p=0.000 n=150)
AppendInt/count=4-4 4.292n ± 3% 4.163n ± 3% ~ (p=0.528 n=150)
AppendInt/count=5-4 33.50n ± 0% 34.93n ± 0% +4.25% (p=0.000 n=150)
AppendInt/count=10-4 76.21n ± 1% 75.67n ± 0% -0.72% (p=0.000 n=150)
AppendInt/count=20-4 150.6n ± 1% 133.0n ± 0% -11.65% (n=150)
AppendInt/count=50-4 284.1n ± 1% 225.6n ± 0% -20.59% (n=150)
AppendInt/count=100-4 544.2n ± 1% 392.4n ± 1% -27.89% (n=150)
AppendInt/count=200-4 1051.5n ± 1% 702.3n ± 0% -33.21% (n=150)
AppendInt/count=400-4 2.041µ ± 1% 1.312µ ± 1% -35.70% (n=150)
AppendInt/count=1000-4 5.224µ ± 2% 2.851µ ± 1% -45.43% (n=150)
AppendInt/count=2000-4 11.770µ ± 1% 6.010µ ± 1% -48.94% (n=150)
AppendInt/count=3000-4 17.747µ ± 2% 8.264µ ± 1% -53.44% (n=150)
geomean 331.8n 246.4n -25.72%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 64.00 ± 0% 64.00 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
AppendInt/count=20-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
AppendInt/count=50-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
AppendInt/count=100-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
AppendInt/count=200-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
AppendInt/count=400-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
AppendInt/count=1000-4 24.56Ki ± 0% 10.05Ki ± 0% -59.07% (n=150)
AppendInt/count=2000-4 58.56Ki ± 0% 20.31Ki ± 0% -65.32% (n=150)
AppendInt/count=3000-4 85.19Ki ± 0% 27.30Ki ± 0% -67.95% (n=150)
geomean ² -42.81%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
AppendInt/count=20-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
AppendInt/count=50-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
AppendInt/count=100-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
AppendInt/count=200-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
AppendInt/count=400-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
AppendInt/count=1000-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
AppendInt/count=2000-4 11.000 ± 0% 1.000 ± 0% -90.91% (n=150)
AppendInt/count=3000-4 12.000 ± 0% 1.000 ± 0% -91.67% (n=150)
geomean ² -72.76% ²
Of course, these are just microbenchmarks, but likely indicate
there are some opportunities here.
The immediately following CL 712422 tackles inlining and is able to get
runtime.freegc working automatically with iterators such as used by
slices.Collect, which becomes able to automatically free the
intermediate memory from its repeated appends (which earlier
in this work required a temporary hand edit to the slices package).
For now, we only use the NoAlias version for element types without
pointers while waiting on additional runtime support in CL 698515.
Updates #74299
Change-Id: I1b9d286aa97c170dcc2e203ec0f8ca72d84e8221
Reviewed-on: https://go-review.googlesource.com/c/go/+/710015
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
2025-11-25 09:57:50 -05:00
|
|
|
// growsliceNoAlias is like growslice but only for the case where
|
|
|
|
|
// we know that oldPtr is not aliased.
|
|
|
|
|
//
|
|
|
|
|
// In other words, the caller must know that there are no other references
|
|
|
|
|
// to the backing memory of the slice being grown aside from the slice header
|
|
|
|
|
// that will be updated with new backing memory when growsliceNoAlias
|
|
|
|
|
// returns, and therefore oldPtr must be the only pointer to its referent
|
|
|
|
|
// aside from the slice header updated by the returned slice.
|
|
|
|
|
//
|
|
|
|
|
// In addition, oldPtr must point to the start of the allocation and match
|
|
|
|
|
// the pointer that was returned by mallocgc. In particular, oldPtr must not
|
|
|
|
|
// be an interior pointer, such as after a reslice.
|
|
|
|
|
//
|
|
|
|
|
// See freegc for details.
|
|
|
|
|
func growsliceNoAlias(oldPtr unsafe.Pointer, newLen, oldCap, num int, et *_type) slice {
|
|
|
|
|
s := growslice(oldPtr, newLen, oldCap, num, et)
|
|
|
|
|
if goexperiment.RuntimeFreegc && oldPtr != nil && oldPtr != s.array {
|
|
|
|
|
if gp := getg(); uintptr(oldPtr) < gp.stack.lo || gp.stack.hi <= uintptr(oldPtr) {
|
|
|
|
|
// oldPtr does not point into the current stack, and it is not
|
|
|
|
|
// the data pointer for s after the grow, so attempt to free it.
|
|
|
|
|
// (Note that freegc also verifies that oldPtr does not point into our stack,
|
|
|
|
|
// but checking here first is slightly cheaper for the case when
|
|
|
|
|
// oldPtr is on the stack and freegc would be a no-op.)
|
|
|
|
|
//
|
|
|
|
|
// TODO(thepudds): it may be that oldPtr==s.array only when elemsize==0,
|
|
|
|
|
// so perhaps we could prohibit growsliceNoAlias being called in that case
|
|
|
|
|
// and eliminate that check here, or alternatively, we could lean into
|
|
|
|
|
// freegc being a no-op for zero-sized allocations (that is, no check of
|
|
|
|
|
// oldPtr != s.array here and just let freegc return quickly).
|
|
|
|
|
noscan := !et.Pointers()
|
|
|
|
|
freegc(oldPtr, uintptr(oldCap)*et.Size_, noscan)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return s
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-17 17:33:15 +03:00
|
|
|
// nextslicecap computes the next appropriate slice length.
|
|
|
|
|
func nextslicecap(newLen, oldCap int) int {
|
|
|
|
|
newcap := oldCap
|
|
|
|
|
doublecap := newcap + newcap
|
|
|
|
|
if newLen > doublecap {
|
|
|
|
|
return newLen
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const threshold = 256
|
|
|
|
|
if oldCap < threshold {
|
|
|
|
|
return doublecap
|
|
|
|
|
}
|
|
|
|
|
for {
|
|
|
|
|
// Transition from growing 2x for small slices
|
|
|
|
|
// to growing 1.25x for large slices. This formula
|
|
|
|
|
// gives a smooth-ish transition between the two.
|
|
|
|
|
newcap += (newcap + 3*threshold) >> 2
|
|
|
|
|
|
|
|
|
|
// We need to check `newcap >= newLen` and whether `newcap` overflowed.
|
|
|
|
|
// newLen is guaranteed to be larger than zero, hence
|
|
|
|
|
// when newcap overflows then `uint(newcap) > uint(newLen)`.
|
|
|
|
|
// This allows to check for both with the same comparison.
|
|
|
|
|
if uint(newcap) >= uint(newLen) {
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Set newcap to the requested cap when
|
|
|
|
|
// the newcap calculation overflowed.
|
|
|
|
|
if newcap <= 0 {
|
|
|
|
|
return newLen
|
|
|
|
|
}
|
|
|
|
|
return newcap
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 17:09:02 -04:00
|
|
|
// reflect_growslice should be an internal detail,
|
|
|
|
|
// but widely used packages access it using linkname.
|
|
|
|
|
// Notable members of the hall of shame include:
|
|
|
|
|
// - github.com/cloudwego/dynamicgo
|
|
|
|
|
//
|
|
|
|
|
// Do not remove or change the type signature.
|
|
|
|
|
// See go.dev/issue/67401.
|
|
|
|
|
//
|
2022-03-02 13:01:48 -08:00
|
|
|
//go:linkname reflect_growslice reflect.growslice
|
|
|
|
|
func reflect_growslice(et *_type, old slice, num int) slice {
|
|
|
|
|
// Semantically equivalent to slices.Grow, except that the caller
|
|
|
|
|
// is responsible for ensuring that old.len+num > old.cap.
|
|
|
|
|
num -= old.cap - old.len // preserve memory of old[old.len:old.cap]
|
|
|
|
|
new := growslice(old.array, old.cap+num, old.cap, num, et)
|
|
|
|
|
// growslice does not zero out new[old.cap:new.len] since it assumes that
|
|
|
|
|
// the memory will be overwritten by an append() that called growslice.
|
|
|
|
|
// Since the caller of reflect_growslice is not append(),
|
|
|
|
|
// zero out this region before returning the slice to the reflect package.
|
2024-02-27 21:51:31 +00:00
|
|
|
if !et.Pointers() {
|
2023-01-20 16:41:57 -05:00
|
|
|
oldcapmem := uintptr(old.cap) * et.Size_
|
|
|
|
|
newlenmem := uintptr(new.len) * et.Size_
|
2022-03-02 13:01:48 -08:00
|
|
|
memclrNoHeapPointers(add(new.array, oldcapmem), newlenmem-oldcapmem)
|
|
|
|
|
}
|
|
|
|
|
new.len = old.len // preserve the old length
|
|
|
|
|
return new
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-23 15:45:03 -05:00
|
|
|
func isPowerOfTwo(x uintptr) bool {
|
|
|
|
|
return x&(x-1) == 0
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-14 16:30:43 +02:00
|
|
|
// slicecopy is used to copy from a string or slice of pointerless elements into a slice.
|
|
|
|
|
func slicecopy(toPtr unsafe.Pointer, toLen int, fromPtr unsafe.Pointer, fromLen int, width uintptr) int {
|
|
|
|
|
if fromLen == 0 || toLen == 0 {
|
2014-07-31 12:43:40 -07:00
|
|
|
return 0
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-14 16:30:43 +02:00
|
|
|
n := fromLen
|
2020-01-31 21:01:55 -08:00
|
|
|
if toLen < n {
|
|
|
|
|
n = toLen
|
2014-07-31 12:43:40 -07:00
|
|
|
}
|
|
|
|
|
|
2014-12-30 12:31:17 -08:00
|
|
|
if width == 0 {
|
|
|
|
|
return n
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-14 16:30:43 +02:00
|
|
|
size := uintptr(n) * width
|
2014-07-31 12:43:40 -07:00
|
|
|
if raceenabled {
|
2024-09-16 14:07:43 -04:00
|
|
|
callerpc := sys.GetCallerPC()
|
2021-05-21 13:37:19 -04:00
|
|
|
pc := abi.FuncPCABIInternal(slicecopy)
|
2020-09-14 16:30:43 +02:00
|
|
|
racereadrangepc(fromPtr, size, callerpc, pc)
|
|
|
|
|
racewriterangepc(toPtr, size, callerpc, pc)
|
2014-07-31 12:43:40 -07:00
|
|
|
}
|
2015-10-21 11:04:42 -07:00
|
|
|
if msanenabled {
|
2020-09-14 16:30:43 +02:00
|
|
|
msanread(fromPtr, size)
|
|
|
|
|
msanwrite(toPtr, size)
|
2015-10-21 11:04:42 -07:00
|
|
|
}
|
2021-01-05 17:52:43 +08:00
|
|
|
if asanenabled {
|
|
|
|
|
asanread(fromPtr, size)
|
|
|
|
|
asanwrite(toPtr, size)
|
|
|
|
|
}
|
2014-07-31 12:43:40 -07:00
|
|
|
|
|
|
|
|
if size == 1 { // common case worth about 2x to do here
|
|
|
|
|
// TODO: is this still worth it with new memmove impl?
|
2020-09-14 16:30:43 +02:00
|
|
|
*(*byte)(toPtr) = *(*byte)(fromPtr) // known to be a byte pointer
|
2014-07-31 12:43:40 -07:00
|
|
|
} else {
|
2020-09-14 16:30:43 +02:00
|
|
|
memmove(toPtr, fromPtr, size)
|
2014-07-31 12:43:40 -07:00
|
|
|
}
|
|
|
|
|
return n
|
|
|
|
|
}
|
2022-12-08 03:51:04 -08:00
|
|
|
|
|
|
|
|
//go:linkname bytealg_MakeNoZero internal/bytealg.MakeNoZero
|
|
|
|
|
func bytealg_MakeNoZero(len int) []byte {
|
|
|
|
|
if uintptr(len) > maxAlloc {
|
|
|
|
|
panicmakeslicelen()
|
|
|
|
|
}
|
2024-02-02 15:54:24 +00:00
|
|
|
cap := roundupsize(uintptr(len), true)
|
2025-07-28 11:36:17 +00:00
|
|
|
return unsafe.Slice((*byte)(mallocgc(cap, nil, false)), cap)[:len]
|
2022-12-08 03:51:04 -08:00
|
|
|
}
|
cmd/compile: stack allocate backing stores during append
We can already stack allocate the backing store during append if the
resulting backing store doesn't escape. See CL 664299.
This CL enables us to often stack allocate the backing store during
append *even if* the result escapes. Typically, for code like:
func f(n int) []int {
var r []int
for i := range n {
r = append(r, i)
}
return r
}
the backing store for r escapes, but only by returning it.
Could we operate with r on the stack for most of its lifeime,
and only move it to the heap at the return point?
The current implementation of append will need to do an allocation
each time it calls growslice. This will happen on the 1st, 2nd, 4th,
8th, etc. append calls. The allocations done by all but the
last growslice call will then immediately be garbage.
We'd like to avoid doing some of those intermediate allocations
if possible. We rewrite the above code by introducing a move2heap
operation:
func f(n int) []int {
var r []int
for i := range n {
r = append(r, i)
}
r = move2heap(r)
return r
}
Using the move2heap runtime function, which does:
move2heap(r):
If r is already backed by heap storage, return r.
Otherwise, copy r to the heap and return the copy.
Now we can treat the backing store of r allocated at the
append site as not escaping. Previous stack allocation
optimizations now apply, which can use a fixed-size
stack-allocated backing store for r when appending.
See the description in cmd/compile/internal/slice/slice.go
for how we ensure that this optimization is safe.
Change-Id: I81f36e58bade2241d07f67967d8d547fff5302b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/707755
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-09-12 14:43:19 -07:00
|
|
|
|
|
|
|
|
// moveSlice copies the input slice to the heap and returns it.
|
|
|
|
|
// et is the element type of the slice.
|
|
|
|
|
func moveSlice(et *_type, old unsafe.Pointer, len, cap int) (unsafe.Pointer, int, int) {
|
|
|
|
|
if cap == 0 {
|
|
|
|
|
if old != nil {
|
|
|
|
|
old = unsafe.Pointer(&zerobase)
|
|
|
|
|
}
|
|
|
|
|
return old, 0, 0
|
|
|
|
|
}
|
|
|
|
|
capmem := uintptr(cap) * et.Size_
|
|
|
|
|
new := mallocgc(capmem, et, true)
|
|
|
|
|
bulkBarrierPreWriteSrcOnly(uintptr(new), uintptr(old), capmem, et)
|
|
|
|
|
memmove(new, old, capmem)
|
|
|
|
|
return new, len, cap
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// moveSliceNoScan is like moveSlice except the element type is known to
|
|
|
|
|
// not have any pointers. We instead pass in the size of the element.
|
|
|
|
|
func moveSliceNoScan(elemSize uintptr, old unsafe.Pointer, len, cap int) (unsafe.Pointer, int, int) {
|
|
|
|
|
if cap == 0 {
|
|
|
|
|
if old != nil {
|
|
|
|
|
old = unsafe.Pointer(&zerobase)
|
|
|
|
|
}
|
|
|
|
|
return old, 0, 0
|
|
|
|
|
}
|
|
|
|
|
capmem := uintptr(cap) * elemSize
|
|
|
|
|
new := mallocgc(capmem, nil, false)
|
|
|
|
|
memmove(new, old, capmem)
|
|
|
|
|
return new, len, cap
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// moveSliceNoCap is like moveSlice, but can pick any appropriate capacity
|
|
|
|
|
// for the returned slice.
|
|
|
|
|
// Elements between len and cap in the returned slice will be zeroed.
|
|
|
|
|
func moveSliceNoCap(et *_type, old unsafe.Pointer, len int) (unsafe.Pointer, int, int) {
|
|
|
|
|
if len == 0 {
|
|
|
|
|
if old != nil {
|
|
|
|
|
old = unsafe.Pointer(&zerobase)
|
|
|
|
|
}
|
|
|
|
|
return old, 0, 0
|
|
|
|
|
}
|
|
|
|
|
lenmem := uintptr(len) * et.Size_
|
|
|
|
|
capmem := roundupsize(lenmem, false)
|
|
|
|
|
new := mallocgc(capmem, et, true)
|
|
|
|
|
bulkBarrierPreWriteSrcOnly(uintptr(new), uintptr(old), lenmem, et)
|
|
|
|
|
memmove(new, old, lenmem)
|
|
|
|
|
return new, len, int(capmem / et.Size_)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// moveSliceNoCapNoScan is a combination of moveSliceNoScan and moveSliceNoCap.
|
|
|
|
|
func moveSliceNoCapNoScan(elemSize uintptr, old unsafe.Pointer, len int) (unsafe.Pointer, int, int) {
|
|
|
|
|
if len == 0 {
|
|
|
|
|
if old != nil {
|
|
|
|
|
old = unsafe.Pointer(&zerobase)
|
|
|
|
|
}
|
|
|
|
|
return old, 0, 0
|
|
|
|
|
}
|
|
|
|
|
lenmem := uintptr(len) * elemSize
|
|
|
|
|
capmem := roundupsize(lenmem, true)
|
|
|
|
|
new := mallocgc(capmem, nil, false)
|
|
|
|
|
memmove(new, old, lenmem)
|
|
|
|
|
if capmem > lenmem {
|
|
|
|
|
memclrNoHeapPointers(add(new, lenmem), capmem-lenmem)
|
|
|
|
|
}
|
|
|
|
|
return new, len, int(capmem / elemSize)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// growsliceBuf is like growslice, but we can use the given buffer
|
|
|
|
|
// as a backing store if we want. bufPtr must be on the stack.
|
|
|
|
|
func growsliceBuf(oldPtr unsafe.Pointer, newLen, oldCap, num int, et *_type, bufPtr unsafe.Pointer, bufLen int) slice {
|
|
|
|
|
if newLen > bufLen {
|
|
|
|
|
// Doesn't fit, process like a normal growslice.
|
|
|
|
|
return growslice(oldPtr, newLen, oldCap, num, et)
|
|
|
|
|
}
|
|
|
|
|
oldLen := newLen - num
|
|
|
|
|
if oldPtr != bufPtr && oldLen != 0 {
|
|
|
|
|
// Move data to start of buffer.
|
|
|
|
|
// Note: bufPtr is on the stack, so no write barrier needed.
|
|
|
|
|
memmove(bufPtr, oldPtr, uintptr(oldLen)*et.Size_)
|
|
|
|
|
}
|
|
|
|
|
// Pick a new capacity.
|
|
|
|
|
//
|
|
|
|
|
// Unlike growslice, we don't need to double the size each time.
|
|
|
|
|
// The work done here is not proportional to the length of the slice.
|
|
|
|
|
// (Unless the memmove happens above, but that is rare, and in any
|
|
|
|
|
// case there are not many elements on this path.)
|
|
|
|
|
//
|
|
|
|
|
// Instead, we try to just bump up to the next size class.
|
|
|
|
|
// This will ensure that we don't waste any space when we eventually
|
|
|
|
|
// call moveSlice with the resulting slice.
|
|
|
|
|
newCap := int(roundupsize(uintptr(newLen)*et.Size_, !et.Pointers()) / et.Size_)
|
|
|
|
|
|
|
|
|
|
// Zero slice beyond newLen.
|
|
|
|
|
// The buffer is stack memory, so NoHeapPointers is ok.
|
|
|
|
|
// Caller will overwrite [oldLen:newLen], so we don't need to zero that portion.
|
|
|
|
|
// If et.Pointers(), buffer is at least initialized so we don't need to
|
|
|
|
|
// worry about the caller overwriting junk in [oldLen:newLen].
|
|
|
|
|
if newLen < newCap {
|
|
|
|
|
memclrNoHeapPointers(add(bufPtr, uintptr(newLen)*et.Size_), uintptr(newCap-newLen)*et.Size_)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return slice{bufPtr, newLen, newCap}
|
|
|
|
|
}
|
cmd/compile: introduce alias analysis and automatically free non-aliased memory after growslice
This CL is part of a set of CLs that attempt to reduce how much work the
GC must do. See the design in https://go.dev/design/74299-runtime-freegc
This CL updates the compiler to examine append calls to prove
whether or not the slice is aliased.
If proven unaliased, the compiler automatically inserts a call to a new
runtime function introduced with this CL, runtime.growsliceNoAlias,
which frees the old backing memory immediately after slice growth is
complete and the old storage is logically dead.
Two append benchmarks below show promising results, executing up to
~2x faster and up to factor of ~3 memory reduction with this CL.
The approach works with multiple append calls for the same slice,
including inside loops, and the final slice memory can be escaping,
such as in a classic pattern of returning a slice from a function
after the slice is built. (The final slice memory is never freed with
this CL, though we have other work that tackles that.)
An example target for this CL is we automatically free the
intermediate memory for the appends in the loop in this function:
func f1(input []int) []int {
var s []int
for _, x := range input {
s = append(s, g(x)) // s cannot be aliased here
if h(x) {
s = append(s, x) // s cannot be aliased here
}
}
return s // slice escapes at end
}
In this case, the compiler and the runtime collaborate so that
the heap allocated backing memory for s is automatically freed after
a successful grow. (For the first grow, there is nothing to free,
but for the second and subsequent growths, the old heap memory is
freed automatically.)
The new runtime.growsliceNoAlias is primarily implemented
by calling runtime.freegc, which we introduced in CL 673695.
The high-level approach here is we step through the IR starting
from a slice declaration and look for any operations that either
alias the slice or might do so, and treat any IR construct we
don't specifically handle as a potential alias (and therefore
conservatively fall back to treating the slice as aliased when
encountering something not understood).
For loops, some additional care is required. We arrange the analysis
so that an alias in the body of a loop causes all the appends in that
same loop body to be marked aliased, even if the aliasing occurs after
the append in the IR:
func f2() {
var s []int
for i := range 10 {
s = append(s, i) // aliased due to next line
alias = s
}
}
For nested loops, we analyse the nesting appropriately so that
for example this append is still proven as non-aliased in the
inner loop even though it aliased for the outer loop:
func f3() {
for range 10 {
var s []int
for i := range 10 {
s = append(s, i) // append using non-aliased slice
}
alias = s
}
}
A good starting point is the beginning of the test/escape_alias.go file,
which starts with ~10 introductory examples with brief comments that
attempt to illustrate the high-level approach.
For more details, see the new .../internal/escape/alias.go file,
especially the (*aliasAnalysis).analyze method.
In the first benchmark, an append in a loop builds up a slice from
nothing, where the slice elements are each 64 bytes. In the table below,
'count' is the number of appends. With 1 append, there is no opportunity
for this CL to free memory. Once there are 2 appends, the growth from
1 element to 2 elements means the compiler-inserted growsliceNoAlias
frees the 1-element array, and we see a ~33% reduction in memory use
and a small reported speed improvement.
As the number of appends increases for example to 5, we are at
a ~20% speed improvement and ~45% memory reduction, and so on until
we reach ~40% faster and ~50% less memory allocated at the end of
the table.
There can be variation in the reported numbers based on -randlayout, so
this table is for 30 different values of -randlayout with a total
n=150. (Even so, there is still some variation, so we probably should
not read too much into small changes.) This is with GOAMD64=v3 on
a VM that gcc reports is cascadelake.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
Append64Bytes/count=1-4 31.09n ± 2% 31.69n ± 1% +1.95% (n=150)
Append64Bytes/count=2-4 73.31n ± 1% 70.27n ± 0% -4.15% (n=150)
Append64Bytes/count=3-4 142.7n ± 1% 124.6n ± 1% -12.68% (n=150)
Append64Bytes/count=4-4 149.6n ± 1% 127.7n ± 0% -14.64% (n=150)
Append64Bytes/count=5-4 277.1n ± 1% 213.6n ± 0% -22.90% (n=150)
Append64Bytes/count=6-4 280.7n ± 1% 216.5n ± 1% -22.87% (n=150)
Append64Bytes/count=10-4 544.3n ± 1% 386.6n ± 0% -28.97% (n=150)
Append64Bytes/count=20-4 1058.5n ± 1% 715.6n ± 1% -32.39% (n=150)
Append64Bytes/count=50-4 2.121µ ± 1% 1.404µ ± 1% -33.83% (n=150)
Append64Bytes/count=100-4 4.152µ ± 1% 2.736µ ± 1% -34.11% (n=150)
Append64Bytes/count=200-4 7.753µ ± 1% 4.882µ ± 1% -37.03% (n=150)
Append64Bytes/count=400-4 15.163µ ± 2% 9.273µ ± 1% -38.84% (n=150)
geomean 601.8n 455.0n -24.39%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
Append64Bytes/count=1-4 64.00 ± 0% 64.00 ± 0% ~ (n=150)
Append64Bytes/count=2-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
Append64Bytes/count=3-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=4-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=5-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=6-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=10-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
Append64Bytes/count=20-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
Append64Bytes/count=50-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
Append64Bytes/count=100-4 15.938Ki ± 0% 8.021Ki ± 0% -49.67% (n=150)
Append64Bytes/count=200-4 31.94Ki ± 0% 16.08Ki ± 0% -49.64% (n=150)
Append64Bytes/count=400-4 63.94Ki ± 0% 32.33Ki ± 0% -49.44% (n=150)
geomean 1.991Ki 1.124Ki -43.54%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
Append64Bytes/count=1-4 1.000 ± 0% 1.000 ± 0% ~ (n=150)
Append64Bytes/count=2-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
Append64Bytes/count=3-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=4-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=5-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=6-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=10-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
Append64Bytes/count=20-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
Append64Bytes/count=50-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
Append64Bytes/count=100-4 8.000 ± 0% 1.000 ± 0% -87.50% (n=150)
Append64Bytes/count=200-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
Append64Bytes/count=400-4 10.000 ± 0% 1.000 ± 0% -90.00% (n=150)
geomean 4.331 1.000 -76.91%
The second benchmark is similar, but instead uses an 8-byte integer
for the slice element. The first 4 appends in the loop never call into
the runtime thanks to the excellent CL 664299 introduced by Keith in
Go 1.25 that allows some <= 32 byte dynamically-sized slices to be on
the stack, so this CL is neutral for <= 32 bytes. Once the 5th append
occurs at count=5, a grow happens via the runtime and heap allocates
as normal, but freegc does not yet have anything to free, so we see
a small ~1.4ns penalty reported there. But once the second growth
happens, the older heap memory is now automatically freed by freegc,
so we start to see some benefit in memory reductions and speed
improvements, starting at a tiny speed improvement (close to a wash,
or maybe noise) by the second growth before count=10, and building up to
~2x faster with ~68% fewer allocated bytes reported.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
AppendInt/count=1-4 2.978n ± 0% 2.969n ± 0% -0.30% (p=0.000 n=150)
AppendInt/count=4-4 4.292n ± 3% 4.163n ± 3% ~ (p=0.528 n=150)
AppendInt/count=5-4 33.50n ± 0% 34.93n ± 0% +4.25% (p=0.000 n=150)
AppendInt/count=10-4 76.21n ± 1% 75.67n ± 0% -0.72% (p=0.000 n=150)
AppendInt/count=20-4 150.6n ± 1% 133.0n ± 0% -11.65% (n=150)
AppendInt/count=50-4 284.1n ± 1% 225.6n ± 0% -20.59% (n=150)
AppendInt/count=100-4 544.2n ± 1% 392.4n ± 1% -27.89% (n=150)
AppendInt/count=200-4 1051.5n ± 1% 702.3n ± 0% -33.21% (n=150)
AppendInt/count=400-4 2.041µ ± 1% 1.312µ ± 1% -35.70% (n=150)
AppendInt/count=1000-4 5.224µ ± 2% 2.851µ ± 1% -45.43% (n=150)
AppendInt/count=2000-4 11.770µ ± 1% 6.010µ ± 1% -48.94% (n=150)
AppendInt/count=3000-4 17.747µ ± 2% 8.264µ ± 1% -53.44% (n=150)
geomean 331.8n 246.4n -25.72%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 64.00 ± 0% 64.00 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
AppendInt/count=20-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
AppendInt/count=50-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
AppendInt/count=100-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
AppendInt/count=200-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
AppendInt/count=400-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
AppendInt/count=1000-4 24.56Ki ± 0% 10.05Ki ± 0% -59.07% (n=150)
AppendInt/count=2000-4 58.56Ki ± 0% 20.31Ki ± 0% -65.32% (n=150)
AppendInt/count=3000-4 85.19Ki ± 0% 27.30Ki ± 0% -67.95% (n=150)
geomean ² -42.81%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
AppendInt/count=20-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
AppendInt/count=50-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
AppendInt/count=100-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
AppendInt/count=200-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
AppendInt/count=400-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
AppendInt/count=1000-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
AppendInt/count=2000-4 11.000 ± 0% 1.000 ± 0% -90.91% (n=150)
AppendInt/count=3000-4 12.000 ± 0% 1.000 ± 0% -91.67% (n=150)
geomean ² -72.76% ²
Of course, these are just microbenchmarks, but likely indicate
there are some opportunities here.
The immediately following CL 712422 tackles inlining and is able to get
runtime.freegc working automatically with iterators such as used by
slices.Collect, which becomes able to automatically free the
intermediate memory from its repeated appends (which earlier
in this work required a temporary hand edit to the slices package).
For now, we only use the NoAlias version for element types without
pointers while waiting on additional runtime support in CL 698515.
Updates #74299
Change-Id: I1b9d286aa97c170dcc2e203ec0f8ca72d84e8221
Reviewed-on: https://go-review.googlesource.com/c/go/+/710015
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
2025-11-25 09:57:50 -05:00
|
|
|
|
|
|
|
|
// growsliceBufNoAlias is a combination of growsliceBuf and growsliceNoAlias.
|
|
|
|
|
// bufPtr must be on the stack.
|
|
|
|
|
func growsliceBufNoAlias(oldPtr unsafe.Pointer, newLen, oldCap, num int, et *_type, bufPtr unsafe.Pointer, bufLen int) slice {
|
|
|
|
|
s := growsliceBuf(oldPtr, newLen, oldCap, num, et, bufPtr, bufLen)
|
|
|
|
|
if goexperiment.RuntimeFreegc && oldPtr != bufPtr && oldPtr != nil && oldPtr != s.array {
|
|
|
|
|
// oldPtr is not bufPtr (the stack buffer) and it is not
|
|
|
|
|
// the data pointer for s after the grow, so attempt to free it.
|
|
|
|
|
// (Note that freegc does a broader check that oldPtr does not point into our stack,
|
|
|
|
|
// but checking here first is slightly cheaper for a common case when oldPtr is bufPtr
|
|
|
|
|
// and freegc would be a no-op.)
|
|
|
|
|
//
|
|
|
|
|
// TODO(thepudds): see related TODO in growsliceNoAlias about possibly eliminating
|
|
|
|
|
// the oldPtr != s.array check.
|
|
|
|
|
noscan := !et.Pointers()
|
|
|
|
|
freegc(oldPtr, uintptr(oldCap)*et.Size_, noscan)
|
|
|
|
|
}
|
|
|
|
|
return s
|
|
|
|
|
}
|