Göran isn't talking about locking the heap.  He's point out that the
_entire application_ would have to be paused, so that the array could be
moved.

Memory allocation does already involve coordination between multiple
threads accessing the heap.  Memory allocations are thread-safe.  But
that's not what Göran is pointing out.

His point, and it's correct, is that if you move the array, you need to
go through the application's entire data and update any references to
that array so that they point to the new location.  Before the array is
moved, all of the threads need to be stopped so that they don't execute
code that would use an out-of-date version of the array (or worse,
unallocated memory).

The .NET memory management does, I believe, include functionality to
defragment the heap.  So it does already have this ability to stop
everything and move the objects around.  But it's not something you'd
want to do under normal circumstances.  IMHO, resizing an array isn't
sufficient cause to justify incurring the penalty of performing that
sort of operation.

Now, all of this is a basic consequence of the way the array data
structure works.  Because the instance is itself the location where the
data is stored, you can't resize the array without these hassles.

Other collection classes don't have this limitation.  If you want a
resizable collection, there are those that exist, like the generic
List<> class.  Even there, when you resize the storage for the
collection, you run the risk of having to perform a copy on the entire
data within the collection, resulting in a performance hit.

But this performance hit is relatively small, involving just the
overhead of copying the data, rather than pausing all of the threads of
the entire application and searching all the data structures (or doing
whatever it is the CLR does when it has to defragment the heap...I don't
actually know the specifics).

Furthermore, this can be done in a well-defined manner, rather than
requiring the entire application to be paused while it happens.  The
class isn't thread-safe, so if you have multiple threads using the class
you'd have to explicitly synchronize those threads while any
modification was being made, but that's a much smaller, more
well-defined mechanism than rearranging the heap itself.

Hope that helps.

Pete

Yes, of course. But the code for allocating memory is very simple, so
it's not a problem that one thread at a time can allocate memory. The
code is basically something like:

IntPtr MemAlloc(int size) {
   IntPtr ptr;
   lock (_sync) {
      if (_heapTop - _heapPointer < size) GC.GimmeMoreHeap(size);
      ptr = _heapPointer;
      _heapPointer += size;
   }
   return ptr;
}

There is of course a bit more code to handle the large objects heap and
such, but that's basically it. The allocation part is really simple.
Check that there is room on the heap, and increase a pointer.

As the garbage collector compacts the heap putting the objects back to
back, I think that a TryStretch method would fail almost every time.