> I didn’t realize that Go was so virtual memory hungry. I wonder why stats > didn’t show me a large peak of memory consumption before the go compiler died?
stats -m shows physical memory usage. Every go program starts by allocating a huge block of virtual space for its garbage-collected allocation arena. A lot of that will normally remain unused, so no corresponding physical ram need be allocated. > Are these changes going to make it into the official kernel source? Any > reason why everyone, even non Go users, wouldn’t want the changes? Depends what you mean by "official". The rpi specific changes are all in /n/sources/contrib/miller/9/bcm, and I will be sending patches for the portable changes soon. This is only for reference - it has been some time since any patches were being applied on /n/sources/plan9. > I didn’t realize that Go programs were so heavy weight. What do embedded Go > users have to do to make things work on other platforms like Linux? Depends what you mean by "embedded". The VM allocation is probably less significant for very small platforms than the size of the runtime library. cpu% cat smallest.go package main func main() { } cpu% go build smallest.go cpu% ls -l smallest --rwxr-x--x M 3990 miller miller 614356 Apr 13 14:42 smallest cpu% size smallest 466123t + 1792d + 87712b = 555627 smallest