stack size
May be this question is not strictly suited to this list, but I see lots of people contributing from lots of different platforms. The question regards to stack space management under different platforms, or execution models. Under my preferred platform ( QNX 4.25 ) stack space is allocated at process creation, and remains fixed until process death. Thas is so because the data segment layout leaves the heap on top, so it can grow easily. So, one must guess how much stack would be needed, and give the figure to the linker. The question is: are there some other ( not exotic, of course ) platforms that allows stack growing on demand ? i.e the stack as one segment by its own, which can be dynamically re-allocated during process lifetime ? Thank you ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: stack size
mnicolet wrote (in a message from Tuesday 8) May be this question is not strictly suited to this list, but I see lots of people contributing from lots of different platforms. The question regards to stack space management under different platforms, or execution models. Under my preferred platform ( QNX 4.25 ) stack space is allocated at process creation, and remains fixed until process death. Thas is so because the data segment layout leaves the heap on top, so it can grow easily. So, one must guess how much stack would be needed, and give the figure to the linker. The question is: are there some other ( not exotic, of course ) platforms that allows stack growing on demand ? i.e the stack as one segment by its own, which can be dynamically re-allocated during process lifetime ? On Unix-like systems (and I guess in modern MS Window too) the virtual memory system allows to allocate a large stack for each process. Real memory is used only as stack grows and as virtual addresses need to have real memory pages vired to them. There still is a physical fixed stack size limit, but it's generally set quite high. I don't know any system without shared memory that would behave this way. In VxWorks you specify the stack size at task creation and it's allocating memory from the global pool. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Re: stack size
- Original Message - From: Matthieu Herrb [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:52 AM Subject: Re: stack size mnicolet wrote (in a message from Tuesday 8) May be this question is not strictly suited to this list, but I see lots of people contributing from lots of different platforms. The question regards to stack space management under different platforms, or execution models. On Unix-like systems (and I guess in modern MS Window too) the virtual memory system allows to allocate a large stack for each process. Real memory is used only as stack grows and as virtual addresses need to have real memory pages vired to them. There still is a physical fixed stack size limit, but it's generally set quite high. I don't know any system without shared memory that would behave this way. In VxWorks you specify the stack size at task creation and it's allocating memory from the global pool. I forget to mention: QNX does use virtual memory, ( reliyng on the processor for actual memory management ) but no disk paging. So it behaves like VxWorks, i.e, early and _true_ stack allocation. Matthieu Thank you. You answered me what I was expecting: no system allows for a true or full dynamic stack size. Another wording: on every system one could reach some stack limit, and therefore one migth care about this figure. So, my true question comes into scene. The people who ported XFree86 to QNX 4.x setted the stack size hint to the Watcom linker to 4 Mb ( yes, 4 Mb ) for the server. I am wondering why a so high figure. I tried to grep the sources searching for some form of alloca usage ( the native one or a home brew, Postgresql style ) without success. In fact, all what is malloc and free related is coded using macros, which even appear redefined for some modules. But what I cannot figure simply is the possible recursions, and/or giant local objects. Is there a true need for such stack size ? marcelo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Re: stack size
On Tue, 08 Jul 2003 10:13:06 -0300, mnicolet wrote: Thank you. You answered me what I was expecting: no system allows for a true or full dynamic stack size. If that's your interpretation, then I'm not sure what you mean by a full dynamic stack size. All the operating systems he mentioned reserve address space for a gigantic stack, but they only allocate physical memory as it is needed. Special tricks with guard pages are used to determine when a new page of physical memory needs to be added to the stack. Another wording: on every system one could reach some stack limit, and therefore one migth care about this figure. Yes, of course. Memory is not infinite, even on a 4GB system. So, my true question comes into scene. The people who ported XFree86 to QNX 4.x setted the stack size hint to the Watcom linker to 4 Mb ( yes, 4 Mb ) for the server. I am wondering why a so high figure. I am wondering (1) why this figure seems high to you, and (2) why you are worried about it? The stack doesn't actually use 4MB of physical memory. It only uses the memory that is required. X11 is a thoroughly modular and layered server. It nests extremely deeply -- much more deeply than a typical application. I'm not saying 4MB is absolutely necessary, but if cutting it to 1MB causes even a single crash, what's the point? Is there a true need for such stack size ? Who cares? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re:: Re: stack size
Thank you. You pointed me back to documentation. QNX 4.x does not page to disk. A philosophical question for a RTOS. The only available memory is RAM. That´s why I care about everything. But it offers two main process image layouts. One that ´sandwiches´ the stack between the BSS and the heap, so the stack memory must be allocated at process startup. And another that leaves the stack at the low end of the data segment, so even if hinted, the stack only grows as required. What you pointed me to. By the way, the idea behind is that managing the stack in its own segment could be prohibitive for a system without disk paging. The question was I took the QNX options verbatim from the people who made the porting, and ended with a X server which at it´s very start was ´using´ more than 4 Mb of data !!! The right answer is to change compile and linking options, so even with a generous limit, the stack would be dynamically allocated as required. Than you again - Original Message - From: Tim Roberts [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 1:34 PM Subject: Re: Re: stack size On Tue, 08 Jul 2003 10:13:06 -0300, mnicolet wrote: Thank you. You answered me what I was expecting: no system allows for a true or full dynamic stack size. If that's your interpretation, then I'm not sure what you mean by a full dynamic stack size. All the operating systems he mentioned reserve address space for a gigantic stack, but they only allocate physical memory as it is needed. Special tricks with guard pages are used to determine when a new page of physical memory needs to be added to the stack. Another wording: on every system one could reach some stack limit, and therefore one migth care about this figure. Yes, of course. Memory is not infinite, even on a 4GB system. So, my true question comes into scene. The people who ported XFree86 to QNX 4.x setted the stack size hint to the Watcom linker to 4 Mb ( yes, 4 Mb ) for the server. I am wondering why a so high figure. I am wondering (1) why this figure seems high to you, and (2) why you are worried about it? The stack doesn't actually use 4MB of physical memory. It only uses the memory that is required. X11 is a thoroughly modular and layered server. It nests extremely deeply -- much more deeply than a typical application. I'm not saying 4MB is absolutely necessary, but if cutting it to 1MB causes even a single crash, what's the point? Is there a true need for such stack size ? Who cares? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: stack size
Tim Roberts wrote: On Tue, 08 Jul 2003 10:13:06 -0300, mnicolet wrote: So, my true question comes into scene. The people who ported XFree86 to QNX 4.x setted the stack size hint to the Watcom linker to 4 Mb ( yes, 4 Mb ) for the server. I am wondering why a so high figure. I am wondering (1) why this figure seems high to you, and (2) why you are worried about it? The stack doesn't actually use 4MB of physical memory. It only uses the memory that is required. X11 is a thoroughly modular and layered server. It nests extremely deeply -- much more deeply than a typical application. I'm not saying 4MB is absolutely necessary, but if cutting it to 1MB causes even a single crash, what's the point? Is there a true need for such stack size ? Who cares? Is QNX a threaded OS (like Netware)? Threaded applications on x86 usually have much smaller default stack limits, averaging 64-128k, because all threads must share the same address space, and a 4MB stack gives you a theoretical limit of only 1024 threads (assuming your kernel uses no memory and your process allocates no data, just stack :) mnicolet: the best way to answer your question Is there a true need for such stack size is probably for you to set the stack size lower and see if it breaks. -- Dan Nelson [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: stack size
On Tue, 08 Jul 2003 16:40:39 -0500, Dan Nelson wrote: Threaded applications on x86 usually have much smaller default stack limits, averaging 64-128k, because all threads must share the same address space, and a 4MB stack gives you a theoretical limit of only 1024 threads (assuming your kernel uses no memory and your process allocates no data, just stack :) Delving deeply into pedantics, the default stack size for a Win32 CreateThread call is 1MB, but you bump into other limits long before you get to 2048 threads (given the 2GB user-mode address space). -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
