I notice that sysMapOS and sysReserveOS on BSD both invoke mmap, and cmd/go has recently started using syscall.Mmap to access cached metadata during package loading.
I can think of the following possible explanations, but I'm not sure which (if any) is correct.
Perhaps a bug in cmd/go (perhaps on the indexing path) is causing it to use more memory than expected?
Perhaps a bug in the OpenBSD mmap implementation causes the cmd/go call to syscall.Mmap to steal an address that was supposed to be reserved for the runtime?
Perhaps a bug somewhere in the runtime causes it to drastically overshoot the heap target? (But I would expect the syscall.Mmap usage to instead cause it to undershoot, since the heap size used to compute GOGC will not include the Mmap'd data.)
This is another case where it would be really helpful to have some heap stats from the runtime when the process OOMs (#52546)...