CS262A Reading Summary 7

Lightweight Recoverable Virtual Memory

M. Satyanarayanan et al
Summary by Feng Zhou
9/19/2002

1. RVM emphasize a lot on portability and simplicity. This is very different from the papers I have already read on VM. The most important characteristic of RVM is that it is purely a library, using standard(Unix) OS interface. This bring up the question of the trade-off between tightly integration and portability, which occurs whenever we design a system. Another perspective on the same issue is mainstream systems are almost always not perfect. However to solve the problems in a revelutional way that changes the interface is often unsuccessful. VM is a good example of this. Approaches like ACPM are very attractive. However they are never widely used.
2. RVM try to solve the problem of lacking transaction support in OSes in a non-obtrusive way, which the authurs call lightweight. Transaction support is useful to a plethora of applications. So a portable library is very helpful.
3. The use of a no-undo/redo logging strategy simplifies the implementation a lot. Thus before-image never needs to be recorded on disk. OS VM is used to provide unlimited buffer space. Although this incurs performance penalty because excessive paging will happen when buffer space becomes larger than system memory, it ensures that RVM will always work. The options of restore/no-restore, flush/no-flush also give applications more choice over the compromise between performance and semantic integrity.

One major flaw:

I think Incremental Truncation (page 7) is not explained very clearly in the paper. Its details of working and implications on transaction semantics are not clarified enough, although I think they are very important issues. One specific problem is what should the system do in the following situation. Two xacts: T1 & T2, both changing a page P. T2 is after T1. Both T1 and T2 commit. T1 has already been flushed to the log while T2 is not(commit with no_flush). The question is shall the log truncation writes P to external pages now? It should not because the in-memory page contains "dirty" data that's not in the log. If system should crash after the write, there will be no way to undo the change. However the data structure presented does not maintain this flag on pages. It cannot be the reserved flag because the text below figure 7 says it can write out P1 although there is a reserved flag on P1. It is also different from Uncommitted Ref Count.