Skip to content

G
golang
Switch branch/tag
  1. 17 Oct, 2016 29 commits
  3. 16 Oct, 2016 6 commits
  5. 15 Oct, 2016 5 commits
    • Austin Clements's avatar
      test: simplify fixedbugs/issue15747.go · ad5fd287
      Austin Clements authored 
      The error check patterns in this test are more complex than necessary
because f2 gets inlined into f1. This behavior isn't important to the
test, so disable inlining of f2 and simplify the error check patterns.

Change-Id: Ia8aee92a52f9217ad71b89b2931494047e8d2185
Reviewed-on: https://go-review.googlesource.com/31132
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      ad5fd287
    • Austin Clements's avatar
      runtime: use more go:nowritebarrierrec in proc.go · 9897e408
      Austin Clements authored 
      Currently we use go:nowritebarrier in many places in proc.go.
go:notinheap and go:yeswritebarrierrec now let us use
go:nowritebarrierrec (the recursive form of the go:nowritebarrier
pragma) more liberally. Do so in proc.go

Change-Id: Ia7fcbc12ce6c51cb24730bf835fb7634ad53462f
Reviewed-on: https://go-review.googlesource.com/30942Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      9897e408
    • Austin Clements's avatar
      runtime: mark several types go:notinheap · 1bc6be64
      Austin Clements authored 
      This covers basically all sysAlloc'd, persistentalloc'd, and
fixalloc'd types.

Change-Id: I0487c887c2a0ade5e33d4c4c12d837e97468e66b
Reviewed-on: https://go-review.googlesource.com/30941Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      1bc6be64
    • Austin Clements's avatar
      runtime: make mSpanList more go:notinheap-friendly · 991a85c8
      Austin Clements authored 
      Currently mspan links to its previous mspan using a **mspan field that
points to the previous span's next field. This simplifies some of the
list manipulation code, but is going to make it very hard to convince
the compiler that mspan list manipulations don't need write barriers.

Fix this by using a more traditional ("boring") linked list that uses
a simple *mspan pointer to the previous mspan. This complicates some
of the list manipulation slightly, but it will let us eliminate all
write barriers from the mspan list manipulation code by marking mspan
go:notinheap.

Change-Id: I0d0b212db5f20002435d2a0ed2efc8aa0364b905
Reviewed-on: https://go-review.googlesource.com/30940Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      991a85c8
    • Austin Clements's avatar
      cmd/compile: add go:notinheap type pragma · 77527a31
      Austin Clements authored 
      This adds a //go:notinheap pragma for declarations of types that must
not be heap allocated. We ensure these rules by disallowing new(T),
make([]T), append([]T), or implicit allocation of T, by disallowing
conversions to notinheap types, and by propagating notinheap to any
struct or array that contains notinheap elements.

The utility of this pragma is that we can eliminate write barriers for
writes to pointers to go:notinheap types, since the write barrier is
guaranteed to be a no-op. This will let us mark several scheduler and
memory allocator structures as go:notinheap, which will let us
disallow write barriers in the scheduler and memory allocator much
more thoroughly and also eliminate some problematic hybrid write
barriers.

This also makes go:nowritebarrierrec and go:yeswritebarrierrec much
more powerful. Currently we use go:nowritebarrier all over the place,
but it's almost never what you actually want: when write barriers are
illegal, they're typically illegal for a whole dynamic scope. Partly
this is because go:nowritebarrier has been around longer, but it's
also because go:nowritebarrierrec couldn't be used in situations that
had no-op write barriers or where some nested scope did allow write
barriers. go:notinheap eliminates many no-op write barriers and
go:yeswritebarrierrec makes it possible to opt back in to write
barriers, so these two changes will let us use go:nowritebarrierrec
far more liberally.

This updates #13386, which is about controlling pointers from non-GC'd
memory to GC'd memory. That would require some additional pragma (or
pragmas), but could build on this pragma.

Change-Id: I6314f8f4181535dd166887c9ec239977b54940bd
Reviewed-on: https://go-review.googlesource.com/30939Reviewed-by: 's avatarKeith Randall <khr@golang.org>
Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      77527a31