An error occurred fetching the project authors.
  1. 21 Apr, 2015 1 commit
    • Austin Clements's avatar
      runtime: multi-threaded, utilization-scheduled background mark · 8d03acce
      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: default avatarRick Hudson <rlh@golang.org>
      8d03acce
  2. 20 Apr, 2015 1 commit
    • Russ Cox's avatar
      runtime: replace func-based write barrier skipping with type-based · 181e26b9
      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: default avatarAustin Clements <austin@google.com>
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      181e26b9
  3. 18 Mar, 2015 1 commit
  4. 16 Mar, 2015 1 commit
  5. 02 Mar, 2015 1 commit
    • Russ Cox's avatar
      runtime: fix traceback of crash before LR is stored · dd82d5e7
      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: default avatarMinux Ma <minux@golang.org>
      dd82d5e7
  6. 26 Feb, 2015 1 commit
    • Matthew Dempsky's avatar
      runtime: simplify CPU profiling code · 3c8a89da
      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: default avatarDmitry Vyukov <dvyukov@google.com>
      3c8a89da
  7. 11 Feb, 2015 1 commit
    • Dmitry Vyukov's avatar
      runtime: never show system goroutines in traceback · 59495e8d
      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: default avatarKeith Randall <khr@golang.org>
      59495e8d
  8. 03 Feb, 2015 2 commits
    • Austin Clements's avatar
      runtime: rearrange framepointer check condition · fc5baec3
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      fc5baec3
    • Austin Clements's avatar
      runtime: use 2*regSize for saved frame pointer check · 67a03fd6
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      67a03fd6
  9. 02 Feb, 2015 1 commit
    • Austin Clements's avatar
      cmd/6g, liblink, runtime: support saving base pointers · 3c0fee10
      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: default avatarRuss Cox <rsc@golang.org>
      3c0fee10
  10. 29 Dec, 2014 1 commit
  11. 28 Dec, 2014 1 commit
  12. 23 Dec, 2014 1 commit
  13. 12 Nov, 2014 1 commit
    • Russ Cox's avatar
      [dev.cc] runtime: delete scalararg, ptrarg; rename onM to systemstack · 656be317
      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
      656be317
  14. 11 Nov, 2014 1 commit
  15. 06 Nov, 2014 1 commit
    • Russ Cox's avatar
      runtime: avoid gentraceback of self on user goroutine stack · 39bcbb35
      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
      39bcbb35
  16. 29 Oct, 2014 1 commit
    • Russ Cox's avatar
      runtime: fix line number in first stack frame in printed stack trace · a22c11b9
      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
      a22c11b9
  17. 30 Sep, 2014 1 commit
  18. 19 Sep, 2014 1 commit
    • Russ Cox's avatar
      runtime: show frames for exported runtime functions · 54245cba
      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
      54245cba
  19. 16 Sep, 2014 1 commit
    • Russ Cox's avatar
      runtime: use traceback to traverse defer structures · f95beae6
      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
      f95beae6
  20. 14 Sep, 2014 1 commit
    • Russ Cox's avatar
      runtime: fix traceback of trap on ARM · d889f5f0
      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
      d889f5f0
  21. 12 Sep, 2014 2 commits
    • Russ Cox's avatar
      runtime: stop scanning stack frames/args conservatively · e844f53a
      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
      e844f53a
    • Russ Cox's avatar
      runtime: look up arg stackmap for makeFuncStub/methodValueStub during traceback · f0d44dbe
      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
      f0d44dbe
  22. 09 Sep, 2014 1 commit
    • Russ Cox's avatar
      runtime: assume precisestack, copystack, StackCopyAlways, ScanStackByFrames · 15b76ad9
      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
      15b76ad9
  23. 08 Sep, 2014 2 commits
    • Russ Cox's avatar
      liblink, runtime: diagnose and fix C code running on Go stack · c81a0ed3
      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
      c81a0ed3
    • Russ Cox's avatar
      build: move package sources from src/pkg to src · c007ce82
      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.
      c007ce82
  24. 05 Sep, 2014 1 commit
    • Russ Cox's avatar
      runtime: do not stop traceback at onM · d16a2ad0
      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
      d16a2ad0
  25. 03 Sep, 2014 3 commits
  26. 02 Sep, 2014 1 commit
    • Russ Cox's avatar
      runtime: convert traceback*.c to Go · fa2af441
      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
      fa2af441