Cherry Mui [Wed, 29 Sep 2021 20:47:12 +0000 (16:47 -0400)]
cmd/link: add runtime.text.N symbols to Mach-O symbol table
On Darwin/ARM64 when external linking, for very large text we
split it into multiple sections. For each section (other than the
first) we create runtime.text.N marker symbols. In CL 316050 I
forgot to add those symbols to the symbol table. This CL does it.
It doesn't actually matter for program execution. But we add them
on ELF when splitting text sections, so we do it here as well.
Also, this makes it easier to tell if we split text sections.
Change-Id: Ida7f8e9431867881e5ee2bc1a2129eeaf83cb878
Reviewed-on: https://go-review.googlesource.com/c/go/+/353209
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Cherry Mui [Thu, 30 Sep 2021 16:02:56 +0000 (12:02 -0400)]
debug/gosym: run TestPCLine on Linux/AMD64 in short mode
Currently TestPCLine is skipped in short mode. The test builds a
Linux/AMD64 binary, so it makes sense to skip it if we're cross
compiling, as building the runtime takes a while. But if we are
on Linux/AMD64, it will only build a small amount of code, which
isn't really slow. The test runs in 0.14 second on my machine.
I think it is acceptable to run in short mode. Then we'll have
trybot coverage for this test.
Change-Id: If682f88c28050f7daafde35b4f9e59c03b764a35
Reviewed-on: https://go-review.googlesource.com/c/go/+/353330
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Add doc comment about the time/tzdata package to the time.LoadLocation
function. The time.LoadLocation function was changed in Go 1.15 to add an extra
source that it considers for the time zone database. That location is the
time/tzdata package. It is not easy to discover this behavior because the
documentation for the time package doesn't mention it in the discussion on the
time.LoadLocation function when discussing the different sources. It would be helpful to
describe all possible sources that time.LoadLocation considers when loading the
time zone database, and so I think it would be worthwhile to mention
time/tzdata.
Change-Id: I408fbe188bf9d4ba797e59ec17eb677136d6a9c2
GitHub-Last-Rev: 3dac204326960a18c4e44d3ea24fd428e91e9fcb
GitHub-Pull-Request: golang/go#48673
Reviewed-on: https://go-review.googlesource.com/c/go/+/352830 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
cmd/asm: add error check for move constant instructions on arm64
The current Go assembler encodes "MOVK $(0<<16|32|48), Rd" as the
same binary with "MOVK $0, Rd", but for arm64 move constant instructions
MOVK, MOVN and MOVZ, "op $0, Rd" and "op $(0<<16|32|48), Rd" have
different semantics. In order not to change the way the assembler
frontend parses constants, this patch adds a check for the zero shifts.
Change-Id: Ia844c419ce49f63605b549e3a2e98d9075dd1cf1
Reviewed-on: https://go-review.googlesource.com/c/go/+/275812
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: fannie zhang <Fannie.Zhang@arm.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
The first field of the func data stored by the linker is the
entry PC for the function. Prior to this change, this was stored
as a relocation to the function. Change this to be an offset
relative to runtime.text.
This reduces the number of relocations on darwin/arm64 by about 10%.
It also slightly shrinks binaries:
It should also incrementally speed up binary launching.
This is the first step towards removing enough relocations
that pages that were previously dirtied by the loader may remain clean,
which will offer memory savings useful in constrained environments.
We do a bunch of manual offset calculations everywhere.
Add a bit of type safety and some helpers.
In addition to making the code clearer and providing a place
to hang some documentation, it also makes upcoming changes easier.
internal/fuzz: disconnect stdout and stderr from the worker
This was useful for debugging while we were developing
the feature, but is now causing extraneous prints that
make the command output difficult to read.
This change also prevents the go command from printing
an extraneous "FAIL" when fuzzing is enabled.
Fixes #48633
Fixes #46631
Change-Id: I636e65f305a20f6dcd843e62090ae228741a3725
Reviewed-on: https://go-review.googlesource.com/c/go/+/352892
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Ian Lance Taylor [Wed, 29 Sep 2021 17:50:18 +0000 (10:50 -0700)]
text/template: check final value for short-circuit and/or
There was a bug in the short-circuit code for and/or added in CL 321490:
it ignored the value passed in by an earlier pipeline.
For #31103
Change-Id: Ic31f4d7cedfe563ef968cbb712ecfb2413c42eb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353130
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
cmd/go: prevent necessary GCFlag from being removed
There are special flags that must be passed to the
compiler at build time in order to instrument the
testing binary for fuzzing.
One potential option would be to add these flags to
p.Internal.Gcflags inside cmd/go/internal/test. However,
future calls to setToolFlags can cause these flags to
get cleared about before the build starts, removing
virtually all coverage guidance. This change moves the
logic to add the flag deeper down the call stack,
preventing it from being cleared.
Change-Id: I40eadb0cacc18f29cee75379cd9380f9e73bb8da
Reviewed-on: https://go-review.googlesource.com/c/go/+/352511
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Robert Findley [Wed, 29 Sep 2021 13:35:02 +0000 (09:35 -0400)]
go/types, types2: rename Environment to Context
Replace the name Environment with Context, as discussed in #47916. Along
the way, fix some stale or inaccurate comments.
The Environment type remains temporarily as an alias for Context, to
allow the x/tools Trybot to pass until dependency on types.Environment
can be removed.
Updates #47916
Change-Id: Iffd069ab0e8adebf4207c8f8891468a64d32b7cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/353089
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Archana R [Fri, 24 Sep 2021 15:31:20 +0000 (10:31 -0500)]
cmd/compile: add PPC64-specific inlining for runtime.memmove
Add rule to PPC64.rules to inline runtime.memmove in more cases, as is
done for other target architectures
Updated tests in codegen/copy.go to verify changes are done on
ppc64/ppc64le
Updates #41662
Change-Id: Id937ce21f9b4f4047b3e66dfa3c960128ee16a2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/352054
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
debug/gosym assumes throughout that bogus input means a malformed file.
That's generally true, but not when you're changing the package.
In that case, the panic usually indicates a newly introduced bug,
and seeing the panic is really useful.
Dan Scales [Wed, 29 Sep 2021 04:14:17 +0000 (21:14 -0700)]
cmd/compile: make sure shapes have proper indexes for sub-instantiation
The computation for determining the shapes to use at the top of
getInstantation was not always creating shapes with the proper indexes.
If an instantiation is being called from another instantiated function,
we cannot just copy the shape types unchanged, because their indexes may
have changed. So, for type args that already shapes, we still call
Shapify() with the correct index.
Fixes #48645
Change-Id: Ibb61c6f9a3c317220fb85135ca87eb5ad4dcff9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/353030
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Michael Pratt [Tue, 28 Sep 2021 18:35:03 +0000 (14:35 -0400)]
runtime: drop nowritebarrier from gcParkAssist
Nothing in this function is at odds with having write barriers. It
originally inherited the annotation from gcAssistAlloc
http://golang.org/cl/30700, which subsequently dropped the annotation in
http://golang.org/cl/32431 as it was unnecessary.
Change-Id: Ie464e6b4ed957f57e922ec043728ff4e15bf35ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/352811
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Robert Griesemer [Wed, 29 Sep 2021 03:42:45 +0000 (20:42 -0700)]
go/types: avoid infinite recursion in unification
This is an almost clean port of CL 352832 from types2 to go/types:
The nest files and unify.go where copied verbatim; unify.go was
adjusted with correct package name, a slightly different comment
was restored to what it was. The test files got adjustments for
error position. infer.go got a missing _Todo error code.
For #48619.
For #48656.
Change-Id: Ia1a2d09e8bb37a85032b4b7e7c7a0b08e8c793a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353029
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Cherry Mui [Tue, 28 Sep 2021 20:20:29 +0000 (16:20 -0400)]
cmd/link: access pcdata via aux symbols
Pcdata are now separate aux symbols. Read them from aux, instead
of using funcinfo.
Now we can remove pcdata fields from funcinfo.
Change-Id: Ie65e3962edecc0f39127a5f6963dc59d1f141e67
Reviewed-on: https://go-review.googlesource.com/c/go/+/352893
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Robert Griesemer [Tue, 28 Sep 2021 20:50:15 +0000 (13:50 -0700)]
cmd/compile/internal/types2: avoid infinite recursion in unification
If the type T inferred for a type parameter P is P itself (or a derived
type containing P), a subsequent unification step leads to infinite
recursion: at each encounter of P with the already inferred type T
(which is or contains P), P stands for that T and the recursive matching
process continues with T, which inevitably contains P again and recursion
never terminates.
This CL introduces a set of masks, one for each type parameter.
When a type parameter is encountered for which a type has already
been inferred, the type parameter is "masked" for the recursive
matching of the inferred type. Masking makes the type parameter
"invisible" such that it will be handled like any other type and
not unpacked further.
Fixes #48619.
For #48656.
Change-Id: Ic1d938322be51fd44323ea14f925303f58b27c97
Reviewed-on: https://go-review.googlesource.com/c/go/+/352832
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
internal/bytealg: port bytealg functions to reg ABI on ppc64x
This adds support for the reg ABI to the bytes functions for
ppc64/ppc64le. These are initially under control of the
GOEXPERIMENT macro until all changes are in.
jiahua wang [Mon, 27 Sep 2021 14:54:16 +0000 (22:54 +0800)]
compress/gzip: add missing license
Change-Id: I80c2c6054f6a5be3555c72056159a47f927f9a44
Reviewed-on: https://go-review.googlesource.com/c/go/+/352409
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
jiahua wang [Sat, 25 Sep 2021 01:24:04 +0000 (09:24 +0800)]
io: add examples for (*SectionReader) Read/Size
Change-Id: Ie804f9a5d1d6beec210d2f8075c030a5c60a78ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/352152
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
reflect,runtime: add reflect support for regabi on PPC64
This adds the regabi support needed for reflect including:
- implementation of the makeFuncSub and methodValueCall for
reflect
- implementations of archFloat32FromReg and archFloat32ToReg
needed for PPC64 due to differences in the way float32 are
represented in registers as compared to other platforms
- change needed to stack.go due to the functions that are
changed above
Change-Id: Ida40d831370e39b91711ccb9616492b7fad3debf
Reviewed-on: https://go-review.googlesource.com/c/go/+/352429
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Leonard Wang [Sat, 11 Sep 2021 12:53:24 +0000 (20:53 +0800)]
runtime: add mp parameter for getMCache
Since all callers of getMCache appear to have mp available,
we pass the mp to getMCache, and reduce one call to getg.
And after modification, getMCache is also inlined.
Change-Id: Ib7880c118336acc026ecd7c60c5a88722c3ddfc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/349329
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Trust: Carlos Amedee <carlos@golang.org>
This is a port of CL 352616 from go/types to types2. It also removes
Interface.IsConstraint and adjusts all uses to use IsMethodSet. The
dual changes are made to the (unexported) type set implementation.
Change-Id: I292b741d1f7cdbaefb483eed75faf7b85a8d2792
Reviewed-on: https://go-review.googlesource.com/c/go/+/352872
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Jay Conrod [Fri, 24 Sep 2021 20:26:35 +0000 (13:26 -0700)]
cmd/go: make 'go get' fail with an error when outside a module
There's no go.mod file for 'go get' to update, so it has no effect,
other than checking arguments and filling the module cache. That might
be useul in some cases, but it seems better to fail loudly in case the
user hasn't seen the deprecation warning, for example, inside a
script.
For #43684
Change-Id: I6e67c782e3a1cb7046eac5c9df17eda7a31c7bce
Reviewed-on: https://go-review.googlesource.com/c/go/+/352149
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Jay Conrod [Tue, 14 Sep 2021 23:23:10 +0000 (16:23 -0700)]
cmd/go: 'go get' no longer builds or installs packages
As part of #40267, 'go install' is now fully responsible for building
and installing executables. 'go get' will only be used to change
versions in go.mod. The -d flag no longer has any effect; its behavior
is the default.
When 'go get' is invoked inside a module on a main package outside of
the main module, it no longer prints any warning. In 1.16-1.17, we
suggested using -d in this situation, but we want
'go get example.com/cmd' to be able to upgrade a tool dependency
without needing -d to suppress the warning.
For #43684
Change-Id: I9daf29c123a5a0e382aa326d62721cb26fc26c19
Reviewed-on: https://go-review.googlesource.com/c/go/+/349997
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
io: update ByteScanner and RuneScanner docs to match long-standing implementations
Do not require the byte or rune unread by the call to match the last
return from ReadByte or ReadRune, since in practice the
implementations of these methods (especially ReadByte) may also unread
bytes from other Read-style methods without reporting an error.
Explicitly allow the Seek-like behavior implemented by bytes.Reader
and bufio.Reader, which can “unread” bytes that were never actually
read.
Explicitly allow ReadByte or ReadRune to return an error after a call
to a non-ReadByte or non-ReadRune operation respectively.
(In practice, implementations today allow very liberal calls to
ReadByte and tend to be more strict about ReadRune, but it seems
simpler to keep the two definitions completely parallel.)
Like CL 349054, this is techincally a breaking change, but given the
long-standing behavior of the implementations in the Go standard
library (such as strings.Reader, bytes.Buffer, and bufio.Reader),
I believe it falls under the “specification errors” exception to the
Go 1 compatibility policy.
Fixes #48449
Change-Id: I61696a59770fe83c667377ba25a072762d3f6f19
Reviewed-on: https://go-review.googlesource.com/c/go/+/351809
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
Robert Griesemer [Wed, 22 Sep 2021 16:55:10 +0000 (09:55 -0700)]
cmd/compile/internal/types2: record all instances, not just inferred instances
This is a port of CL 349629 from go/types to types2, adjusted to
make it work for types2. It also includes the necessary compiler
changes, provided by mdempsky.
Change-Id: If8de174cee9c69df0d0642fcec1ee7622b7c3852
Reviewed-on: https://go-review.googlesource.com/c/go/+/351455
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Dan Scales <danscales@google.com>
Cherry Mui [Mon, 27 Sep 2021 19:35:46 +0000 (15:35 -0400)]
cmd/internal/obj: index pcdata symbols in NumberSyms
When writing an object file, most symbols are indexed in
NumberSyms. Currently, pcdata symbols are indexed late and
separately. This is not really necessary, as pcdata symbols
already exist at the time of NumberSyms. Just do it there.
As pcdata symbols are laid out in the pclntab in a special way at
link time, distinguish them from other symbols in the content
hash. (In the old code this was partly achieved by indexing them
late.)
Change-Id: Ie9e721382b0af2cfb39350d031e2e66d79095a3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/352611
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Robert Findley [Mon, 27 Sep 2021 23:49:38 +0000 (19:49 -0400)]
go/types: add the Interface.IsMethodSet method
As pointed out in #47916, the IsConstraint method becomes ambiguously
named if ever we allow interfaces with structural restrictions outside
of constraint position.
Add instead an IsMethodSet method, which has the opposite sense and
avoids this ambiguity. In a subsequent CL the IsConstraint method will
be removed, once x/tools has been updated to use the IsMethodSet API.
Updates #47916
Change-Id: I82ad16b111464b0cd2f354b8ecdd4b3f14796cd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/352616
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>
Robert Findley [Mon, 27 Sep 2021 23:23:17 +0000 (19:23 -0400)]
go/types: add a NewSignatureType constructor accepting type parameters
In #47916, consensus has emerged that adding a new constructor is
preferable to using setters for type parameters. This is more consistent
with the rest of the type API, which is immutable except in cases where
mutation is necessary to break cycles (such as Named.SetUnderlying).
This CL adds a new constructor NewSignatureType that accepts type
parameters and receiver type parameters, deprecating the existing
NewSignature constructor. SetTypeParams and SetRecvTypeParams are not
yet removed: this will be done in a follow-up CL once x/tools no longer
has a dependency on the old APIs.
Updates #47916
Change-Id: I9d04dcfd304344d2aa08e527b371c3faa9d738e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/352615
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>
cmd/internal/obj: refactor code to separate content-addressable symbols by section
The goal of this change is to improve the documentation
and make it easier to keep Link.NumberSyms and writer.contentHash aligned.
No functional changes.
A subsequent change will add conditions to contentHashSection.
Ian Lance Taylor [Mon, 27 Sep 2021 21:27:59 +0000 (14:27 -0700)]
io: avoid integer overflow in NewSectionReader
Fixes #48620
Change-Id: I37a5909ad27dc4a170929cb2e2ed1045cf524d59
Reviewed-on: https://go-review.googlesource.com/c/go/+/352629
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
As discussed in #47658, Value already has CanAddr and CanInterface to
test if a call to Addr or Inteface, respectively, does not result in a
panic.
Therefore we add CanInt, CanUint, CanFloat and CanComplex to ease the
test for a possible panic in calling, respectively, Int, Uint, Float and
Complex.
Fixes #47658
Change-Id: I58b77d77e6eec9f34234e985f631eab72b5b935e
Reviewed-on: https://go-review.googlesource.com/c/go/+/352131
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
A subsequent change will alter the semantics of _func.entry.
To make that change obvious and clear, change _func.entry to a method,
and rename the field to _func.entryPC.
runtime: change funcinl sentinel value from 0 to ^0
_func and funcinl are type-punned.
We distinguish them at runtime by inspecting the first word.
Prior to this change, we used 0 as the sentinel value
that means that a Func is a funcinl.
That worked because _func's first word is the functions' entry PC,
and 0 is not a valid PC. I plan to make *_func's entry PC relative
to the containing module. As a result, 0 will be a valid value,
for the first function in the module.
Switch to ^0 as the new sentinel value, which is neither a valid
entry PC nor a valid PC offset.
runtime.Func.{Name,FileLine} need to be able to
go from a *_func to a funcInfo. The missing bit of
information is what module contains that *_func.
The existing implementation looked up the module
using the *_func's entry PC. A subsequent change will
store *_func's entry PC relative to the containing module.
Change the module lookup to instead for the module
whose pclntable contains the *_func,
cutting all dependencies on the contents of the *_func.
Keith Randall [Tue, 7 Sep 2021 16:44:29 +0000 (09:44 -0700)]
runtime: make slice growth formula a bit smoother
Instead of growing 2x for < 1024 elements and 1.25x for >= 1024 elements,
use a somewhat smoother formula for the growth factor. Start reducing
the growth factor after 256 elements, but slowly.
(Note that the real growth factor, both before and now, is somewhat
larger because we round up to the next size class.)
This CL also makes the growth monotonic (larger initial capacities
make larger final capacities, which was not true before). See discussion
at https://groups.google.com/g/golang-nuts/c/UaVlMQ8Nz3o
256 was chosen as the threshold to roughly match the total number of
reallocations when appending to eventually make a very large
slice. (We allocate smaller when appending to capacities [256,1024]
and larger with capacities [1024,...]).
Change-Id: I876df09fdc9ae911bb94e41cb62675229cb10512
Reviewed-on: https://go-review.googlesource.com/c/go/+/347917
Trust: Keith Randall <khr@golang.org>
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Martin Möhrmann <martin@golang.org>
Keith Randall [Fri, 10 Sep 2021 22:24:16 +0000 (15:24 -0700)]
cmd/compile: keep methods on generic types from being deadcode eliminated
We currently make dictionaries contain a relocation pointing to
methods that generic code might use, so that those methods are not
deadcode eliminated. However, with inlining we can end up not using
the dictionary, making the reference from the dictionary to the method
no longer keep the method alive.
Fix this by keeping the dictionary alive at generic interface call sites.
It's a bit of overkill, as we only need to keep the dictionary statically
alive. We don't actually need it dynamically alive, which is what KeepAlive
does. But it works. It ends up generating a LEAQ + stack spill that aren't
necessary, but that's pretty low overhead.
To make this work, I needed to stop generating methods on shape types.
We should do this anyway, as we shouldn't ever need them. But currently
we do use them! issue44688.go has a test that only works because it calls
a method on a shape type. I've disabled that test for now, will work on it
in a subsequent CL.
Fixes #48047
Change-Id: I78968868d6486c1745f51b8b43be0898931432a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/349169
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Dan Scales [Thu, 23 Sep 2021 03:20:09 +0000 (20:20 -0700)]
cmd/compile: allow methods on shape types (but no bodies)
In a previous change, I was too aggressive in substInstType() in not
generating methods for shape types during import. We do actually want to
generate the method nodes - we just don't want to generate method bodies
(which we would never use). We may need the method nodes for checking
types later in the compile (especially with inlining).
So, we do generate method nodes for shape types during import. In
order to avoid the name collision we previously had, we now add
".nofunc." to the method nodes for shape types (during import and in the
type substituter). We do that by passing in a 'isMethodNode' arg to
MakeInstSym. We keep the normal name (without ".nofunc") for any other
method nodes, and for the instantiated functions that help with
implementing the methods of fully-instantiated types. The ".nofunc"
names will never appear in the executable, since we don't generate any
method bodies for the method nodes of shape types.
Change-Id: I3e57e328691214140ca5f48d32011552d2a0d45d
Reviewed-on: https://go-review.googlesource.com/c/go/+/352470
Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Keith Randall [Fri, 24 Sep 2021 22:07:59 +0000 (15:07 -0700)]
cmd/compile: leave dictionary argument out of traceback argument list
The dictionary argument is implicit; the user doesn't need to see it.
Update #48578
Change-Id: I367ba4b6622119d3e01aaded90463d16823915a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/352119
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Keith Randall [Fri, 24 Sep 2021 21:55:06 +0000 (14:55 -0700)]
runtime: elide instantiated types in tracebacks
They tend to be things like ".shape.int" which are noisy, if not
otherwise confusing.
It would be nice to somehow print the real instantiations here, but that
requires keeping track of the dictionary argument so the instantiating
types could be found. One day, maybe, but not today.
Fixes #48578
Change-Id: I0968d24e110b6d47c9468c45372a6979575a8d29
Reviewed-on: https://go-review.googlesource.com/c/go/+/352118
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Rhys Hiltner [Fri, 13 Aug 2021 16:01:13 +0000 (09:01 -0700)]
runtime: use per-thread profiler for SetCgoTraceback platforms
Updates #35057
Change-Id: I61d772a2cbfb27540fb70c14676c68593076ca94
Reviewed-on: https://go-review.googlesource.com/c/go/+/342054
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Rhys Hiltner [Thu, 23 Sep 2021 23:46:58 +0000 (16:46 -0700)]
runtime: move sigprofNonGo
The sigprofNonGo and sigprofNonGoPC functions are only used on unix-like
platforms. In preparation for unix-specific changes to sigprofNonGo,
move it (plus its close relative) to a unix-specific file.
Updates #35057
Change-Id: I9c814127c58612ea9a9fbd28a992b04ace5c604d
Reviewed-on: https://go-review.googlesource.com/c/go/+/351790
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: David Chase <drchase@google.com>
Rhys Hiltner [Fri, 13 Aug 2021 15:58:40 +0000 (08:58 -0700)]
runtime: profile with per-thread timers on Linux
Using setitimer on Linux to request SIGPROF signal deliveries in
proportion to the process's on-CPU time results in under-reporting when
the program uses several goroutines in parallel. Linux calculates the
process's total CPU spend on a regular basis (often every 4ms); if the
process has spent enough CPU time since the last calculation to warrant
more than one SIGPROF (usually 10ms for the default sample rate of 100
Hz), the kernel is often able to deliver only one of them. With these
common settings, that results in Go CPU profiles being attenuated for
programs that use more than 2.5 goroutines in parallel.
To avoid in effect overflowing the kernel's process-wide CPU counter,
and relying on Linux's typical behavior of having the active thread
handle the resulting process-targeted signal, use timer_create to
request a timer for each OS thread that the Go runtime manages. Have
each timer track the CPU time of a single thread, with the resulting
SIGPROF going directly to that thread.
To continue tracking CPU time spent on threads that don't interact with
the Go runtime (such as those created and used in cgo), keep using
setitimer in addition to the new mechanism. When a SIGPROF signal
arrives, check whether it's due to setitimer or timer_create and filter
as appropriate: If the thread is known to Go (has an M) and has a
timer_create timer, ignore SIGPROF signals from setitimer. If the thread
is not known to Go (does not have an M), ignore SIGPROF signals that are
not from setitimer.
Counteract the new bias that per-thread profiling adds against
short-lived threads (or those that are only active on occasion for a
short time, such as garbage collection workers on mostly-idle systems)
by configuring the timers' initial trigger to be from a uniform random
distribution between "immediate trigger" and the full requested sample
period.
Updates #35057
Change-Id: Iab753c4e5101bdc09ef9132eec84a75478e05579
Reviewed-on: https://go-review.googlesource.com/c/go/+/324129
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Rhys Hiltner [Fri, 13 Aug 2021 15:51:46 +0000 (08:51 -0700)]
runtime: allow per-OS changes to unix profiler
Updates #35057
Change-Id: I56ea8f4750022847f0866c85e237a2cea40e0ff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/342053
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Rhys Hiltner [Fri, 13 Aug 2021 15:34:25 +0000 (08:34 -0700)]
runtime: add timer_create syscalls for Linux
Updates #35057
Change-Id: Id702b502fa4e4005ba1e450a945bc4420a8a8b8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/342052
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Than McIntosh <thanm@google.com>
cmd/compile: clean up remnants of amd64p32 in OnesCount
Change-Id: Ie90d8dd3f644a96cda706c6a5286e99042e070bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/352129 Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
jiahua wang [Wed, 22 Sep 2021 14:32:55 +0000 (22:32 +0800)]
encoding/base32: Add examples for Encode/Decode
Updates golang/go#37595
Change-Id: I7568e7416d5504e9dc67061c79f66e3a0d597dee
Reviewed-on: https://go-review.googlesource.com/c/go/+/351470
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: David Chase <drchase@google.com>
Change-Id: I9921ba5c29ada6ff06d147f6d9b46a29101c449c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350694 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: David Chase <drchase@google.com>
jiahua wang [Fri, 24 Sep 2021 02:07:44 +0000 (10:07 +0800)]
bytes: add example for (*Buffer).Next
Change-Id: Ic0a97fd7bb89865448e436e5c092415a29d8badf
Reviewed-on: https://go-review.googlesource.com/c/go/+/352009
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: David Chase <drchase@google.com>
Nigel Tao [Fri, 24 Sep 2021 00:43:55 +0000 (10:43 +1000)]
image/draw: add RGBA64Image fast path for RGBA dst
This should have been part of https://golang.org/cl/340049 but I
overlooked it. That commit added fast path code when the destination
image was *not* an *image.RGBA. This commit edits func drawRGBA.
name old time/op new time/op delta
RGBA1-4 5.11ms ± 1% 1.12ms ± 1% -78.01% (p=0.008 n=5+5)
RGBA2-4 8.69ms ± 1% 2.98ms ± 1% -65.77% (p=0.008 n=5+5)
Updates #44808.
Updates #46395.
Change-Id: I899d46d985634fc81ea47ff4f0d436630e8a961c
Reviewed-on: https://go-review.googlesource.com/c/go/+/351852
Trust: Nigel Tao <nigeltao@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
In CL 349613,we have supported types.IdentityStrict() that does strict
type comparison.
Therefore, OCONVNOP becomes a possible case in call.X.Op().
Fixes #48604
Change-Id: Ibab27ffcf09656e3380314662f05f38294c1c6ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/351857
Trust: Dan Scales <danscales@google.com>
Trust: David Chase <drchase@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Dan Scales [Fri, 24 Sep 2021 15:57:06 +0000 (08:57 -0700)]
cmd/compile: deal with blank nodes with typeparam type during stenciling
Deal correctly with a blank local variable with type param type. This is
a special case, because a blank local variable is not in the fn.Dcl
list. In this case, we must explicitly create a new blank node with the
correct substituted type, so we have correct types if the blank local
variable has an initializing assignment.
Fixes #48602
Change-Id: I903ea44b29934e180404e32800773b7309bf297b
Reviewed-on: https://go-review.googlesource.com/c/go/+/352117
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Daniel Martí [Sat, 16 Jan 2021 18:03:31 +0000 (18:03 +0000)]
cmd/gofmt: format files in parallel
gofmt is pretty heavily CPU-bound, since parsing and formatting 1MiB
of Go code takes much longer than reading that amount of bytes from
disk. However, parsing and manipulating a large Go source file is very
difficult to parallelize, so we continue to process each file in its
own goroutine.
A Go module may contain a large number of Go source files, so we need
to bound the amount of work in flight. However, because the
distribution of sizes for Go source files varies widely — from tiny
doc.go files containing a single package comment all the way up to
massive API wrappers generated by automated tools — the amount of
time, work, and memory overhead needed to process each file also
varies. To account for this variability, we limit the in-flight work
by bytes of input rather than by number of files. That allows us to
make progress on many small files while we wait for work on a handful
of large files to complete.
The gofmt tool has a well-defined output format on stdout, which was
previously deterministic. We keep it deterministic by printing the
results of each file in order, using a lazily-synchronized io.Writer
(loosly inspired by Haskell's IO monad). After a file has been
formatted in memory, we keep it in memory (again, limited by the
corresponding number of input bytes) until the output for all previous
files has been flushed. This adds a bit of latency compared to
emitting the output in nondeterministic order, but a little extra
latency seems worth the cost to preserve output stability.
This change is based on Daniel Martí's work in CL 284139, but using a
weighted semaphore and ephemeral goroutines instead of a worker pool
and batches. Benchmark results are similar, and I find the concurrency
in this approach a bit easier to reason about.
In the batching-based approach, the batch size allows us to "look
ahead" to find large files and start processing them early. To keep
the CPUs saturated and prevent stragglers, we would need to tune the
batch size to be about the same as the largest input files. If the
batch size is set too high, a large batch of small files could turn
into a straggler, but if the batch size is set too low, the largest
files in the data set won't be started early enough and we'll end up
with a large-file straggler.
One possible alternative would be to sort by file size instead of
batching: identify all of the files to be processed, sort from largest
to smallest, and then process the largest files first so that the
"tail" of processing covers the smallest files. However, that approach
would still fail to saturate available CPU when disk latency is high,
would require buffering an arbitrary amount of metadata in order to
sort by size, and (perhaps most importantly!) would not allow the
`gofmt` binary to preserve the same (deterministic) output order that
it has today.
In contrast, with a semaphore we can produce the same deterministic
output as ever using only one tuning parameter: the memory footprint,
expressed as a rough lower bound on the amount of RAM available per
thread. While we're below the memory limit, we can run arbitrarily
many disk operations arbitrarily far ahead, and process the results of
those operations whenever they become avaliable. Then it's up to the
kernel (not us) to schedule the disk operations for throughput and
latency, and it's up to the runtime (not us) to schedule the
goroutines so that they complete quickly.
In practice, even a modest assumption of a few megabytes per thread
seems to provide a nice speedup, and it should scale reasonably even
to machines with vastly different ratios of CPU to disk. (In practice,
I expect that most 'gofmt' invocations will work with files on at most
one physical disk, so the CPU:disk ratio should vary more-or-less
directly with the thread count, whereas the CPU:memory ratio is
more-or-less independent of thread count.)
Jay Conrod [Fri, 24 Sep 2021 17:46:09 +0000 (10:46 -0700)]
cmd/go: make 'go mod why -m' work in inconsistent, pruned module
'go mod why -m' works by listing modules matching command line
arguments, then loading "all" packages and finding which of the listed
modules provide packages imported by the main module.
If go.mod is inconsistent (that is, a requirement has a lower version
than MVS would select when the module graph is loaded) and pruned
(that is, the module graph is only loaded when necessary), then
modload.ListModules may return modules with different versions than
would be selected in modload.LoadPackages.
'go mod why -m' was too strict about this, mapping module paths and
versions to packages. With this fix, it maps module paths without
versions to packages.
Fixes #48613
Change-Id: I836c46289bb647d6c46ec65e7589531da532d5e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/352115
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
The delayTransform only checks whether ir.CurFunc is generic function or
not. but when compiling a non-generic closure inside a generic function,
we also want to delay the transformation, which delayTransform fails to
detect, since when ir.CurFunc is the closure, not the top level function.
Instead, we must rely on irgen.topFuncIsGeneric field to decide whether
to delay the transformation, the same logic with what is being done for
not adding closure inside a generic function to g.target.Decls list.
Fixes #48609
Change-Id: I5bf5592027d112fe8b19c92eb906add424c46507
Reviewed-on: https://go-review.googlesource.com/c/go/+/351855
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Dan Scales [Sun, 19 Sep 2021 03:02:08 +0000 (20:02 -0700)]
cmd/compile: fix crawler for unexported fields with instantiated types
In markType() in crawler.go, mark the type of a unexported field if it
is a fully-instantiated type, since we create and instantiate the
methods of any fully-instantiated type that we see during import. As
before, we still do not mark the type of an unexported field if that
type is not generic. Fixes #48454 and most recent issue described in
48337. The included test is similar to the case in 48454.
Fixes #48454
Fixes #48337
Change-Id: I77a2a62b9e2647876facfa6f004201e8f699c905
Reviewed-on: https://go-review.googlesource.com/c/go/+/351315
Trust: Dan Scales <danscales@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org>
Dan Scales [Fri, 24 Sep 2021 16:13:32 +0000 (09:13 -0700)]
cmd/compile: fix case in dictPass where OMETHVALUE should become ODOTMETH
When I separate out the dictionary transformations to dictPass, I missed
duplicating a conditional that deals with OMETHVALUE nodes that are
actually called. We create the OMETHVALUE when transforming bounds
function reference (before we know whether that reference will be
called), and we need to call transformDot() again to convert the
OMETHVALUE to ODOTMETH if the reference is actually called (the usual
case). Without this change, we leave the OMETHVALUE in, and extra *-fm
are created and used unncessarily.
Also, fixed a few places where we were missing ir.MarkFunc(), which sets
the class of a function node properly.
Change-Id: I6b02613039b16b507b44525faa2cd7031afb6982
Reviewed-on: https://go-review.googlesource.com/c/go/+/352069
Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Jay Conrod [Mon, 13 Sep 2021 23:48:53 +0000 (16:48 -0700)]
cmd/go: refactor {Allow,Disallow}WriteGoMod to ExplicitWriteGoMod
Subcommands may now set the global flag modload.ExplicitWriteGoMod
instead of calling {Allow,Disallow}WriteGoMod.
When ExplicitWriteGoMod is false (default), modload.LoadPackages and
ListModules will either update go.mod and go.sum or report an error if
they need to be updated, depending on cfg.BuildMod.
When ExplicitWriteGoMod is true, commands must explicitly call
modload.WriteGoMod to update go.mod and go.sum or report an
error. Commands that perform some operation after loading the build
list (like downloading zips or building packages) and commands that
load packages multiple times should set this. For now, only 'go get'
and 'go mod download' set this.
This CL is a pure refactor: no change in behavior is expected.
There are some other minor changes in here, too: commitRequirements no
longer sets the global requirements: that should be done separately first.
Change-Id: I69942a808bb177faf7904a53aaf2d4ac68500e82
Reviewed-on: https://go-review.googlesource.com/c/go/+/349600
Trust: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Jay Conrod [Wed, 22 Sep 2021 23:16:16 +0000 (16:16 -0700)]
cmd/go: test that graph, verify, and why don't write go.mod or go.sum
They should also not report an error if these files need to be
updated. These commands are used for debugging, so it's important that
they still work when go.mod and go.sum are incomplete.
For #40775
Change-Id: I1b731599e5a4510f47827b9812525636a7402bf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/351468
Trust: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Cherry Mui [Wed, 22 Sep 2021 22:32:45 +0000 (18:32 -0400)]
runtime: set vdsoSP to caller's SP consistently
m.vdsoSP should be set to the SP of the caller of nanotime1,
instead of the SP of nanotime1 itself, which matches m.vdsoPC.
Otherwise the unmatched vdsoPC and vdsoSP would make the stack
trace look like recursive.
We already do it correctly on AMD64, 386, and RISCV64. This CL
fixes the rest.
Joel Sing [Fri, 17 Sep 2021 06:53:11 +0000 (16:53 +1000)]
cmd/compile: optimise immediate operands with constants on riscv64
Instructions with immediates can be precomputed when operating on a
constant - do so for SLTI/SLTIU, SLLI/SRLI/SRAI, NEG/NEGW, ANDI, ORI
and ADDI. Additionally, optimise ANDI and ORI when the immediate is
all ones or all zeroes.
In particular, the RISCV64 logical left and right shift rules
(Lsh*x*/Rsh*Ux*) produce sequences that check if the shift amount
exceeds 64 and if so returns zero. When the shift amount is a
constant we can precompute and eliminate the filter entirely.
Likewise the arithmetic right shift rules produce sequences that
check if the shift amount exceeds 64 and if so, ensures that the
lower six bits of the shift are all ones. When the shift amount
is a constant we can precompute the shift value.
This removes more than 30,000 instructions from the Go binary and
should improve performance in a variety of areas - of note
runtime.makemap_small drops from 48 to 36 instructions. Similar
gains exist in at least other parts of runtime and math/bits.
Change-Id: I33f6f3d1fd36d9ff1bda706997162bfe4bb859b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/350689
Trust: Joel Sing <joel@sing.id.au> Reviewed-by: Michael Munday <mike.munday@lowrisc.org> Reviewed-by: Cherry Mui <cherryyz@google.com>