1. 17 Jan, 2019 6 commits
    • Robert Griesemer's avatar
      math/big: document that Rat.SetString accepts _decimal_ float representations · 33caf3be
      Robert Griesemer authored
      Updates #29799.
      
      Change-Id: I267c2c3ba3964e96903954affc248d0c52c4916c
      Reviewed-on: https://go-review.googlesource.com/c/158397Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      33caf3be
    • Michael Anthony Knyszek's avatar
      runtime: don't coalesce scavenged spans with unscavenged spans · 6e9f664b
      Michael Anthony Knyszek authored
      As a result of changes earlier in Go 1.12, the scavenger became much
      more aggressive. In particular, when scavenged and unscavenged spans
      coalesced, they would always become scavenged. This resulted in most
      spans becoming scavenged over time. While this is good for keeping the
      RSS of the program low, it also causes many more undue page faults and
      many more calls to madvise.
      
      For most applications, the impact of this was negligible. But for
      applications that repeatedly grow and shrink the heap by large amounts,
      the overhead can be significant. The overhead was especially obvious on
      older versions of Linux where MADV_FREE isn't available and
      MADV_DONTNEED must be used.
      
      This change makes it so that scavenged spans will never coalesce with
      unscavenged spans. This  results in fewer page faults overall. Aside
      from this, the expected impact of this change is more heap growths on
      average, as span allocations will be less likely to be fulfilled. To
      mitigate this slightly, this change also coalesces spans eagerly after
      scavenging, to at least ensure that all scavenged spans and all
      unscavenged spans are coalesced with each other.
      
      Also, this change adds additional logic in the case where two adjacent
      spans cannot coalesce. In this case, on platforms where the physical
      page size is larger than the runtime's page size, we realign the
      boundary between the two adjacent spans to a physical page boundary. The
      advantage of this approach is that "unscavengable" spans, that is, spans
      which cannot be scavenged because they don't cover at least a single
      physical page are grown to a size where they have a higher likelihood of
      being discovered by the runtime's scavenging mechanisms when they border
      a scavenged span. This helps prevent the runtime from accruing pockets
      of "unscavengable" memory in between scavenged spans, preventing them
      from coalescing.
      
      We specifically choose to apply this logic to all spans because it
      simplifies the code, even though it isn't strictly necessary. The
      expectation is that this change will result in a slight loss in
      performance on platforms where the physical page size is larger than the
      runtime page size.
      
      Update #14045.
      
      Change-Id: I64fd43eac1d6de6f51d7a2ecb72670f10bb12589
      Reviewed-on: https://go-review.googlesource.com/c/158078
      Run-TryBot: Michael Knyszek <mknyszek@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAustin Clements <austin@google.com>
      6e9f664b
    • Michael Anthony Knyszek's avatar
      runtime: de-duplicate coalescing code · 2f99e889
      Michael Anthony Knyszek authored
      Currently the code surrounding coalescing is duplicated between merging
      with the span before the span considered for coalescing and merging with
      the span after. This change factors out the shared portions of these
      codepaths into a local closure which acts as a helper.
      
      Change-Id: I7919fbed3f9a833eafb324a21a4beaa81f2eaa91
      Reviewed-on: https://go-review.googlesource.com/c/158077
      Run-TryBot: Michael Knyszek <mknyszek@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAustin Clements <austin@google.com>
      2f99e889
    • Michael Anthony Knyszek's avatar
      runtime: refactor coalescing into its own method · 79ac638e
      Michael Anthony Knyszek authored
      The coalescing process is complex and in a follow-up change we'll need
      to do it in more than one place, so this change factors out the
      coalescing code in freeSpanLocked into a method on mheap.
      
      Change-Id: Ia266b6cb1157c1b8d3d8a4287b42fbcc032bbf3a
      Reviewed-on: https://go-review.googlesource.com/c/157838
      Run-TryBot: Michael Knyszek <mknyszek@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAustin Clements <austin@google.com>
      79ac638e
    • Austin Clements's avatar
      doc/go1.12: link to ABIInternal design document · e2ff7328
      Austin Clements authored
      The ABI changes should be completely transparent to Go code, but could
      cause linking issues in certain situations involving assembly code
      reaching across package boundaries. If users encounter linking
      problems, point them to the "Compatibility" section of the ABI design
      document, which gives some guidance.
      
      Change-Id: I4156d164562e2ec0de7ae8f9a3631a32ec45b317
      Reviewed-on: https://go-review.googlesource.com/c/158237Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      e2ff7328
    • Ian Lance Taylor's avatar
      testing: report the failing test in a late log panic · 006a5e7d
      Ian Lance Taylor authored
      Updates #29388
      
      Change-Id: Icb0e6048d05fde7a5486b923ff62147edb5c8dac
      Reviewed-on: https://go-review.googlesource.com/c/157617
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: 's avatarDamien Neil <dneil@google.com>
      006a5e7d
  2. 16 Jan, 2019 2 commits
  3. 15 Jan, 2019 5 commits
  4. 14 Jan, 2019 5 commits
  5. 12 Jan, 2019 1 commit
  6. 11 Jan, 2019 2 commits
    • Sebastiaan van Stijn's avatar
      cmd/go: remove note about GOCACHE=off in docs · a2bb68de
      Sebastiaan van Stijn authored
      This patch removes mention of GOCACHE=off from the help/docs.
      It is no longer supported in Go 1.12, per the release notes.
      
      Fixes #29680
      
      Change-Id: I53ab15a62743f2e55ae1d8aa50629b1bf1ae32ad
      GitHub-Last-Rev: 31e904f51dece13645696a87b1164d86c984457f
      GitHub-Pull-Request: golang/go#29681
      Reviewed-on: https://go-review.googlesource.com/c/157517
      Run-TryBot: Elias Naur <elias.naur@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBryan C. Mills <bcmills@google.com>
      a2bb68de
    • Austin Clements's avatar
      cmd/compile: separate data and function LSyms · a2e79571
      Austin Clements authored
      Currently, obj.Ctxt's symbol table does not distinguish between ABI0
      and ABIInternal symbols. This is *almost* okay, since a given symbol
      name in the final object file is only going to belong to one ABI or
      the other, but it requires that the compiler mark a Sym as being a
      function symbol before it retrieves its LSym. If it retrieves the LSym
      first, that LSym will be created as ABI0, and later marking the Sym as
      a function symbol won't change the LSym's ABI.
      
      Marking a Sym as a function symbol before looking up its LSym sounds
      easy, except Syms have a dual purpose: they are used just as interned
      strings (every function, variable, parameter, etc with the same
      textual name shares a Sym), and *also* to store state for whatever
      package global has that name. As a result, it's easy to slip up and
      look up an LSym when a Sym is serving as the name of a local variable,
      and then later mark it as a function when it's serving as the global
      with the name.
      
      In general, we were careful to avoid this, but #29610 demonstrates one
      case where we messed up. Because of on-demand importing from indexed
      export data, it's possible to compile a method wrapper for a type
      imported from another package before importing an init function from
      that package. If the argument of the method is named "init", the
      "init" LSym will be created as a data symbol when compiling the
      wrapper, before it gets marked as a function symbol.
      
      To fix this, we separate obj.Ctxt's symbol tables for ABI0 and
      ABIInternal symbols. This way, the compiler will simply get a
      different LSym once the Sym takes on its package-global meaning as a
      function.
      
      This fixes the above ordering issue, and means we no longer need to go
      out of our way to create the "init" function early and mark it as a
      function symbol.
      
      Fixes #29610.
      Updates #27539.
      
      Change-Id: Id9458b40017893d46ef9e4a3f9b47fc49e1ce8df
      Reviewed-on: https://go-review.googlesource.com/c/157017
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      a2e79571
  7. 10 Jan, 2019 5 commits
  8. 09 Jan, 2019 10 commits
  9. 08 Jan, 2019 4 commits