An error occurred fetching the project authors.
- 21 Apr, 2015 1 commit
-
-
Austin Clements authored
Currently, the concurrent mark phase is performed by the main GC goroutine. Prior to the previous commit enabling preemption, this caused marking to always consume 1/GOMAXPROCS of the available CPU time. If GOMAXPROCS=1, this meant background GC would consume 100% of the CPU (effectively a STW). If GOMAXPROCS>4, background GC would use less than the goal of 25%. If GOMAXPROCS=4, background GC would use the goal 25%, but if the mutator wasn't using the remaining 75%, background marking wouldn't take advantage of the idle time. Enabling preemption in the previous commit made GC miss CPU targets in completely different ways, but set us up to bring everything back in line. This change replaces the fixed GC goroutine with per-P background mark goroutines. Once started, these goroutines don't go in the standard run queues; instead, they are scheduled specially such that the time spent in mutator assists and the background mark goroutines totals 25% of the CPU time available to the program. Furthermore, this lets background marking take advantage of idle Ps, which significantly boosts GC performance for applications that under-utilize the CPU. This requires also changing how time is reported for gctrace, so this change splits the concurrent mark CPU time into assist/background/idle scanning. This also requires increasing the size of the StackRecord slice used in a GoroutineProfile test. Change-Id: I0936ff907d2cee6cb687a208f2df47e8988e3157 Reviewed-on: https://go-review.googlesource.com/8850Reviewed-by:
Rick Hudson <rlh@golang.org>
-
- 20 Apr, 2015 1 commit
-
-
Russ Cox authored
This CL revises CL 7504 to use explicitly uintptr types for the struct fields that are going to be updated sometimes without write barriers. The result is that the fields are now updated *always* without write barriers. This approach has two important properties: 1) Now the GC never looks at the field, so if the missing reference could cause a problem, it will do so all the time, not just when the write barrier is missed at just the right moment. 2) Now a write barrier never happens for the field, avoiding the (correct) detection of inconsistent write barriers when GODEBUG=wbshadow=1. Change-Id: Iebd3962c727c0046495cc08914a8dc0808460e0e Reviewed-on: https://go-review.googlesource.com/9019Reviewed-by:
Austin Clements <austin@google.com> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 18 Mar, 2015 1 commit
-
-
Josh Bleecher Snyder authored
Comment changes only. Change-Id: I56848814564c4aa0988b451df18bebdfc88d6d94 Reviewed-on: https://go-review.googlesource.com/7721Reviewed-by:
Rob Pike <r@golang.org>
-
- 16 Mar, 2015 1 commit
-
-
Aram Hăvărneanu authored
Change-Id: Ibda6a5bedaff57fd161d63fc04ad260931d34413 Reviewed-on: https://go-review.googlesource.com/7142Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 02 Mar, 2015 1 commit
-
-
Russ Cox authored
This fixes runtime's TestBreakpoint on ppc64: the Breakpoint frame was not showing up in the trace. It seems like f.frame should be either the frame size including the saved LR (if any) or the frame size not including the saved LR. On ppc64, f.frame is the frame size not including the saved LR. On arm, f.frame is the frame size not including the saved LR, except when that's -4, f.frame is 0 instead. The code here in the runtime expects that f.frame is the frame size including the saved LR. Since all three disagree and nothing else uses f.frame anymore, stop using it here too. Use funcspdelta, which tells us the exact difference between the FP and SP. If it's zero, LR has not been saved yet, so the one saved for sigpanic should be recorded. This fixes TestBreakpoint on both ppc64 and ppc64le. I don't really understand how it ever worked there. Change-Id: I2d2c580d5c0252cc8471e828980aeedcab76858d Reviewed-on: https://go-review.googlesource.com/6430Reviewed-by:
Minux Ma <minux@golang.org>
-
- 26 Feb, 2015 1 commit
-
-
Matthew Dempsky authored
This makes Go's CPU profiling code somewhat more idiomatic; e.g., using := instead of forward declaring variables, using "int" for element counts instead of "uintptr", and slices instead of C-style pointer+length. This makes the code easier to read and eliminates a lot of type conversion clutter. Additionally, in sigprof we can collect just maxCPUProfStack stack frames, as cpuprof won't use more than that anyway. Change-Id: I0235b5ae552191bcbb453b14add6d8c01381bd06 Reviewed-on: https://go-review.googlesource.com/6072 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
- 11 Feb, 2015 1 commit
-
-
Dmitry Vyukov authored
Fixes #9791 g.issystem flag setup races with other code wherever we set it. Even if we set both in parent goroutine and in the system goroutine, it is still possible that some other goroutine crashes before the flag is set. We could pass issystem flag to newproc1, but we start all goroutines with go nowadays. Instead look at g.startpc to distinguish system goroutines (similar to topofstack). Change-Id: Ia3467968dee27fa07d9fecedd4c2b00928f26645 Reviewed-on: https://go-review.googlesource.com/4113Reviewed-by:
Keith Randall <khr@golang.org>
-
- 03 Feb, 2015 2 commits
-
-
Austin Clements authored
The test for the framepointer experiment flag is cheaper and more branch-predictable than the other parts of this conditional, so move it first. This is also more readable. (Originally, the flag check required parsing the experiments string, which is why it was done last. Now that flag is cached.) Change-Id: I84e00fa7e939e9064f0fa0a4a6fe00576dd61457 Reviewed-on: https://go-review.googlesource.com/3782Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
Previously, we checked for a saved frame pointer by looking for a 2*ptrSize gap between the argument pointer and the locals pointer. The intent of this check was to look for a two stack slot gap (caller IP and saved frame pointer), but stack slots are regSize, not ptrSize. Correct this by checking instead for a 2*regSize gap. On most platforms, this made no difference because ptrSize==regSize. However, on amd64p32 (nacl), the saved frame pointer check incorrectly fired when there was no saved frame pointer because the one stack slot for the caller IP left an 8 byte gap, which is 2*ptrSize (but not 2*regSize) on amd64p32. Fixes #9760. Change-Id: I6eedcf681fe5bf2bf924dde8a8f2d9860a4d758e Reviewed-on: https://go-review.googlesource.com/3781Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 02 Feb, 2015 1 commit
-
-
Austin Clements authored
This adds a "framepointer" GOEXPERIMENT that that makes the amd64 toolchain maintain base pointer chains in the same way that gcc -fno-omit-frame-pointer does. Go doesn't use these saved base pointers, but this does enable external tools like Linux perf and VTune to unwind Go stacks when collecting system-wide profiles. This requires support in the compilers to not clobber BP, support in liblink for generating the BP-saving function prologue and unwinding epilogue, and support in the runtime to save BPs across preemption, to skip saved BPs during stack unwinding and, and to adjust saved BPs during stack moving. As with other GOEXPERIMENTs, everything from the toolchain to the runtime must be compiled with this experiment enabled. To do this, run make.bash (or all.bash) with GOEXPERIMENT=framepointer. Change-Id: I4024853beefb9539949e5ca381adfdd9cfada544 Reviewed-on: https://go-review.googlesource.com/2992Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 29 Dec, 2014 1 commit
-
-
Keith Randall authored
They are no longer needed now that C is gone. goatoi -> atoi gofuncname/funcname -> funcname/cfuncname goroundupsize -> already existing roundupsize Change-Id: I278bc33d279e1fdc5e8a2a04e961c4c1573b28c7 Reviewed-on: https://go-review.googlesource.com/2154Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-
- 28 Dec, 2014 1 commit
-
-
Keith Randall authored
Rename "gothrow" to "throw" now that the C version of "throw" is no longer needed. This change is purely mechanical except in panic.go where the old version of "throw" has been deleted. sed -i "" 's/[[:<:]]gothrow[[:>:]]/throw/g' runtime/*.go Change-Id: Icf0752299c35958b92870a97111c67bcd9159dc3 Reviewed-on: https://go-review.googlesource.com/2150Reviewed-by:
Minux Ma <minux@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
- 23 Dec, 2014 1 commit
-
-
Keith Randall authored
Calls to goproc/deferproc used to push & pop two extra arguments, the argument size and the function to call. Now, we allocate space for those arguments in the outargs section so we don't have to modify the SP. Defers now use the stack pointer (instead of the argument pointer) to identify which frame they are associated with. A followon CL might simplify funcspdelta and some of the stack walking code. Fixes issue #8641 Change-Id: I835ec2f42f0392c5dec7cb0fe6bba6f2aed1dad8 Reviewed-on: https://go-review.googlesource.com/1601Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 12 Nov, 2014 1 commit
-
-
Russ Cox authored
Scalararg and ptrarg are not "signal safe". Go code filling them out can be interrupted by a signal, and then the signal handler runs, and if it also ends up in Go code that uses scalararg or ptrarg, now the old values have been smashed. For the pieces of code that do need to run in a signal handler, we introduced onM_signalok, which is really just onM except that the _signalok is meant to convey that the caller asserts that scalarg and ptrarg will be restored to their old values after the call (instead of the usual behavior, zeroing them). Scalararg and ptrarg are also untyped and therefore error-prone. Go code can always pass a closure instead of using scalararg and ptrarg; they were only really necessary for C code. And there's no more C code. For all these reasons, delete scalararg and ptrarg, converting the few remaining references to use closures. Once those are gone, there is no need for a distinction between onM and onM_signalok, so replace both with a single function equivalent to the current onM_signalok (that is, it can be called on any of the curg, g0, and gsignal stacks). The name onM and the phrase 'm stack' are misnomers, because on most system an M has two system stacks: the main thread stack and the signal handling stack. Correct the misnomer by naming the replacement function systemstack. Fix a few references to "M stack" in code. The main motivation for this change is to eliminate scalararg/ptrarg. Rick and I have already seen them cause problems because the calling sequence m.ptrarg[0] = p is a heap pointer assignment, so it gets a write barrier. The write barrier also uses onM, so it has all the same problems as if it were being invoked by a signal handler. We worked around this by saving and restoring the old values and by calling onM_signalok, but there's no point in keeping this nice home for bugs around any longer. This CL also changes funcline to return the file name as a result instead of filling in a passed-in *string. (The *string signature is left over from when the code was written in and called from C.) That's arguably an unrelated change, except that once I had done the ptrarg/scalararg/onM cleanup I started getting false positives about the *string argument escaping (not allowed in package runtime). The compiler is wrong, but the easiest fix is to write the code like Go code instead of like C code. I am a bit worried that the compiler is wrong because of some use of uninitialized memory in the escape analysis. If that's the reason, it will go away when we convert the compiler to Go. (And if not, we'll debug it the next time.) LGTM=khr R=r, khr CC=austin, golang-codereviews, iant, rlh https://golang.org/cl/174950043
-
- 11 Nov, 2014 1 commit
-
-
Russ Cox authored
The conversion was done with an automated tool and then modified only as necessary to make it compile and run. [This CL is part of the removal of C code from package runtime. See golang.org/s/dev.cc for an overview.] LGTM=r R=r, dave CC=austin, dvyukov, golang-codereviews, iant, khr https://golang.org/cl/166520043
-
- 06 Nov, 2014 1 commit
-
-
Russ Cox authored
Gentraceback may grow the stack. One of the gentraceback wrappers may grow the stack. One of the gentraceback callback calls may grow the stack. Various stack pointers are stored in various stack locations as type uintptr during the execution of these calls. If the stack does grow, these stack pointers will not be updated and will start trying to decode stack memory that is no longer valid. It may be possible to change the type of the stack pointer variables to be unsafe.Pointer, but that's pretty subtle and may still have problems, even if we catch every last one. An easier, more obviously correct fix is to require that gentraceback of the currently running goroutine must run on the g0 stack, not on the goroutine's own stack. Not doing this causes faults when you set StackFromSystem = 1 StackFaultOnFree = 1 The new check in gentraceback will catch future lapses. The more general problem is calling getcallersp but then calling a function that might relocate the stack, which would invalidate the result of getcallersp. Add note to stubs.go declaration of getcallersp explaining the problem, and check all existing calls to getcallersp. Most needed fixes. This affects Callers, Stack, and nearly all the runtime profiling routines. It does not affect stack copying directly nor garbage collection. LGTM=khr R=khr, bradfitz CC=golang-codereviews, r https://golang.org/cl/167060043
-
- 29 Oct, 2014 1 commit
-
-
Russ Cox authored
Originally traceback was only used for printing the stack when an unexpected signal came in. In that case, the initial PC is taken from the signal and should be used unaltered. For the callers, the PC is the return address, which might be on the line after the call; we subtract 1 to get to the CALL instruction. Traceback is now used for a variety of things, and for almost all of those the initial PC is a return address, whether from getcallerpc, or gp->sched.pc, or gp->syscallpc. In those cases, we need to subtract 1 from this initial PC, but the traceback code had a hard rule "never subtract 1 from the initial PC", left over from the signal handling days. Change gentraceback to take a flag that specifies whether we are tracing a trap. Change traceback to default to "starting with a return PC", which is the overwhelmingly common case. Add tracebacktrap, like traceback but starting with a trap PC. Use tracebacktrap in signal handlers. Fixes #7690. LGTM=iant, r R=r, iant CC=golang-codereviews https://golang.org/cl/167810044
-
- 30 Sep, 2014 1 commit
-
-
Keith Randall authored
Our traceback code needs to know the PC of several special functions, including goexit, mcall, etc. Make sure that these PCs are initialized before any traceback occurs. Fixes #8766 LGTM=rsc R=golang-codereviews, rsc, khr, bradfitz CC=golang-codereviews https://golang.org/cl/145570043
-
- 19 Sep, 2014 1 commit
-
-
Russ Cox authored
The current Windows build failure happens because by default runtime frames are excluded from stack traces. Apparently the Windows breakpoint path dies with an ordinary panic, while the Unix path dies with a throw. Breakpoint is a strange function and I don't mind that it's a little different on the two operating systems. The panic squelches runtime frames but the throw shows them, because throw is considered something that shouldn't have happened at all, so as much detail as possible is wanted. The runtime exclusion is meant to prevents printing too much noise about internal runtime details. But exported functions are not internal details, so show exported functions. If the program dies because you called runtime.Breakpoint, it's okay to see that frame. This makes the Breakpoint test show Breakpoint in the stack trace no matter how it is handled. Should fix Windows build. Tested on Unix by changing Breakpoint to fault instead of doing a breakpoint. TBR=brainman CC=golang-codereviews https://golang.org/cl/143300043
-
- 16 Sep, 2014 1 commit
-
-
Russ Cox authored
This makes the GC and the stack copying agree about how to interpret the defer structures. Previously, only the stack copying treated them precisely. This removes an untyped memory allocation and fixes at least three copystack bugs. To make sure the GC can find the deferred argument frame until it has been copied, keep a Defer on the defer list during its execution. In addition to making it possible to remove the untyped memory allocation, keeping the Defer on the list fixes two races between copystack and execution of defers (in both gopanic and Goexit). The problem is that once the defer has been taken off the list, a stack copy that happens before the deferred arguments have been copied back to the stack will not update the arguments correctly. The new tests TestDeferPtrsPanic and TestDeferPtrsGoexit (variations on the existing TestDeferPtrs) pass now but failed before this CL. In addition to those fixes, keeping the Defer on the list helps correct a dangling pointer error during copystack. The traceback routines walk the Defer chain to provide information about where a panic may resume execution. When the executing Defer was not on the Defer chain but instead linked from the Panic chain, the traceback had to walk the Panic chain too. But Panic structs are on the stack and being updated by copystack. Traceback's use of the Panic chain while copystack is updating those structs means that it can follow an updated pointer and find itself reading from the new stack. The new stack is usually all zeros, so it sees an incorrect early end to the chain. The new TestPanicUseStack makes this happen at tip and dies when adjustdefers finds an unexpected argp. The new StackCopyPoison mode causes an earlier bad dereference instead. By keeping the Defer on the list, traceback can avoid walking the Panic chain at all, making it okay for copystack to update the Panics. We'd have the same problem for any Defers on the stack. There was only one: gopanic's dabort. Since we are not taking the executing Defer off the chain, we can use it to do what dabort was doing, and then there are no Defers on the stack ever, so it is okay for traceback to use the Defer chain even while copystack is executing: copystack cannot modify the Defer chain. LGTM=khr R=khr CC=dvyukov, golang-codereviews, iant, rlh https://golang.org/cl/141490043
-
- 14 Sep, 2014 1 commit
-
-
Russ Cox authored
The merged traceback was wrong for LR machines, because traceback didn't pass lr to gentraceback. Now that we have a test looking at traceback output for a trap (the test of runtime.Breakpoint), we caught this. While we're here, fix a 'set and not used' warning. Fixes arm build. TBR=r R=r CC=golang-codereviews https://golang.org/cl/143040043
-
- 12 Sep, 2014 2 commits
-
-
Russ Cox authored
The goal here is to commit fully to having precise information about stack frames. If we need information we don't have, crash instead of assuming we should scan conservatively. Since the stack copying assumes fully precise information, any crashes during garbage collection that are introduced by this CL are crashes that could have happened during stack copying instead. Those are harder to find because stacks are copied much less often than the garbage collector is invoked. In service of that goal, remove ARGSIZE macros from asm_*.s, change switchtoM to have no arguments (it doesn't have any live arguments), and add args and locals information to some frames that can call back into Go. LGTM=khr R=khr, rlh CC=golang-codereviews https://golang.org/cl/137540043
-
Russ Cox authored
makeFuncStub and methodValueStub are used by reflect as generic function implementations. Each call might have different arguments. Extract those arguments from the closure data instead of assuming it is the same each time. Because the argument map is now being extracted from the function itself, we don't need the special cases in reflect.Call anymore, so delete those. Fixes an occasional crash seen when stack copying does not update makeFuncStub's arguments correctly. Will also help make it safe to require stack maps in the garbage collector. Derived from CL 142000044 by khr. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/143890044
-
- 09 Sep, 2014 1 commit
-
-
Russ Cox authored
Commit to stack copying for stack growth. We're carrying around a surprising amount of cruft from older schemes. I am confident that precise stack scans and stack copying are here to stay. Delete fallback code for when precise stack info is disabled. Delete fallback code for when copying stacks is disabled. Delete fallback code for when StackCopyAlways is disabled. Delete Stktop chain - there is only one stack segment now. Delete M.moreargp, M.moreargsize, M.moreframesize, M.cret. Delete G.writenbuf (unrelated, just dead). Delete runtime.lessstack, runtime.oldstack. Delete many amd64 morestack variants. Delete initialization of morestack frame/arg sizes (shortens split prologue!). Replace G's stackguard/stackbase/stack0/stacksize/ syscallstack/syscallguard/forkstackguard with simple stack bounds (lo, hi). Update liblink, runtime/cgo for adjustments to G. LGTM=khr R=khr, bradfitz CC=golang-codereviews, iant, r https://golang.org/cl/137410043
-
- 08 Sep, 2014 2 commits
-
-
Russ Cox authored
This CL contains compiler+runtime changes that detect C code running on Go (not g0, not gsignal) stacks, and it contains corrections for what it detected. The detection works by changing the C prologue to use a different stack guard word in the G than Go prologue does. On the g0 and gsignal stacks, that stack guard word is set to the usual stack guard value. But on ordinary Go stacks, that stack guard word is set to ^0, which will make any stack split check fail. The C prologue then calls morestackc instead of morestack, and morestackc aborts the program with a message about running C code on a Go stack. This check catches all C code running on the Go stack except NOSPLIT code. The NOSPLIT code is allowed, so the check is complete. Since it is a dynamic check, the code must execute to be caught. But unlike the static checks we've been using in cmd/ld, the dynamic check works with function pointers and other indirect calls. For example it caught sigpanic being pushed onto Go stacks in the signal handlers. Fixes #8667. LGTM=khr, iant R=golang-codereviews, khr, iant CC=golang-codereviews, r https://golang.org/cl/133700043
-
Russ Cox authored
Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg.
-
- 05 Sep, 2014 1 commit
-
-
Russ Cox authored
Behavior before this CL: 1. If onM is called on a g0 stack, it just calls the given function. 2. If onM is called on a gsignal stack, it calls badonm. 3. If onM is called on a curg stack, it switches to the g0 stack and then calls the function. In cases 1 and 2, if the program then crashes (and badonm always does), we want to see what called onM, but the traceback stops at onM. In case 3, the traceback must stop at onM, because the g0 stack we are renting really does stop at onM. The current code stops the traceback at onM to handle 3, at the cost of making 1 and 2 crash with incomplete traces. Change traceback to scan past onM but in case 3 make it look like on the rented g0 stack, onM was called from mstart. The traceback already knows that mstart is a top-of-stack function. Alternate fix at CL 132610043 but I think this one is cleaner. This CL makes 3 the exception, while that CL makes 1 and 2 the exception. Submitting TBR to try to get better stack traces out of the freebsd/amd64 builder, but happy to make changes in a followup CL. TBR=khr R=khr CC=golang-codereviews https://golang.org/cl/133620043
-
- 03 Sep, 2014 3 commits
-
-
Russ Cox authored
Because symtab.c was partially converted before, the diffs are not terribly useful. The earlier conversion was trying to refactor or clean up the code in addition to doing the translation. It also made a mistake by redefining Func to be something users could overwrite. I undid those changes, making symtab.go a more literal line-for-line translation of symtab.c instead. LGTM=josharian R=golang-codereviews, dave, bradfitz, josharian CC=golang-codereviews, iant, khr, r https://golang.org/cl/140880043
-
Keith Randall authored
LGTM=rsc R=golang-codereviews, rsc, khr CC=golang-codereviews https://golang.org/cl/139900043
-
Russ Cox authored
They were in proc.c mainly because there was no portable traceback source file. As part of converting them to Go, move to traceback.go. In order to get access to the PC of _rt0_go, rename to runtime.rt0_go. LGTM=r R=golang-codereviews, r CC=dvyukov, golang-codereviews, iant, khr https://golang.org/cl/139110043
-
- 02 Sep, 2014 1 commit
-
-
Russ Cox authored
The two converted files were nearly identical. Instead of continuing that duplication, I merged them into a single traceback.go. Tested on arm, amd64, amd64p32, and 386. LGTM=r R=golang-codereviews, remyoudompheng, dave, r CC=dvyukov, golang-codereviews, iant, khr https://golang.org/cl/134200044
-