[Mono-devel-list] Thread stacks sizes - interpreter vs J

[Bernie Solomon]

After the various replies to my message what I am considering
is making CreateThread take notice of its stacksize argument.
If it is zero use 2Mb/4Mb for 32/64 bits.

Also at the metadata level add a mono_thread_set_default_stacksize
routine to change the default used in the calls to CreateThread
from within metadata. Then the interpreter can set the stack larger
if need be (as I need at present...)

As for other configuration options wouldn't it be better to
have this in an apps config file than in an environment variable?

As for the size. The HP compiler generates a stack frame
of about 3k for the interpreter main routine - that is the statically
calculated size - alloca will increase this at runtime. This is because
every variable is separately allocated on the stack even if by scoping
rules two variables can use the same slot. So the only way of reducing
this is by moving variables up to the top of the routine and reusing
them wherever possible at the source level. This is definitely not my
preference in terms of code style but maybe this is a special case
(or if I could find an option to change the compiler behaviour that
would help too...).

Now I happened to try fiddling with stack sizes while building
corlib_test.dll with mcs. It definitely blows a 16Mb stack size. At this
point the stack is 4,600 frames deep which doing the math is about
what you'd expect for that frame size. The bulk of the stack is
in calls to Resolve & DoResolve methods in mcs from various classes.
I am not sure if any implementation of tail calls and making those work
in the interpreter would actually help here or not as I haven't studied
the compiler code to see if the calls can be optimized this way.

So I think everything is actually behaving predictably and for
the moment I'll stick to setting a 32Mb stack at least for the
interpreter on HP.

Bernie Solomon
----- Original Message ----- 
From: "Paolo Molaro" <lupus at ximian.com>
To: <mono-devel-list at lists.ximian.com>
Sent: Monday, October 06, 2003 7:18 AM
Subject: Re: [Mono-devel-list] Thread stacks sizes - interpreter vs J


> On 10/06/03 Dick Porter wrote:
> > On Sat, 2003-10-04 at 11:32, Varga Zoltan wrote:
> > >    I would recommend adding a function to io-layer to set
> > > the default
> > > stack size. The JIT and the interpreter could call it with
> > > different values on startup.
> >
> > We can't add any external API to io-layer that isn't in the w32 API.
>
> There is no need for an additional API entry point: CreateThread already
> has an argument to specify the stack size for the thread, so io-layer
> just needs to be fixed to obey that argument and the entry point could
> be added to metadata/.
>
> > For the stack size, CreateThread sets it because of issues with BSD.  It
> > would probably be best to just conditionally define that and let other
> > platforms use their defaults.
>
> As for the original issue: it makes sense to double the default stack
> size for 64 bit apps, but I'm not sure increasing the stack size for mint
is
> a correct solution: if it requires 30+MB of stack, there is something
> else to fix. I would support using an environment variable to set the
> stack size to non-default values, so that specific apps that may have
> particular demands can be tweaked, both increasing the stack size (mint
> until it's fixed) and decreasing it (think an app server with thousand
> of threads on a 32bit system).
>
> lupus
>
> -- 
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>