[Prev][Next][Index][Thread]
Re: Mac d2c
In article <3873800F.B7E463E@lostwax.com>, Rob Myers <robm@lostwax.com> wrote:
> (Thanks).
> How do UNIX systems handle their stacks???
They generally save something like a GB of address space for the stack.
Actual pages of memory aren't allocated until the program starts using
them, but there is a lot of space available.
> And will giving the PPC app a bigger stack in its cfrg Resource help?
I think the default Mac stack is 64 KB at the moment (it used to be 32 KB
back in the 680x0 days). This is usually enough for interactive programs
where the user creates and destroys documents at random, forcing the
program to heap-allocate everything, but batch programs from other
platforms tend to bust it. If the program has done a MaxApplZone() call
at the start (as most do) then busting the stack immediately overwrites
part of the heap. If MaxApplZone() hasn't been called then the heap
starts small and grows as needed and busting past the end of the stack
doesn't do any harm unless it's really serious.
The best solution is probably to find any large stack-allocated stuff and
put i in the heap instead.
Compiled Dylan code should generally be fine, as anything big is
automatically heap-allocated anyway. I'd be concerned about some of the C
runtime code though. Are there any large arrays?
Where does the memory pointed to by the "orig_sp" argument to every
Dylan-geneated function come from? It's used as a stack to hold temporary
stuff, but clearly must be allocated by something before the program
starts (and is therefore likely to be fixed sized, which probably means
that it is sized to be "big enough").
That's a prime suspect, I think.
-- Bruce
Follow-Ups:
References: