Mind leaving this as NonNull to avoid the cognitive overhead of using SendSyncPtr?

(un-resolving this since this is still SendSyncPtr?)

Oh huh, I guess I lost this in a rebase or something, because I definitely undid this change at one point

Should this be inverted? First GC then maybe grow if necessary?

We want to grow first because

1. it is usually cheaper (just updating the accessible region of a mapping; even copying bytes to a new region is also cheaper) and

2. if we swapped the order, then we could hit the following pathological case:

   // Assume: the GC heap has capacity for N objects, and we have N-1
   // objects allocated and held alive.
   
   // Allocate an object, now the GC heap is at capacity. We do not keep the
   // object live, however.
   drop(allocate());
   
   loop {
       // Upon entry of this loop, the GC heap is at capacity.
   
       // Allocate another object. This triggers a collect-or-else-grow, the
       // collection reclaims the previously allocated object, and then this
       // allocation succeeds without needing to grow the heap.
       drop(allocate());
   
       // At the end of this loop, the GC heap is still at capacity.
   }

   This scenario means we will trigger a GC on every allocation inside the loop which is super pathological. We should really only enter into this kind of behavior when there really is no more memory we can give the GC heap (and even then, the embedder probably wants to cancel the execution via async epochs/fuel at some point; may eventually make sense to add a GC limiter style API).

That makes sense, but isn't this current behavior pathological too? GC heaps will, by default, balloon to 4G before a GC ever runs?

This makes me think that there's not an ideal answer one way or the other, but picking either extreme seems bad?

I think growing to the limit before doing GC is actually what you want: you don't want to do GC if you can avoid it. Growing the heap is faster than doing a GC. There are knobs for limiting the max size of memories, including the GC heap, so unbounded growth isn't really a concern (also there is a hard bound of 4 GiB since the GC heap is a 32-bit memory). And we are likely going to throw away the whole store, and the GC heap along with it, before we ever need to collect, and doing that is also much faster than doing a collection.