Skip to content

G
go
Switch branch/tag
  1. 30 Jan, 2019 3 commits
  3. 29 Jan, 2019 4 commits
  5. 28 Jan, 2019 2 commits
  7. 27 Jan, 2019 4 commits
  9. 25 Jan, 2019 2 commits
  11. 23 Jan, 2019 6 commits
  13. 22 Jan, 2019 3 commits
    • Keith Randall's avatar
      cmd/compile: don't bother compiling functions named "_" · 1fb59614
      Keith Randall authored 
      They can't be used, so we don't need code generated for them. We just
need to report errors in their bodies.

This is the minimal CL for 1.12. For 1.13, CL 158845 will remove
a bunch of special cases sprinkled about the compiler to handle "_"
functions, which should (after this CL) be unnecessary.

Update #29870

Change-Id: Iaa1c194bd0017dffdce86589fe2d36726ee83c13
Reviewed-on: https://go-review.googlesource.com/c/158820
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      1fb59614
    • Filippo Valsorda's avatar
      crypto/subtle: normalize constant time ops docs · ef82ecd0
      Filippo Valsorda authored 
      ConstantTimeCompare is fairly useless if you can't rely on it being zero
when the slices are different, but thankfully it has that property
thanks to the final ConstantTimeByteEq.

Change-Id: Id51100ed7d8237abbbb15778a259065b162a48ad
Reviewed-on: https://go-review.googlesource.com/c/158643Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: default avatarAdam Langley <agl@golang.org>
      ef82ecd0
    • Dmitri Shuralyov's avatar
      cmd/go: copy missing bit of documentation about code generated comment · 8d2e65d2
      Dmitri Shuralyov authored 
      This CL attempts to restore the clarity of the original specification
at https://golang.org/s/generatedcode that the line may appear
anywhere. It is preferable (for human readability), and most common
for it to be early in the file, but that is merely a convention, not
a strict well-specified requirement. Document it as so.

Background

Issue #13560 was a proposal define a standard for marking files as
generated, one that is suitable to be recognized both by humans
and machine tools. It was accepted, and the final specification
was documented at https://golang.org/s/generatedcode. Its text,
copied exactly:

	Generated files are marked by a line of text that matches
	the regular expression, in Go syntax:

		^// Code generated .* DO NOT EDIT\.$

	The .* means the tool can put whatever folderol it wants in there,
	but the comment must be a single line and must start with Code generated
	and end with DO NOT EDIT., with a period.

	The text may appear anywhere in the file.

The https://golang.org/s/generatedcode link points to a comment
in a very large GitHub issue. That makes it harder to find.
Issue #25433 was opened about moving that information somewhere else.
It was resolved via CL 118756, which added text to cmd/go documentation
at https://golang.org/cmd/go/#hdr-Generate_Go_files_by_processing_source:

	To convey to humans and machine tools that code is generated,
	generated source should have a line early in the file that
	matches the following regular expression (in Go syntax):

		^// Code generated .* DO NOT EDIT\.$

The CL description noted that "This change merely moves that
information to a more visible place." The intention was to preserve
the specification unmodified.

The original specification was very clear that "The text may appear
anywhere in the file." The new text in cmd/go documentation wasn't
very clear. "A line early in the file" is not a precise enough criteria
to be recognized by a machine tool, because there isn't a precise
definition of what lines are "early in the file".

Updates #13560
Updates #25433
Updates #28089

Change-Id: I4e374163b16c3f972f9591ec2647fd3d5a2dd5ae
Reviewed-on: https://go-review.googlesource.com/c/158817Reviewed-by: default avatarRob Pike <r@golang.org>
      8d2e65d2
  15. 21 Jan, 2019 3 commits
  17. 20 Jan, 2019 2 commits
  19. 18 Jan, 2019 8 commits
  21. 17 Jan, 2019 3 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: default 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: default 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: default avatarAustin Clements <austin@google.com>
      2f99e889
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7