RVM, a recoverable virtual memory implementation, was designed with lessons learned from Camelot in mind. The biggest design principle in its creation was simpicity over generality, which led to RVM's lack of support for nesting, distribution, and concurrency control, along with its being decoupled from the operating system. RVM uses logging and allows no-flush transactions and has a memory allocator and segment loader layered on top of it. RVM uses external data segments as backing stores for recoverable memory and only transfers committed changes to these external segments, allowing for no-undo/redo logging.
It was impressive to hear that RVM had actually been in use for two years prior to the paper's writing. As the authors point out, however, RVM has a weak point in that programmers must explicitly remember to make a set_range call if they want the memory modifications to be restored in the event of failure. This scenario could be easily remedied during compilation or post-compilation stages.
No comments:
Post a Comment