summaryrefslogtreecommitdiff
path: root/src/runtime
Commit message (Collapse)AuthorAgeFilesLines
* runtime: improve out-of-memory message when VirtualAlloc failsAustin Clements2017-07-211-2/+11
| | | | | | | | | | Fixes #19514. Change-Id: I93600d5c3d11ecab5a47dd4cd55ed3aea05e221e Reviewed-on: https://go-review.googlesource.com/49611 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: use SIGKILL if SIGQUIT is blocked; skip tests that need SIGQUITAustin Clements2017-07-202-0/+36
| | | | | | | | | | | | | | | | | | | | | | | The runtime tests may be invoked from a parent that has SIGQUIT blocked. For example, Java invokes subprocesses this way. In this situation, TestCrashDumpsAllThreads and TestPanicSystemstack will fail because they depend on SIGQUIT to get tracebacks, and any subprocess test that times out will fail to kill the subprocess. Fix this by detecting if SIGQUIT is blocked and, if so, skipping tests that depend on it and using SIGKILL to kill timed-out subprocesses. Based on a fix by Carl Henrik Lunde in https://golang.org/issue/19196#issuecomment-316145733 Fixes #19196. Change-Id: Ia20bf15b96086487d0ef6b75239dcc260c21714c Reviewed-on: https://go-review.googlesource.com/50330 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime: don't call libc sigaction function in forked childIan Lance Taylor2017-07-202-1/+18
| | | | | | | | | | | | If we are using vfork, and if something (such as TSAN) is intercepting the sigaction function, then we must call the system call, not the libc function. Otherwise the intercepted sigaction call in the child may trash the data structures in the parent. Change-Id: Id9588bfeaa934f32c920bf829c5839be5cacf243 Reviewed-on: https://go-review.googlesource.com/50251 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Austin Clements <austin@google.com>
* runtime: only trace mark assists that do workAustin Clements2017-07-191-6/+8
| | | | | | | | | | | | | | | | | | Currently we trace mark assists even if they're satisfied entirely by stealing. This means even if background marking is keeping up with allocation, we'll still emit a trace event every N bytes of allocation. The event will be a few microseconds, if that, but they're frequent enough that, when zoomed out in the trace view, it looks like all of the time is spent in mark assists even if almost none is. Change this so we only emit a trace event if the assist actually has to do assisting. This makes the traces of these events far more useful. Change-Id: If4aed1c413b814341ef2fba61d2f10751d00451b Reviewed-on: https://go-review.googlesource.com/50030 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Rick Hudson <rlh@golang.org>
* runtime: move tSweepTerm capture closer to STWAustin Clements2017-07-181-2/+2
| | | | | | | | | | | | | | tSweepTerm and pauseStart are supposed to be when STW was triggered, but right now they're captured a bit before STW. Move these down to immediately before we trigger STW. Fixes #19590. Change-Id: Icd48a5c4d45c9b36187ff986e4f178b5064556c1 Reviewed-on: https://go-review.googlesource.com/49612 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: always use 2MB stacks on 64-bit WindowsAustin Clements2017-07-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Currently, Windows stacks are either 128kB or 2MB depending on whether the binary uses cgo. This is because we assume that Go system stacks and the small amount of C code invoked by the standard library can operate within smaller stacks, but general Windows C code assumes larger stacks. However, it's easy to call into arbitrary C code using the syscall package on Windows without ever importing cgo into a binary. Such binaries need larger system stacks even though they don't use cgo. Fix this on 64-bit by increasing the system stack size to 2MB always. This only costs address space, which is free enough on 64-bit to not worry about. We keep (for now) the existing heuristic on 32-bit, where address space comes at more of a premium. Updates #20975. Change-Id: Iaaaa9a2fcbadc825cddc797aaaea8d34ef8debf2 Reviewed-on: https://go-review.googlesource.com/49331 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
* runtime: fix duplicate "the"sDaniel Morsing2017-07-151-1/+1
| | | | | | | | kicking off contributing again with a classic Change-Id: Ifb0aed8f1dc854f85751ce0495967a3c4315128d Reviewed-on: https://go-review.googlesource.com/49016 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: don't call t.Parallel in TestCgoSignalDeadlockIan Lance Taylor2017-07-131-1/+4
| | | | | | | | | | | | | | | It seems that when too much other code is running on the system, the testprogcgo code can overrun its timeouts. Updates #18598. Not marking the issue as fixed until it doesn't recur for some time. Change-Id: Ieaf106b41986fdda76b1d027bb9d5e3fb805cc3b Reviewed-on: https://go-review.googlesource.com/48233 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: pass CLONE_SYSVSEM to cloneAustin Clements2017-07-121-0/+1
| | | | | | | | | | | | | | | | | | SysV semaphore undo lists should be shared by threads, just like several other resources listed in cloneFlags. Currently we don't do this, but it probably doesn't affect anything because 1) probably nobody uses SysV semaphores from Go and 2) Go-created threads never exit until the process does. Beyond being the right thing to do, user-level QEMU requires this flag because it depends on glibc to create new threads and glibc uses this flag. Fixes #20763. Change-Id: I1d1dafec53ed87e0f4d4d432b945e8e68bb72dcd Reviewed-on: https://go-review.googlesource.com/48170 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: make TestStackGrowth a serial testAustin Clements2017-07-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | TestStackGrowth is currently a parallel test. However, it depends on a 20 second timeout, which is already dubious in a parallel test, and became really problematic on slow builders when runtime.GC switched to triggering concurrent GC instead of STW GC. Before that change, the test spent much of its time in STW GC, so it wasn't *really* parallel. After that change, it was competing with all of the other parallel tests and GC likely started taking ~4 times longer. On most builders the whole test runs in well under a second, but on the slow builders that was enough to push it over the 20 second timeout. Fix this by making the test serial. Updates #19381 (probably fixes it, but we'll have to wait and see). Change-Id: I21af7cf543ab07f1ec1c930bfcb355b0df75672d Reviewed-on: https://go-review.googlesource.com/48110 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Elias Naur <elias.naur@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: simplify description of FuncForPC behavior in case of inliningCostin Chirvasuta2017-07-111-1/+1
| | | | | | | | | The current description refers to the outermost "frame" which can be misleading. A user reading it can think it means a stack frame. Change-Id: Ie2c7cb4b4db8f41572df206478ce3b46a0245a5d Reviewed-on: https://go-review.googlesource.com/47850 Reviewed-by: Austin Clements <austin@google.com>
* runtime: use next timer to decide whether to relaxAustin Clements2017-07-074-21/+24
| | | | | | | | | | | | | | | | | | | Currently, sysmon waits 60 ms during idle before relaxing. This is primarily to avoid reducing the precision of short-duration timers. Of course, if there are no short-duration timers, this wastes 60 ms running the timer at high resolution. Improve this by instead inspecting the time until the next timer fires and relaxing the timer resolution immediately if the next timer won't fire for a while. Updates #20937. Change-Id: If4ad0a565b65a9b3e8c4cdc2eff1486968c79f24 Reviewed-on: https://go-review.googlesource.com/47833 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: delay before osRelaxingAustin Clements2017-07-073-3/+30
| | | | | | | | | | | | | | | | | | | | | | Currently, sysmon relaxes the Windows timer resolution as soon as the Go process becomes idle. However, if it's going idle because of a short sleep (< 15.6 ms), this can turn that short sleep into a long sleep (15.6 ms). To address this, wait for 60 ms of idleness before relaxing the timer resolution. It would be better to check the time until the next wakeup and relax immediately if it makes sense, but there's currently no interaction between sysmon and the timer subsystem, so adding this simple delay is a much simpler and safer change for late in the release cycle. Fixes #20937. Change-Id: I817db24c3bdfa06dba04b7bc197cfd554363c379 Reviewed-on: https://go-review.googlesource.com/47832 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: save r11 in ARM addmoduledataAustin Clements2017-07-071-1/+3
| | | | | | | | | | | | | | | | | | R11 is callee-save in the C ABI, but the temporary register in the Go ABI. Currently it's being clobbered by runtime.addmoduledata, which has to follow the C ABI. The observed effect of this was that dl_open_worker was returning to a bad PC because after it failed to restore its SP because it was using R11 as a frame pointer. Fix this by saving R11 around addmoduledata. Fixes #19674. Change-Id: Iaacbcc76809a3aa536e9897770831dcbcb6c8245 Reviewed-on: https://go-review.googlesource.com/47831 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
* runtime: document FuncForPC behavior with inliningAustin Clements2017-07-071-0/+3
| | | | | | | Change-Id: I1c02aa4f7131ae984fda66b32e8a993c0a40b8f4 Reviewed-on: https://go-review.googlesource.com/47690 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
* runtime: prevent descheduling while holding rwmutex read lockAustin Clements2017-07-062-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently only the rwmutex write lock prevents descheduling. The read lock does not. This leads to the following situation: 1. A reader acquires the lock and gets descheduled. 2. GOMAXPROCS writers attempt to acquire the lock (or at least one writer does, followed by readers). This blocks all of the Ps. 3. There is no 3. The descheduled reader never gets to run again because there are no Ps, so it never releases the lock and the system deadlocks. Fix this by preventing descheduling while holding the read lock. This requires also rewriting TestParallelRWMutexReaders to always create enough GOMAXPROCS and to use non-blocking operations for synchronization. Fixes #20903. Change-Id: Ibd460663a7e5a555be5490e13b2eaaa295fac39f Reviewed-on: https://go-review.googlesource.com/47632 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime/pprof: Fix type name in function commentFabian Wickborn2017-07-051-1/+1
| | | | | | | | | | | | | The name LabelList was changed to LabelSet during the development of the proposal [1], except in one function comment. This commit fixes that. Fixes #20905. [1] https://github.com/golang/go/issues/17280 Change-Id: Id4f48d59d7d513fa24b2e42795c2baa5ceb78f36 Reviewed-on: https://go-review.googlesource.com/47470 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: clean up mheap.allocLargeAustin Clements2017-07-031-9/+4
| | | | | | | | | | | | | | mheap.allocLarge just calls bestFitTreap and is the only caller of bestFitTreap. Flatten these into a single function. Also fix their comments: allocLarge claims to return exactly npages but can in fact return a larger span, and h.freelarge is not in fact indexed by span start address. Change-Id: Ia20112bdc46643a501ea82ea77c58596bc96f125 Reviewed-on: https://go-review.googlesource.com/47315 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
* runtime: allow calling Func.Name on nil pointerJoe Tsai2017-06-302-0/+14
| | | | | | | | | | | | | | | The Func type has allowed calling the Func.Name method on a nil pointer since Go1.2, where it returned an empty string. A regression caused by CL/37331 caused this behavior to change. This breaks code that lazily does runtime.FuncForPC(myPtr).Name() without first checking that myPtr is actually non-nil. Fixes #20872 Change-Id: Iae9a2ebabca5e9d1f5a2cdaf2f30e9c6198fec4f Reviewed-on: https://go-review.googlesource.com/47354 Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: use rwmutex for execLockAustin Clements2017-06-281-9/+8
| | | | | | | | | | | | | | Currently the execLock is a mutex, which has the unfortunate side-effect of serializing all thread creation. This replaces it with an rwmutex so threads can be created in parallel, but exec still blocks thread creation. Fixes #20738. Change-Id: Ia8f30a92053c3d28af460b0da71176abe5fd074b Reviewed-on: https://go-review.googlesource.com/47072 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime: make rwmutex work on Ms instead of GsAustin Clements2017-06-284-29/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently runtime.rwmutex is written to block the calling goroutine rather than the calling thread. However, rwmutex was intended to be used in the scheduler, which means it needs to be a thread-level synchronization primitive. Hence, this modifies rwmutex to synchronize threads instead of goroutines. This has the consequence of making it write-barrier-free, which is also important for using it in the scheduler. The implementation makes three changes: it replaces the "w" semaphore with a mutex, since this was all it was being used for anyway; it replaces "writerSem" with a single pending M that parks on its note; and it replaces "readerSem" with a list of Ms that park on their notes plus a pass count that together emulate a counting semaphore. I model-checked the safety and liveness of this implementation through >1 billion schedules. For #20738. Change-Id: I3cf5a18c266a96a3f38165083812803510217787 Reviewed-on: https://go-review.googlesource.com/47071 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime: temporarily skip gdb python-related tests on solarisShawn Walker-Salas2017-06-281-0/+4
| | | | | | | | | | | Updates #20821 Change-Id: I77a5b9a3bbb931845ef52a479549d71069af9540 Reviewed-on: https://go-review.googlesource.com/46913 Run-TryBot: Shawn Walker-Salas <shawn.walker@oracle.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime: get more info for TestCgoSignalDeadlock failuresIan Lance Taylor2017-06-271-2/+6
| | | | | | | | | | Updates #18598 Change-Id: I13c60124714cf9d1537efa0a7dd1e6a0fed9ae5b Reviewed-on: https://go-review.googlesource.com/46723 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: drain local runq when dedicated mark worker runsAustin Clements2017-06-261-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | When the dedicated mark worker runs, the scheduler won't run on that P again until GC runs out of mark work. As a result, any goroutines in that P's local run queue are stranded until another P steals them. In a normally operating system this may take a long time, and in a 100% busy system, the scheduler never attempts to steal from another P. Fix this by draining the local run queue into the global run queue if the dedicated mark worker has run for long enough. We don't do this immediately upon scheduling the dedicated mark worker in order to avoid destroying locality if the mark worker runs for a short time. Instead, the scheduler delays draining the run queue until the mark worker gets its first preemption request (and otherwise ignores the preemption request). Fixes #20011. Change-Id: I13067194b2f062b8bdef25cb75e4143b7fb6bb73 Reviewed-on: https://go-review.googlesource.com/46610 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
* os/signal: avoid race between Stop and receiving on channelIan Lance Taylor2017-06-242-7/+76
| | | | | | | | | | | | | | | | When Stop is called on a channel, wait until all signals have been delivered to the channel before returning. Use atomic operations in sigqueue to communicate more reliably between the os/signal goroutine and the signal handler. Fixes #14571 Change-Id: I6c5a9eea1cff85e37a34dffe96f4bb2699e12c6e Reviewed-on: https://go-review.googlesource.com/46003 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
* runtime/cgo: fix typosHiroshi Ioka2017-06-2121-21/+21
| | | | | | Change-Id: I6265ac81e5c38b201e14ddba2d6b9f0e73d8445c Reviewed-on: https://go-review.googlesource.com/46310 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* all: gofmtMikio Hara2017-06-211-1/+1
| | | | | | | | Change-Id: I2d0439a9f068e726173afafe2ef1f5d62b7feb4d Reviewed-on: https://go-review.googlesource.com/46190 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime, syscall: workaround for bug in Linux's execveJohn R. Lenton2017-06-201-0/+22
| | | | | | | | | | | | | | | | | | | | | Linux's execve has (at the time of writing, and since v2.6.30) a bug when it ran concurrently with clone, in that it would fail to set up some datastructures if the thread count before and after some steps differed. This is described better and in more detail by Colin King in Launchpad¹ and kernel² bugs. When a program written in Go runtime.Exec's a setuid binary, this issue may cause the resulting process to not have the expected uid. This patch works around the issue by using a mutex to serialize exec and clone. 1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819 2. https://bugzilla.kernel.org/show_bug.cgi?id=195453 Fixes #19546 Change-Id: I126e87d1d9ce3be5ea4ec9c7ffe13f92e087903d Reviewed-on: https://go-review.googlesource.com/43713 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: add read/write mutex typeIan Lance Taylor2017-06-193-0/+287
| | | | | | | | | | | | | | | This is a runtime version of sync.RWMutex that can be used by code in the runtime package. The type is not quite the same, in that the zero value is not valid. For future use by CL 43713. Updates #19546 Change-Id: I431eb3688add16ce1274dab97285f555b72735bf Reviewed-on: https://go-review.googlesource.com/45991 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
* runtime: enable GDB tests on mips64 (except TestGdbPythonCgo)Vladimir Stefanovic2017-06-151-11/+1
| | | | | | | | | | | | | | They were failing when run on 32bit RFS, with 32bit gdb. (mips64 builder now has 64bit RFS, with gdb 7.9.) Leaving TestGdbPythonCgo disabled, it behaves as described in #18784. Fixes #18173 Change-Id: I3c438cd5850b7bfd118ac6396f40c1208bac8c2d Reviewed-on: https://go-review.googlesource.com/45874 Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: restore arm assembly stubs for div/modKeith Randall2017-06-152-1/+117
| | | | | | | | | | | | These are used by DIV[U] and MOD[U] assembly instructions. Add a test in the stdlib so we actually exercise linking to these routines. Update #19507 Change-Id: I0d8e19a53e3744abc0c661ea95486f94ec67585e Reviewed-on: https://go-review.googlesource.com/45703 Reviewed-by: Cherry Zhang <cherryyz@google.com>
* runtime: remove unused arm assembly for div/modKeith Randall2017-06-142-129/+6
| | | | | | | | | | Also add runtime· prefixes to the code that is still used. Fixes #19507 Change-Id: Ib6da6b2a9e398061d3f93958ee1258295b6cc33b Reviewed-on: https://go-review.googlesource.com/45699 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: don't run TestCgoNumGoroutine on Windows or Plan 9Ian Lance Taylor2017-06-142-0/+6
| | | | | | | | | | | | The test requires pthreads. Fixes #20666. Change-Id: Icb2400250a80cdad6680cd1ef6c18ef7343d5e29 Reviewed-on: https://go-review.googlesource.com/45701 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: record mutex event before readyingAustin Clements2017-06-142-4/+7
| | | | | | | | | | | | | | | | | | | | | Currently, semrelease1 readies the next waiter before recording a mutex event. However, if the next waiter is expecting to look at the mutex profile, as is the case in TestMutexProfile, this may delay recording the event too much. Swap the order of these operations so semrelease1 records the mutex event before readying the next waiter. This also means readying the next waiter is the very last thing semrelease1 does, which seems appropriate. Fixes #19139. Change-Id: I1a62063599fdb5d49bd86061a180c0a2d659474b Reviewed-on: https://go-review.googlesource.com/45751 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Peter Weinberger <pjw@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime, syscall: reset signal handlers to default in childIan Lance Taylor2017-06-147-10/+149
| | | | | | | | | | | | | | | | | | | | | | | Block all signals during a fork. In the parent process, after the fork, restore the signal mask. In the child process, reset all currently handled signals to the default handler, and then restore the signal mask. The effect of this is that the child will be operating using the same signal regime as the program it is about to exec, as exec resets all non-ignored signals to the default, and preserves the signal mask. We do this so that in the case of a signal sent to the process group, the child process will not try to run a signal handler while in the precarious state after a fork. Fixes #18600. Change-Id: I9f39aaa3884035908d687ee323c975f349d5faaa Reviewed-on: https://go-review.googlesource.com/45471 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
* runtime: speed up stack copyingJosh Bleecher Snyder2017-06-142-10/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was surprised to see readvarint show up in a cpu profile. Use a few simple optimizations to speed up stack copying: * Avoid making a copy of the cache.entries array or any of its elements. * Use a shift instead of a signed division in stackmapdata. * Change readvarint to return the number of bytes consumed rather than an updated slice. * Make some minor optimizations to readvarint to help the compiler. * Avoid called readvarint when the value fits in a single byte. The first and last optimizations are the most significant, although they all contribute a little. Add a benchmark for stack copying that includes lots of different functions in a recursive loop, to bust the cache. This might speed up other runtime operations as well; I only benchmarked stack copying. name old time/op new time/op delta StackCopy-8 96.4ms ± 2% 82.7ms ± 1% -14.24% (p=0.000 n=20+19) StackCopyNoCache-8 167ms ± 1% 131ms ± 1% -21.58% (p=0.000 n=20+20) Change-Id: I13d5c455c65073c73b656acad86cf8e8e3c9807b Reviewed-on: https://go-review.googlesource.com/43150 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
* runtime: move pdesc into pAustin Clements2017-06-142-5/+6
| | | | | | | | | | | | | | | There are currently two arrays indexed by P ID: allp and pdesc. Consolidate these by moving the pdesc fields into type p so they can be indexed off allp along with all other per-P state. For #15131. Change-Id: Ib6c4e6e7612281a1171ba4a0d62e52fd59e960b4 Reviewed-on: https://go-review.googlesource.com/45572 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
* runtime: increase MaxGomaxprocs to 1024Austin Clements2017-06-131-1/+1
| | | | | | | | | | | | | | | | | Currently MaxGomaxprocs is 256. The previous CL saved enough per-P static space that we can quadruple MaxGomaxprocs (and hence the static size of allp) and still come out ahead. This is safe for Go 1.9. In Go 1.10 we'll eliminate the hard-coded limit entirely. Updates #15131. Change-Id: I919ea821c1ce64c27812541dccd7cd7db4122d16 Reviewed-on: https://go-review.googlesource.com/45673 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
* runtime: clean up some silly allp loopsAustin Clements2017-06-132-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Back in the day, allp was just a pointer to an array. As a result, the runtime has a few loops of the form: for i := 0; ; i++ { p := allp[i] if p == nil { break } ... } This is silly now because it requires that allp be one longer than the maximum possible number of Ps, but now that allp is in Go it has a length. Replace these with range loops. Change-Id: I91ef4bc7bd3c9d4fda2264f4aa1b1d0271d7f578 Reviewed-on: https://go-review.googlesource.com/45571 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime, unicode: use consistent banner for generated codeBrad Fitzpatrick2017-06-1311-11/+11
| | | | | | | | | | | | | Per golang.org/s/generatedcode Updates #nnn Change-Id: Ia7513ef6bd26c20b62b57b29f7770684a315d389 Reviewed-on: https://go-review.googlesource.com/45470 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Matt Layher <mdlayher@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: YIELD in procyield on ARMAustin Clements2017-06-091-0/+1
| | | | | | | | | | | | | | | | | | | ARM currently does not use a hardware yield instruction in the spin loop in procyield because the YIELD instruction was only added in ARMv6K. However, it appears earlier ARM chips will interpret the YIELD encoding as an effective NOP (specifically an MSR instruction that ultimately has no effect on the CPSR register). Hence, use YIELD in procyield on ARM since it should be, at worst, harmless. Fixes #16663. Change-Id: Id1787ac48862b785b92c28f1ac84cb4908d2173d Reviewed-on: https://go-review.googlesource.com/45250 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
* runtime: print pc with fp/sp in tracebackAustin Clements2017-06-091-1/+1
| | | | | | | | | | | If we're in a situation where printing the fp and sp in the traceback is useful, it's almost certainly also useful to print the PC. Change-Id: Ie48a0d5de8a54b5b90ab1d18638a897958e48f70 Reviewed-on: https://go-review.googlesource.com/45210 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
* syscall: make windows Exit call runtime.exitAlex Brainman2017-06-081-0/+6
| | | | | | | | | | | | | | | | Both runtime.exit and syscall.Exit call Windows ExitProcess. But recently (CL 34616) runtime.exit was changed to ignore Windows CreateThread errors if ExitProcess is called. This CL adjusts syscall.Exit to do the same. Fixes #18253 (maybe) Change-Id: I6496c31b01e7c7d73b69c0b2ae33ed7fbe06736b Reviewed-on: https://go-review.googlesource.com/45115 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Austin Clements <austin@google.com>
* runtime: more diagnostics for TestStackGrowthAustin Clements2017-06-081-0/+6
| | | | | | | | | | | | | This adds diagnostics so we can tell if the finalizer has started, in addition to whether or not it has finished. Updates #19381. Change-Id: Icb7b1b0380c9ad1128b17074828945511a6cca5d Reviewed-on: https://go-review.googlesource.com/45138 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime: fix documentation error about runtime.GC()Austin Clements2017-06-081-1/+1
| | | | | | | | | runtime.GC no longer triggers a STW GC. This fixes the description of GODEBUG=gctrace=1 so it doesn't claim otherwise. Change-Id: Ibd34a55c5ae7b5eda5c2393b9a6674bdf1d51eb3 Reviewed-on: https://go-review.googlesource.com/45131 Reviewed-by: Rick Hudson <rlh@golang.org>
* runtime: fix tab/space inconsistency in runtime-gdb.pyAustin Clements2017-06-081-1/+1
| | | | | | | | Change-Id: I78c6198eb909e679cf0f776b77dda52211bfd347 Reviewed-on: https://go-review.googlesource.com/45133 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: fix GDB goroutine N command when N is runningAustin Clements2017-06-082-4/+41
| | | | | | | | | | | | | | | | | | The current implementation of "goroutine N cmd" assumes it can get goroutine N's state from the goroutine's sched buffer. But this only works if the goroutine is blocked. Extend find_goroutine so that, if there is no saved scheduler state for a goorutine, it tries to find the thread the goroutine is running on and use the thread's current register state. We also extend find_goroutine to understand saved syscall register state. Fixes #13887. Change-Id: I739008a8987471deaa4a9da918655e4042cf969b Reviewed-on: https://go-review.googlesource.com/45031 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime: mark extra M's G as dead when not in useAustin Clements2017-06-073-3/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently the extra Ms created for cgo callbacks have a corresponding G that's kept in syscall state with only a call to goexit on its stack. This leads to confusing output from runtime.NumGoroutines and in tracebacks: goroutine 17 [syscall, locked to thread]: runtime.goexit() .../src/runtime/asm_amd64.s:2197 +0x1 Fix this by putting this goroutine into state _Gdead when it's not in use instead of _Gsyscall. To keep the goroutine counts correct, we also add one to sched.ngsys while the goroutine is in _Gdead. The effect of this is as if the goroutine simply doesn't exist when it's not in use. Fixes #16631. Fixes #16714. Change-Id: Ieae08a2febd4b3d00bef5c23fd6ca88fb2bb0087 Reviewed-on: https://go-review.googlesource.com/45030 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime: deflake TestPanicRaceIan Lance Taylor2017-06-071-13/+30
| | | | | | | | | | | | | The test is inherently racy, and for me fails about 0.05% of the time. So only fail the test if it fails ten times in a row. Fixes #20594 Change-Id: I3b3f7598f2196f7406f1a3937f38f21ff0c0e4b5 Reviewed-on: https://go-review.googlesource.com/45020 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: intercept munmap as we do mmapIan Lance Taylor2017-06-066-3/+60
| | | | | | | | | | | | | | | | | For cgo programs on linux-amd64 we call the C function mmap. This supports programs such as the C memory sanitizer that need to intercept all calls to mmap. It turns out that there are programs that intercept both mmap and munmap, or that at least expect that if they intercept mmap, they also intercept munmap. So, if we permit mmap to be intercepted, also permit munmap to be intercepted. No test, as it requires two odd things: a C program that intercepts mmap and munmap, and a Go program that calls munmap. Change-Id: Iec33f47d59f70dbb7463fd12d30728c24cd4face Reviewed-on: https://go-review.googlesource.com/45016 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
View Lorry Controller Status