Skip to content

G
golang
Switch branch/tag
  1. 01 Nov, 2016 30 commits
  3. 31 Oct, 2016 10 commits
    • Matthew Dempsky's avatar
      cmd/compile: move parser.go remnants into noder.go · 2d4d22af
      Matthew Dempsky authored 
      Change-Id: I54f8788a4703283b9aa3904e2e610097ac3e3586
Reviewed-on: https://go-review.googlesource.com/32471
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      2d4d22af
    • Austin Clements's avatar
      runtime: perform write barriers on direct channel receive · f2d05389
      Austin Clements authored 
      Currently we have write barriers for direct channel sends, where the
receiver is blocked and the sender is writing directly to the
receiver's stack; but not for direct channel receives, where the
sender is blocked and the receiver is reading directly from the
sender's stack.

This was okay with the old write barrier because either 1) the
receiver would write the received pointer into the heap (causing it to
be shaded), 2) the pointer would still be on the receiver's stack at
mark termination and we would rescan it, or 3) the receiver dropped
the pointer so it wasn't necessarily reachable anyway.

This is not okay with the write barrier because it lets a grey stack
send a white pointer to a black stack and then remove it from its own
stack. If the grey stack was the sole grey-protector of this pointer,
this hides the object from the garbage collector.

Fix this by making direct receives perform a stack-to-stack write
barrier just like direct sends do.

Fixes #17694.

Change-Id: I1a4cb904e4138d2ac22f96a3e986635534a5ae41
Reviewed-on: https://go-review.googlesource.com/32450Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      f2d05389
    • Dhananjay Nakrani's avatar
      cmd/compile: avoid nil-ing out a node's Type in typecheckcomplit() on error · 9a8bf2d6
      Dhananjay Nakrani authored 
      typecheckcomplit nils out node's type, upon finding new errors.
This hides new errors in children's node as well as the type info
of current node. This change fixes that.

Fixes #17645.

Change-Id: Ib473291f31c7e8fa0307cb1d494e0c112ddd3583
Reviewed-on: https://go-review.googlesource.com/32324Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      9a8bf2d6
    • Austin Clements's avatar
      runtime: make assists perform root jobs · d35dfd40
      Austin Clements authored 
      Currently, assists can only perform heap marking jobs. However, at the
beginning of GC, there are only root jobs and no heap marking jobs. As
a result, there's often a period at the beginning of a GC cycle where
no goroutine has accumulated assist credit, but at the same time it
can't get any credit because there are no heap marking jobs for it to
do yet. As a result, many goroutines often block on the assist queue
at the very beginning of the GC cycle.

This commit fixes this by allowing assists to perform root marking
jobs. The tricky part of this (and the reason we haven't done this
before) is that stack scanning jobs can lead to deadlocks if the
goroutines performing the stack scanning are themselves
non-preemptible, since two non-preemptible goroutines may try to scan
each other. To address this, we use the same insight d6625caf used to
simplify the mark worker stack scanning: as long as we're careful with
the stacks and only drain jobs while on the system stack, we can put
the goroutine into a preemptible state while we drain jobs. This means
an assist's user stack can be scanned while it continues to do work.

This reduces the rate of assist blocking in the x/benchmarks HTTP
benchmark by a factor of 3 and all remaining blocking happens towards
the *end* of the GC cycle, when there may genuinely not be enough work
to go around.

Ideally, assists would get credit for working on root jobs. Currently
they do not; however, this change prioritizes heap work over root jobs
in assists, so they're likely to mostly perform heap work. In contrast
with mark workers, for assists, the root jobs act only as a backstop
to create heap work when there isn't enough heap work.

Fixes #15361.

Change-Id: If6e169863e4ad75710b0c8dc00f6125b41e9a595
Reviewed-on: https://go-review.googlesource.com/32432Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      d35dfd40
    • Austin Clements's avatar
      runtime: lift systemstack part of gcAssistAlloc · f9e1adb7
      Austin Clements authored 
      This lifts the part of gcAssistAlloc that runs on the system stack to
its own function in preparation for letting assists perform root jobs
(notably stack scanning). This makes it easy to see that there are no
references to the user stack once we've entered gcAssistAlloc1, which
means it's safe to shrink the stack while in gcAssistAlloc1.

This does not yet make assists perform root jobs, so it's not actually
possible for the stack to shrink yet. That will happen in the next
commit.

The code in gcAssistAlloc1 is identical to the code that's currently
passed in a closure to systemstack with one exception. Currently, we
set the "completed" variable in the enclosing scope to indicate that
the assist completed the mark phase. This is exactly the sort of
cross-stack reference lifting this function is meant to prevent. We
replace this variable with setting gp.param to nil or non-nil to
indicate the completion status.

Updates #15361.

Change-Id: Iba7cfb758c781070a441aea86c0117b399a24dbd
Reviewed-on: https://go-review.googlesource.com/32431
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      f9e1adb7
    • Robert Griesemer's avatar
      go/types: basic Defs/Uses test for aliases · cba0957a
      Robert Griesemer authored 
      Change-Id: I113ea712838511ee823375d9ea059089195414f5
Reviewed-on: https://go-review.googlesource.com/32449
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarAlan Donovan <adonovan@google.com>
      cba0957a
    • Jaana Burcu Dogan's avatar
      doc: replace code.google.com/p/sitesearch with its new destination · 9dba3387
      Jaana Burcu Dogan authored 
      Fixes #16910.

Change-Id: I0e97e88bee0361cd3621cacd1d4b84e6e42af718
Reviewed-on: https://go-review.googlesource.com/32424Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      9dba3387
    • Robert Griesemer's avatar
      go/types: implement missing String method for Alias object · a42ba23d
      Robert Griesemer authored 
      Change-Id: Iba5cfa033483b843dbd3681ffad50b117cced4a7
Reviewed-on: https://go-review.googlesource.com/32448Reviewed-by: 's avatarAlan Donovan <adonovan@google.com>
      a42ba23d
    • Dhananjay Nakrani's avatar
      cmd/compile: initialize Decldepth in all cases · f46239b8
      Dhananjay Nakrani authored 
      Previously, on encountering Func.Nname.Type == nil, typecheckfunc()
returned without initializing Decldepth for that func. This causes
typecheckclosure() to fatal. This change ensures that we initialize
Decldepth in all cases.

Fixes #17588.

Change-Id: I2e3c81ad52e8383395025388989e8dbf03438b68
Reviewed-on: https://go-review.googlesource.com/32415Reviewed-by: 's avatarJosh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      f46239b8
    • Keith Randall's avatar
      cmd/compile: make [0]T and [1]T SSAable types · 74144506
      Keith Randall authored 
      We used to have to keep on-stack copies of these types.
Now they can be registerized.

[0]T is kind of trivial but might as well handle it.

This change enables another change I'm working on to improve how x.(T)
expressions are handled (#17405).  This CL helps because now all
types that are direct interface types are registerizeable (e.g. [1]*byte).

No higher-degree arrays for now because non-constant indexes are hard.

Update #17405

Change-Id: I2399940965d17b3969ae66f6fe447a8cefdd6edd
Reviewed-on: https://go-review.googlesource.com/32416
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      74144506