To ensure atomic replacement of the varTable when growing, we currently use an int-width varTableStamp as a spin lock, incrementing it for each concurrent mutator attempting to grow the table. Only one can win, with the others re-acquiring the table and re-checking its size to accommodate their incoming value.

Using an int is almost certainly excessive; the field is only ever incremented, so the only risk would come from having more than int-range concurrent mutators. Even with virtual threads in play, we're unlikely to see a billion concurrent threads all trying to grow the variable table.

Using a boolean may be too pessimistic, as it would prevent two concurrent threads from updating a table that's already wide enough (we use this atomic mechanism around the entirety of varTable updating, even with it does not need to grow).

We should explore options to shrink or eliminate this field. As an int, it consumes 4 bytes of every object that will rarely be needed, and there may be better, more modern ways for us to atomically update the varTable field that do not involve implementing our own numeric spin lock.