Yes this makes sense. Starting out with a suitable initial stack size on different platforms is reasonble. We also found that the way the thread stack gets mapped on Windows and Linux is different ( Windows incrementally maps with a guardpage, whereas Linux maps most of it upfront ). I am surethat several such considerations go into choosing the init size for the IBM VM. We need to tune the init stack sizes too, but this test does not provide enough good data to set these values.
Thanks, Rana On 1/10/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote: > I am not sure that we need to do something about this. The default initial > stack size on Windows is 1M, and that is the recommended init size for real > applications. The fact that our threads start with a larger intial stack > mapped( default ) than RI is a design issue, it is not a bug. We could > start > with 2K and create many more threads! Exactly as Gregory points out, > ultimately we will hit virtual memory limits and fail. The reason the RI > seems to fail less is that the test ends before running out of virtual > memory.On my 32 bit RHEL Linux box, RI fails almost every time with > MegaSpawn, with an identical OOME error message and stack dump. FWIW the IBM VM 'design point' is to create threads on 32-bit Windows with an OS stack size of 32K for just this reason. On all other 32-bit platforms, and 64-bit Windows, the initial size is 256K. Regards, Tim
