From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9739a352230f78fcb10629cdbc856dfc@ladd.quanstro.net> References: <20110403211333.GA3905@dinah> <946377fc99d55f66708553c16bb698de@coraid.com> <9739a352230f78fcb10629cdbc856dfc@ladd.quanstro.net> Date: Mon, 4 Apr 2011 16:09:24 -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: c8f4fd88-ead6-11e9-9d60-3106f5b1d025 On Mon, Apr 4, 2011 at 8:59 AM, erik quanstrom wrote: > this is the whole point of the big allocation, so why > would we drag this into plan 9, when it's not necessary. > the plan 9 heap is contiguous. Sorry, Erik, I misunderstood your point. I guess what you are pointing out is that on Plan 9, presumably, since the Go runtime is the only thing that might call brk(), it will always get a virtually contiguous heap. Therefore, instead of a huge upfront allocation, Go runtime could call brk() as needed. Can we safely assume that only the Go runtime will call brk()? What if we link a library into Go that calls brk() as well -- won't that violate Go's model? Probably not worth worrying about since Russ says he's good with the other change. thanks ron