Andrew Tridgell's KnightCap did this differently: it's a network chess server, and it would dump its data to a file and re-exec. The trick here is that it would keep the (network) fds open for zero downtime. IIRC he used a Perl script called datadumper to gen the code marshal/demarshal the structures.
This has the advantage that reboots can be handled fairly seemlessly too (though there will be reconnections then of).
Eh, you could probably get away with it if you use BearSSL[0]. The only difficulty would be:
These elements can be allocated anywhere in (writable) memory, e.g.
heap, data segment or stack. They must not be moved while in use
(they may contain pointers to each other and to themselves).
Which you could probably get around with by just keeping track of offsets and using mmap
I did something similar ones as a vs code extension for love2d which I called live2d, so that you could develop your game while it was running. It was incredibly fun, but incredibly hard to use, and nobody had any interest in it, so I abandoned it and lost the source code eventually. But it worked so well. I had invented this thing called magic tables to go along with it and make it easier to use, I forgot what they did, I just remember the name and how cool it was.
This has the advantage that reboots can be handled fairly seemlessly too (though there will be reconnections then of).
https://gist.github.com/kentonv/bc7592af98c68ba2738f44369208...
For those curious research "SCM_RIGHTS" (Socket-Level Control Message) and sendmsg/recvmsg
[0]: https://www.bearssl.org/api1.html
Error handling strategies, and what fallback state things fall into when the hot code breaks, would be great to hear about.