Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: slice bounds out of range in mheap on darwin/arm64 (iOS 10) #18651

Closed
crawshaw opened this issue Jan 13, 2017 · 11 comments

Comments

Projects
None yet
6 participants
@crawshaw
Copy link
Contributor

commented Jan 13, 2017

Testing Go on an iPhone at 9cf06ed.

(lldb) fatal error: slice bounds out of range
(lldb) 
runtime stack:
runtime.throw(0x4284e5c, 0x19)
	/Users/crawshaw/go/src/runtime/panic.go:(lldb) 596 +0x70
runtime.panicCheckMalloc(0x433f0e0, 0x434fd10)
	/Users/crawshaw/go/src/runtime/panic.go:20 +0x68
runtime.panicslice()
	/Users/crawshaw/go/src/runtime/panic.go:34 +0x38(lldb) 
runtime.(*mheap).mapSpans(0x435dc20, 0x88968000)
	/Users/crawshaw/go/src/runtime/mheap.go:455 +0xbc
runtime.(*mheap).sysAlloc(0x435dc20, 0x40010000, 0x0)
	(lldb) /Users/crawshaw/go/src/runtime/malloc.go:412 +0x434
runtime.(*mheap).grow(0x435dc20, 0x20008, 0x0)
	/Users/crawshaw/go/src/runtime/mheap.go(lldb) :774 +0x50
runtime.(*mheap).allocSpanLocked(0x435dc20, 0x20001, 0xffffffffffffffff)
	/Users/crawshaw/go/src/runtime/mheap.go:678 +0x3c8
runtime.(*mheap).alloc_m(0x435dc20, 0x20001, 0x100000000, 0x87c0680)
	/Users/crawshaw/go/src/runtime/mheap.go:562 +0(lldb) xc0
runtime.(*mheap).alloc.func1()
	/Users/crawshaw/go/src/runtime/mheap.go:(lldb) 627 +0x40
runtime.systemstack(0x16e34adb8)
	/Users/crawshaw/go/src/runtime/asm_arm64.s:255 +0xb8
runtime.(*mheap).alloc(0x435dc20, 0x20001, 0x100000000, 0x4117988)
	/Users/crawshaw/go/src/runtime/mheap.go:628 +0x6c
runtime.largeAlloc(0x40002000, 0x411(lldb) a700, 0x88718000)
	/Users/crawshaw/go/src/runtime/malloc.go:795 +0x78
runtime.mallocgc.func1()
	/Users/crawshaw/go/src/runtime/malloc.go:690 +0x34
runtime.systemstack(0x8730000)
	/Users/crawshaw/go/src/runtime/asm_arm64.s:241 +0x90
runtime.mstart()
(lldb) 	/Users/crawshaw/go/src/runtime/proc.go:1132

goroutine 78 [running]:
runtime.systemstack_switch()
	/Users/crawshaw/go/src/runtime/asm_arm64.s:190 +0x8 fp=0x8748ba0 sp=0x8748b90
runtime.mallocgc(0x40002000, 0x0, 0x8748d00, 0x756ea16397212c)
	/Users/c(lldb) rawshaw/go/src/runtime/malloc.go:691 +0x818 fp=0x8748c40 sp=0x8748ba0
runtime.growslice(0x423c960, 0x872c070, 0x10, 0x10, 0x40000010, 0x40000000, 0x8748d10, 0x41d36c8)
	/Users/crawshaw/go/src/runtime/slice.go:140 +0x1cc fp=0x8748cc0 sp=0x8748c40
encodin(lldb) g/gob.encUint8Array(0x885a870, 0x88fe100, 0x423a7c0, 0x8720020, 0x97)
	/Users/crawshaw/go/src/encoding/gob/encode.go:251 +0x13c fp=0x8748d40 sp=0x8748cc0
encoding/gob.(*Encoder).encodeSingle(0x8792000, 0x8792038, 0x883d5c0, 0x423a7c0, 0x8720020, 0x97)
	(lldb) /Users/crawshaw/go/src/encoding/gob/encode.go:307 +0x168 fp=0x8748da0 sp=0x8748d40
encoding/gob.(*Encoder).encode(0x8792000, 0x8792038, 0x423a7c0, 0x8720020, 0x97, 0x8725240)
	/Users/crawshaw/go/src/encoding/gob/encode.go:709 +0xfc fp=0x8748df0 sp=0x8748(lldb) da0
