From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <20110403211333.GA3905@dinah> <946377fc99d55f66708553c16bb698de@coraid.com> <9739a352230f78fcb10629cdbc856dfc@ladd.quanstro.net> <224a2b9fd0b816400c0e5690336df9f9@brasstown.quanstro.net> Date: Mon, 4 Apr 2011 21:00:14 -0700 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Go Plan 9 Topicbox-Message-UUID: c94748d6-ead6-11e9-9d60-3106f5b1d025 I tried a simple hack on 9vx. First, I had sysbrk_ return the max possible value instead of the requested value. I.e., if go runtime asked for 768MB, I had it return something less than TSTKTOP, which is around 256 MB. I like this because if we change the USTKTOP on 9vx in future we don't have to recompile the go runtime, and a single binary can run on many 9vx systems which might have different limits compiled in. Unfortunately the runtime code ignores the returned value from sbrk_; strike one. I then had it return -1 when asked for more memory than could be returned; Got this: term% ./testgo.out throw: and that was it. Russ, could the go runtime maybe use the value returned by sbrk instead of assuming it got all it asked for? ron