[m-dev.] Mercury and GCC split stacks

[Paul Bone]

On Mon, Sep 08, 2014 at 12:08:54AM +1000, Paul Bone wrote:
> On Fri, Sep 05, 2014 at 02:01:37PM +0200, Zoltan Somogyi wrote:
> > 
> > 
> > On Fri, 5 Sep 2014 15:38:41 +1000, Paul Bone <paul at bone.id.au> wrote:
> >  Also I like the idea of using something like mprotect to implement
> > > stack extension for low level C grades.  I'd prefer this kind of "trap" to
> > > detect when stack extension is required rather than a test for each stack
> > > frame.
> > 
> > The tradeoff is that an mmap trap requires, for each stack, a buffer
> > that is the size of a page, since the VM hardware on typical machines
> > cannot set permissions on any smaller unit of memory than that.
> > If you want to have tens or hundreds of thousands of stacks
> > (because you have that many threads), like Erlang was designed for,
> > this per-stack overhead (in address space, if not in memory) becomes
> > excessive.
> 
> If it's only in address space then I don't think ti would be excessive on a
> 64bit system.
> 
> If we assume 10,000 threads with an average of 10 stack segments each that's
> 100,000 stack segments  with one protected page is 400,000KB of memory
> (assuming 4KB pages) or 409,600,000 bytes.  It's true that this would be
> excessive if these pages were mapped to physical memory.
> 
> However the total amount of address space available is:
> 
>     2^64 = 18.446 * 10^18.
> 
> Of which we want to use 409 * 10^6, or less than 10 * -9 percent.
> 
> Many CPUs also support 4MB pages, but these are not used often, but this
> makes things a little over 1,000x worse, but that's still only 10*-6
> percent of your address space.  I'm not concerned.

But I agree that the tradeoff exists and in different sinarios, such as
32bit address spaces, then this could be a problem.



-- 
Paul Bone