Skip to content

G
golang
Switch branch/tag
  1. 20 Feb, 2018 3 commits
  3. 19 Feb, 2018 9 commits
    • Alberto Donizetti's avatar
      encoding/xml: simplify slice-growing logic in rawToken · 252ee909
      Alberto Donizetti authored 
      It appears that old code (from 2009) in xml.(*Decoder).rawToken
replicates append's slice-growing functionality by allocating a new,
bigger backing array and then calling copy.

Simplifying the code by replacing it with a single append call does
not seem to hurt performance:

name         old time/op    new time/op    delta
Marshal-4      11.2µs ± 1%    11.3µs ±10%    ~     (p=0.069 n=19+17)
Unmarshal-4    28.6µs ± 1%    28.4µs ± 1%  -0.60%  (p=0.000 n=20+18)

name         old alloc/op   new alloc/op   delta
Marshal-4      5.78kB ± 0%    5.78kB ± 0%    ~     (all equal)
Unmarshal-4    8.61kB ± 0%    8.27kB ± 0%  -3.90%  (p=0.000 n=20+20)

name         old allocs/op  new allocs/op  delta
Marshal-4        23.0 ± 0%      23.0 ± 0%    ~     (all equal)
Unmarshal-4       189 ± 0%       190 ± 0%  +0.53%  (p=0.000 n=20+20)

Change-Id: Ie580d1216a44760e611e63dee2c339af5465aea5
Reviewed-on: https://go-review.googlesource.com/86655Reviewed-by: 's avatarDaniel Martí <mvdan@mvdan.cc>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      252ee909
    • Ahmet Soormally's avatar
      regexp: dont use builtin type as variable name · bb355ed5
      Ahmet Soormally authored 
      The existing implementation declares a variable error which collides
with builting type error.

This change simply renames error variable to err.

Change-Id: Ib56c2530f37f53ec70fdebb825a432d4c550cd04
Reviewed-on: https://go-review.googlesource.com/87775Reviewed-by: 's avatarDaniel Martí <mvdan@mvdan.cc>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
      bb355ed5
    • Daniel Martí's avatar
      text/template: remove associate's error return · eb5925f5
      Daniel Martí authored 
      It's always nil, so simplify its signature. Found with unparam.

Change-Id: I45dd0f868ec2f5de98a970776be686417c8d73b6
Reviewed-on: https://go-review.googlesource.com/95235
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      eb5925f5
    • Keith Randall's avatar
      cmd/compile: add | operator to make rewrite rules more succinct · b657c002
      Keith Randall authored 
      Instead of

(And64 x x) -> x
(And32 x x) -> x
(And16 x x) -> x
(And8  x x) -> x

we can now do:

(And(64|32|16|8) x x) -> x

Any part of an opcode can have a parenthesized, |-separated list of possibilites.
The rule is then expanded using each piece of the | combo.
If there are multiple | clauses, they get expanded in tandem.
(All the first positions, then all the second positions, etc.)
All places | opcodes appear must have the same count.

A more complicated example:

(MOV(L|SS)load [off1] {sym1} (LEAQ4 [off2] {sym2} ptr idx) mem) && is32Bit(off1+off2) && canMergeSym(sym1, sym2) ->
	(MOV(L|SS)loadidx4 [off1+off2] {mergeSym(sym1,sym2)} ptr idx mem)

This meta-rule generates 2 rules, a MOVL and a MOVSS rule.

This CL is carefully orchestrated to not change the generated rules file at all.
In some cases, this means we can't align the rules nicely because it changes
the whitespace in the generated code.  I'll clean that up as a separate step.

There are many more opportunites to compactify rules using this new mechanism.
I've just done some examples, there's more to do.

