Мне удалось определить, где gccgo запрашивает столько памяти.Он находится в файле libgo / go / runtime / malloc.go в функции mallocinit:
// If we fail to allocate, try again with a smaller arena.
// This is necessary on Android L where we share a process
// with ART, which reserves virtual memory aggressively.
// In the worst case, fall back to a 0-sized initial arena,
// in the hope that subsequent reservations will succeed.
arenaSizes := [...]uintptr{
512 << 20,
256 << 20,
128 << 20,
0,
}
for _, arenaSize := range &arenaSizes {
// SysReserve treats the address we ask for, end, as a hint,
// not as an absolute requirement. If we ask for the end
// of the data segment but the operating system requires
// a little more space before we can start allocating, it will
// give out a slightly higher pointer. Except QEMU, which
// is buggy, as usual: it won't adjust the pointer upward.
// So adjust it upward a little bit ourselves: 1/4 MB to get
// away from the running binary image and then round up
// to a MB boundary.
p = round(getEnd()+(1<<18), 1<<20)
pSize = bitmapSize + spansSize + arenaSize + _PageSize
if p <= procBrk && procBrk < p+pSize {
// Move the start above the brk,
// leaving some room for future brk
// expansion.
p = round(procBrk+(1<<20), 1<<20)
}
p = uintptr(sysReserve(unsafe.Pointer(p), pSize, &reserved))
if p != 0 {
break
}
}
if p == 0 {
throw("runtime: cannot reserve arena virtual address space")
}
Интересная часть заключается в том, что при сбое больших размеров он возвращается к меньшим размерам арены.Поэтому ограничение виртуальной памяти, доступной для исполняемого файла go, фактически ограничит объем, который он будет успешно распределять.
Я смог использовать ulimit -v 327680
, чтобы ограничить виртуальную память меньшими числами:
VmPeak: 300772 kB
VmSize: 300772 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 5712 kB
VmRSS: 5712 kB
VmData: 296276 kB
VmStk: 132 kB
VmExe: 2936 kB
VmLib: 0 kB
VmPTE: 56 kB
VmPMD: 0 kB
VmSwap: 0 kB
Это все еще большие числа, но лучшее, что может достичь исполняемый файл gccgo.Таким образом, ответ на вопрос: да, вы можете уменьшить VmData скомпилированного исполняемого файла gccgo, но вам не стоит об этом беспокоиться. (На 64-битной машине gccgo пытается выделить 512 ГБ.)