An error occurred fetching the project authors.
  1. 25 Feb, 2015 3 commits
  2. 20 Feb, 2015 3 commits
  3. 19 Feb, 2015 6 commits
    • Russ Cox's avatar
      runtime: do not unmap work.spans until after checkmark phase · 5254b7e9
      Russ Cox authored
      This is causing crashes.
      
      Change-Id: I1832f33d114bc29894e491dd2baac45d7ab3a50d
      Reviewed-on: https://go-review.googlesource.com/5330Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      5254b7e9
    • Russ Cox's avatar
      runtime: missed change from reorganization CL · 6c4b54f4
      Russ Cox authored
      That is, I accidentally dropped this change of Austin's
      when preparing my CL. I blame Git.
      
      Change-Id: I9dd772c84edefad96c4b16785fdd2dea04a4a0d6
      Reviewed-on: https://go-review.googlesource.com/5320Reviewed-by: default avatarAustin Clements <austin@google.com>
      6c4b54f4
    • Russ Cox's avatar
      runtime: reorganize memory code · 484f801f
      Russ Cox authored
      Move code from malloc1.go, malloc2.go, mem.go, mgc0.go into
      appropriate locations.
      
      Factor mgc.go into mgc.go, mgcmark.go, mgcsweep.go, mstats.go.
      
      A lot of this code was in certain files because the right place was in
      a C file but it was written in Go, or vice versa. This is one step toward
      making things actually well-organized again.
      
      Change-Id: I6741deb88a7cfb1c17ffe0bcca3989e10207968f
      Reviewed-on: https://go-review.googlesource.com/5300Reviewed-by: default avatarAustin Clements <austin@google.com>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      484f801f
    • Austin Clements's avatar
      runtime: switch to gcWork abstraction · 02dcdba7
      Austin Clements authored
      This converts the garbage collector from directly manipulating work
      buffers to using the new gcWork abstraction.
      
      The previous management of work buffers was rather ad hoc.  As a
      result, switching to the gcWork abstraction changes many details of
      work buffer management.
      
      If greyobject fills a work buffer, it can now pull from work.partial
      in addition to work.empty.
      
      Previously, gcDrain started with a partial or empty work buffer and
      fetched an empty work buffer if it filled its current buffer (in
      greyobject).  Now, gcDrain starts with a full work buffer and fetches
      an partial or empty work buffer if it fills its current buffer (in
      greyobject).  The original behavior was bad because gcDrain would
      immediately drop the empty work buffer returned by greyobject and
      fetch a full work buffer, which greyobject was likely to immediately
      overflow, fetching another empty work buffer, etc.  The new behavior
      isn't great at the start because greyobject is likely to immediately
      overflow the full buffer, but the steady-state behavior should be more
      stable.  Both before and after this change, gcDrain fetches a full
      work buffer if it drains its current buffer.  Basically all of these
      choices are bad; the right answer is to use a dual work buffer scheme.
      
      Previously, shade always fetched a work buffer (though usually from
      m.currentwbuf), even if the object was already marked.  Now it only
      fetches a work buffer if it actually greys an object.
      
      Change-Id: I8b880ed660eb63135236fa5d5678f0c1c041881f
      Reviewed-on: https://go-review.googlesource.com/5232Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      02dcdba7
    • Austin Clements's avatar
      runtime: introduce higher-level GC work abstraction · b30d19de
      Austin Clements authored
      This introduces a producer/consumer abstraction for GC work pointers
      that internally handles the details of filling, draining, and
      shuffling work buffers.
      
      In addition to simplifying the GC code, this should make it easy for
      us to change how we use work buffers, including cleaning up how we use
      the work.partial queue, reintroducing a FIFO lookahead cache, adding
      prefetching, and using dual buffers to avoid flapping.
      
      This commit doesn't change any existing code.  The following commit
      will switch the garbage collector from explicit workbuf manipulation
      to gcWork.
      
      Change-Id: Ifbfe5fff45bf0362d6d7c3cecb061f0c9874077d
      Reviewed-on: https://go-review.googlesource.com/5231Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      b30d19de
    • Austin Clements's avatar
      runtime: make gcDrainN take an int instead of uintptr · 1ae124b5
      Austin Clements authored
      Nit.  There's no reason to take a uintptr and doing so just requires
      casts in annoying places.
      
      Change-Id: Ifeb9638c6d94eae619c490930cf724cc315680ba
      Reviewed-on: https://go-review.googlesource.com/5230Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      1ae124b5
  4. 13 Feb, 2015 6 commits
  5. 12 Feb, 2015 1 commit
  6. 11 Feb, 2015 1 commit
  7. 02 Feb, 2015 2 commits
  8. 29 Jan, 2015 1 commit
  9. 28 Jan, 2015 3 commits
  10. 21 Jan, 2015 1 commit
  11. 20 Jan, 2015 1 commit
  12. 19 Jan, 2015 2 commits
    • Russ Cox's avatar
      runtime: factor out bitmap, finalizer code from malloc/mgc · 3965d750
      Russ Cox authored
      The code in mfinal.go is moved from malloc*.go and mgc*.go
      and substantially unchanged.
      
      The code in mbitmap.go is also moved from those files, but
      cleaned up so that it can be called from those files (in most cases
      the code being moved was not already a standalone function).
      I also renamed the constants and wrote comments describing
      the format. The result is a significant cleanup and isolation of
      the bitmap code, but, roughly speaking, it should be treated
      and reviewed as new code.
      
      The other files changed only as much as necessary to support
      this code movement.
      
      This CL does NOT change the semantics of the heap or type
      bitmaps at all, although there are now some obvious opportunities
      to do so in followup CLs.
      
      Change-Id: I41b8d5de87ad1d3cd322709931ab25e659dbb21d
      Reviewed-on: https://go-review.googlesource.com/2991Reviewed-by: default avatarKeith Randall <khr@golang.org>
      3965d750
    • Russ Cox's avatar
      runtime: move write barrier code into mbarrier.go · 4d226dfe
      Russ Cox authored
      I also added new comments at the top of mbarrier.go,
      but the rest of the code is just copy-and-paste.
      
      Change-Id: Iaeb2b12f8b1eaa33dbff5c2de676ca902bfddf2e
      Reviewed-on: https://go-review.googlesource.com/2990Reviewed-by: default avatarAustin Clements <austin@google.com>
      4d226dfe
  13. 14 Jan, 2015 3 commits
  14. 12 Jan, 2015 1 commit
    • Austin Clements's avatar
      runtime: add GODEBUG=gccheckmark=0/1 · 654297cb
      Austin Clements authored
      Previously, gccheckmark could only be enabled or disabled by calling
      runtime.GCcheckmarkenable/GCcheckmarkdisable.  This was a necessary
      hack because GODEBUG was broken.
      
      Now that GODEBUG works again, move control over gccheckmark to a
      GODEBUG variable and remove these runtime functions.  Currently,
      gccheckmark is enabled by default (and will probably remain so for
      much of the 1.5 development cycle).
      
      Change-Id: I2bc6f30c21b795264edf7dbb6bd7354b050673ab
      Reviewed-on: https://go-review.googlesource.com/2603Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      654297cb
  15. 08 Jan, 2015 1 commit
    • Rick Hudson's avatar
      runtime: increase GC concurrency. · db7fd1c1
      Rick Hudson authored
      run GC in its own background goroutine making the
      caller runnable if resources are available. This is
      critical in single goroutine applications.
      Allow goroutines that allocate a lot to help out
      the GC and in doing so throttle their own allocation.
      Adjust test so that it only detects that a GC is run
      during init calls and not whether the GC is memory
      efficient. Memory efficiency work will happen later
      in 1.5.
      
      Change-Id: I4306f5e377bb47c69bda1aedba66164f12b20c2b
      Reviewed-on: https://go-review.googlesource.com/2349Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      db7fd1c1
  16. 06 Jan, 2015 2 commits
    • Russ Cox's avatar
      runtime: fix two garbage collector bugs · 02f89331
      Russ Cox authored
      First, call clearcheckmarks immediately after changing checkmark,
      so that there is less time when the checkmark flag and the bitmap
      are inconsistent. The tiny gap between the two lines is fine, because
      the world is stopped. Before, the gap was much larger and included
      such code as "go bgsweep()", which allocated.
      
      Second, modify gcphase only when the world is stopped.
      As written, gcscan_m was changing gcphase from 0 to GCscan
      and back to 0 while other goroutines were running.
      Another goroutine running at the same time might decide to
      sleep, see GCscan, call gcphasework, and start "helping" by
      scanning its stack. That's fine, except that if gcphase flips back
      to 0 as the goroutine calls scanblock, it will start draining the
      work buffers prematurely.
      
      Both of these were found wbshadow=2 (and a lot of hard work).
      Eventually that will run automatically, but right now it still
      doesn't quite work for all.bash, due to mmap conflicts with
      pthread-created threads.
      
      Change-Id: I99aa8210cff9c6e7d0a1b62c75be32a23321897b
      Reviewed-on: https://go-review.googlesource.com/2340Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      02f89331
    • Russ Cox's avatar
      runtime: add GODEBUG wbshadow for finding missing write barriers · dcec123a
      Russ Cox authored
      This is the detection code. It works well enough that I know of
      a handful of missing write barriers. However, those are subtle
      enough that I'll address them in separate followup CLs.
      
      GODEBUG=wbshadow=1 checks for a write that bypassed the
      write barrier at the next write barrier of the same word.
      If a bug can be detected in this mode it is typically easy to
      understand, since the crash says quite clearly what kind of
      word has missed a write barrier.
      
      GODEBUG=wbshadow=2 adds a check of the write barrier
      shadow copy during garbage collection. Bugs detected at
      garbage collection can be difficult to understand, because
      there is no context for what the found word means.
      Typically you have to reproduce the problem with allocfreetrace=1
      in order to understand the type of the badly updated word.
      
      Change-Id: If863837308e7c50d96b5bdc7d65af4969bf53a6e
      Reviewed-on: https://go-review.googlesource.com/2061Reviewed-by: default avatarAustin Clements <austin@google.com>
      dcec123a
  17. 29 Dec, 2014 1 commit
  18. 28 Dec, 2014 1 commit
  19. 12 Dec, 2014 1 commit