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

[Khalid El-K. <kha...@ho...>]

thanx for the very detailed reply :-)

>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
> >
>


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus