1. 28 Apr, 2011 12 commits
    • Russ Cox's avatar
      gc: preserve original expression for errors · 8133cb35
      Russ Cox authored
      Fixes #1722.
      
      R=ken2
      CC=golang-dev
      https://golang.org/cl/4442099
      8133cb35
    • Evan Shaw's avatar
      http: add Header.Write method · f319e1df
      Evan Shaw authored
      R=golang-dev, bradfitz, dsymonds
      CC=golang-dev
      https://golang.org/cl/4426069
      f319e1df
    • Andrew Gerrand's avatar
      tag weekly.2011-04-27 · d2d50f85
      Andrew Gerrand authored
      R=golang-dev
      CC=golang-dev
      https://golang.org/cl/4439081
      d2d50f85
    • Andrew Gerrand's avatar
      weekly.2011-04-27 · 5a8ae387
      Andrew Gerrand authored
      R=rsc
      CC=golang-dev
      https://golang.org/cl/4437077
      5a8ae387
    • Andrew Gerrand's avatar
      200bd0a0
    • Brad Fitzpatrick's avatar
      adler32: speed up ~40% by avoiding bounds checks · ba43be30
      Brad Fitzpatrick authored
      before & after:
      adler32.BenchmarkGolden	  100000	     14747 ns/op
      adler32.BenchmarkGolden	  200000	      8761 ns/op
      
      Found by profiling PNG encoding.
      
      R=rsc, bradfitzwork, eds
      CC=golang-dev
      https://golang.org/cl/4441073
      ba43be30
    • Russ Cox's avatar
      runtime: fix typo in gc bug fix · 37b34940
      Russ Cox authored
      This time for sure.
      
      R=golang-dev, dsymonds
      CC=golang-dev
      https://golang.org/cl/4437078
      37b34940
    • Lorenzo Stoakes's avatar
      gc: correctly handle fields of pointer type to recursive forward references · b6f0632e
      Lorenzo Stoakes authored
      Previously, whether declaring a type which copied the structure of a type it was referenced in via a pointer field would work depended on whether you declared it before or after the type it copied, e.g. type T2 T1; type T1 struct { F *T2 } would work, however type T1 struct { F *T2 }; type T2 T1 wouldn't.
      
      Fixes #667.
      
      R=rsc
      CC=golang-dev
      https://golang.org/cl/4313064
      b6f0632e
    • Russ Cox's avatar
      runtime: stack split + garbage collection bug · 370276a3
      Russ Cox authored
      The g->sched.sp saved stack pointer and the
      g->stackbase and g->stackguard stack bounds
      can change even while "the world is stopped",
      because a goroutine has to call functions (and
      therefore might split its stack) when exiting a
      system call to check whether the world is stopped
      (and if so, wait until the world continues).
      
      That means the garbage collector cannot access
      those values safely (without a race) for goroutines
      executing system calls.  Instead, save a consistent
      triple in g->gcsp, g->gcstack, g->gcguard during
      entersyscall and have the garbage collector refer
      to those.
      
      The old code was occasionally seeing (because of
      the race) an sp and stk that did not correspond to
      each other, so that stk - sp was not the number of
      stack bytes following sp.  In that case, if sp < stk
      then the call scanblock(sp, stk - sp) scanned too
      many bytes (anything between the two pointers,
      which pointed into different allocation blocks).
      If sp > stk then stk - sp wrapped around.
      On 32-bit, stk - sp is a uintptr (uint32) converted
      to int64 in the call to scanblock, so a large (~4G)
      but positive number.  Scanblock would try to scan
      that many bytes and eventually fault accessing
      unmapped memory.  On 64-bit, stk - sp is a uintptr (uint64)
      promoted to int64 in the call to scanblock, so a negative
      number.  Scanblock would not scan anything, possibly
      causing in-use blocks to be freed.
      
      In short, 32-bit platforms would have seen either
      ineffective garbage collection or crashes during garbage
      collection, while 64-bit platforms would have seen
      either ineffective or incorrect garbage collection.
      You can see the invalid arguments to scanblock in the
      stack traces in issue 1620.
      
      Fixes #1620.
      Fixes #1746.
      
      R=iant, r
      CC=golang-dev
      https://golang.org/cl/4437075
      370276a3
    • Russ Cox's avatar
      cgo: handle versioned ELF symbols · 09092a78
      Russ Cox authored
      Fixes #1397.
      
      R=iant
      CC=golang-dev
      https://golang.org/cl/4444064
      09092a78
    • Russ Cox's avatar
      runtime: allow use of >512 MB on 32-bit platforms · 70b0de8e
      Russ Cox authored
      runtime: memory allocated by OS not in usable range
      runtime: out of memory: cannot allocate 1114112-byte block (2138832896 in use)
      throw: out of memory
      
      runtime.throw+0x40 /Users/rsc/g/go/src/pkg/runtime/runtime.c:102
              runtime.throw(0x1fffd, 0x101)
      runtime.mallocgc+0x2af /Users/rsc/g/go/src/pkg/runtime/malloc.c:60
              runtime.mallocgc(0x100004, 0x0, 0x1, 0x1, 0xc093, ...)
      runtime.mal+0x40 /Users/rsc/g/go/src/pkg/runtime/malloc.c:289
              runtime.mal(0x100004, 0x20bc4)
      runtime.new+0x26 /Users/rsc/g/go/src/pkg/runtime/malloc.c:296
              runtime.new(0x100004, 0x8fe84000, 0x20bc4)
      main.main+0x29 /Users/rsc/x.go:11
              main.main()
      runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:93
              runtime.mainstart()
      runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:178
              runtime.goexit()
      ----- goroutine created by -----
      _rt0_386+0xbf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:80
      
      R=iant, r
      CC=golang-dev
      https://golang.org/cl/4444073
      70b0de8e
    • Andrew Gerrand's avatar
      mime/multipart: add ReadForm and associated types · 33ca16d6
      Andrew Gerrand authored
      R=brad_danga_com, rsc, dfc, r, dchest, bradfitz
      CC=golang-dev
      https://golang.org/cl/4439075
      33ca16d6
  2. 27 Apr, 2011 13 commits
  3. 26 Apr, 2011 13 commits
  4. 25 Apr, 2011 2 commits