Russ Cox [Mon, 16 Mar 2015 20:46:25 +0000 (16:46 -0400)]
cmd/internal/gc: cache ProgInfo in Prog
The ProgInfo is loaded many times during each analysis pass.
Load it once at the beginning (in Flowstart if using that, or explicitly,
as in plive.go) and then refer to the cached copy.
Removes many calls to proginfo.
Makes Prog a little bigger, but the previous CL more than compensates.
Russ Cox [Mon, 16 Mar 2015 19:54:44 +0000 (15:54 -0400)]
cmd/internal/obj: replace Addr.U struct {...} with Val interface{}
An interface{} is more in the spirit of the original union.
By my calculations, on 64-bit systems this reduces
Addr from 120 to 80 bytes, and Prog from 592 to 424 bytes.
Change-Id: I0d7b0981513c2a3c94c9ac76bb4f8816485b5a3c
Reviewed-on: https://go-review.googlesource.com/7744 Reviewed-by: Rob Pike <r@golang.org>
Russ Cox [Thu, 19 Mar 2015 23:42:16 +0000 (19:42 -0400)]
runtime: implement atomicand8 atomically
We're skating on thin ice, and things are finally starting to melt around here.
(I want to avoid the debugging session that will happen when someone
uses atomicand8 expecting it to be atomic with respect to other operations.)
Change-Id: I254f1582be4eb1f2d7fbba05335a91c6bf0c7f02
Reviewed-on: https://go-review.googlesource.com/7861 Reviewed-by: Minux Ma <minux@golang.org>
Russ Cox [Mon, 16 Mar 2015 19:31:32 +0000 (15:31 -0400)]
cmd/internal/obj: shuffle link.go to put declarations in original order
I think the file ended up in the order of the typedefs instead of the
order of the actual struct definitions. You can see where some of
the declarations were because some of the comments didn't move.
Put things back in the original order.
Russ Cox [Mon, 16 Mar 2015 19:18:49 +0000 (15:18 -0400)]
cmd/dist: add //line to copied bootstrap files
This way the error messages will show the original file name
in addition to the bootstrap file name, so that you have some
chance of making the correction in the original instead of the copy
(which will be blown away).
Before:
/Users/rsc/g/go/pkg/bootstrap/src/bootstrap/5g/gsubr.go:863: undefined: a
After:
/Users/rsc/g/go/src/cmd/5g/gsubr.go:860[/Users/rsc/g/go/pkg/bootstrap/src/bootstrap/5g/gsubr.go:863]: undefined: a
Change-Id: I8d6006abd9499edb16d9f27fe8b7dc6cae143fca
Reviewed-on: https://go-review.googlesource.com/7741 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Mon, 9 Mar 2015 00:56:15 +0000 (20:56 -0400)]
runtime: add GODEBUG=sbrk=1 to bypass memory allocator (and GC)
To reduce lock contention in this mode, makes persistent allocation state per-P,
which means at most 64 kB overhead x $GOMAXPROCS, which should be
completely tolerable.
Change-Id: I34ca95e77d7e67130e30822e5a4aff6772b1a1c5
Reviewed-on: https://go-review.googlesource.com/7740 Reviewed-by: Rick Hudson <rlh@golang.org>
David Crawshaw [Thu, 19 Mar 2015 17:15:56 +0000 (13:15 -0400)]
cmd/dist: update android testing TODO, add iOS
This CL updates a TODO on a condition excluding a lot of tests on
android, clarifying what needs to be done. Several of the tests should
be turned off, for example anything depending on the Go tool, others
should be enabled. (See #8345, comment 3 for more details.)
Also add iOS, which has the same set of restrictions.
Tested manually on linux/amd64, darwin/amd64, android/arm, darwin/arm.
Change-Id: Ifa71fb443a66eb8d7732f3b0c1408947b583c1f1
Reviewed-on: https://go-review.googlesource.com/7800 Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/internal/gc, runtime: speed up some cases of _, ok := i.(T)
Some type assertions of the form _, ok := i.(T) allow efficient inlining.
Such type assertions commonly show up in type switches.
For example, with this optimization, using 6g, the length of
encoding/binary's intDataSize function shrinks from 2224 to 1728 bytes (-22%).
Austin Clements [Thu, 12 Mar 2015 17:09:30 +0000 (13:09 -0400)]
runtime: combine gcWorkProducer into gcWork
The distinction between gcWorkProducer and gcWork (producer and
consumer) is not serving us as originally intended, so merge these
into just gcWork.
The original intent was to replace the currentwbuf cache with a
gcWorkProducer. However, with gchelpwork (aka mutator assists),
mutators can both produce and consume work, so it will make more sense
to cache a whole gcWork.
Change-Id: I6e633e96db7cb23a64fbadbfc4607e3ad32bcfb3
Reviewed-on: https://go-review.googlesource.com/7733 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Thu, 12 Mar 2015 17:03:50 +0000 (13:03 -0400)]
runtime: don't use cached wbuf in markroot
Currently markroot fetches the wbuf to fill from the per-M wbuf
cache. The wbuf cache is primarily meant for the write barrier because
it produces very little work on each call. There's little point to
using the cache in mark root, since each call to markroot is likely to
produce a large amount of work (so the slight win on getting it from
the cache instead of from the central wbuf lists doesn't matter), and
markroot does not dispose the wbuf back to the cache (so most markroot
calls won't get anything from the wbuf cache anyway).
Instead, just get the wbuf from the central wbuf lists like other work
producers. This will simplify later changes.
Change-Id: I07a18a4335a41e266a6d70aa3a0911a40babce23
Reviewed-on: https://go-review.googlesource.com/7732 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Wed, 18 Mar 2015 15:22:12 +0000 (11:22 -0400)]
runtime: run concurrent mark phase on regular stack
Currently, the GC's concurrent mark phase runs on the system
stack. There's no need to do this, and running it this way ties up the
entire M and P running the GC by preventing the scheduler from
preempting the GC even during concurrent mark.
Fix this by running concurrent mark on the regular G stack. It's still
non-preemptible because we also set preemptoff around the whole GC
process, but this moves us closer to making it preemptible.
Change-Id: Ia9f1245e299b8c5c513a4b1e3ef13eaa35ac5e73
Reviewed-on: https://go-review.googlesource.com/7730 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Tue, 17 Mar 2015 19:31:11 +0000 (15:31 -0400)]
runtime: improve comment in concurrent GC
"Sync" is not very informative. What's being synchronized and with
whom? Update this comment to explain what we're really doing: enabling
write barriers.
Change-Id: I4f0cbb8771988c7ba4606d566b77c26c64165f0f
Reviewed-on: https://go-review.googlesource.com/7700 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Tue, 17 Mar 2015 19:28:57 +0000 (15:28 -0400)]
runtime: remove pointless harvestwbufs
Currently we harvestwbufs the moment we enter the mark phase, even
before starting the world again. Since cached wbufs are only filled
when we're in mark or mark termination, they should all be empty at
this point, making the harvest pointless. Remove the harvest.
We should, but do not currently harvest at the end of the mark phase
when we're running out of work to do.
Change-Id: I5f4ba874f14dd915b8dfbc4ee5bb526eecc2c0b4
Reviewed-on: https://go-review.googlesource.com/7669 Reviewed-by: Rick Hudson <rlh@golang.org>
Change-Id: I5a49f56518adf7d64ba8610b51ea1621ad888fc4
Reviewed-on: https://go-review.googlesource.com/7771 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Switch statements do a binary search on long runs of constants.
Doing a less-than comparison on a string is much more expensive
than on (say) an int. Use two part comparison for strings:
First compare length, then the strings themselves.
Change-Id: I79b7ed8f7e78e9d35b5e30ef70b98db64bc68a7b
Reviewed-on: https://go-review.googlesource.com/7720 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Dmitry Vyukov [Fri, 13 Mar 2015 10:37:57 +0000 (13:37 +0300)]
runtime: add a select test
One of my earlier versions of finer-grained select locking
failed on this test. If you just naively lock and check channels
one-by-one, it is possible that you skip over ready channels.
Consider that initially c1 is ready and c2 is not. Select checks c2.
Then another goroutine makes c1 not ready and c2 ready (in that order).
Then select checks c1, concludes that no channels are ready and
executes the default case. But there was no point in time when
no channel is ready and so default case must not be executed.
Aaron Jacobs [Tue, 17 Mar 2015 21:14:07 +0000 (08:14 +1100)]
bufio: fix incorrect comment on Scanner.Scan
Change-Id: I216511a4bce431de0a468f618a7a7c4da79e2979
Reviewed-on: https://go-review.googlesource.com/7710 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Adam Langley [Mon, 16 Mar 2015 23:45:29 +0000 (16:45 -0700)]
crypto/tls: panic with unknown hash functions.
Just so that we notice in the future if another hash function is added
without updating this utility function, make it panic when passed an
unknown handshake hash function. (Which should never happen.)
Russ Cox [Tue, 17 Mar 2015 19:07:05 +0000 (15:07 -0400)]
runtime: fix writebarrier throw in lock_sema
The value in question is really a bit pattern
(a pointer with extra bits thrown in),
so treat it as a uintptr instead, avoiding the
generation of a write barrier when there
might not be a p.
Rick Hudson [Thu, 12 Mar 2015 18:19:21 +0000 (14:19 -0400)]
runtime: Remove write barriers during STW.
The GC assumes that there will be no asynchronous write barriers when
the world is stopped. This keeps the synchronization between write
barriers and the GC simple. However, currently, there are a few places
in runtime code where this assumption does not hold.
The GC stops the world by collecting all Ps, which stops all user Go
code, but small parts of the runtime can run without a P. For example,
the code that releases a P must still deschedule its G onto a runnable
queue before stopping. Similarly, when a G returns from a long-running
syscall, it must run code to reacquire a P.
Currently, this code can contain write barriers. This can lead to the
GC collecting reachable objects if something like the following
sequence of events happens:
1. GC stops the world by collecting all Ps.
2. G #1 returns from a syscall (for example), tries to install a
pointer to object X, and calls greyobject on X.
3. greyobject on G #1 marks X, but does not yet add it to a write
buffer. At this point, X is effectively black, not grey, even though
it may point to white objects.
4. GC reaches X through some other path and calls greyobject on X, but
greyobject does nothing because X is already marked.
5. GC completes.
6. greyobject on G #1 adds X to a work buffer, but it's too late.
7. Objects that were reachable only through X are incorrectly collected.
To fix this, we check the invariant that no asynchronous write
barriers happen when the world is stopped by checking that write
barriers always have a P, and modify all currently known sources of
these writes to disable the write barrier. In all modified cases this
is safe because the object in question will always be reachable via
some other path.
Some of the trace code was turned off, in particular the
code that traces returning from a syscall. The GC assumes
that as far as the heap is concerned the thread is stopped
when it is in a syscall. Upon returning the trace code
must not do any heap writes for the same reasons discussed
above.
The Go runtime does something surprisingly similar, building the
runtime's envs []string using gostringnocopy. Both libc and the Go
runtime reusing memory interacts badly. When syscall.Setenv uses cgo
to call setenv(3), C modifies the underlying memory of a Go string.
This manifests on android/arm. With GOROOT=/data/local/tmp, a
runtime test calls syscall.Setenv("/os"), resulting in
runtime.GOROOT()=="/os\x00a/local/tmp/goroot".
Avoid this by copying environment string memory into Go.
Covered by runtime.TestFixedGOROOT on android/arm.
Change-Id: Id0cf9553969f587addd462f2239dafca1cf371fa
Reviewed-on: https://go-review.googlesource.com/7663 Reviewed-by: Keith Randall <khr@golang.org>
Dmitry Vyukov [Fri, 13 Mar 2015 13:02:47 +0000 (16:02 +0300)]
runtime: fix comment
IRIW requires 4 threads: first writes x, second writes y,
third reads x and y, fourth reads y and x.
This is Peterson/Dekker mutual exclusion algorithm based on
critical store-load sequences:
http://en.wikipedia.org/wiki/Dekker's_algorithm
http://en.wikipedia.org/wiki/Peterson%27s_algorithm
Dmitry Vyukov [Wed, 11 Mar 2015 15:29:12 +0000 (18:29 +0300)]
runtime: remove futile wakeups from trace
Channels and sync.Mutex'es allow another goroutine to acquire resource
ahead of an unblocked goroutine. This is good for performance, but
leads to futile wakeups (the unblocked goroutine needs to block again).
Futile wakeups caused user confusion during the very first evaluation
of tracing functionality on a real server (a goroutine as if acquires a mutex
in a loop, while there is no loop in user code).
This change detects futile wakeups on channels and emits a special event
to denote the fact. Later parser finds entire wakeup sequences
(unblock->start->block) and removes them.
sync.Mutex will be supported in a separate change.
Change-Id: Iaaaee9d5c0921afc62b449a97447445030ac19d3
Reviewed-on: https://go-review.googlesource.com/7380 Reviewed-by: Keith Randall <khr@golang.org>
David Crawshaw [Sun, 8 Mar 2015 15:37:02 +0000 (11:37 -0400)]
runtime/cgo: catch EXC_BAD_ACCESS on darwin/arm
The Go builders (and standard development cycle) for programs on iOS
require running the programs under lldb. Unfortunately lldb intercepts
SIGSEGV and will not give it back.
https://llvm.org/bugs/show_bug.cgi?id=22868
We get around this by never letting lldb see the SIGSEGV. On darwin,
Unix signals are emulated on top of mach exceptions. The debugger
registers a task-level mach exception handler. We register a
thread-level exception handler which acts as a faux signal handler.
The thread-level handler gets precedence over the task-level handler,
so we can turn the exception EXC_BAD_ACCESS into a panic before lldb
can see it.
Fixes #10043
Change-Id: I64d7c310dfa7ecf60eb1e59f094966520d473335
Reviewed-on: https://go-review.googlesource.com/7072 Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Austin Clements [Thu, 12 Mar 2015 18:26:04 +0000 (14:26 -0400)]
runtime: factor object dumping code out of greyobject
When checkmark fails, greyobject dumps both the object that pointed to
the unmarked object and the unmarked object. This code cluttered up
greyobject, was copy-pasted for the two objects, and the copy for
dumping the unmarked object was not entirely correct.
Extract object dumping out to a new function. This declutters
greyobject and fixes the bugs in dumping the unmarked object. The new
function is slightly cleaned up from the original code to have more
natural control flow and shows a marker on the field in the base
object that points to the unmarked object to make it easy to find.
Change-Id: Ib51318a943f50b0b99995f0941d03ee8876b9fcf
Reviewed-on: https://go-review.googlesource.com/7506 Reviewed-by: Rick Hudson <rlh@golang.org>
Russ Cox [Mon, 16 Mar 2015 23:03:09 +0000 (19:03 -0400)]
cmd/internal/gc: mv builtins builtin
This directory is processed by mkbuiltin.go and generates builtin.go.
It should be named builtin too, not builtins, both for consistency
and because file and directory names in general are singular unless
forced otherwise.
Commented on CL 6233 too.
Change-Id: Ic5d3671443ae9292b69fda118f61a11c88d823fa
Reviewed-on: https://go-review.googlesource.com/7660 Reviewed-by: Minux Ma <minux@golang.org>
Russ Cox [Sun, 8 Mar 2015 17:33:49 +0000 (13:33 -0400)]
cmd/gc: rewrite argtype to substitute in a single pass
Substituting in multiple passes meant walking the type
multiple times, and worse, if a complex type was substituted
in an early pass, later passes would follow it, possibly recursively,
until hitting the depth 10 limit.
Joël Stemmer [Fri, 6 Mar 2015 13:08:55 +0000 (14:08 +0100)]
crypto/tls: return correct hash function when using client certificates in handshake
Commit f1d669aee994b28e1afcfe974680565932d25b70 added support for
AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it
did not take the arbitrary hash function into account in the TLS client
handshake when using client certificates.
The hashForClientCertificate method always returned SHA256 as its
hashing function, even if it actually used a different one to calculate
its digest. Setting up the connection would eventually fail with the
error "tls: failed to sign handshake with client certificate:
crypto/rsa: input must be hashed message".
Included is an additional test for this specific situation that uses the
SHA384 hash.
Fixes #9808
Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3
Reviewed-on: https://go-review.googlesource.com/7040 Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Nick Sullivan [Wed, 25 Feb 2015 01:55:25 +0000 (17:55 -0800)]
crypto/rsa: implement crypto.Decrypter
Decrypter is an interface to support opaque private keys that perform
decryption operations. This interface is analogous to the crypto.Signer
interface.
This change introduces the crypto.Decrypter interface and implements
the crypto.Decrypter interface for rsa.PrivateKey with both OAEP and
PKCS#1 v1.5 padding modes.
Change-Id: I433f649f84ed3c2148337d735cafd75f1d94a904
Reviewed-on: https://go-review.googlesource.com/3900 Reviewed-by: Adam Langley <agl@golang.org>
Rob Pike [Tue, 13 Jan 2015 22:13:42 +0000 (09:13 +1100)]
text/template: protect against explicit nil in field chains
An explicit nil in an expression like nil.Foo caused a panic
because the evaluator attempted to reflect on the nil.
A typeless nil like this cannot be used to do anything, so
just error out.
Fixes #9426
Change-Id: Icd2c9c7533dda742748bf161eced163991a12f54
Reviewed-on: https://go-review.googlesource.com/7643 Reviewed-by: David Symonds <dsymonds@golang.org>
Aram Hăvărneanu [Sun, 8 Mar 2015 12:58:16 +0000 (13:58 +0100)]
cmd/internal/obj, cmd/internal/obj/arm64: add support for GOARCH=arm64
ARM64 (ARMv8) has 32 general purpose, 64-bit integer registers
(R0-R31), 32 64-bit scalar floating point registers (F0-F31), and
32 128-bit vector registers (unused, V0-V31).
R31 is either the stack pointer (RSP), or the zero register (ZR),
depending on the instruction. Note the distinction between the
hardware stack pointer, RSP, and the virtual stack pointer SP.
The (hardware) stack pointer must be 16-byte aligned at all times;
the RSP register itself must be aligned, offset(RSP) only has to
have natural alignment.
Instructions are fixed-width, and are 32-bit wide. ARM64 supports
ARMv7 too (32-bit ARM), but not in the same process. In general,
there is not much in common between 32-bit ARM and ARM64, it's a
new architecture.
All implementations have floating point instructions.
This change adds a Prog.To3 field analogous to Prog.To. It is used
by exclusive load/store instructions such as STLXR which read from
one register, and write to both a register and a memory address.
STLXRW R1, (R0), R3
This will store the word contained in R1 to the memory address
pointed by R0. R3 will be updated with the status result of the
store. It is used to implement atomic operations.
No other changes are made to the portable Prog and Addr structures.
Joel Sing [Sun, 18 Jan 2015 10:02:58 +0000 (21:02 +1100)]
all: remove dragonfly/386 port
DragonFlyBSD dropped support for i386 in 4.0 and there is no longer a
dragonfly/386 - as such, remove the Go port.
Fixes #8951
Fixes #7580
Fixes #7421
Change-Id: I69022ab2262132e8f97153f14dc8c37c98527008
Reviewed-on: https://go-review.googlesource.com/7543 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dave Cheney <dave@cheney.net> Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Joel Sing <jsing@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Michael Hudson-Doyle [Sat, 7 Mar 2015 03:28:07 +0000 (16:28 +1300)]
cmd/internal/ld: remove some dead code
Just little bits and pieces I noticed were unused in passing, and
some more found with https://github.com/opennota/check.
Change-Id: I199fecdbf8dc2ff9076cf4ea81395275c7f171c3
Reviewed-on: https://go-review.googlesource.com/7033 Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Matthew Dempsky [Mon, 9 Mar 2015 18:14:35 +0000 (11:14 -0700)]
cmd/internal/gc: remove unused fields
Change-Id: I3096a7497955bc475739739ee23be387e9162867
Reviewed-on: https://go-review.googlesource.com/7210
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Sat, 14 Mar 2015 00:24:30 +0000 (17:24 -0700)]
math/big: wrap Float.Cmp result in struct to prevent wrong use
Float.Cmp used to return a value < 0, 0, or > 0 depending on how
arguments x, y compared against each other. With the possibility
of NaNs, the result was changed into an Accuracy (to include Undef).
Consequently, Float.Cmp results could still be compared for (in-)
equality with 0, but comparing if < 0 or > 0 would provide the
wrong answer w/o any obvious notice by the compiler.
This change wraps Float.Cmp results into a struct and accessors
are used to access the desired result. This prevents incorrect
use.
Change-Id: I34e6a6c1859251ec99b5cf953e82542025ace56f
Reviewed-on: https://go-review.googlesource.com/7526 Reviewed-by: Rob Pike <r@golang.org>