Currently, run.go sets GOEXPERIMENT build tags based on the
*difference* from the baseline experiment configuration, rather than
the absolute experiment configuration. This differs from cmd/go. As a
result, if we set a baseline configuration and don't override it with
a GOEXPERIMENT setting, run.go won't set any GOEXPERIMENT build tags,
instead of setting the tags corresponding to the baseline
configuration.
Fix this by making compile -V=goexperiment produce the full
GOEXPERIMENT configuration, which run.go can then use to set exactly
the right set of build tags.
For #40724.
Change-Id: Ieda6ea62f1a1fabbe8d749d6d09c198fd5ca8377
Reviewed-on: https://go-review.googlesource.com/c/go/+/310171
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We need to adjust baseline experiment configuration based on the
configured GOOS and GOARCH, so it can't live in goexperiment. Move it
to objabi.
Change-Id: I65f4ce56902c6c1a82735050773c58f2d1320cc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/310169
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The existing implementation allows read / write deadlines to exist
in the past. This updates conditionals to only add to the deadline
when the value is positive.
Fixes: #39177
Change-Id: I841c30ba2849a337e7bc98c8aa136c4527c314ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/235437
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Damien Neil <dneil@google.com>
The shift amount should be masked to avoid rotation values
beyond the numer of bits. In this case, if the shift amount
is 0, it should rotate 0, not 32.
Fixes#45589
Change-Id: I1e764497a39d0ec128e29af42352b70c70b2ecc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/310569
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
Only complain about missing type; leave it to type-checking
to decide whether "..." is permitted in the first place.
Fixes#43674.
Change-Id: Icbc8f084e364fe3ac16076406a134354219c08d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/310209
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This requires consolidating the register move operations into a
single case entry in asmout. These moves are also used to
sign/zero-extend register values.
Combine the three asmout cases for register moves. This allows
AMOVWZ and AMOVW to be handled with the same optab entries.
Likewise, remove the diagnostic error for non-zero constant
loads into R0 using the register move operations, it is not
possible to match this asmout case with a non-zero constant.
Finally, fix the load constant 0 via "MOV[BHW]{,Z} $0, Rx".
These now generate "li Rx, $0" instead of a zero/sign-extend
of the contents of R0.
Change-Id: Ia4a263661582f10feda27ee21cb121e05ea931dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/308190
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
If there is more than the expected single dial, the channel will block.
Allow at least one connection per client, and do the expected cleanup.
Updates #45570
Change-Id: Iaecd45298a7d7c591b7d7b1be13cea6e4a1e2e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/310213
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Damien Neil <dneil@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
This is probably unlikely in practice, but when debugging alignment
related issues on ppc64 using very small text section splits, the elf
header could grow beyond the preallocated space and quietly stomp
on the first few text sections.
Change-Id: Ided58aa0b1e60f9da4b3cb277e4ebafcee4ec693
Reviewed-on: https://go-review.googlesource.com/c/go/+/307430
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
The previous CL introduced macros for transitions from the Windows ABI
to the Go ABI. This CL does the same for SysV and uses them in almost
all places where we transition from the C ABI to the Go ABI.
Compared to Windows, this transition is much simpler and I didn't find
any places that were getting it wrong. But this does let us unify a
lot of code nicely and introduces some degree of abstraction around
these ABI transitions.
Change-Id: Ib6bdecafce587ce18fca4c8300fcf401284a2bcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/309930
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
There are several assembly functions that transition from the Windows
ABI to the Go ABI. These all need to save all registers that are
callee-save in the Windows ABI and caller-save in the Go ABI and
prepare the register state for Go. However, they all do this slightly
differently and most of them don't save the necessary XMM registers
for this transition (which could corrupt them in the C caller).
Furthermore, now that we have a carefully specified Go ABI, it's clear
that none of these actually get all of the details 100% right.
So, unify this code into two macros in a shared header in
runtime/cgo/abi_amd64.h that handle all necessary registers and setup
and use these macros everywhere on Windows that handles transitions
from C to Go.
Change-Id: I62f41345a507aad1ca383814ac8b7e2a9ffb821e
Reviewed-on: https://go-review.googlesource.com/c/go/+/309769
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This function bounces between the C and Go ABIs a few times. This CL
narrows the scope of the Go -> C transition to just around the branch
that calls C. This lets us take advantage of C callee-save registers
to simplify the code a little.
Change-Id: I1ffa0b9e50325425c5ec66596978aeb6450a6b57
Reviewed-on: https://go-review.googlesource.com/c/go/+/309929
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 308931 ported several runtime assembly functions to ABIInternal so
that compiler-generated ABIInternal calls don't go through ABI
wrappers, but it missed the runtime assembly functions that are
actually defined in internal/bytealg.
This eliminates the cost of wrappers for the BleveQuery and
GopherLuaKNucleotide benchmarks, but there's still more to do for
Tile38.
0-base 1-wrappers
sec/op sec/op vs base
BleveQuery 6.507 ± 0% 6.477 ± 0% -0.46% (p=0.004 n=20)
GopherLuaKNucleotide 30.39 ± 1% 30.34 ± 0% ~ (p=0.301 n=20)
Tile38IntersectsCircle100kmRequest 1.038m ± 1% 1.080m ± 2% +4.03% (p=0.000 n=20)
For #40724.
Change-Id: I0b722443f684fcb997b1d70802c5ed4b8d8f9829
Reviewed-on: https://go-review.googlesource.com/c/go/+/310184
Trust: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
According the armv8-a specification, the destination register of the ADDS/ADDSW/
SUBS/SUBSW instructions can not be RSP, the current implementation does not
check this and encodes this wrong instruction format as a CMN instruction. This
CL adds a check and test cases for this situation.
Change-Id: I92cc2f8e17dbda70f0dce8fddf1ca6d5d7730589
Reviewed-on: https://go-review.googlesource.com/c/go/+/309989
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Updates #45448
Change-Id: I2e79ae6b9cf43a481aa703578712619ea344e421
Reviewed-on: https://go-review.googlesource.com/c/go/+/310212
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I28a1910890659aaa449ffd2a847cd4ced5a8600d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310211
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Add in some missing global assignment ops to the list of globals ops
that should be traversed to look for generic function instantiations.
The most common other one for global assigments (and the relevant one
for this bug) is OAS2FUNC, but also look at global assigments with
OAS2DOTTYPE, OAS2MAPR, OAS2RECV, and OASOP.
Bonus small fix: get rid of -G=3 case in ir.IsAddressable. Now that we
don't call the old typechecker from noder2, we don't need this -G-3
check anymore.
Fixes#45547.
Change-Id: I75fecec55ea0d6f62e1c2294d4d77447ed9be6ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/310210
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes#44602
Change-Id: I28b6df5e2523fc2ece6fd8251fcabc83c7c38d89
Reviewed-on: https://go-review.googlesource.com/c/go/+/256478
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #45448
Change-Id: I4d8e5d7e57818355ef2bc33b57ddf9c8b8da3e62
Reviewed-on: https://go-review.googlesource.com/c/go/+/310030
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Updates #45448
Change-Id: Ic096fe1c58c124fb8d84ee15c9446e7ed060b24f
Reviewed-on: https://go-review.googlesource.com/c/go/+/310032
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
This change conforms Recorder with net/http servers, to panic
when a handler writes a non-3 digit XXX status code.
Fixes#45353
Change-Id: Id5ed4af652e8c150ae86bf50402b800d935e2203
Reviewed-on: https://go-review.googlesource.com/c/go/+/308950
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
This test expects 'go mod tidy' to fail if the existing module graph
has a bad checksum. However, there is no intrinsic reason why 'go mod
tidy' should fail in that case: the module contains no packages, and
thus no imports, so 'go mod tidy' can justifiably remove all
requirements without regard to any errors that may have already been
present in the module graph.
Adding a source file that imports a package from the module with the
bad checksum should guarantee that 'go mod tidy' reports the checksum
eror.
For #36460
Change-Id: I59734ac524031288bc03a11f58eed5abe2db76b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/309334
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
In CL 307909 we generate code that spills pointer-typed argument
registers if it is part of an SSA-able aggregate. The current
code spill the register unconditionally. Sometimes it is
unnecessary, because it is already spilled, or it is never live.
This CL reworks the spill generation. We move it to the end of
compilation, after liveness analysis, so we have information about
if a spill is necessary, and only generate spills for the
necessary ones.
Change-Id: I8d60be9b2c47651aeda14f5e2d1bbd207c134b26
Reviewed-on: https://go-review.googlesource.com/c/go/+/309331
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Fix a buglet in TestFinalizerRegisterABI that was causing problems
when run with GOEXPERIMENT=regabi.
Updates #40724.
Change-Id: I950c4aa3df69eada23e600f01e6804eb136ce806
Reviewed-on: https://go-review.googlesource.com/c/go/+/310077
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The debug call tests currently assume that the target Go function is
ABI0; this is clearly no longer true when we switch to the new ABI, so
make the tests set up argument register state in the debug call handler
and copy back results returned in registers.
A small snag in calling a Go function that follows the new ABI is that
the debug call protocol depends on the AX register being set to a
specific value as it bounces in and out of the handler, but this
register is part of the new register ABI, so results end up being
clobbered. Use R12 instead.
Next, the new desugaring behavior for "go" statements means that
newosproc1 must always call a function with no frame; if it takes any
arguments, it closes over them and they're passed in the context
register. Currently when debugCallWrap creates a new goroutine, it uses
newosproc1 directly and passes a non-zero-sized frame, so that needs to
be updated. To fix this, briefly use the g's param field which is
otherwise only used for channels to pass an explicitly allocated object
containing the "closed over" variables. While we could manually do the
desugaring ourselves (we cannot do so automatically because the Go
compiler prevents heap-allocated closures in the runtime), that bakes in
more ABI details in a place that really doesn't need to care about them.
Finally, there's an old bug here where the context register was set up
in CX, so technically closure calls never worked. Oops. It was otherwise
harmless for other types of calls before, but now CX is an argument
register, so now that interferes with regular calls, too.
For #40724.
Change-Id: I652c25ed56a25741bb04c24cfb603063c099edde
Reviewed-on: https://go-review.googlesource.com/c/go/+/309169
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Updates #45402
Change-Id: Ie84795ed456883c0558fa9b5e3f2186f5f2c0fd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/309356
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
The lines with tzdata are quite long.
It is easier to just copy a file than to encode it as
a string literal when adding a new test case.
Change-Id: Ibcaf347c3101a0f05b094e582b3473c7c35b685a
Reviewed-on: https://go-review.googlesource.com/c/go/+/308998
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Updates #45402
Change-Id: Ic2f696837034de17333a6a53127a4bfd301e96a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/309354
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Named.SetTParams sets the type parameters for a named type.
Named.Orig returns the original generic type an instantiated
type is derived from. Added a new field orig for that purpose
and renamed the already existing orig field to fromRHS.
Finally, updated various comments.
Change-Id: Ic9d173e42740422d195713d8bdc62a54dc8c5f54
Reviewed-on: https://go-review.googlesource.com/c/go/+/309832
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Now that go/ast changes have been guarded behind the typeparams build
tag, we no longer have coverage for tests involving generic code.
Add a new testing step to cmd/dist to run go/... and cmd/gofmt tests
using -tags=typeparams.
Comment out parser object resolution assertions that currently fail, and
which will be fixed by CL 304456.
Fixes#44933
Change-Id: I481dd4246a016f410307865b6c6c2bb3c8e6e3bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/310071
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
My rebase of https://golang.org/cl/300649 before submitting broke the
build (and tests) when using the typeparams build constraint. In a
subsequent CL I add test coverage back to cmd/dist.
This time, I've tested by running:
- go test -tags=typeparams go/...
- go test -tags=typeparams cmd/gofmt
All tests pass except for the new TestResolution/typeparams.go2, which I
will fix in a follow-up CL.
For #44933
Change-Id: I439d387841604cf43a90e2ce41dbe6bbbdb0306d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310070
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes this failure:
go test cmd/compile/internal/ssa -run TestStmtLines -v
=== RUN TestStmtLines
stmtlines_test.go:115: Saw too many (amd64, > 1%) lines without
statement marks, total=88263, nostmt=1930
('-run TestStmtLines -v' lists failing lines)
The failure has two causes.
One is that the first-line adjuster in code generation was relocating
"first lines" to instructions that would either not have any code generated,
or would have the statment marker removed by a different believed-good heuristic.
The other was that statement boundaries were getting attached to register
values (that with the old ABI were loads from the stack, hence real instructions).
The register values disappear at code generation.
The fixes are to (1) note that certain instructions are not good choices for
"first value" and skip them, and (2) in an expandCalls post-pass, look for
register valued instructions and under appropriate conditions move their
statement marker to a compatible use.
Also updates TestStmtLines to always log the score, for easier comparison of
minor compiler changes.
Updates #40724.
Change-Id: I485573ce900e292d7c44574adb7629cdb4695c3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/309649
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The compiler currently emits an "*.args_stackmap" symbol for all
bodyless functions, so that asm functions will have the proper stack
map. At the moment the code in the compiler that emits args_stackmap
assumes ABI0; to avoid misleading stackmaps, turn off args_stackmap
generation for non-ABI0 asm functions.
Updates #40724.
Change-Id: Ia5e3528d56da5fb107e799bd658e52496ba4a331
Reviewed-on: https://go-review.googlesource.com/c/go/+/309790
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change the assembler to enforce the requirement that ABIInternal
functions need to be NOSPLIT. At the moment all of the assembly
routines in the runtime that are defined as ABIInternal also
happen to be NOSPLIT, but this CL makes it mandatory.
Updates #40724.
Change-Id: Ief80d22de1782edb44b798fcde9aab8a93548722
Reviewed-on: https://go-review.googlesource.com/c/go/+/309789
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When callMethod calls the underlying method, after reflectcall
it gets the result registers in "Ints" slots but not in "Ptrs"
slots. If the GC runs at this point, it may lose track of those
pointers and free the memory they point to.
To make sure the GC sees the pointer results, copy "Ints" to
"Ptrs", and keep them alive until we return to the caller.
This fixes test/fixedbugs/issue27695.go with register ABI.
Change-Id: I4092c91bcbd6954683740a12d91d689900446875
Reviewed-on: https://go-review.googlesource.com/c/go/+/309909
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The 'go mod tidy' hint was truncated due to a typo in CL 293689,
and that particular case was not covered by any existing test.
Updates #36460
Updates #40775
Change-Id: Ib6fa872a9dfdafc4e9a112e8add2ff5aecd2dbd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/310089
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This makes it clearer that i and hbits advance together.
As a bonus, it generates slightly better code.
Change-Id: I24d51102535c39f962a59c1a4a7c5c894339aa18
Reviewed-on: https://go-review.googlesource.com/c/go/+/309569
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
For #44167.
Change-Id: Ie3cf8d2960c843a782ec85426fa73c279adaed64
Reviewed-on: https://go-review.googlesource.com/c/go/+/306605
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
For #44167.
Change-Id: I15817006f1870d6237cd06dabad988da3f23a6d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/306604
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change moves next_gc and last_next_gc into gcControllerState under
the names heapGoal and lastHeapGoal respectively. These are
fundamentally GC pacer related values, and so it makes sense for them to
live here.
Partially generated by
rf '
ex . {
memstats.next_gc -> gcController.heapGoal
memstats.last_next_gc -> gcController.lastHeapGoal
}
'
except for updates to comments and gcControllerState methods, where
they're accessed through the receiver, and trace-related renames of
NextGC -> HeapGoal, while we're here.
For #44167.
Change-Id: I1e871ad78a57b01be8d9f71bd662530c84853bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/306603
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
