Re: [DotGNU]huge structs with ilrun , problems

[Fergus Henderson]

On 12-Feb-2003, Rhys Weatherley <address@hidden> wrote:
> On Wednesday 12 February 2003 08:42 am, Gopal V wrote:
> > Hey All,
> >     I was looking at some IL code from somewhere which used a large
> > struct of about 40000 bytes which was causing StackOverflowExceptions
> > for ilrun. I did what every bug hunter does -- wrote a binary search
> > test suite to hit upon the magic number where the bug starts . So here
> > it is .
> >
> > char big[32732]; // works
> > char very_big[32733]; // StackOverflowException
> 
> The size of a thread's stack is fixed at startup time, as realloc'ing it is 
> not an option - any managed pointers to variables on the stack would point at 
> dead air after the realloc, leading to crashes.

Yes.  Actually it's even worse than that.  If it was just managed pointers that
you had to worry about, it might be possible for the GC to update those
pointers when moving the stack.  But there might also be *unmanaged* pointers
to variables on the stack, and unmanaged pointers are indistinguishable from
integers -- the CLR engine isn't allowed to modify the integer value of those
unmanaged pointers.

> > What could be a good solution to this problem ? ..
> 
> We could perhaps add some detection code to the CVM coder that looks for large
> local variables and moves them out into the heap.  e.g. instead of allocating 
> the variable directly in the stack, it stores a pointer to a GC-allocated 
> block in the stack.

That is only valid provided that you are using a non-moving GC (which
currently you are).  But as you say, that doesn't solve the problem in
general.  I think using a linked list of stack sections (or something
similar) is about the only complete solution, but as well as being
difficult to implement, there might also be performance costs to that.

-- 
Fergus Henderson <address@hidden>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.