add allocation metering to XS

[warner]

What is the Problem Being Solved?

To switch to XS, we need to protect dynamic vats against code that allocates so much memory that the process crashes (because the host computer cannot supply enough virtual memory space, due to a ulimit setting or limited RAM+swap space), or the host computer goes into a swap thrash (preventing progress of other vats). We want the xsnap worker to signal a metering fault before it starts to cause problems.

The Moddable folks tell us that xsnap's fxAbort(XS_NOT_ENOUGH_MEMORY_EXIT) will be called if malloc ever fails, and at that point the engine state is probably toast (we really need to call c_exit(status) to terminate the process, because returning from fxAbort() is going to lead to null pointer dereferences and such). If fxAbort() is called with different status codes (e.g. XS_TOO_MUCH_COMPUTATION_EXIT), then it may be safe to return from fxAbort(), and/or call fxExitToHost() to tell the engine to unwind the JS stack and return from the top-level engine invocation (preserving the ability to make more invocations in the future).

It sounds like fxExitToHost() does a longjmp. So the way to instrument memory allocation will be:

• change the allocator we give to XS to increment a big counter with the requested size
• if this counter overflows the allocation limit, call fxExitToHost(), which will not return (from the point of view of the caller: it longjmps away)
• XS doesn't currently free() the memory until the entire engine terminates, so we never decrement the counter
  • which is good, because we don't know the size of that memory chunk, so wouldn't know how much to decrement it by

The allocator is controlled by xsnap.h when it does #define mxUseDefaultChunkAllocation 1 and mxUseDefaultSlotAllocation. When set, these tell https://github.com/Moddable-OpenSource/moddable/blob/4ae91266ad4a9a4370e335d3904834ccccc3c5dc/xs/sources/xsPlatforms.c#L116-L143 to use c_malloc()/c_free(). I'm guessing we want to delete those #defines and instead implement our own fxAllocateChunks, fxFreeChunks (which can be a no-op), fxAllocateSlots, and fxFreeSlots.

I think that will be complete, at least as far as the heap is concerned. We'll need to investigate the stack as well, but I'm pretty sure that's already covered (our fxAbort handles an XS_STACK_OVERFLOW_EXIT status value).

[warner]

I'll try my hand at this and will drag in @dckc and @michaelfig when I inevitably get stuck.

[dckc]

@warner here's a preview in case you're interested; I think it came out OK:

• cbe63dc feat(xsnap): specify exit codes for meter exhaustion etc.