Thanks Richard for doing the go port to plan9/arm. I was going to start on that myself until I found out it was already done. :-)
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? Perhaps it allocates a huge chunk of virtual memory on startup. I’ll check for that kernel change in my kernel source. If it’s not there I’ll recompile and give it a shot. 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? I believe that my rpi only has the 512MB of RAM so I’ll add swap. 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? Cheers, Chris > On Apr 13, 2016, at 5:10 AM, Richard Miller <9f...@hamnavoe.com> wrote: > >> I tried a bootstrapped version on my RPi but it fails with a "fork/exec ... >> virtual memory allocation failed” error when I try to compile anything. > > Go needs a lot of virtual memory - it won't even pass the installation test > suite > if you give it less than a gigabyte. That was the reason for the change to > the > definition in /sys/src/9/bcm/mem.h mentioned earlier: > > < #define USTKTOP 0x20000000 /* user segment end +1 > */ > --- >> #define USTKTOP 0x40000000 /* user segment end +1 >> */ > > Are you running a 9pi kernel built with this change? There are newer kernel > binaries > in /n/sources/contrib/miller/9pi* with this and other tweaks applied. If you > are > using an older pi with 512MB of ram, you'll need to activate swap(8). > > The plan9_arm version of go is expected to be in the 1.7 release. It is > already > self hosting: if you look at the builder dashboard in http://build.golang.org > which tracks updates being built and tested on all platforms, the "plan9 arm" > column at the far right is a Raspberry Pi 3 managed by David du Colombier. > It doesn't keep up with every update because a complete build and test suite > run takes a bit over an hour. > >
