Set at least PTHREAD_STACK_MIN stack size when creating threads.

Set at least PTHREAD_STACK_MIN stack size when creating threads.

This patch makes sure, that the stack size of the new threads are never
less than PTHREAD_STACK_MIN, otherwise the pthread_attr_setstacksize()
function sets the default stack size (8MB), which leads to failure
in the BootUpMemoryUse test.

TEST=cctest/test-mark-compact/BootUpMemoryUse
BUG=
R=yangguo@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=17610

[palfia, 2013-11-06 23:54:26]

Hi Yang and Jakob,

Please take a look.

Thanks!

[Yang, 2013-11-07 09:40:08]

On 2013/11/06 23:54:26, palfia wrote:
> Hi Yang and Jakob,
> 
> Please take a look.
> 
> Thanks!

Seems like the right place to compare stack_size_ to PTHREAD_STACK_MIN is at the
place where stack_size_ is initialized as part of Thread constructor.

I would even go even further and just do a CHECK_GE(stack_size_,
PTHREAD_STACK_MIN) so people setting arbitrarily small stack limits are not
surprised it's ignored.

[palfia, 2013-11-07 15:18:29]

Thanks for the review! I've uploaded a new patchset, my answers are below.

On 2013/11/07 09:40:08, Yang wrote:
> On 2013/11/06 23:54:26, palfia wrote:
> > Hi Yang and Jakob,
> > 
> > Please take a look.
> > 
> > Thanks!
> 
> Seems like the right place to compare stack_size_ to PTHREAD_STACK_MIN is at
the
> place where stack_size_ is initialized as part of Thread constructor.

Done.

> I would even go even further and just do a CHECK_GE(stack_size_,
> PTHREAD_STACK_MIN) so people setting arbitrarily small stack limits are not
> surprised it's ignored.

The main problem is that the small stack size value is actually coming from
kSweeperThreadStackSize, kSamplerThreadStackSize and kProfilerStackSize
constants, which are all smaller than the minimal stack size on MIPS (128KB). So
this CHECK would be always false on MIPS.

[Yang, 2013-11-08 08:55:14]

On 2013/11/07 15:18:29, palfia wrote:
> Thanks for the review! I've uploaded a new patchset, my answers are below.
> 
> On 2013/11/07 09:40:08, Yang wrote:
> > On 2013/11/06 23:54:26, palfia wrote:
> > > Hi Yang and Jakob,
> > > 
> > > Please take a look.
> > > 
> > > Thanks!
> > 
> > Seems like the right place to compare stack_size_ to PTHREAD_STACK_MIN is at
> the
> > place where stack_size_ is initialized as part of Thread constructor.
> 
> Done.
> 
> > I would even go even further and just do a CHECK_GE(stack_size_,
> > PTHREAD_STACK_MIN) so people setting arbitrarily small stack limits are not
> > surprised it's ignored.
> 
> The main problem is that the small stack size value is actually coming from
> kSweeperThreadStackSize, kSamplerThreadStackSize and kProfilerStackSize
> constants, which are all smaller than the minimal stack size on MIPS (128KB).
So
> this CHECK would be always false on MIPS.

lgtm.

[palfia, 2013-11-08 17:34:36]

On 2013/11/08 08:55:14, Yang wrote:
> On 2013/11/07 15:18:29, palfia wrote:
> > Thanks for the review! I've uploaded a new patchset, my answers are below.
> > 
> > On 2013/11/07 09:40:08, Yang wrote:
> > > On 2013/11/06 23:54:26, palfia wrote:
> > > > Hi Yang and Jakob,
> > > > 
> > > > Please take a look.
> > > > 
> > > > Thanks!
> > > 
> > > Seems like the right place to compare stack_size_ to PTHREAD_STACK_MIN is
at
> > the
> > > place where stack_size_ is initialized as part of Thread constructor.
> > 
> > Done.
> > 
> > > I would even go even further and just do a CHECK_GE(stack_size_,
> > > PTHREAD_STACK_MIN) so people setting arbitrarily small stack limits are
not
> > > surprised it's ignored.
> > 
> > The main problem is that the small stack size value is actually coming from
> > kSweeperThreadStackSize, kSamplerThreadStackSize and kProfilerStackSize
> > constants, which are all smaller than the minimal stack size on MIPS
(128KB).
> So
> > this CHECK would be always false on MIPS.
> 
> lgtm.

It seems that patchset #2 introduces some test failures on ia32/x64. The
stack_size_ = 0 case means that the thread must use the default stack size, but
this solution replaces the 0 value with PTHREAD_STACK_MIN.

I've uploaded a new patchset which solves these failures.

Please take another look.

[ouggnay, 2013-11-08 20:52:20]

On 2013/11/08 17:34:36, palfia wrote:
> On 2013/11/08 08:55:14, Yang wrote:
> > On 2013/11/07 15:18:29, palfia wrote:
> > > Thanks for the review! I've uploaded a new patchset, my answers are below.
> > > 
> > > On 2013/11/07 09:40:08, Yang wrote:
> > > > On 2013/11/06 23:54:26, palfia wrote:
> > > > > Hi Yang and Jakob,
> > > > > 
> > > > > Please take a look.
> > > > > 
> > > > > Thanks!
> > > > 
> > > > Seems like the right place to compare stack_size_ to PTHREAD_STACK_MIN
is
> at
> > > the
> > > > place where stack_size_ is initialized as part of Thread constructor.
> > > 
> > > Done.
> > > 
> > > > I would even go even further and just do a CHECK_GE(stack_size_,
> > > > PTHREAD_STACK_MIN) so people setting arbitrarily small stack limits are
> not
> > > > surprised it's ignored.
> > > 
> > > The main problem is that the small stack size value is actually coming
from
> > > kSweeperThreadStackSize, kSamplerThreadStackSize and kProfilerStackSize
> > > constants, which are all smaller than the minimal stack size on MIPS
> (128KB).
> > So
> > > this CHECK would be always false on MIPS.
> > 
> > lgtm.
> 
> It seems that patchset #2 introduces some test failures on ia32/x64. The
> stack_size_ = 0 case means that the thread must use the default stack size,
but
> this solution replaces the 0 value with PTHREAD_STACK_MIN.
> 
> I've uploaded a new patchset which solves these failures.
> 
> Please take another look.

lgtm

[palfia, 2013-11-09 00:14:32]

Committed patchset #3 manually as r17610 (presubmit successful).