wondering about my VM and whether i should ape the WASM memory model (memory is just pages of bytes, good luck! if you need more then you can request more pages which get tacked onto the end) or if i should take a page from the old Amiga block and basically provide malloc and free as built-in system calls
using just a linear memory space certainly makes strict bounds checking faster/easier
it'd also make my format more compatible with webassembly, i guess. not sure how important that is when you can just transpile to C and then compile to wasm from there
i would really like to be able to avoid making everything that builds on this VM have to implement its own malloc, but the only way i can see to effectively sandbox a program is to give it linear memory starting at a certain address, so that all memory operations can simply be checked against the upper bounds of the linear memory
but if i do that, then either the VM has to supply a custom malloc with first-class heaps over that linear memory, or the program itself needs to provide it
which means that there's no way to both sandbox a program properly *and* avoid reinventing the wheel with malloc :| this sucks
@eniko WASM ran into the same problem but worse with "every binary shipping its own GC" and I believe that this is why there's on-going design work on a sort of shared GC API that isn't necessarily a whole GC, but provides a bunch of mechanisms to share one across different WASM 'processes' without breaking sandboxing.
I forgot the details but perhaps there is something of interest in there for the issue you're having?
@joepie91 yeah, GC is its own bucket of issues