Binary managers
RealKC opened this issue · 3 comments
Currently reqvm simply loads all of the binary in memory at once, this is simple but does not scale. I should consider adding a way for the VM to choose between loading all of the binary in memory or not. Possible "backends":
- memory backed - loads all of the binary into memory. (like what we currently do)
- file backed - does not load the binary in memory but rather stores a file object, jumping is a seek operation
- memory mapped file - maybe, will have to do some research about this stuff.
- handle errors.
- wrap the low level APIs
This is a low priority issue that should wait until higher priority things are done(e.g. the assembler).
Commit 4bedf72 added the binary_manager interface, a vector based implementation of it, and a ifstream based implementation of it. I still should look into memory mapped IO and I'll use this comment to drop some resources about memory mapped IO I'll have to look into later:
- Windows: https://docs.microsoft.com/en-us/windows/win32/memory/file-mapping
- linux: http://man7.org/linux/man-pages/man2/mmap.2.html (is the situation on other *nix'es similar?)
Alright, in 7c00112 I've wrapped the low level APIs for memory mapping into a class that deals with the platform details, but I don't check for errors and/or handle them in any way.
I'll likely want to wrap these errors using the <system_error> facilities. This seems like a nice start for a series about doing exactly that.
The functions whose errors we should wrap:
- Win32:
CreateFileW,GetFileSizeEx,CreateFileMappingA,MapViewOfFile. - POSIX:
open,fstat,mmap.
Would there be any good way to log errors encountered on discarding the (view and) the mapping, and closing the file?
I read that series of blog posts and it seems like the <system_error> facilities require quite a bit of boilerplate and solve a problem I'm not sure I have. I'll write my own exception class to wrap those errors.