1. 06 Oct, 2011 7 commits
    • Miki Tebeka's avatar
      testing: Add support for running tests in parallel (t.Parallel API). · f80d8fbc
      Miki Tebeka authored
      See discussion at https://groups.google.com/d/topic/golang-dev/RAKiqi44GEU/discussion
      
      R=golang-dev, bradfitz, dvyukov, rogpeppe, r, r, borman
      CC=golang-dev
      https://golang.org/cl/5071044
      f80d8fbc
    • Rob Pike's avatar
      C+A: Miki Tebeka miki.tebeka@gmail.com · cd80d04c
      Rob Pike authored
      R=golang-dev, gri
      CC=golang-dev, miki.tebeka
      https://golang.org/cl/5225042
      cd80d04c
    • Dmitriy Vyukov's avatar
      runtime: faster finalizers · c14b2689
      Dmitriy Vyukov authored
      Linux/amd64, 2 x Intel Xeon E5620, 8 HT cores, 2.40GHz
      benchmark                    old ns/op    new ns/op    delta
      BenchmarkFinalizer              420.00       261.00  -37.86%
      BenchmarkFinalizer-2            985.00       201.00  -79.59%
      BenchmarkFinalizer-4           1077.00       244.00  -77.34%
      BenchmarkFinalizer-8           1155.00       180.00  -84.42%
      BenchmarkFinalizer-16          1182.00       184.00  -84.43%
      
      BenchmarkFinalizerRun          2128.00      1378.00  -35.24%
      BenchmarkFinalizerRun-2        1655.00      1418.00  -14.32%
      BenchmarkFinalizerRun-4        1634.00      1522.00   -6.85%
      BenchmarkFinalizerRun-8        2213.00      1581.00  -28.56%
      BenchmarkFinalizerRun-16       2424.00      1599.00  -34.03%
      
      Darwin/amd64, Intel L9600, 2 cores, 2.13GHz
      benchmark                    old ns/op    new ns/op    delta
      BenchmarkChanCreation          1451.00       926.00  -36.18%
      BenchmarkChanCreation-2        3124.00      1412.00  -54.80%
      BenchmarkChanCreation-4        6121.00      2628.00  -57.07%
      
      BenchmarkFinalizer              684.00       420.00  -38.60%
      BenchmarkFinalizer-2          11195.00       398.00  -96.44%
      BenchmarkFinalizer-4          15862.00       654.00  -95.88%
      
      BenchmarkFinalizerRun          2025.00      1397.00  -31.01%
      BenchmarkFinalizerRun-2        3920.00      1447.00  -63.09%
      BenchmarkFinalizerRun-4        9471.00      1545.00  -83.69%
      
      R=golang-dev, cw, rsc
      CC=golang-dev
      https://golang.org/cl/4963057
      c14b2689
    • Russ Cox's avatar
      runtime: fix malloc sampling bug · ad35cea7
      Russ Cox authored
      The malloc sample trigger was not being set in a
      new m, so the first allocation in each new m - the
      goroutine structure - was being sampled with
      probability 1 instead of probability sizeof(G)/rate,
      an oversampling of about 5000x for the default
      rate of 1 MB.  This bug made pprof graphs show
      far more G allocations than there actually were.
      
      R=golang-dev, r
      CC=golang-dev
      https://golang.org/cl/5224041
      ad35cea7
    • Dmitriy Vyukov's avatar
      runtime: fix spurious deadlock reporting · 56959158
      Dmitriy Vyukov authored
      Fixes #2337.
      Unfortunate sequence of events is:
      1. maxcpu=2, mcpu=1, grunning=1
      2. starttheworld creates an extra M:
         maxcpu=2, mcpu=2, grunning=1
      4. the goroutine calls runtime.GOMAXPROCS(1)
         maxcpu=1, mcpu=2, grunning=1
      5. since it sees mcpu>maxcpu, it calls gosched()
      6. schedule() deschedules the goroutine:
         maxcpu=1, mcpu=1, grunning=0
      7. schedule() call getnextandunlock() which
         fails to pick up the goroutine again,
         because canaddcpu() fails, because mcpu==maxcpu
      8. then it sees that grunning==0,
         reports deadlock and terminates
      
      R=golang-dev, rsc
      CC=golang-dev
      https://golang.org/cl/5191044
      56959158
    • Mikio Hara's avatar
      build: clear execute bit from source files · 504963e6
      Mikio Hara authored
      R=golang-dev, alex.brainman
      CC=golang-dev
      https://golang.org/cl/5201042
      504963e6
    • Wei Guangjing's avatar
      cgo: support for mingw-w64 4.5.1 and newer · e7042418
      Wei Guangjing authored
      R=rsc, jp, hectorchu
      CC=golang-dev
      https://golang.org/cl/4962051
      e7042418
  2. 05 Oct, 2011 18 commits
  3. 04 Oct, 2011 8 commits
    • Paul Borman's avatar
      pkg/syscall: add Mkfifo for linux platforms · 0b534bc9
      Paul Borman authored
      R=golang-dev, bradfitz
      CC=golang-dev
      https://golang.org/cl/5131055
      0b534bc9
    • Brad Fitzpatrick's avatar
      websocket: better error message in a test · c31f987b
      Brad Fitzpatrick authored
      R=golang-dev, dsymonds
      CC=golang-dev
      https://golang.org/cl/5185045
      c31f987b
    • Paul Borman's avatar
      time: make month/day name comparisons case insenstive · 93b8438e
      Paul Borman authored
      Fixes #2324.
      
      R=r, r
      CC=golang-dev
      https://golang.org/cl/5180044
      93b8438e
    • Russ Cox's avatar
      5g, 6g, 8g: fix loop finding bug, squash jmps · e2d326b8
      Russ Cox authored
      The loop recognizer uses the standard dominance
      frontiers but gets confused by dead code, which
      has a (not explicitly set) rpo number of 0, meaning it
      looks like the head of the function, so it dominates
      everything.  If the loop recognizer encounters dead
      code while tracking backward through the graph
      it fails to recognize where it started as a loop, and
      then the optimizer does not registerize values loaded
      inside that loop.  Fix by checking rpo against rpo2r.
      
      Separately, run a quick pass over the generated
      code to squash JMPs to JMP instructions, which
      are convenient to emit during code generation but
      difficult to read when debugging the -S output.
      A side effect of this pass is to eliminate dead code,
      so the output files may be slightly smaller and the
      optimizer may have less work to do.
      There is no semantic effect, because the linkers
      flatten JMP chains and delete dead instructions
      when laying out the final code.  Doing it here too
      just makes the -S output easier to read and more
      like what the final binary will contain.
      
      The "dead code breaks loop finding" bug is thus
      fixed twice over.  It seemed prudent to fix loopit
      separately just in case dead code ever sneaks back
      in for one reason or another.
      
      R=ken2
      CC=golang-dev
      https://golang.org/cl/5190043
      e2d326b8
    • Gustavo Niemeyer's avatar
      path/filepath: added Rel as the complement of Abs · da99a5bc
      Gustavo Niemeyer authored
      R=golang-dev, rsc, gustavo, r, borman
      CC=golang-dev
      https://golang.org/cl/4981049
      da99a5bc
    • Joe Poirier's avatar
      cgo: allow Window's specific path characters in flag directives. · aec89a6d
      Joe Poirier authored
      Example: #cgo windows LDFLAGS: -LC:\\WINDOWS\\system32
      
      R=alex.brainman, go.peter.90, golang-dev, rsc
      CC=golang-dev
      https://golang.org/cl/5154042
      aec89a6d
    • Brad Fitzpatrick's avatar
      Fix build, disabling flaky registerization test. · 2cef85f8
      Brad Fitzpatrick authored
      R=golang-dev, dsymonds
      CC=golang-dev
      https://golang.org/cl/5179045
      2cef85f8
    • Nigel Tao's avatar
      image: spin off a new color package out of the image package. · a2846e65
      Nigel Tao authored
      The spin-off renames some types. The new names are simply better:
      image.Color              -> color.Color
      image.ColorModel         -> color.Model
      image.ColorModelFunc     -> color.ModelFunc
      image.PalettedColorModel -> color.Palette
      image.RGBAColor          -> color.RGBA
      image.RGBAColorModel     -> color.RGBAModel
      image.RGBA64Color        -> color.RGBA64
      image.RGBA64ColorModel   -> color.RGBA64Model
      (similarly for NRGBAColor, GrayColorModel, etc)
      
      The image.ColorImage type stays in the image package, but is renamed:
      image.ColorImage -> image.Uniform
      
      The image.Image implementations (image.RGBA, image.RGBA64, image.NRGBA,
      image.Alpha, etc) do not change their name, and gain a nice symmetry:
      an image.RGBA is an image of color.RGBA, etc.
      
      The image.Black, image.Opaque uniform images remain unchanged (although
      their type is renamed from image.ColorImage to image.Uniform). The
      corresponding color types (color.Black, color.Opaque, etc) are new.
      
      Nothing in the image/ycbcr is renamed yet. The ycbcr.YCbCrColor and
      ycbcr.YCbCrImage types will eventually migrate to color.YCbCr and
      image.YCbCr, but that will be a separate CL.
      
      R=r, bsiegert
      CC=golang-dev
      https://golang.org/cl/5132048
      a2846e65
  4. 03 Oct, 2011 5 commits
  5. 01 Oct, 2011 2 commits