From mboxrd@z Thu Jan  1 00:00:00 1970
From: quanstro@quanstro.net (erik quanstrom)
Date: Mon,  4 Apr 2011 11:59:16 -0400
Subject: [9fans] Go Plan 9
In-Reply-To: <BANLkTimMsU3GCh2On9tSvTTzzVz0WyYrHA@mail.gmail.com>
References: <AANLkTik3gx8QK7O-+O=R8oFELTt6WgVHO3dJV51cZiPQ@mail.gmail.com>
	<AANLkTi=7L-mqU=mFODnGcYCmyvR02M=MLFzKPpH2v2B1@mail.gmail.com>
	<20110403211333.GA3905@dinah>
	<946377fc99d55f66708553c16bb698de@coraid.com>
	<BANLkTimMsU3GCh2On9tSvTTzzVz0WyYrHA@mail.gmail.com>
Message-ID: <9739a352230f78fcb10629cdbc856dfc@ladd.quanstro.net>
Topicbox-Message-UUID: c83625e8-ead6-11e9-9d60-3106f5b1d025

On Mon Apr  4 11:19:37 EDT 2011, rminnich at gmail.com wrote:
> On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom <quanstro at labs.coraid.com> wrote:
> >> The reason it doesn't work on 9vx is because the 32 bit Go runtime
> >> reserves a large chunk of address space (currently 768mb). ?On all
> >> other platforms, this is accomplised with an mmap equivalient, which
> >> we all know won't work on Plan 9.
> >>
> >
> > if i read the thread on this topic correctly, this reservation
> > isn't necessary on plan 9, since there are no shared libraries
> > and the heap will always be contiguous.
> >
> 
> no, the shared libraries are not going to affect the heap size.
> Certainly not to this scale.
> 

i'm not quite sure what you're saying "no" to.

in any event, my understanding is, it's not the size of
the heap, it's the heap's continuity.  if the heap
is not contiguous, you'll need a structure tracking it.
according to lwn http://lwn.net/Articles/428100/

	In the process of trying to reach that goal of
	"low enough overhead and no significant latency," the
	Go developers have made some simplifying assumptions,
	one of which is that the memory being managed
	for a running application comes from a
	single, virtually-contiguous address range.

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.

- erik