Skip to content

G
golang
Switch branch/tag
  1. 14 Jun, 2017 10 commits
    • Alberto Donizetti's avatar
      doc: list html/template and text/template changes in 1.9 relnotes · 2c3c8c42
      Alberto Donizetti authored 
      Updates #20587

Change-Id: I3d65a0124157990b302db8879ee1a4941124ea11
Reviewed-on: https://go-review.googlesource.com/45730Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      2c3c8c42
    • Austin Clements's avatar
      runtime: record mutex event before readying · b067ad93
      Austin Clements authored 
      Currently, semrelease1 readies the next waiter before recording a
mutex event. However, if the next waiter is expecting to look at the
mutex profile, as is the case in TestMutexProfile, this may delay
recording the event too much.

Swap the order of these operations so semrelease1 records the mutex
event before readying the next waiter. This also means readying the
next waiter is the very last thing semrelease1 does, which seems
appropriate.

Fixes #19139.

Change-Id: I1a62063599fdb5d49bd86061a180c0a2d659474b
Reviewed-on: https://go-review.googlesource.com/45751
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: 's avatarPeter Weinberger <pjw@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      b067ad93
    • Lynn Boger's avatar
      cmd/link: implement trampolines for ppc64le with ext linking · 738739f5
      Lynn Boger authored 
      When using golang on ppc64le there have been issues
when building executables that generate extremely large text
sections.  This is due to the call instruction and the limitation
on the offset field, which is smaller than most platforms.  If the
size of the call target offset is too big for the offset field in
the call instruction, then link errors can occur.

The original solution to this problem in golang was to split the
text section when it became too large, allowing the external (GNU)
linker to insert the necessary stub to handle the long call.  That
worked fine until the another size limit for the program size was hit,
where a plt_branch was created instead of a long branch.  In that case
the plt_branch code sequence expects r2 to contain the address of the
TOC, but when golang creates dynamic executables by default
(-buildmode=exe) r2 does not always contain the address of the TOC
and as a result when building programs that reach this extremely
large size, a runtime SEGV or SIGILL can occur due to branching to a bad
address.

When using internal linking, trampolines are generated to handle the
long calls but the text sections are not split.  With this change,
text sections will still be split approrpriately with external linking
but if the buildmode being used does not maintain r2 as the TOC
addresses, then trampolines will be created for those calls.

Fixes #20497

Change-Id: If5400b0f86c2c08e106b332be6db0b259b07d93d
Reviewed-on: https://go-review.googlesource.com/45130
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      738739f5
    • Ian Lance Taylor's avatar
      runtime, syscall: reset signal handlers to default in child · df0892cb
      Ian Lance Taylor authored 
      Block all signals during a fork. In the parent process, after the
fork, restore the signal mask. In the child process, reset all
currently handled signals to the default handler, and then restore the
signal mask.

The effect of this is that the child will be operating using the same
signal regime as the program it is about to exec, as exec resets all
non-ignored signals to the default, and preserves the signal mask.

We do this so that in the case of a signal sent to the process group,
the child process will not try to run a signal handler while in the
precarious state after a fork.

Fixes #18600.

Change-Id: I9f39aaa3884035908d687ee323c975f349d5faaa
Reviewed-on: https://go-review.googlesource.com/45471
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarAustin Clements <austin@google.com>
      df0892cb
    • Alan Donovan's avatar
      go/token: use fine-grained locking in FileSet · 17ba830f
      Alan Donovan authored 
      Before, all accesses to the lines and infos tables of each File were
serialized by the lock of the owning FileSet, causing parsers running
in parallel to contend.  Now, each File has its own mutex.

This fixes a data race in (*File).PositionFor, which used to call
f.position then f.unpack without holding the mutex's lock.

Fixes golang/go#18348

Change-Id: Iaa5989b2eba88a7fb2e91c1a0a8bc1e7f6497f2b
Reviewed-on: https://go-review.googlesource.com/34591Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      17ba830f
    • Brad Fitzpatrick's avatar
      doc: add more Go 1.9 notes · 76319222
      Brad Fitzpatrick authored 
      Updates #20587

Change-Id: I7effe922242db45f3ce74882d07511aaaac2f634
Reviewed-on: https://go-review.googlesource.com/45613Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      76319222
    • Josh Bleecher Snyder's avatar
      runtime: speed up stack copying · aafd9640
      Josh Bleecher Snyder authored 
      I was surprised to see readvarint show up in a cpu profile.

Use a few simple optimizations to speed up stack copying:

* Avoid making a copy of the cache.entries array or any of its elements.
* Use a shift instead of a signed division in stackmapdata.
* Change readvarint to return the number of bytes consumed
  rather than an updated slice.
* Make some minor optimizations to readvarint to help the compiler.
* Avoid called readvarint when the value fits in a single byte.

The first and last optimizations are the most significant,
although they all contribute a little.

Add a benchmark for stack copying that includes lots of different
functions in a recursive loop, to bust the cache.

This might speed up other runtime operations as well;
I only benchmarked stack copying.

name                old time/op  new time/op  delta
StackCopy-8         96.4ms ± 2%  82.7ms ± 1%  -14.24%  (p=0.000 n=20+19)
StackCopyNoCache-8   167ms ± 1%   131ms ± 1%  -21.58%  (p=0.000 n=20+20)

Change-Id: I13d5c455c65073c73b656acad86cf8e8e3c9807b
Reviewed-on: https://go-review.googlesource.com/43150
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarAustin Clements <austin@google.com>
      aafd9640
    • Brad Fitzpatrick's avatar
      path, path/filepath: clarify and cross-reference packages · 2f7fbf88
      Brad Fitzpatrick authored 
      The path package has a reference to the path/filepath package, so add
a reverse reference.

And clarify the path package doesn't do Windows paths.

Fixes #20117

Change-Id: I65c5ce24e600b32ea20c5821b744bd89f6aff98c
Reviewed-on: https://go-review.googlesource.com/45653Reviewed-by: 's avatarJaana Burcu Dogan <jbd@google.com>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      2f7fbf88
    • Austin Clements's avatar
      runtime: move pdesc into p · f4f01851
      Austin Clements authored 
      There are currently two arrays indexed by P ID: allp and pdesc.
Consolidate these by moving the pdesc fields into type p so they can
be indexed off allp along with all other per-P state.

For #15131.

Change-Id: Ib6c4e6e7612281a1171ba4a0d62e52fd59e960b4
Reviewed-on: https://go-review.googlesource.com/45572
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      f4f01851
    • Hiroshi Ioka's avatar
      go/printer: handle associated comments for CommentedNode · 0253299a
      Hiroshi Ioka authored 
      Current CommentedNode cannot handle associated comments which satisfy
    node.End() < comment.Pos()

This CL solves it.

Fixes #20635

Change-Id: I58e2e3703999bb38a6ce37112e986c4b1b2eace0
Reviewed-on: https://go-review.googlesource.com/45292
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      0253299a
  3. 13 Jun, 2017 16 commits
  5. 12 Jun, 2017 6 commits
  7. 11 Jun, 2017 1 commit
  9. 09 Jun, 2017 7 commits