Change-Id: I8a5e748cd0761ccbb12d09b01925b2f1f4b2f608
Reviewed-on: https://go-review.googlesource.com/86595
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      b657c002
    • Daniel Martí's avatar
      all: add more uses of stringer · 60cf9ec6
      Daniel Martí authored 
      By grepping for ]string{$, one can find many manual implementations of
stringer. The debug/dwarf ones needed the new -trimprefix flag, too.

html/template was fairly simple, just implementing the fallback as
stringer would. The changes there are trivial.

The ones in debug/dwarf needed a bit of extra logic since the GoString
wants to use its own format, depending on whether or not the value is
one of the known constants.

Change-Id: I501ea7deaa538fa425c8e9c2bb895f480169273f
Reviewed-on: https://go-review.googlesource.com/77253
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      60cf9ec6
    • Daniel Martí's avatar
      text/template: differentiate nil from missing arg · 3cb54c86
      Daniel Martí authored 
      reflect.Value is a struct and does not have a kind nor any flag for
untyped nils. As a result, it is tricky to differentiate when we're
missing a value, from when we have one but it is untyped nil.

We could start using *reflect.Value instead, to add one level of
indirection, using nil for missing values and new(reflect.Value) for
untyped nils. However, that is a fairly invasive change, and would also
mean unnecessary allocations.

Instead, use a special reflect.Value that depicts when a value is
missing. This is the case for the "final" reflect.Value in multiple
scenarios, such as the start of a pipeline. Give it a specific,
unexported type too, to make sure it cannot be mistaken for any other
valid value.

Finally, replace "final.IsValid()" with "final != missingVal", since
final.IsValid() will be false when final is an untyped nil.

Also add a few test cases, all different variants of the untyped nil
versus missing value scenario.

Fixes #18716.

Change-Id: Ia9257a84660ead5a7007fd1cced7782760b62d9d
Reviewed-on: https://go-review.googlesource.com/95215
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRob Pike <r@golang.org>
      3cb54c86
    • Daniel Martí's avatar
      html/template: remove unused func · a95c5f04
      Daniel Martí authored 
      Noticed while reading some code.

Change-Id: I63f8c7a453d4895583a8ffc13bec57385b6944aa
Reviewed-on: https://go-review.googlesource.com/95195
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      a95c5f04
    • Martin Möhrmann's avatar
      runtime: avoid clearing memory during byte slice allocation in gobytes · dfb0e4f6
      Martin Möhrmann authored 
      Avoid using make in gobytes which clears the byte slice backing
array unnecessarily since the content is overwritten immediately again.

Check that the user provided length is positive and below the maximum
allowed allocation size explicitly in gobytes as this was done in makeslice
before this change.

Fixes #23634

Change-Id: Id852619e932aabfc468871c42ad07d34da91f45c
Reviewed-on: https://go-review.googlesource.com/94760
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      dfb0e4f6
    • Yazen2017's avatar
      doc: improve clarity of map index examples · a4e950ec
      Yazen2017 authored 
      The fourth example for map indexing states you have a map of type [K]V
and attempts to read in a variable of type T.  Further, the example
is meant to showcase the boolean return variable saying whether the
map contained a key, but overrides to type T.  This will not compile.

Changed last updated date to February 18

Fixes: #23895

Change-Id: I63c52adbcd989afd4855e329e6c727f4c01f7881
Reviewed-on: https://go-review.googlesource.com/94906Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      a4e950ec
  5. 18 Feb, 2018 2 commits
  7. 17 Feb, 2018 9 commits
  9. 16 Feb, 2018 7 commits
  11. 15 Feb, 2018 10 commits
    • Balaram Makam's avatar
      cmd/compile: arm64 intrinsics for math/bits.OnesCount · fcba0514
      Balaram Makam authored 
      This adds math/bits intrinsics for OnesCount on arm64.

name         old time/op  new time/op  delta
OnesCount    3.81ns ± 0%  1.60ns ± 0%  -57.96%  (p=0.000 n=7+8)
OnesCount8   1.60ns ± 0%  1.60ns ± 0%     ~     (all equal)
OnesCount16  2.41ns ± 0%  1.60ns ± 0%  -33.61%  (p=0.000 n=8+8)
OnesCount32  4.17ns ± 0%  1.60ns ± 0%  -61.58%  (p=0.000 n=8+8)
OnesCount64  3.80ns ± 0%  1.60ns ± 0%  -57.84%  (p=0.000 n=8+8)

Update #18616

Conflicts:
	src/cmd/compile/internal/gc/asm_test.go

Change-Id: I63ac2f63acafdb1f60656ab8a56be0b326eec5cb
Reviewed-on: https://go-review.googlesource.com/90835
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      fcba0514
    • Matthew Dempsky's avatar
      cmd/compile/internal/gc: use functype instead of OTFUNC · c26fac88
      Matthew Dempsky authored 
      Slightly simpler.

Change-Id: Ic3a96675c56cc8c2e336b932536c2247f8cbb96d
Reviewed-on: https://go-review.googlesource.com/39996
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      c26fac88
    • Austin Clements's avatar
      runtime: replace _MaxMem with maxAlloc · d7691d05
      Austin Clements authored 
      Now that we have memLimit, also having _MaxMem is a bit confusing.

Replace it with maxAlloc, which better conveys what it limits. We also
define maxAlloc slightly differently: since it's now clear that it
limits allocation size, we can account for a subtle difference between
32-bit and 64-bit.

Change-Id: Iac39048018cc0dae7f0919e25185fee4b3eed529
Reviewed-on: https://go-review.googlesource.com/85890
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      d7691d05
    • Austin Clements's avatar
      runtime: move comment about address space sizes to malloc.go · 90666b8a
      Austin Clements authored 
      Currently there's a detailed comment in lfstack_64bit.go about address
space limitations on various architectures. Since that's now relevant
to malloc, move it to a more prominent place in the documentation for
memLimitBits.

Updates #10460.

Change-Id: If9708291cf3a288057b8b3ba0ba6a59e3602bbd6
Reviewed-on: https://go-review.googlesource.com/85889
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      90666b8a
    • Austin Clements's avatar
      runtime: remove non-reserved heap logic · 51ae88ee
      Austin Clements authored 
      Currently large sysReserve calls on some OSes don't actually reserve
the memory, but just check that it can be reserved. This was important
when we called sysReserve to "reserve" many gigabytes for the heap up
front, but now that we map memory in small increments as we need it,
this complication is no longer necessary.

This has one curious side benefit: currently, on Linux, allocations
that are large enough to be rejected by mmap wind up freezing the
application for a long time before it panics. This happens because
sysReserve doesn't reserve the memory, so sysMap calls mmap_fixed,
which calls mmap, which fails because the mapping is too large.
However, mmap_fixed doesn't inspect *why* mmap fails, so it falls back
to probing every page in the desired region individually with mincore
before performing an (otherwise dangerous) MAP_FIXED mapping, which
will also fail. This takes a long time for a large region. Now this
logic is gone, so the mmap failure leads to an immediate panic.

Updates #10460.

Change-Id: I8efe88c611871cdb14f99fadd09db83e0161ca2e
Reviewed-on: https://go-review.googlesource.com/85888
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      51ae88ee
    • Austin Clements's avatar
      runtime: use sparse mappings for the heap · 2b415549
      Austin Clements authored 
      This replaces the contiguous heap arena mapping with a potentially
sparse mapping that can support heap mappings anywhere in the address
space.

This has several advantages over the current approach:

* There is no longer any limit on the size of the Go heap. (Currently
  it's limited to 512GB.) Hence, this fixes #10460.

* It eliminates many failures modes of heap initialization and
  growing. In particular it eliminates any possibility of panicking
  with an address space conflict. This can happen for many reasons and
  even causes a low but steady rate of TSAN test failures because of
  conflicts with the TSAN runtime. See #16936 and #11993.

* It eliminates the notion of "non-reserved" heap, which was added
  because creating huge address space reservations (particularly on
  64-bit) led to huge process VSIZE. This was at best confusing and at
  worst conflicted badly with ulimit -v. However, the non-reserved
  heap logic is complicated, can race with other mappings in non-pure
  Go binaries (e.g., #18976), and requires that the entire heap be
  either reserved or non-reserved. We currently maintain the latter
  property, but it's quite difficult to convince yourself of that, and
  hence difficult to keep correct. This logic is still present, but
  will be removed in the next CL.

* It fixes problems on 32-bit where skipping over parts of the address
  space leads to mapping huge (and never-to-be-used) metadata
  structures. See #19831.

This also completely rewrites and significantly simplifies
mheap.sysAlloc, which has been a source of many bugs. E.g., #21044,
 #20259, #18651, and #13143 (and maybe #23222).

This change also makes it possible to allocate individual objects
larger than 512GB. As a result, a few tests that expected huge
allocations to fail needed to be changed to make even larger
allocations. However, at the moment attempting to allocate a humongous
object may cause the program to freeze for several minutes on Linux as
we fall back to probing every page with addrspace_free. That logic
(and this failure mode) will be removed in the next CL.

Fixes #10460.
Fixes #22204 (since it rewrites the code involved).

This slightly slows down compilebench and the x/benchmarks garbage
benchmark.

name       old time/op     new time/op     delta
Template       184ms ± 1%      185ms ± 1%    ~     (p=0.065 n=10+9)
Unicode       86.9ms ± 3%     86.3ms ± 1%    ~     (p=0.631 n=10+10)
GoTypes        599ms ± 0%      602ms ± 0%  +0.56%  (p=0.000 n=10+9)
Compiler       2.87s ± 1%      2.89s ± 1%  +0.51%  (p=0.002 n=9+10)
SSA            7.29s ± 1%      7.25s ± 1%    ~     (p=0.182 n=10+9)
Flate          118ms ± 2%      118ms ± 1%    ~     (p=0.113 n=9+9)
GoParser       147ms ± 1%      148ms ± 1%  +1.07%  (p=0.003 n=9+10)
Reflect        401ms ± 1%      404ms ± 1%  +0.71%  (p=0.003 n=10+9)
Tar            175ms ± 1%      175ms ± 1%    ~     (p=0.604 n=9+10)
XML            209ms ± 1%      210ms ± 1%    ~     (p=0.052 n=10+10)

(https://perf.golang.org/search?q=upload:20171231.4)

name                       old time/op  new time/op  delta
Garbage/benchmem-MB=64-12  2.23ms ± 1%  2.25ms ± 1%  +0.84%  (p=0.000 n=19+19)

(https://perf.golang.org/search?q=upload:20171231.3)

Relative to the start of the sparse heap changes (starting at and
including "runtime: fix various contiguous bitmap assumptions"),
overall slowdown is roughly 1% on GC-intensive benchmarks:

name        old time/op     new time/op     delta
Template        183ms ± 1%      185ms ± 1%  +1.32%  (p=0.000 n=9+9)
Unicode        84.9ms ± 2%     86.3ms ± 1%  +1.65%  (p=0.000 n=9+10)
GoTypes         595ms ± 1%      602ms ± 0%  +1.19%  (p=0.000 n=9+9)
Compiler        2.86s ± 0%      2.89s ± 1%  +0.91%  (p=0.000 n=9+10)
SSA             7.19s ± 0%      7.25s ± 1%  +0.75%  (p=0.000 n=8+9)
Flate           117ms ± 1%      118ms ± 1%  +1.10%  (p=0.000 n=10+9)
GoParser        146ms ± 2%      148ms ± 1%  +1.48%  (p=0.002 n=10+10)
Reflect         398ms ± 1%      404ms ± 1%  +1.51%  (p=0.000 n=10+9)
Tar             173ms ± 1%      175ms ± 1%  +1.17%  (p=0.000 n=10+10)
XML             208ms ± 1%      210ms ± 1%  +0.62%  (p=0.011 n=10+10)
[Geo mean]      369ms           373ms       +1.17%

(https://perf.golang.org/search?q=upload:20180101.2)

name                       old time/op  new time/op  delta
Garbage/benchmem-MB=64-12  2.22ms ± 1%  2.25ms ± 1%  +1.51%  (p=0.000 n=20+19)

(https://perf.golang.org/search?q=upload:20180101.3)

Change-Id: I5daf4cfec24b252e5a57001f0a6c03f22479d0f0
Reviewed-on: https://go-review.googlesource.com/85887
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      2b415549
    • Austin Clements's avatar
      runtime: eliminate most uses of mheap_.arena_* · 45ffeab5
      Austin Clements authored 
      This replaces all uses of the mheap_.arena_* fields outside of
mallocinit and sysAlloc. These fields fundamentally assume a
contiguous heap between two bounds, so eliminating these is necessary
for a sparse heap.

Many of these are replaced with checks for non-nil spans at the test
address (which in turn checks for a non-nil entry in the heap arena
array). Some of them are just for debugging and somewhat meaningless
with a sparse heap, so those we just delete.

Updates #10460.

Change-Id: I8345b95ffc610aed694f08f74633b3c63506a41f
Reviewed-on: https://go-review.googlesource.com/85886
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      45ffeab5
    • Austin Clements's avatar
      runtime: make span map sparse · d6e82185
      Austin Clements authored 
      This splits the span map into separate chunks for every 64MB of the
heap. The span map chunks now live in the same indirect structure as
the bitmap.

Updates #10460.

This causes a slight improvement in compilebench and the x/benchmarks
garbage benchmark. I'm not sure why it improves performance.

name       old time/op     new time/op     delta
Template       185ms ± 1%      184ms ± 1%    ~            (p=0.315 n=9+10)
Unicode       86.9ms ± 1%     86.9ms ± 3%    ~            (p=0.356 n=9+10)
GoTypes        602ms ± 1%      599ms ± 0%  -0.59%         (p=0.002 n=9+10)
Compiler       2.89s ± 0%      2.87s ± 1%  -0.50%          (p=0.003 n=9+9)
SSA            7.25s ± 0%      7.29s ± 1%    ~            (p=0.400 n=9+10)
Flate          118ms ± 1%      118ms ± 2%    ~            (p=0.065 n=10+9)
GoParser       147ms ± 2%      147ms ± 1%    ~            (p=0.549 n=10+9)
Reflect        403ms ± 1%      401ms ± 1%  -0.47%         (p=0.035 n=9+10)
Tar            176ms ± 1%      175ms ± 1%  -0.59%         (p=0.013 n=10+9)
XML            211ms ± 1%      209ms ± 1%  -0.83%        (p=0.011 n=10+10)

(https://perf.golang.org/search?q=upload:20171231.1)

name                       old time/op  new time/op  delta
Garbage/benchmem-MB=64-12  2.24ms ± 1%  2.23ms ± 1%  -0.36%  (p=0.001 n=20+19)

(https://perf.golang.org/search?q=upload:20171231.2)

Change-Id: I2563f8704ab9812434947faf293c5327f9b0d07a
Reviewed-on: https://go-review.googlesource.com/85885
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      d6e82185
    • Austin Clements's avatar
      runtime: abstract remaining mheap.spans access · 0de5324d
      Austin Clements authored 
      This abstracts the remaining direct accesses to mheap.spans into new
mheap.setSpan and mheap.setSpans methods.

For #10460.

Change-Id: Id1db8bc5e34a77a9221032aa2e62d05322707364
Reviewed-on: https://go-review.googlesource.com/85884
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      0de5324d
    • Austin Clements's avatar
      runtime: make the heap bitmap sparse · c0392d2e
      Austin Clements authored 
      This splits the heap bitmap into separate chunks for every 64MB of the
heap and introduces an index mapping from virtual address to metadata.
It modifies the heapBits abstraction to use this two-level structure.
Finally, it modifies heapBitsSetType to unroll the bitmap into the
object itself and then copy it out if the bitmap would span
discontiguous bitmap chunks.

This is a step toward supporting general sparse heaps, which will
eliminate address space conflict failures as well as the limit on the
heap size.

It's also advantageous for 32-bit. 32-bit already supports
discontiguous heaps by always starting the arena at address 0.
However, as a result, with a contiguous bitmap, if the kernel chooses
a high address (near 2GB) for a heap mapping, the runtime is forced to
map up to 128MB of heap bitmap. Now the runtime can map sections of
the bitmap for just the parts of the address space used by the heap.

Updates #10460.

This slightly slows down the x/garbage and compilebench benchmarks.
However, I think the slowdown is acceptably small.

name        old time/op     new time/op     delta
Template        178ms ± 1%      180ms ± 1%  +0.78%    (p=0.029 n=10+10)
Unicode        85.7ms ± 2%     86.5ms ± 2%    ~       (p=0.089 n=10+10)
GoTypes         594ms ± 0%      599ms ± 1%  +0.70%    (p=0.000 n=9+9)
Compiler        2.86s ± 0%      2.87s ± 0%  +0.40%    (p=0.001 n=9+9)
SSA             7.23s ± 2%      7.29s ± 2%  +0.94%    (p=0.029 n=10+10)
Flate           116ms ± 1%      117ms ± 1%  +0.99%    (p=0.000 n=9+9)
GoParser        146ms ± 1%      146ms ± 0%    ~       (p=0.193 n=10+7)
Reflect         399ms ± 0%      403ms ± 1%  +0.89%    (p=0.001 n=10+10)
Tar             173ms ± 1%      174ms ± 1%  +0.91%    (p=0.013 n=10+9)
XML             208ms ± 1%      210ms ± 1%  +0.93%    (p=0.000 n=10+10)
[Geo mean]      368ms           371ms       +0.79%

name                       old time/op  new time/op  delta
Garbage/benchmem-MB=64-12  2.17ms ± 1%  2.21ms ± 1%  +2.15%  (p=0.000 n=20+20)

Change-Id: I037fd283221976f4f61249119d6b97b100bcbc66
Reviewed-on: https://go-review.googlesource.com/85883
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      c0392d2e