Sure there's problems. Unix won and multics lost, and we have half a century of accrued complexity around that, and a couple weekends of hacking isn't going to get us all the way back to a perfect Single Level Store.
Is this something we can and should all switch to? No. The costs are high, it's not practical. But I think over time, especially with the rise of CXL and rdma resurgent, we'll see zero-cooy zero-serialize techniques like this grow back & be huge performance wins for us, be much simpler to handle, even with the adaption we'll have to do.
Like needing to allocate a fixed amount of memory for your whole program upfront or juggling multiple fds.
Or that there is some state you can not carry over even with that and if you try you can easily run into soundness issues.
Or that the state saved might be "in between" operations in a very unexpected way and in turn unsound.
etc.
Can I not do the normal virtual memory thing and allocate far more memory than I actually have hardware for?
> Or that there is some state you can not carry over even with that and if you try you can easily run into soundness issues.
I mean, fair... you're going to have to be careful what you save either way but making saving things the default does seem like more of a footgun.
> Or that the state saved might be "in between" operations in a very unexpected way and in turn unsound.
This applies even if you only use it for some structs? This whole mechanism seems like it would only be sound if it was only used after clean exits.
yes, except maybe if a Drop constructor is run unexpectedly on the exit or similar
generally I think using it with anything which has pointers and/or runs Drop in it is brittle and prone to bugs
in turn most things which do not have pointers should be fine with a clean exit
and anything which only consists of memory where any bit combination is always valid should always be sound even on a abort (e.g. a `[u8]` allocated directly in that memory region or a `[T]` where `T` only has primitive non-allocating types)
I do think though that these patterns of having file descriptors of stuff that can be passed around, and having semi-seamless "just map in the object whole" have a ton of super powered ultra-high performance wins to it that deserve a lot of exploration & effort that justify their pursuit.
But Checkpoint Restore in Userspace/criu just works & is great for fast loading a thing. Still, we need at least some fd passing for apps like no-downtime-restart (or smart draining + SO_REUSEPORT); that's a real need. Going further and passing around memfd's is cool.
It's gotten dropped, but for example Apache Arrow had a Plasma object store for this stuff for a while, that I wish was still on the scene (or something like it). Arrow is a particular data-format with it's own libraries, versus what we have here which is coding-as-usual(-ish); 1/2 patterns. The second might be harder but I still think it has potential.
I'm working on a project now where I'm maintaining half a dozen forks just to add a single line.