[context] Why does boost::ctx::minimum_stacksize() on Windows return 65536
Hey all, Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).as px). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On Sat, Sep 1, 2012 at 7:01 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Hey all,
Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).as px).
A thread's minimum stack size is Windows' allocation granularity, which is not the size of a single page. Currently this is 64KB. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.aspx VirtualAlloc also rounds up allocations to this granularity. If you request 4KB, you'll actually waste a lot of space and get 64KB. The allocation granularity can be determined using GetSystemInfo(). -- Cory Nelson http://int64.org
Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs. 85).as px).
A thread's minimum stack size is Windows' allocation granularity, which is not the size of a single page. Currently this is 64KB. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.aspx
VirtualAlloc also rounds up allocations to this granularity. If you request 4KB, you'll actually waste a lot of space and get 64KB.
The allocation granularity can be determined using GetSystemInfo().
This is definitely true for the stack allocated by CreateThread, CreateFiber et.al. However there is no limitation in actually using a smaller stack in Boost.Context as it allocates the stack outside of CreateThread or CreateFiber, directly using VirtalAlloc. The docs of VirtualAlloc specify that the minimal (enforced) allocation size there is 4k - i.e. the page size (see the link I provided above). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On Sat, Sep 1, 2012 at 8:50 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs. 85).as px).
A thread's minimum stack size is Windows' allocation granularity, which is not the size of a single page. Currently this is 64KB. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.aspx
VirtualAlloc also rounds up allocations to this granularity. If you request 4KB, you'll actually waste a lot of space and get 64KB.
The allocation granularity can be determined using GetSystemInfo().
This is definitely true for the stack allocated by CreateThread, CreateFiber et.al. However there is no limitation in actually using a smaller stack in Boost.Context as it allocates the stack outside of CreateThread or CreateFiber, directly using VirtalAlloc.
The docs of VirtualAlloc specify that the minimal (enforced) allocation size there is 4k - i.e. the page size (see the link I provided above).
For VirtualAlloc, reserves are allocation granularity based and commits are page based. For Context to use VirtualAlloc and give you 4KB without wasting 60KB, it'd have to build its own allocator and might as well just use malloc/new. -- Cory Nelson http://int64.org
Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en- us/library/windows/desktop/aa366887(v=vs. 85).as px).
A thread's minimum stack size is Windows' allocation granularity, which is not the size of a single page. Currently this is 64KB. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.aspx
VirtualAlloc also rounds up allocations to this granularity. If you request 4KB, you'll actually waste a lot of space and get 64KB.
The allocation granularity can be determined using GetSystemInfo().
This is definitely true for the stack allocated by CreateThread, CreateFiber et.al. However there is no limitation in actually using a smaller stack in Boost.Context as it allocates the stack outside of CreateThread or CreateFiber, directly using VirtalAlloc.
The docs of VirtualAlloc specify that the minimal (enforced) allocation size there is 4k - i.e. the page size (see the link I provided above).
For VirtualAlloc, reserves are allocation granularity based and commits are page based.
The docs say: <quote> lpAddress: The starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. </quote> That means the starting address (only if specified) is aligned with the allocation granularity, not the allocated size. Further: <quote> dwSize: The size of the region, in bytes. If the lpAddress parameter is NULL, this value is rounded up to the next page boundary. Otherwise, the allocated pages include all pages containing one or more bytes in the range from lpAddress to lpAddress+dwSize. </quote> This implies that if lpAddress is NULL the function allocates minimally 4k.
For Context to use VirtualAlloc and give you 4KB without wasting 60KB, it'd have to build its own allocator and might as well just use malloc/new.
You're not 'wasting' 60k. Those are never committed in the first place. Besides, what would be so bad in building your own allocator or using malloc/new just as well? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On Sat, Sep 1, 2012 at 9:56 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en- us/library/windows/desktop/aa366887(v=vs. 85).as px).
A thread's minimum stack size is Windows' allocation granularity, which is not the size of a single page. Currently this is 64KB. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.aspx
VirtualAlloc also rounds up allocations to this granularity. If you request 4KB, you'll actually waste a lot of space and get 64KB.
The allocation granularity can be determined using GetSystemInfo().
This is definitely true for the stack allocated by CreateThread, CreateFiber et.al. However there is no limitation in actually using a smaller stack in Boost.Context as it allocates the stack outside of CreateThread or CreateFiber, directly using VirtalAlloc.
The docs of VirtualAlloc specify that the minimal (enforced) allocation size there is 4k - i.e. the page size (see the link I provided above).
For VirtualAlloc, reserves are allocation granularity based and commits are page based.
The docs say:
<quote> lpAddress: The starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. </quote>
That means the starting address (only if specified) is aligned with the allocation granularity, not the allocated size.
Further:
<quote> dwSize: The size of the region, in bytes. If the lpAddress parameter is NULL, this value is rounded up to the next page boundary. Otherwise, the allocated pages include all pages containing one or more bytes in the range from lpAddress to lpAddress+dwSize. </quote>
This implies that if lpAddress is NULL the function allocates minimally 4k.
For Context to use VirtualAlloc and give you 4KB without wasting 60KB, it'd have to build its own allocator and might as well just use malloc/new.
You're not 'wasting' 60k. Those are never committed in the first place.
Those with a 32-bit address space might have issue with something wasting 90% of it.
Besides, what would be so bad in building your own allocator or using malloc/new just as well?
A custom allocator could be good. malloc/new might be feasible if you're not worried about possibly sharing pages with other contexts. -- Cory Nelson http://int64.org
On Sat, Sep 1, 2012 at 9:56 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en- us/library/windows/desktop/aa366887(v=vs. 85).as px).
A thread's minimum stack size is Windows' allocation granularity, which is not the size of a single page. Currently this is 64KB. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.a spx
VirtualAlloc also rounds up allocations to this granularity. If you request 4KB, you'll actually waste a lot of space and get 64KB.
The allocation granularity can be determined using GetSystemInfo().
This is definitely true for the stack allocated by CreateThread, CreateFiber et.al. However there is no limitation in actually using a smaller stack in Boost.Context as it allocates the stack outside of CreateThread or CreateFiber, directly using VirtalAlloc.
The docs of VirtualAlloc specify that the minimal (enforced) allocation size there is 4k - i.e. the page size (see the link I provided above).
For VirtualAlloc, reserves are allocation granularity based and commits are page based.
The docs say:
<quote> lpAddress: The starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. </quote>
That means the starting address (only if specified) is aligned with the allocation granularity, not the allocated size.
Further:
<quote> dwSize: The size of the region, in bytes. If the lpAddress parameter is NULL, this value is rounded up to the next page boundary. Otherwise, the allocated pages include all pages containing one or more bytes in the range from lpAddress to lpAddress+dwSize. </quote>
This implies that if lpAddress is NULL the function allocates minimally
4k.
For Context to use VirtualAlloc and give you 4KB without wasting 60KB, it'd have to build its own allocator and might as well just use malloc/new.
You're not 'wasting' 60k. Those are never committed in the first place.
Those with a 32-bit address space might have issue with something wasting 90% of it.
As I said, you're not 'wasting' it if you're planning on using 4k stack space only anyways.
Besides, what would be so bad in building your own allocator or using malloc/new just as well?
A custom allocator could be good. malloc/new might be feasible if you're not worried about possibly sharing pages with other contexts.
Ok. So what's your point? My initial question still stands: Why is this (too large) minimum stack size limit imposed on me by the library? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On Sun, Sep 2, 2012 at 8:52 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
On Sat, Sep 1, 2012 at 9:56 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
> Why is the minimally possible stack size in Boost.Context on > Windows set to be 64k? This seems to be way too high for > applications where only a minimal amount of stack is required. I > assume, that since Boost.Context allocates the stack using > VirtualAlloc the minimum possible value should be equal to the > page size (see http://msdn.microsoft.com/en- us/library/windows/desktop/aa366887(v=vs. > 85).as > px).
A thread's minimum stack size is Windows' allocation granularity, which is not the size of a single page. Currently this is 64KB. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.a spx
VirtualAlloc also rounds up allocations to this granularity. If you request 4KB, you'll actually waste a lot of space and get 64KB.
The allocation granularity can be determined using GetSystemInfo().
This is definitely true for the stack allocated by CreateThread, CreateFiber et.al. However there is no limitation in actually using a smaller stack in Boost.Context as it allocates the stack outside of CreateThread or CreateFiber, directly using VirtalAlloc.
The docs of VirtualAlloc specify that the minimal (enforced) allocation size there is 4k - i.e. the page size (see the link I provided above).
For VirtualAlloc, reserves are allocation granularity based and commits are page based.
The docs say:
<quote> lpAddress: The starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. </quote>
That means the starting address (only if specified) is aligned with the allocation granularity, not the allocated size.
Further:
<quote> dwSize: The size of the region, in bytes. If the lpAddress parameter is NULL, this value is rounded up to the next page boundary. Otherwise, the allocated pages include all pages containing one or more bytes in the range from lpAddress to lpAddress+dwSize. </quote>
This implies that if lpAddress is NULL the function allocates minimally
4k.
For Context to use VirtualAlloc and give you 4KB without wasting 60KB, it'd have to build its own allocator and might as well just use malloc/new.
You're not 'wasting' 60k. Those are never committed in the first place.
Those with a 32-bit address space might have issue with something wasting 90% of it.
As I said, you're not 'wasting' it if you're planning on using 4k stack space only anyways.
You're reserving 64KB and committing 4KB of it. That 60KB of reserved space will not be usable by other contexts or allocators. The committed memory usage of the app will still only be 4KB so you're not wasting physical memory, but yes, you are definitely wasting address space. It's frighteningly easy to run up against the limits of a 32-bit address space, and this type of usage would severely and pointlessly limit the number of contexts you can create. I speak from experience, I've made this mistake with VirtualAlloc before. I'm not trying to make your life harder!
Besides, what would be so bad in building your own allocator or using malloc/new just as well?
A custom allocator could be good. malloc/new might be feasible if you're not worried about possibly sharing pages with other contexts.
Ok. So what's your point?
You asked my opinion about custom allocators and malloc/new, so I gave it. Was yours a rhetorical question?
My initial question still stands: Why is this (too large) minimum stack size limit imposed on me by the library?
I agree. -- Cory Nelson http://int64.org
> > Why is the minimally possible stack size in Boost.Context on > > Windows set to be 64k? This seems to be way too high for > > applications where only a minimal amount of stack is > > required. I assume, that since Boost.Context allocates the > > stack using VirtualAlloc the minimum possible value should be > > equal to the page size (see http://msdn.microsoft.com/en- us/library/windows/desktop/aa366887(v=vs. > > 85).as > > px). > > A thread's minimum stack size is Windows' allocation > granularity, which is not the size of a single page. Currently this is 64KB. > See > http://msdn.microsoft.com/en-us/library/windows/desktop/ms68677 > 4.a > spx > > VirtualAlloc also rounds up allocations to this granularity. If > you request 4KB, you'll actually waste a lot of space and get 64KB. > > The allocation granularity can be determined using GetSystemInfo().
This is definitely true for the stack allocated by CreateThread, CreateFiber et.al. However there is no limitation in actually using a smaller stack in Boost.Context as it allocates the stack outside of CreateThread or CreateFiber, directly using VirtalAlloc.
The docs of VirtualAlloc specify that the minimal (enforced) allocation size there is 4k - i.e. the page size (see the link I provided above).
For VirtualAlloc, reserves are allocation granularity based and commits are page based.
The docs say:
<quote> lpAddress: The starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. </quote>
That means the starting address (only if specified) is aligned with the allocation granularity, not the allocated size.
Further:
<quote> dwSize: The size of the region, in bytes. If the lpAddress parameter is NULL, this value is rounded up to the next page boundary. Otherwise, the allocated pages include all pages containing one or more bytes in the range from lpAddress to lpAddress+dwSize. </quote>
This implies that if lpAddress is NULL the function allocates minimally 4k.
For Context to use VirtualAlloc and give you 4KB without wasting 60KB, it'd have to build its own allocator and might as well just use malloc/new.
You're not 'wasting' 60k. Those are never committed in the first place.
Those with a 32-bit address space might have issue with something wasting 90% of it.
As I said, you're not 'wasting' it if you're planning on using 4k stack space only anyways.
You're reserving 64KB and committing 4KB of it. That 60KB of reserved space will not be usable by other contexts or allocators. The committed memory usage of the app will still only be 4KB so you're not wasting physical memory, but yes, you are definitely wasting address space. It's frighteningly easy to run up against the limits of a 32-bit address space, and this type of usage would severely and pointlessly limit the number of contexts you can create.
I speak from experience, I've made this mistake with VirtualAlloc before. I'm not trying to make your life harder!
Sure, I fully understand the implications. So as it turns out, while my suggestion 'wastes' address space (only), the current library forces me to 'waste' reserved memory even if I'm not planning to use it (granted, the memory will probably never be committed, but it still has to be reserved by the system, e.g. it adds to the memory footprint of my application). If I know I'm on a 64bit system and I only need 4k or 8k stack space, and I know that I will create millions of stacks, I still prefer not to have to implement my own allocator just to be able to get a optimal allocation strategy.
Besides, what would be so bad in building your own allocator or using malloc/new just as well?
A custom allocator could be good. malloc/new might be feasible if you're not worried about possibly sharing pages with other contexts.
Ok. So what's your point?
You asked my opinion about custom allocators and malloc/new, so I gave it. Was yours a rhetorical question?
You started the discussion wrt a custom allocator, not me.
My initial question still stands: Why is this (too large) minimum stack size limit imposed on me by the library?
I agree.
Good. That makes two of us not being happy with the current setup. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Am 02.09.2012 02:01, schrieb Hartmut Kaiser:
Hey all,
Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).as px).
boost.context provides a default implementation of a stack-allocator (class stack_allocator) which appends each stack a guard page (guard pages will not be mapped to physical pages - you don't was memory). Function VirtualProtect() is used to set the 'guard' flag on the page and requires VirtualAlloc(). I decided to provide the same stacksize as Win32 Fiber API does - which is system's allocation granularity (64kB; using GetSystemInfo() ). If context's default stack allocation does not satisfy your requirements you can easily implement and use your own stack allocator together with make_fcontext()/jump_fcontext(). regards, Oliver
Oliver,
Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs. 85).as px).
boost.context provides a default implementation of a stack-allocator (class stack_allocator) which appends each stack a guard page (guard pages will not be mapped to physical pages - you don't was memory). Function VirtualProtect() is used to set the 'guard' flag on the page and requires VirtualAlloc().
I don't see how that info relates to my question, sorry. Even if I need only 4k of stack space (or 8k, or whatever), I still would like to get the guard page detecting stack overruns.
I decided to provide the same stacksize as Win32 Fiber API does - which is system's allocation granularity (64kB; using GetSystemInfo() ).
CreateFiberEx allows specifying committed and reserved stack sizes (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682406(v=vs.85).a spx)
If context's default stack allocation does not satisfy your requirements you can easily implement and use your own stack allocator together with make_fcontext()/jump_fcontext().
I understand that I can implement my own allocator. But why should I be forced to do so if all I need to change is to remove the check for the minimal stack size. The constraint you're trying to enforce is something belonging into the documentation, not the code. The current implementation just makes your library less usable for people knowing what they're doing. BTW, on an unrelated note: I think the ctx::minimum_stacksize() and ctx::maximum_stacksize() functions should be tied to the allocator. They should not be global as they will return wrong numbers if a custom allocator is used. But that's just IMHO. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Am 02.09.2012 19:32, schrieb Hartmut Kaiser:
I don't see how that info relates to my question, sorry. Even if I need only 4k of stack space (or 8k, or whatever), I still would like to get the guard page detecting stack overruns. My target development platform is POSIX - not Windows; maybe my understanding of the related MSDN articles was not correct.
But why should I be forced to do so if all I need to change is to remove the check for the minimal stack size. The constraint you're trying to enforce is something belonging into the documentation, not the code. You are referring to the precondition in maximum_stacksize()? The documentation of maximum_stacksize() contains the info that is_stack_unbounded() returns false as precondition.
BTW, on an unrelated note: I think the ctx::minimum_stacksize() and ctx::maximum_stacksize() functions should be tied to the allocator. They should not be global as they will return wrong numbers if a custom allocator is used. good point - both functions should be part of the stack_allocator interface. I'll change it asap.
What are the minimum and maximum stacksize on the several Windows versions (XP, 7, 8, Ce, R, ...)? I didn't found infos in the MSDN about this issue. Maybe pagesize? SUggestions? Oliver
Oliver,
I don't see how that info relates to my question, sorry. Even if I need only 4k of stack space (or 8k, or whatever), I still would like to get the guard page detecting stack overruns. My target development platform is POSIX - not Windows; maybe my understanding of the related MSDN articles was not correct.
I think you got everything right except for the assumption that everybody wants to reserve stacks of 64k size or more.
But why should I be forced to do so if all I need to change is to remove the check for the minimal stack size. The constraint you're trying to enforce is something belonging into the documentation, not the code. You are referring to the precondition in maximum_stacksize()? The documentation of maximum_stacksize() contains the info that is_stack_unbounded() returns false as precondition.
I'm referring to my initial question: Why does the library enforce a minimum stack size of 64k on Windows if all I need are 4k + guard page.
BTW, on an unrelated note: I think the ctx::minimum_stacksize() and ctx::maximum_stacksize() functions should be tied to the allocator. They should not be global as they will return wrong numbers if a custom allocator is used. good point - both functions should be part of the stack_allocator interface. I'll change it asap.
What are the minimum and maximum stacksize on the several Windows versions (XP, 7, 8, Ce, R, ...)? I didn't found infos in the MSDN about this issue. Maybe pagesize? SUggestions?
Well, I can't answer this question. All I know is that VirtualAlloc does not allow allocating less than a page, regardless of the (Windows) system. Thus I assume the minimal stack size in Boost.Context should be a page as well (well, plus guard page). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Am 02.09.2012 20:11, schrieb Hartmut Kaiser:
Oliver,
BTW, on an unrelated note: I think the ctx::minimum_stacksize() and ctx::maximum_stacksize() functions should be tied to the allocator. They should not be global as they will return wrong numbers if a custom allocator is used. good point - both functions should be part of the stack_allocator interface. I'll change it asap.
What are the minimum and maximum stacksize on the several Windows versions (XP, 7, 8, Ce, R, ...)? I didn't found infos in the MSDN about this issue. Maybe pagesize? SUggestions? Well, I can't answer this question. All I know is that VirtualAlloc does not allow allocating less than a page, regardless of the (Windows) system. Thus I assume the minimal stack size in Boost.Context should be a page as well (well, plus guard page).
OK - following suggestion for Windows: minimum_stacksize()/maximum_stacksize() will be static member funcs of class stack_allocator. minimum_stacksize() returns pagesize + 1kB maximum_stacksize() returns 1GB (but will never useable) default_stacksize() returns 64 kB is_stack_unbounded() will always return true for all Windows versions stack_allocator creates a guard page at the lower end of the stack. maximum_stacksize() still has ! is_stack_unbounded() as preconditon - which means you will/can never use the value returned by maximum_stacksize() until I find some informations about those limit in the MSDN (for the several Windows flavours). What do you think? Oliver
BTW, on an unrelated note: I think the ctx::minimum_stacksize() and ctx::maximum_stacksize() functions should be tied to the allocator. They should not be global as they will return wrong numbers if a custom allocator is used. good point - both functions should be part of the stack_allocator interface. I'll change it asap.
What are the minimum and maximum stacksize on the several Windows versions (XP, 7, 8, Ce, R, ...)? I didn't found infos in the MSDN about this issue. Maybe pagesize? SUggestions? Well, I can't answer this question. All I know is that VirtualAlloc does not allow allocating less than a page, regardless of the (Windows) system. Thus I assume the minimal stack size in Boost.Context should be a page as well (well, plus guard page).
OK - following suggestion for Windows:
minimum_stacksize()/maximum_stacksize() will be static member funcs of class stack_allocator. minimum_stacksize() returns pagesize + 1kB
Why + 1kb? Shouldn't the guard page have 4k as well?
maximum_stacksize() returns 1GB (but will never useable) default_stacksize() returns 64 kB is_stack_unbounded() will always return true for all Windows versions
stack_allocator creates a guard page at the lower end of the stack. maximum_stacksize() still has ! is_stack_unbounded() as preconditon - which means you will/can never use the value returned by maximum_stacksize() until I find some informations about those limit in the MSDN (for the several Windows flavours).
What do you think?
Sounds good to me. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
OK - following suggestion for Windows:
minimum_stacksize()/maximum_stacksize() will be static member funcs of class stack_allocator. minimum_stacksize() returns pagesize + 1kB
Why + 1kb? Shouldn't the guard page have 4k as well?
Am 02.09.2012 20:27, schrieb Hartmut Kaiser: pagesize == reserved for guard page 1kb usable for application but you can argument that VirtualAlloc will use a multiple of pagesize Oliver
Am 02.09.2012 20:27, schrieb Hartmut Kaiser:
OK - following suggestion for Windows:
minimum_stacksize()/maximum_stacksize() will be static member funcs of class stack_allocator. minimum_stacksize() returns pagesize + 1kB Why + 1kb? Shouldn't the guard page have 4k as well?
maximum_stacksize() returns 1GB (but will never useable) default_stacksize() returns 64 kB is_stack_unbounded() will always return true for all Windows versions
stack_allocator creates a guard page at the lower end of the stack. maximum_stacksize() still has ! is_stack_unbounded() as preconditon - which means you will/can never use the value returned by maximum_stacksize() until I find some informations about those limit in the MSDN (for the several Windows flavours).
What do you think?
After some tests I got exceptions thrown by Windows because the stack was too small (8kB). The simple example 'jump.exe' didn't work. I've concerns that users of boost.context will complain that their apps do not work (because of a too small stack) and call boost.context garbage.
OK - following suggestion for Windows:
minimum_stacksize()/maximum_stacksize() will be static member funcs of class stack_allocator. minimum_stacksize() returns pagesize + 1kB
Why + 1kb? Shouldn't the guard page have 4k as well?
maximum_stacksize() returns 1GB (but will never useable) default_stacksize() returns 64 kB is_stack_unbounded() will always return true for all Windows versions
stack_allocator creates a guard page at the lower end of the stack. maximum_stacksize() still has ! is_stack_unbounded() as preconditon - which means you will/can never use the value returned by maximum_stacksize() until I find some informations about those limit in the MSDN (for the several Windows flavours).
What do you think?
After some tests I got exceptions thrown by Windows because the stack was too small (8kB). The simple example 'jump.exe' didn't work. I've concerns that users of boost.context will complain that their apps do not work (because of a too small stack) and call boost.context garbage.
Yes, they will call it garbage. So just give them the megabytes they (think that they) need! It will be difficult to please all the people all the time. For example, I will be pleading for fine granularity of the stack size with sizes as small as 32 bytes. That's right, I really said 32 bytes! You want my opinion? Everyone will just assume that it works. And they will for the most part be using giant PCs and work stations. So just setup the default, naive stack with a few megabytes and allow for expert fine-tuned granularity down to small stack sizes with expert methods. Document these briefly. Sincerely, Chris.
Am 02.09.2012 20:11, schrieb Hartmut Kaiser:
good point - both functions should be part of the stack_allocator interface. I'll change it asap.
What are the minimum and maximum stacksize on the several Windows versions (XP, 7, 8, Ce, R, ...)? I didn't found infos in the MSDN about this issue. Maybe pagesize? SUggestions? Well, I can't answer this question. All I know is that VirtualAlloc does not allow allocating less than a page, regardless of the (Windows) system. Thus I assume the minimal stack size in Boost.Context should be a page as well (well, plus guard page).
revision 80375 contains suggested modifications - x64 Windows required a stacksize larger than 8kB (exception handling raises exception otherwise). Oliver
participants (4)
-
Christopher Kormanyos -
Cory Nelson -
Hartmut Kaiser -
Oliver Kowalke