cmd/compile: 1.12 compiler needs double the memory than 1.11

[pmuetschard]

What version of Go are you using (go version)?

1.12.4 vs 1.11.2

Details

We (https://github.com/google/gapid) generate go code based off our own domain specific language. We generate 2 go packages each with about 500k LOC. I have observed that the memory needed by the go compiler for these packages has doubled in 1.12 compared to 1.11. In 1.11, the compile executable used between 3.5G and 4G of RAM for each package, while the 1.12 version needs ~8G (resident memory, virtual memory is even more). I have observed this on both X86_64 Linux and MacOS. This causes our build bots to run out of memory and the compile fails with the below stack trace.

I don't know if you can fix this, but I felt that doubling the memory usage is a significant enough performance regression you might want to know about.

fatal error: runtime: out of memory

runtime stack:
runtime.throw(0xe5ddf9, 0x16)
	/usr/local/go/src/runtime/panic.go:617 +0x72
runtime.sysMap(0xc184000000, 0x4000000, 0x16c9178)
	/usr/local/go/src/runtime/mem_linux.go:170 +0xc7
runtime.(*mheap).sysAlloc(0x16a17c0, 0x4000, 0x16a17d0, 0x2)
	/usr/local/go/src/runtime/malloc.go:633 +0x1cd
runtime.(*mheap).grow(0x16a17c0, 0x2, 0x0)
	/usr/local/go/src/runtime/mheap.go:1232 +0x42
runtime.(*mheap).allocSpanLocked(0x16a17c0, 0x2, 0x16c9188, 0x7f5385d8bab0)
	/usr/local/go/src/runtime/mheap.go:1150 +0x3a7
runtime.(*mheap).alloc_m(0x16a17c0, 0x2, 0xc183fc0048, 0x7f5385d8bab0)
	/usr/local/go/src/runtime/mheap.go:977 +0xc2
runtime.(*mheap).alloc.func1()
	/usr/local/go/src/runtime/mheap.go:1048 +0x4c
runtime.systemstack(0x0)
	/usr/local/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
	/usr/local/go/src/runtime/proc.go:1153

goroutine 1 [running]:
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:311 fp=0xc11639f4c8 sp=0xc11639f4c0 pc=0x458f70
runtime.(*mheap).alloc(0x16a17c0, 0x2, 0x7f5386010048, 0x7f5385d8bab0)
	/usr/local/go/src/runtime/mheap.go:1047 +0x8a fp=0xc11639f518 sp=0xc11639f4c8 pc=0x423faa
runtime.(*mcentral).grow(0x16a2d40, 0x0)
	/usr/local/go/src/runtime/mcentral.go:256 +0x95 fp=0xc11639f560 sp=0xc11639f518 pc=0x416ee5
runtime.(*mcentral).cacheSpan(0x16a2d40, 0x190)
	/usr/local/go/src/runtime/mcentral.go:106 +0x2ff fp=0xc11639f5c0 sp=0xc11639f560 pc=0x4169ef
runtime.(*mcache).refill(0x7f539a2cd008, 0x48)
	/usr/local/go/src/runtime/mcache.go:135 +0x86 fp=0xc11639f5e0 sp=0xc11639f5c0 pc=0x416486
runtime.(*mcache).nextFree(0x7f539a2cd008, 0xf6bf01e5f765ea48, 0x40869d, 0xc11639fa98, 0x1fa2ae7604efec75)
	/usr/local/go/src/runtime/malloc.go:786 +0x88 fp=0xc11639f618 sp=0xc11639f5e0 pc=0x40b3c8
runtime.mallocgc(0x700, 0xe0fd00, 0x1, 0x1)
	/usr/local/go/src/runtime/malloc.go:939 +0x76e fp=0xc11639f6b8 sp=0xc11639f618 pc=0x40bcde
runtime.newarray(0xe0fd00, 0x4, 0xc183ffc000)
	/usr/local/go/src/runtime/malloc.go:1085 +0x63 fp=0xc11639f6e8 sp=0xc11639f6b8 pc=0x40c1d3
runtime.makeBucketArray(0xddd400, 0xcdf62a782fd61c02, 0x0, 0xb71308, 0xc11639f920)
	/usr/local/go/src/runtime/map.go:364 +0x18e fp=0xc11639f720 sp=0xc11639f6e8 pc=0x40d0ce
runtime.hashGrow(0xddd400, 0xc11639f928)
	/usr/local/go/src/runtime/map.go:1035 +0x8b fp=0xc11639f770 sp=0xc11639f720 pc=0x40eddb
runtime.mapassign(0xddd400, 0xc11639f928, 0xc11639f900, 0x16c7160)
	/usr/local/go/src/runtime/map.go:654 +0x147 fp=0xc11639f7f8 sp=0xc11639f770 pc=0x40da37
cmd/compile/internal/ssa.zcse(0xc183f4cb00)
	/usr/local/go/src/cmd/compile/internal/ssa/zcse.go:24 +0x281 fp=0xc11639faf8 sp=0xc11639f7f8 pc=0xb6ad31
cmd/compile/internal/ssa.Compile(0xc183f4cb00)
	/usr/local/go/src/cmd/compile/internal/ssa/compile.go:90 +0x479 fp=0xc1163a3578 sp=0xc11639faf8 pc=0x637519
cmd/compile/internal/gc.buildssa(0xc0181f49a0, 0x0, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/ssa.go:233 +0xbfd fp=0xc1163a36e8 sp=0xc1163a3578 pc=0xca6f0d
cmd/compile/internal/gc.compileSSA(0xc0181f49a0, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/pgen.go:299 +0x4d fp=0xc1163a3798 sp=0xc1163a36e8 pc=0xc71add
cmd/compile/internal/gc.compile(0xc0181f49a0)
	/usr/local/go/src/cmd/compile/internal/gc/pgen.go:278 +0x5b1 fp=0xc1163a3838 sp=0xc1163a3798 pc=0xc71a01
cmd/compile/internal/gc.funccompile(0xc0181f49a0)
	/usr/local/go/src/cmd/compile/internal/gc/pgen.go:221 +0xc2 fp=0xc1163a3890 sp=0xc1163a3838 pc=0xc71342
cmd/compile/internal/gc.Main(0xe76770)
	/usr/local/go/src/cmd/compile/internal/gc/main.go:665 +0x3059 fp=0xc1163a3f20 sp=0xc1163a3890 pc=0xc48f39
main.main()
	/usr/local/go/src/cmd/compile/main.go:51 +0xad fp=0xc1163a3f98 sp=0xc1163a3f20 pc=0xd8401d
runtime.main()
	/usr/local/go/src/runtime/proc.go:200 +0x20c fp=0xc1163a3fe0 sp=0xc1163a3f98 pc=0x42e58c
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc1163a3fe8 sp=0xc1163a3fe0 pc=0x45aec1

[randall77]

Do you have a self-contained test I can run? The full build of gapid looks huge and has lots of non-Go dependencies.
Have you tried tip?

[bradfitz]

@pmuetschard, the time when we could've done anything to fix Go 1.12 was about 5 months ago. That tree is pretty locked down at this point. But we're mid-freeze and still stabilizing Go 1.13 now (tip == the HEAD of our current master branch), so testing that would be useful.

But any fixes there would almost certainly be out of scope for our backporting policy. (That's reserved for critical & security bugs)

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)