Skip to content

G
go
Switch branch/tag
  1. 05 Aug, 2019 1 commit
  3. 03 Aug, 2019 1 commit
  5. 02 Aug, 2019 8 commits
  7. 01 Aug, 2019 5 commits
  9. 31 Jul, 2019 5 commits
  11. 30 Jul, 2019 6 commits
    • David Ndungu's avatar
      net/http: improve Request.Form and Request.PostForm documentation · 1ad64faf
      David Ndungu authored 
      Request.PostForm gets populated with form data for PATCH, POST, or PUT
http verbs.

Change-Id: I33065aa78a8470c4e9490aac830aa6f5963c61cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/187821Reviewed-by: default avatarEmmanuel Odeke <emm.odeke@gmail.com>
      1ad64faf
    • Bryan C. Mills's avatar
      cmd/go/internal/cache: verify that timestamp is positive · 5f8d8161
      Bryan C. Mills authored 
      An apparent typo caused us to re-check size instead.

Updates #29667

Change-Id: Icc1fb9cef1ba77b8490c8fbe6c343be06ff48d8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/188020
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      5f8d8161
    • Bryan C. Mills's avatar
      cmd/go/internal/cache: avoid ioutil.WriteFile for writing cache entries · 2fc7574a
      Bryan C. Mills authored 
      ioutil.WriteFile always truncates the destination file to 0 before
writing, which is inappropriate for unsynchronized, idempotent,
fixed-size files such as the cache entry files here.

Instead, truncate the file only after writing it, so that a second
write will never (even temporarily!) remove the contents of a
preceding write.

Fixes #29667

Change-Id: I16a53ce79d8a23d23580511cb6abd062f54b65ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/188157
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      2fc7574a
    • Michael Knyszek's avatar
      runtime: call sysHugePage less often · 8c3040d7
      Michael Knyszek authored 
      Currently when we coalesce memory we make a sysHugePage call
(MADV_HUGEPAGE) to ensure freed and coalesced huge pages are treated as
such so the scavenger's assumptions about performance are more in line
with reality.

Unfortunately we do it way too often because we do it if there was any
change to the huge page count for the span we're coalescing into, not
taking into account that it could coalesce with its neighbors and not
actually create a new huge page.

This change makes it so that it only calls sysHugePage if the original
huge page counts between the span to be coalesced into and its neighbors
do not add up (i.e. a new huge page was created due to alignment). Calls
to sysHugePage will now happen much less frequently, as intended.

Updates #32828.

Change-Id: Ia175919cb79b730a658250425f97189e27d7fda3
Reviewed-on: https://go-review.googlesource.com/c/go/+/186926
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarAustin Clements <austin@google.com>
      8c3040d7
    • Michael Anthony Knyszek's avatar
      runtime: add physHugePageShift · a41ebe6e
      Michael Anthony Knyszek authored 
      This change adds physHugePageShift which is defined such that
1 << physHugePageShift == physHugePageSize. The purpose of this variable
is to avoid doing expensive divisions in key functions, such as
(*mspan).hugePages.

This change also does a sweep of any place we might do a division or mod
operation with physHugePageSize and turns it into bit shifts and other
bitwise operations.

Finally, this change adds a check to mallocinit which ensures that
physHugePageSize is always a power of two. osinit might choose to ignore
non-powers-of-two for the value and replace it with zero, but mallocinit
will fail if it's not a power of two (or zero). It also derives
physHugePageShift from physHugePageSize.

This change helps improve the performance of most applications because
of how often (*mspan).hugePages is called.

Updates #32828.

Change-Id: I1a6db113d52d563f59ae8fd4f0e130858859e68f
Reviewed-on: https://go-review.googlesource.com/c/go/+/186598
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarAustin Clements <austin@google.com>
      a41ebe6e
    • Andrew Todd's avatar
      strings: clarify usage of Title and ToTitle · fbb819eb
      Andrew Todd authored 
      This is intended to help clear up confusion around the usage of the
Title and ToTitle functions. It includes a link to define title case
to distinguish it from upper case. It also includes an additional
example for the ToTitle function to showcase the difference in behavior
between it and the Title function.

Fixes #33302

Change-Id: I44e62962fb04d0d22966a39eda3a2d16de7a2291
Reviewed-on: https://go-review.googlesource.com/c/go/+/187825Reviewed-by: default avatarRob Pike <r@golang.org>
      fbb819eb
  13. 29 Jul, 2019 3 commits
  15. 28 Jul, 2019 1 commit
  17. 27 Jul, 2019 2 commits
  19. 23 Jul, 2019 4 commits
  21. 22 Jul, 2019 2 commits
  23. 19 Jul, 2019 2 commits
    • Jay Conrod's avatar
      cmd/go: document go get @upgrade behavior in release notes · f518a96e
      Jay Conrod authored 
      Fixes #33149

Change-Id: If9ff24fea6d087b4047a9f6e50f99f449f9b1c52
Reviewed-on: https://go-review.googlesource.com/c/go/+/186618
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      f518a96e
    • Austin Clements's avatar
      runtime: align allocations harder in GODEBUG=sbrk=1 mode · 5b15510d
      Austin Clements authored 
      Currently, GODEBUG=sbrk=1 mode aligns allocations by their type's
alignment. You would think this would be the right thing to do, but
because 64-bit fields are only 4-byte aligned right now (see #599),
this can cause a 64-bit field of an allocated object to be 4-byte
aligned, but not 8-byte aligned. If there is an atomic access to that
unaligned 64-bit field, it will crash.

This doesn't happen in normal allocation mode because the
size-segregated allocation and the current size classes will cause any
types larger than 8 bytes to be 8 byte aligned.

We fix this by making sbrk=1 mode use alignment based on the type's
size rather than its declared alignment. This matches how the tiny
allocator aligns allocations.

This was tested with

  GOARCH=386 GODEBUG=sbrk=1 go test sync/atomic

This crashes with an unaligned access before this change, and passes
with this change.

This should be reverted when/if we fix #599.

Fixes #33159.

Change-Id: Ifc52c72c6b99c5d370476685271baa43ad907565
Reviewed-on: https://go-review.googlesource.com/c/go/+/186919
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: default avatarKeith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      5b15510d
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7