Re: [Dev-C++] dynamic or stack allocation ...

[Per W. <pw...@ia...>]

Small OS preallocates the stack to a fixed size at startup. OS using
virtual memory and MMU normally let's the stack grow at runtime. This
stack growth is one level below the use of dynamic allocation on heap,
since the OS uses the memory paging scheme of the processor.

One method the OS may use is to add a write-protected guard page last on
the stack. As soon as the program tries to write to this guard page, the
OS gets a memory protection error. It detects that the stack is about to
overflow and oens the guard page for writing and adds a new guard page 4kB
(for x86) higher on the stack. This scheme may fail for a method using a
large auto buffer, since if the buffer is larger than the guard page, the
first write might come at a an address AFTER the guard page. A lot of
compilers will add extra code for functions with large auto variables,
where the extra funcrion prolog touches the stack in 4kB steps to let the
OS detect and add the needed number of new pages.

One other method for the OS to handle the stack is to have a very large
hole in the virtual address space after the end of the stack. If an access
comes to the nearest MB (or whatever) of the stack top, the OS then
assumes that it isn't a bad pointer access but a function with large auto
variables, and then fills up the stack with needed number of new pages.

A lot of OS does NOT allow the stack to grow for any threads that gets
started by the main process. This is because the virtual address space of
most processors is a bit cramped, and to leave large address map holes for
the individual stacks to grow into would seriously reduce number of
concurrent threads the process might have. At creation, the process have
to specify the maximum stack size needed for the new threads and then the
stacks are placed end-to-end in the virtual memory address map.

Auto-allocated data is only possible when life span of a variable follows
the call nesting of the used functions, since the variables will be
automatically released when the function returns. No function might return
a pointer to one of it's auto variables, and have the caller reference
that pointer.


While there exists schemes for allocation of variable-sized data on the
stack, they are normally plagued by incompatiblities between compilers,
used processors etc and should normally not be used, i.e. if you don't
know the needed size in the beginning, the recommendation is to go for
heap allocation.

If the needed memory block is very large, heap memory should also be used,
since the OS might have a stack size limit a lot smaller than malloc/new
might support. Also, some combinations of compilers and OS fails to detect
and auto-grow the stack for some scenarios with large auto variables.


A single call for dynamic allocation is not a problem. It's when the
allocation and/or release is in a loop or a time-critical part of a
program you'll have to watch out for the speed issue.

For embedded programming there's the extra problem that asynchronous
events, such as interrupt service routines may normally not call most OS
and library functions, since that might result in deadlock. If a thread is
in a critical section the ISR needs access to, the OS can't just park the
ISR until the thread releases the critical section.

/Per W

On Thu, 3 Apr 2003, Khalid El-Kary wrote:

> Hi fellows,
>
> right now i know that memory in the stack gets allocated for once during the
> start-up of the programm, and dynamically allocated memory gets allocated
> while the programm is running.
>
> stack memory is faster at execution.
> dynamic memory is slower (the time consumed by malloc/free)
>
> but ...
>
> I want to know when exactly should i use stack memory and when exactly
> should i use dynamic memory ?
>
> thanx in advance
>
> Regards,
> Khalid Al-Kary
>
>
>
>
>
> _________________________________________________________________
> MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> http://join.msn.com/?page=features/virus
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>