encoding/gob.(*Encoder).EncodeValue(0x8792000, 0x423a7c0, 0x8720020, 0x97, 0x0, 0x0)
	/Users/crawshaw/go/src/encoding/gob/encoder.go:250 +0x2e8 fp=0x8748ea0 sp=0x8748df0
encoding/gob.(*Encoder).Encode(0x8792000, 0x423a7c0, 0x8720020, 0x8720020, 0x40(lldb) 000000)
	/Users/crawshaw/go/src/encoding/gob/encoder.go:175 +0x4c fp=0x8748ee0 sp=0x8748ea0
encoding/gob.TestHugeWriteFails(0x8b1f2b0)
	/Users/crawshaw/go/src/encoding/gob/encoder_test.go:1075 +0xe8 fp=0x8748fa0 sp=0x8748ee0
testing.tRunner(0x8b1f2b0, (lldb) 0x428c5a8)
	/Users/crawshaw/go/src/testing/testing.go:656 +0x84 fp=0x8748fc0 sp=0x8748fa0
runtime.goexit()
	/Users/crawshaw/go/src/runtime/asm_arm64.s:981 +0x4 fp=0x8748fc0 sp=0x8748fc0
created by testing.(*T).Run
	/Users/crawshaw/go/src/testing/testi(lldb) ng.go:693 +0x234

goroutine 1 [chan receive]:
testing.(*T).Run(0x87e40d0, 0x4282603, 0x12, 0x428c5a8, 0x1)
	/Users/crawshaw/go/src/testing/testing.go:694 +0x254
testing.runTests.func1(0x87e40d0)
	/Users/crawshaw/go/src/testing/testing.go:877 +0x58
t(lldb) esting.tRunner(0x87e40d0, 0x875dd60)
	/Users/crawshaw/go/src/testing/testing.go:656 +0x84
testing.runTests(0x87ea020, 0x4356a40, 0x5a, 0x5a, 0x41267d8)
	/Users/crawshaw/go/src/testing/testing.go:883 +0x260
testing.(*M).Run(0x875df28, 0x875ded8)
	/Users/crawshaw/go/src/testing/testing.go:818 +0xe0
main.main()
	encoding/gob/_test/_testmain.go:278 +0x314

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	/Users/crawshaw/go/src/runtime/asm_arm64.s:981 +0x(lldb) 4

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
	/Users/crawshaw/go/src/runtime/sigqueue.go:116 +0xe0
os/signal.loop()
	/Users/crawshaw/go/src/os/signal/signal_unix.go:22 +0x18
created by os/signal.init.1
	/Users/crawshaw/go/src/os/signal/signal_unix.go:28 +0x30

goroutine 6 [select, locked to thread]:
runtime.gopark(0x428d028, 0x0, 0x427f832, 0x6, 0x18, 0x2)
	/Users/crawshaw/go/src/runtime/proc.go:271 +0xfc
runtime.selectgoImpl(0x873c750, 0x18, 0x2)
	/Users/crawshaw/go/src/runtime/select(lldb) .go:423 +0xed0
runtime.selectgo(0x873c750)
	/Users/crawshaw/go/src/runtime/select.go:238 +0x10
runtime.ensureSigM.func1()
	/Users/crawshaw/go/src/runtime/signal_unix.go:434 +0x25c
runtime.goexit()
	/Users/crawshaw/go/src/runtime/asm_arm64.s:981 +0x4
(lldb) Process 4164 exited with status = 2 (0x00000002) 
(lldb) go_darwin_arm_exec: test timeout (test completion)
FAIL	encoding/gob	200.084s

In a subsequent run I saw:

(lldb) fatal error: runtime: out of memory
(lldb) 
runtime stack:
runtime.throw(0x4217f08, 0x16)
	/Users/crawshaw/go/src/runtime/panic.go:596 +0x70
runtime.sysMap(0x2690000, 0x3fec000, 0x888e8001, 0x4306b38)
	/Users/crawshaw/go/src/runtime/mem_darwin.go:58 +0xb0
runtime.(*mheap).mapBits(0x42f1bc0, 0(lldb) xc88f8000)
	/Users/crawshaw/go/src/runtime/mbitmap.go:159 +0xa8
runtime.(*mheap).sysAlloc(0x42f1bc0(lldb) , 0x40010000, 0x1)
	/Users/crawshaw/go/src/runtime/malloc.go:468 +0x250
runtime.(*mheap).grow(0x42f1bc0, 0x20008, 0x0)
	/Users/crawshaw/go/src/runtime/mheap.go:774 +0x50
runtime.(*mheap).allocSpanLocked(0x42f1bc0, 0x20001, 0x0)
	/Users/crawshaw/go/src(lldb) /runtime/mheap.go:678 +0x3c8
runtime.(*mheap).alloc_m(0x42f1bc0, 0x20001, 0xffffff0100000000, 0x40818b4)
	/Users/crawshaw/go/src/runtime/mheap.go:562 +0xc0
runtime.(*mheap).alloc.func1()
	/Users/crawshaw/go/src/runtime/mheap.go:627 +0x40
runtime.syste(lldb) mstack(0x16e3bedb8)
	/Users/crawshaw/go/src/runtime/asm_arm64.s:255 +0xb8
runtime.(*mheap).alloc(0x42f1bc0, 0x20001, 0x100000000, 0x408fd08)
	/Users/crawshaw/go/src/runtime/mheap.go:628 +0x6c
runtime.largeAlloc(0x40002000, 0x100000000, 0x0)
	/Users/cr(lldb) awshaw/go/src/runtime/malloc.go:795 +0x78
runtime.mallocgc.func1()
	/Users/crawshaw/go/src/runtime/malloc.go:690 +0x34
runtime.systemstack(0x86c0000)
	/Users/crawshaw/go/src/runtime/asm_arm64.s:241 +0x90
runtime.mstart()
	/Users/crawshaw/go/src/runti(lldb) me/proc.go:1132

goroutine 75 [running]:
runtime.systemstack_switch()
	/Users/crawshaw/go/src/runtime/asm_arm64.s:190 +0x8 fp=0x86dfba0 sp=0x86dfb90
runtime.mallocgc(0x40002000, 0x0, 0x86a5800, 0x4087f38)
	/Users/crawshaw/go/src/runtime/malloc.go:691(lldb)  +0x818 fp=0x86dfc40 sp=0x86dfba0
runtime.growslice(0x41d0900, 0x896fcf0, 0x10, 0x10, 0x40000010, 0x40000000, 0x86cec00, 0x4167c08)
	/Users/crawshaw/go/src/runtime/slice.go:140 +0x1cc fp=0x86dfcc0 sp=0x86dfc40
encoding/gob.encUint8Array(0x87dc8d0, 0x897(lldb) 73c0, 0x41ce760, 0x897f580, 0x97)
	/Users/crawshaw/go/src/encoding/gob/encode.go:251 +0x13c fp=0x86dfd40 sp=0x86dfcc0
encoding/gob.(*Encoder).encodeSingle(0x8addb80, 0x8addbb8, 0x87c5620, 0x41ce760, 0x897f580, 0x97)
	/Users/crawshaw/go/src/encoding/gob/(lldb) encode.go:307 +0x168 fp=0x86dfda0 sp=0x86dfd40
encoding/gob.(*Encoder).encode(0x8addb80, 0x8addbb8, 0x41ce760, 0x897f580, 0x97, 0x870d180)
	/Users/crawshaw/go/src/encoding/gob/encode.go:709 +0xfc fp=0x86dfdf0 sp=0x86dfda0
encoding/gob.(*Encoder).EncodeValue(0x8addb80, 0x41ce760, 0x897f580, 0x97, 0x0, 0x0)
	/Users/crawshaw/go/src/encoding/gob/encoder.go:250 +0x2e8 fp=0x86dfea0 sp=0x86dfdf0
(lldb) encoding/gob.(*Encoder).Encode(0x8addb80, 0x41ce760, 0x897f580, 0x897f580, 0x40000000)
	/Users/crawshaw/go/src/encoding/gob/encoder.go:175 +0x4c fp=0x86dfee0 sp=0x86dfea0
encoding/gob.TestHugeWriteFails(0x897bad0)
	/Users/crawshaw/go/src/encoding/gob/en(lldb) coder_test.go:1075 +0xe8 fp=0x86dffa0 sp=0x86dfee0
testing.tRunner(0x897bad0, 0x4220548)
	/Users/crawshaw/go/src/testing/testing.go:656 +0x84 fp=0x86dffc0 sp=0x86dffa0
runtime.goexit()
	/Users/crawshaw/go/src/runtime/asm_arm64.s:981 +0x4 fp=0x86dffc0 sp=0x86dffc0
created by testing.(*T).Run
	/Users/crawshaw/go/src/testing/testing.go:693 +0x234

goroutine 1 [chan receive]:
testing.(*T).Run(0x87780d0, 0x42165a3, 0x12, 0x4220548, 0x1)
	/Users/crawshaw/go/src/testing/testing.go:694 +0x254
testing.run(lldb) Tests.func1(0x87780d0)
	/Users/crawshaw/go/src/testing/testing.go:877 +0x58
testing.tRunner(0x87780d0, 0x86edd60)
	/Users/crawshaw/go/src/testing/testing.go:656 +0x84
testing.runTests(0x86b0080, 0x42ea9e0, 0x5a, 0x5a, 0x40bad18)
	/Users/crawshaw/go/sr(lldb) c/testing/testing.go:883 +0x260
testing.(*M).Run(0x86edf28, 0x86eded8)
	/Users/crawshaw/go/src/testing/testing.go:818 +0xe0
main.main()
	encoding/gob/_test/_testmain.go:278 +0x314

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	/Users/(lldb) crawshaw/go/src/runtime/asm_arm64.s:981 +0x4

goroutine 19 [syscall]:
os/signal.signal_recv(0x0)
	/Users/crawshaw/go/src/runtime/sigqueue.go:116 +0xe0
os/signal.loop()
	/Users/crawshaw/go/src/os/signal/signal_unix.go:22 +0x18(lldb) 
created by os/signal.init.1
	/Users/crawshaw/go/src/os/signal/signal_unix.go:28 +0x30

goroutine 20 [select, locked to thread]:
runtime.gopark(0x4220fc8, 0x0, 0x42137d2, 0x6, 0x18, 0x2)
	/Users/crawshaw/go/src/runtime/proc.go:271 +0xfc
runtime.selectgoImpl(0x86d8f50, 0x18, 0x2)
	/Users/crawshaw/go/src/runtime/select.go:423 +0xed0
runtime.selectgo(0x86d8f50)
	/Users/crawshaw/go/src/runtime/select.go:238 +0x10
runtime.ensureSigM.func1()
	/Users/crawshaw/go/src/runtime/signal_unix.go:434 +0x25c
runtime.goexit()
	/Users/crawshaw/go/src/runtime/asm_arm64.s:981 +0x4
(lldb) Process 4313 exited with status = 2 (0x00000002) 
(lldb) go_darwin_arm_exec: test timeout (test completion)
exit status 1
FAIL	encoding/gob	19.704s

Seems to be a moderately reliable failure.

(it is failing much faster than the test harness suggests, in under a second.)

cc @aclements

@bradfitz bradfitz added this to the Go1.8Maybe milestone Jan 13, 2017

@aclements

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

runtime.largeAlloc(0x40002000, 0x411a700, 0x88718000)
/Users/crawshaw/go/src/runtime/malloc.go:795 +0x78

This is doing a 1 GB allocation and it looks like a few lines earlier in TestHugeWriteFails the test did another 1 GB allocation (which seems to have succeeded). Darwin/arm64 only reserves 2 GB for the Go heap, so this should fail. The error message is no good, though.

The bad error message is because mheap.sysAlloc is a little confused. Because the darwin/arm64 heap is only 2 GB, we wound up in the 32-bit path. That's not so bad, except that it assumes we can grow the reservation up to 4 GB (_MaxArena32), but mallocinit only reserved auxiliary structures for a 2 GB heap. When we try to grow the spans array past mallocinit's reservation, it crashes.

I think this "worked" until 5915ce6 in late October because it silently walked off the end of the spans array and corrupted something else (probably the heap bitmap). In October I changed it to use a slice instead of ugly pointer math, so we now get bounds checking for free where we didn't have any sort of overflow check before.

(Also, given the name of the test, shouldn't gob fail gracefully before allocating a huge slice?)

@crawshaw

This comment has been minimized.

Copy link
Contributor Author

commented Jan 13, 2017

Thanks for the analysis. Somehow I missed this was happening in a test that should be skipped in -short mode. That suggests there's something wrong with my test harness, I believe all.bash should run -short by default.

Then there is the issue of making this error clearer (and ideally, handled properly by encoding/gob), but I believe that is a pre-existing condition so we can punt it to 1.9.

@aclements

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

Then there is the issue of making this error clearer (and ideally, handled properly by encoding/gob), but I believe that is a pre-existing condition so we can punt it to 1.9.

Sounds good. I'm fairly certain the only consequence of not changing this is that you get one panic instead of another, but trying to fix it may have other consequences. :)

I've got a fix queued up, which I'll send for Go 1.9.

@gopherbot

This comment has been minimized.

Copy link

commented Jan 13, 2017

CL https://golang.org/cl/35253 mentions this issue.

@gopherbot

This comment has been minimized.

Copy link

commented Jan 13, 2017

CL https://golang.org/cl/35252 mentions this issue.

@aclements

This comment has been minimized.

Copy link
Member

commented Jan 17, 2017

/cc @robpike @rsc: Should encoding/gob's TestHugeWriteFails be failing before it attempts to allocate enough memory to encode the entire (huge) input? The runtime bug in this issue was tickled because TestHugeWriteFails attempted to allocate a 1 GB buffer rather than failing early on the huge input. The code is clearly written to encode the whole thing and only then check if it got too big, but I'm wondering if that's what it should be doing.

@aclements aclements modified the milestones: Go1.9, Go1.8Maybe Jan 17, 2017

@robpike

This comment has been minimized.

Copy link
Contributor

commented Jan 17, 2017

@aclements If you can write a simple reproducer, please file an issue and assign it to me.

@gopherbot

This comment has been minimized.

Copy link

commented Feb 6, 2017

CL https://golang.org/cl/35251 mentions this issue.

@nightlyone

This comment has been minimized.

Copy link
Contributor

commented Feb 6, 2017

@aclements since https://golang.org/cl/35251 removes the broken ulimit -v check, could you link the issue tracking re-adding that check? Even if it's considered not worthy to re-add, people should at least be able to find the reasons.

@aclements

This comment has been minimized.

Copy link
Member

commented Feb 6, 2017

@nightlyone, thanks. Added a reference to the commit message.

gopherbot pushed a commit that referenced this issue Feb 7, 2017

runtime: make _MaxMem an untyped constant
Currently _MaxMem is a uintptr, which is going to complicate some
further changes. Make it untyped so we'll be able to do untyped math
on it before truncating it to a uintptr.

The runtime assembly is identical before and after this change on
{linux,windows}/{amd64,386}.

Updates #18651.

Change-Id: I0f64511faa9e0aa25179a556ab9f185ebf8c9cf8
Reviewed-on: https://go-review.googlesource.com/35251
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

gopherbot pushed a commit that referenced this issue Feb 7, 2017

runtime: simplify and cleanup mallocinit
mallocinit has evolved organically. Make a pass to clean it up in
various ways:

1. Merge the computation of spansSize and bitmapSize. These were
   computed on every loop iteration of two different loops, but always
   have the same value, which can be derived directly from _MaxMem.
   This also avoids over-reserving these on MIPS, were _MaxArena32 is
   larger than _MaxMem.

2. Remove the ulimit -v logic. It's been disabled for many releases
   and the dead code paths to support it are even more wrong now than
   they were when it was first disabled, since now we *must* reserve
   spans and bitmaps for the full address space.

3. Make it clear that we're using a simple linear allocation to lay
   out the spans, bitmap, and arena spaces. Previously there were a
   lot of redundant pointer computations. Now we just bump p1 up as we
   reserve the spaces.

In preparation for #18651.

Updates #5049 (respect ulimit).

Change-Id: Icbe66570d3a7a17bea227dc54fb3c4978b52a3af
Reviewed-on: https://go-review.googlesource.com/35252
Reviewed-by: Russ Cox <rsc@golang.org>

@gopherbot gopherbot closed this in 4af6b81 Feb 7, 2017

@gopherbot

This comment has been minimized.

Copy link

commented Jan 2, 2018

Change https://golang.org/cl/85887 mentions this issue: runtime: use sparse mappings for the heap

gopherbot pushed a commit that referenced this issue Feb 15, 2018

runtime: use sparse mappings for the heap
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: Rick Hudson <rlh@golang.org>

@golang golang locked and limited conversation to collaborators Jan 2, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.