No disagreement there, especially with emphasis on "modest".  My point
is that your entire process shares a single virtual address space.  Even
though using the stack prevents fragmentation, it doesn't necessarily
get around other memory space limitations.

In particular, either the stack has a fixed limit in size, in which case
putting large things on it isn't a good idea, or the stack has a dynamic
limit in size, affected by what else is in the virtual address space in
your process.  In this latter case, allocations in the heap and
especially fragmentation in the heap, can still easily affect how large
your stack can get.

Let's take an imaginary situation, in which the heap grows from the 0
offset of the process's available virtual address space and the stack
grows from the very end of that virtual address space.

Let's also assume that you have successfully fragmented the heap such
that there is not single contiguous block of address space available.
This means that between the last block used by the heap and the first
block used by the stack, there is not enough room for the desired
allocation.

In this case, it doesn't matter where you try to allocate the block, it
won't succeed.  The stack can't grow down far enough, and there's not
enough room left in the heap.

Now, let's assume that having failed the allocation, you have the
ability to go through and do some cleanup (for example, perhaps the
fragmenting blocks in the heap are eligible for garbage collection).

Let's also assume that within the heap, so many of the fragmenting
blocks can be freed that enough room can be made for the desired allocation.

Let's also assume that last fragmenting block, nearest the stack, could
not be freed.

In this case, a heap allocation will succeed while a stack allocation
will not.

Now, I realize that the example is over-simplistic, and I realize it may
not reflect the exact nature of memory layout for a .NET program.  But
the underlying mechanisms are still valid and I think the example still
applies.  The stack has a very restrictive nature, and it can fail in
fragile ways, whereas the heap is more dynamic and has the ability to
recover to some extent from fragmentation.

The stack, even though it itself doesn't wind up fragmented per se, is
still susceptible to fragmentation, so unless the only thing that's
likely to cause fragmentation is the thing you're allocating on the
stack, using the stack for that one thing doesn't necessarily buy you
much.  Even worse, all it takes is a single poorly-placed heap
allocation for fragmentation to break stack allocations, whereas you
need to fragment a large portion of the entire virtual address space to
break heap allocations.

I will also point out another little gotcha: a very large object on the
stack incurs a significant performance hit, because of the way that
detection of stack problems on Windows works.  In particular, Windows
has a stack observer that considers a non-contiguous access of an
element on the stack to be a problem.  If you allocate something very
large on the stack, the potential exists for a reference to skip a page
of memory.  Windows deals with this by touching all of the new pages
allocated in the address space to ensure that they've been committed and
don't cause the error-detection to be set off.

In your case this should be less of a problem, because one hopes you are
not creating such a large thing on the stack on every call.  But it's
still something to consider.

Anyway, I admit there's some hand-waving there, but my experience has
been that allocating things on the stack is best left for relatively
small local variables.  If you want to allow allocation of large things,
you need to pick a maximum size you'll handle, and always allocate
something that large; otherwise, your code may break well after you've
deployed it, at a time when you can't easily fix it.

Pete