For #47694.
Change-Id: Ia80a1859bd0fc6f08d27293f519c22fd9a804fd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/361894
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
These are tested in golang.org/cl/357169 and golang.org/cl/358540.
Change-Id: I5add3f202db71731487f2688234c547abe1fd287
Reviewed-on: https://go-review.googlesource.com/c/go/+/361416
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change allows the check to pass unmodified under GopherJS, which
stack traces are formatted differently (due to being generated by
NodeJS). There are no other functions named `interestingGoroutines` in
the standard library, so it's very unlikely to create false negatives,
and will allow reduce the number of overlays GopherJS needs to maintain.
Change-Id: I925594c6c313ca35805811f240c8528241950547
GitHub-Last-Rev: 26b32efb22
GitHub-Pull-Request: golang/go#49128
Reviewed-on: https://go-review.googlesource.com/c/go/+/358154
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Damien Neil <dneil@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Also, correct TestAppendRune error message.
Change-Id: I3ca3ac7051af1ae6d449381b78efa86c2f6be8ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/354529
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: Id2336a6059f7a8d627e6c0661a4d4c05485b65f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/355589
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Trust: Robert Findley <rfindley@google.com>
The old implement passed start - 1 or end in func lookup to adjust the offset.But if the time is close to the last zoneTrans, like the issue, testcase and comment, the "start" from lookup will be omega. It can't be adjusted correctly.
Fixes#49284
Change-Id: Ibaf82dc4db6d5dd3279796f003d2b19c38a26341
Reviewed-on: https://go-review.googlesource.com/c/go/+/360616
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Findley <rfindley@google.com>
Change-Id: I2668cdea64f75bee87d424730d404834d69362a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/357270
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Title doesn't handle Unicode punctuation and language-specific
capitalization rules. Replace the BUG comment with a Deprecated
one, suggesting a more robust alternative, and allowing Title
to be exposed to tooling.
Fixes#48367.
Change-Id: I952f1f37cd35b587a95893fb022827bdd9ec7de9
Reviewed-on: https://go-review.googlesource.com/c/go/+/359485
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
This allows callers of *File.Symbols to distinguish absence of symbols
from other errors as can already by done in debug/elf.
Fixes#48052
Change-Id: I5ba15d8473911e516c016a69c1f1c710f7fc4cd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/350229
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: Ieb107fdfccde9f054491f667a384b16f7af71dea
Reviewed-on: https://go-review.googlesource.com/c/go/+/355289
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Fixes#48948
Change-Id: I411e3be99c7979ae289fd937388aae63d81adb59
GitHub-Last-Rev: 14abd7e4d7
GitHub-Pull-Request: golang/go#48993
Reviewed-on: https://go-review.googlesource.com/c/go/+/356009
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Damien Neil <dneil@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Fixes#49315
Change-Id: I0887bad1059b25ae0749bfa1ed6ddccbecca7951
Reviewed-on: https://go-review.googlesource.com/c/go/+/361074
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Change-Id: I5ebfc6a89323cc086ea0e0b619370dc45da1f3a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/345437
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Damien Neil <dneil@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently, newstack loads gp.stackguard0 twice to check for different
poison values. The race window between these two checks can lead to
unintentional stack doubling, and ultimately to stack overflows.
Specifically, newstack checks if stackguard0 is stackPreempt first,
then it checks if it's stackForceMove. If stackguard0 is set to
stackForceMove on entry, but changes to stackPreempt between the two
checks, newstack will incorrectly double the stack allocation.
Fix this by loading stackguard0 exactly once and then checking it
against different poison values.
The effect of this is relatively minor because stackForceMove is only
used by a small number of runtime tests. I found this because
mayMorestackMove uses stackForceMove aggressively, which makes this
failure mode much more likely.
Change-Id: I1f8b6a6744e45533580a3f45d7030ec2ec65a5fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/361775
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
For #30432
Change-Id: I84f208705483018559b425b3669e724e7d5627ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/361814
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This does not change any code, just reformats the comments in
the asm code.
Change-Id: I70fbfa77db164898d25b59b589d3e85b8399b0fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/361694
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
The amd64/arm64 relocation processing is used as a template
and updated for ppc64le.
This requires updating the TOC relocation handling code to
support linux type TOC relocations too (note, AIX uses
TOC-indirect accesses).
Noteably, the shared flag of go functions is used as a proxy
for the local entry point offset encoded in elf objects. Functions
in go ppc64le shared objects always[1] insert 2 instructions to
regenerate the TOC pointer.
[1] excepting a couple special runtime functions, see preprocess
in obj9.go for specific details of this behavior.
Change-Id: I3646e6dc8a0a0ffe712771a976983315eae5c418
Reviewed-on: https://go-review.googlesource.com/c/go/+/352829
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
This test appears to deadlock frequently on the only netbsd-arm64
builder we have (netbsd-arm64-bsiegert). Skip the test to provide
more useful test coverage for other failures.
For #49382
Change-Id: I3be32f58ce1e396f7c69163e70cf58f779f57ac6
Reviewed-on: https://go-review.googlesource.com/c/go/+/361615
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
consistentHeapStats is updated during a stack allocation, so a stack
growth during an acquire or release could cause another acquire to
happen before the operation completes fully. This may lead to an invalid
sequence number.
Fixes#49395.
Change-Id: I41ce3393dff80201793e053d4d6394d7b211a5b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/361158
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Currently the scavenger is paced to 1% of 1 CPU because it had
scalability problems. As of the last few CLs, that should be largely
resolved. This change resolves the TODO and paces the scavenger
according to 1% of overall CPU time.
This change is made separately to allow it to be more easily rolled
back.
Change-Id: I1ab4de24ba41c564960701634a128a813c55ece9
Reviewed-on: https://go-review.googlesource.com/c/go/+/358675
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently the scavenge rate is determined by a bunch of ad-hoc
mechanisms. Just use a controller instead, now that we have one.
To facilitate this, the scavenger now attempts to scavenge for at least
1 ms at a time, because any less and the timer system is too imprecise to
give useful feedback to the controller. Also increase the amount that we
scavenge at once, to try to reduce the overheads involved (at the
expense of a little bit of latency).
This change also modifies the controller to accept an update period,
because it's useful to allow that to be variable.
Change-Id: I8a15b2355d0a7c6cbac68c957082d5819618f7d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/353975
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change adds a new debug flag that makes the runtime map pages
PROT_NONE in sysUnused on Linux, in addition to the usual madvise calls.
This behavior mimics the behavior of decommit on Windows, and is helpful
in debugging the scavenger. sysUsed is also updated to re-map the pages
as PROT_READ|PROT_WRITE, mimicing Windows' explicit commit behavior.
Change-Id: Iaac5fcd0e6920bd1d0e753dd4e7f0c0b128fe842
Reviewed-on: https://go-review.googlesource.com/c/go/+/356612
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change modifies the scavenger to no longer hold the heap lock while
actively scavenging pages. To achieve this, the change also:
* Reverses the locking behavior of the (*pageAlloc).scavenge API, to
only acquire the heap lock when necessary.
* Introduces a new lock on the scavenger-related fields in a pageAlloc
so that access to those fields doesn't require the heap lock. There
are a few places in the scavenge path, notably reservation, that
requires synchronization. The heap lock is far too heavy handed for
this case.
* Changes the scavenger to marks pages that are actively being scavenged
as allocated, and "frees" them back to the page allocator the usual
way.
* Lifts the heap-growth scavenging code out of mheap.grow, where the
heap lock is held, and into allocSpan, just after the lock is
released. Releasing the lock during mheap.grow is not feasible if we
want to ensure that allocation always makes progress (post-growth,
another allocator could come in and take all that space, forcing the
goroutine that just grew the heap to do so again).
This change means that the scavenger now must do more work for each
scavenge, but it is also now much more scalable. Although in theory it's
not great by always taking the locked paths in the page allocator, it
takes advantage of some properties of the allocator:
* Most of the time, the scavenger will be working with one page at a
time. The page allocator's locked path is optimized for this case.
* On the allocation path, it doesn't need to do the find operation at
all; it can go straight to setting bits for the range and updating the
summary structure.
Change-Id: Ie941d5e7c05dcc96476795c63fef74bcafc2a0f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/353974
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
CL 287654 converted the syscall package on openbsd/386 to use libc.
However, the mksyscall.pl invocation wasn't adjusted. Do so now to use
syscall_openbsd_libc.go like the other libc-based openbsd ports.
Change-Id: I48a7bd6ce4c25eca5222f560ed584e412b466111
Reviewed-on: https://go-review.googlesource.com/c/go/+/361481
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The first stack-trace in #49361 shows that traceBuf must precede fin in
lockrank ordering, since traceBuf is acquired in StartTrace(), which
eventually leads to getting fin in queueFinalizer(). It is fine to move
traceBuf above fin, since there are no other conflicting dependencies.
The second stack trace shows that there is an edge bewtween reflectOffs
and fin, since reflectOffs is acquired in addReflectOff, and map
operations can lead to an allocation that eventually causes fin to be
acquired in queueFinalizer().
Fixes#49361
Change-Id: I8e857ef9ecdff37fdd229e4dba22e15bc71d4ba5
Reviewed-on: https://go-review.googlesource.com/c/go/+/361407
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The argument liveness tests expect outputs where a dead stack slot
has a poisoned value. If the test function is preempted at the
prologue, it will go with the morestack code path which will spill
all the argument registers. Mark them nosplit to avoid that.
Should fix#49354.
Change-Id: I3b13e72e925748687a53c494bfaa70f07d9496fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/361211
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
CL 360057 fixed missing update source type in storeArgOrLoad. However,
we should only update the type when processing struct/array. If we
update the type right before calling storeArgOrLoad, we may generate a
value with invalid type, e.g, OpStructSelect with non-struct type.
Fixes#49378
Change-Id: Ib7e10f72f818880f550aae5c9f653db463ce29b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361594
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently, we rely on a "crawling" step during export to identify
function and method bodies that need to be exported or re-exported so
we can trim out unnecessary ones and reduce build artifact sizes. To
catch cases where we expect a function to be inlinable but we failed
to export its body, we made this condition a fatal compiler error.
However, with generics, it's much harder to perfectly identify all
function bodies that need to be exported; and several attempts at
tweaking the algorithm have resulted in still having failure cases.
So for now, this CL changes a missing inline body into a graceful
failure instead.
Change-Id: I04b0872d0dcaae9c3de473e92ce584e4ec6fd782
Reviewed-on: https://go-review.googlesource.com/c/go/+/361403
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
The current code, introduced in CL 2422, mixes K bits of entropy with
the private key and message digest to generate the signature nonce,
where K is half the bit size of the curve. While the ECDLP complexity
(and hence security level) of a curve is half its bit size, the birthday
bound on K bits is only K/2. For P-224, this means we should expect a
collision after 2^56 signatures over the same message with the same key.
A collision, which is unlikely, would still not be a major practical
concern, because the scheme would fall back to a secure deterministic
signature scheme, and simply leak the fact that the two signed messages
are the same (which is presumably already public).
Still, we can simplify the code and remove the eventuality by always
drawing 256 bits of entropy.
Change-Id: I58097bd3cfc9283503e38751c924c53d271af92b
Reviewed-on: https://go-review.googlesource.com/c/go/+/352530
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This adds a maymorestack hook that moves the stack at every
cooperative preemption point.
For #48297.
Change-Id: Ic15f9bcbc163345e6422586302d57fda4744caec
Reviewed-on: https://go-review.googlesource.com/c/go/+/359797
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
This adds a maymorestack hook that forces a preemption at every
possible cooperative preemption point. This would have helped us catch
several recent preemption-related bugs earlier, including #47302,
#47304, and #47441.
For #48297.
Change-Id: Ib82c973589c8a7223900e1842913b8591938fb9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/359796
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
This adds a debugging hook for optionally calling a "maymorestack"
function in the prologue of any function that might call morestack
(whether it does at run time or not). The maymorestack function will
let us improve lock checking and add debugging modes that stress
function preemption and stack growth.
Passes toolstash-check -all (except on js/wasm, where toolstash
appears to be broken)
Fixes#48297.
Change-Id: I27197947482b329af75dafb9971fc0d3a52eaf31
Reviewed-on: https://go-review.googlesource.com/c/go/+/359795
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This moves and slightly generalizes the -d debug flag parser from
cmd/compile/internal/base to cmd/internal/objabi so that we can use
the same debug flag syntax in other tools.
This makes a few minor tweaks to implementation details. The flag
itself is now just a flag.Value that gets constructed explicitly,
rather than at init time, and we've cleaned up the implementation a
little (e.g., using a map instead of a linear search of a slice). The
help text is now automatically alphabetized. Rather than describing
the values of some flags in the help text footer, we simply include it
in the flags' help text and make sure multi-line help text renders
sensibly.
For #48297.
Change-Id: Id373ee3b767e456be483fb28c110d025149be532
Reviewed-on: https://go-review.googlesource.com/c/go/+/359956
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A code comment on amd64 for windows and plan9 contained a snippet for
splitting apart the sec and nsec components of a unix timestamp, with
produced assembly below, which was then cleaned up by hand. When arm64
was ported, that code snippet in the comment went through the compiler
to produce some code that was then pasted and cleaned up. Unfortunately,
the comment had a typo in it, containing 8 zeros instead of 9.
This resulted in the constant used in the assembly being wrong, spotted
by @bufflig's eagle eyes. So, this commit fixes the comment on all three
platforms, and the assembly on windows/arm64.
Fixes#48072.
Change-Id: I786fe89147328b0d25544f52c927ddfdb9f6f1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/361474
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
TestHammerStoreLoad involves a stress test of StorePointer, which has a
write barrier. The "pointer" that is being written is not a real value,
which is generally fine (though not *really* safe) on 64-bit systems
because they never point to an actual object.
On 32-bit systems, however, this is much more likely. Because I can't
figure out how to rewrite the test such that it still is testing the
same conditions but is also using real pointers, just disable the GC
during the test, and make sure there isn't one currently in progress.
Fixes#49362.
Change-Id: If81883fedf06568132e6484f40c820aa69027a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/361455
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
We were re-allocating a new RawSockaddrAny on every UDP read/write.
We can re-use them instead.
This reduces the number of allocs for UDP read/write on windows to zero.
Co-authored-by: David Crawshaw <crawshaw@golang.org>
Change-Id: I2f05c974e2e7b4f67937ae4e1c99583e81d140af
Reviewed-on: https://go-review.googlesource.com/c/go/+/361404
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
...instead of the structs themselves.
Escape analysis can handle this,
and it'll avoid a bunch of large struct copies.
Change-Id: Ia9c6064ed32a4c26d5a96dae2ed7d7ece6d38704
Reviewed-on: https://go-review.googlesource.com/c/go/+/361264
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The new GC pacer has a bug where the hard goal isn't set in relation to
the original heap goal, but rather to the one already extrapolated for
overshoot.
In practice, I have never once seen this case arise because the
extrapolated goal used for overshoot is conservative. No test because
writing a test for this case is impossible in the idealized model the
pacer tests create. It is possible to simulate but will take more work.
For now, just leave a TODO.
Change-Id: I24ff710016cd8100fad54f71b2c8cdea0f7dfa79
Reviewed-on: https://go-review.googlesource.com/c/go/+/361435
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
