Frequently Asked Questions for Appel & Li's paper "Virtual memory
primitives for user programs"

Q: What is the relationship of the garbage collector to the OS?

A: No direct relation. The garbage collector is part of a language
runtime (e.g., Python or Go runtime). The python interpreter, for
example, runs as a user program, on top of the kernel, and one
component of the interpreter is the garbage collector.  Unlike in C,
in these languages the developer doesn't have to call malloc/free to
manage memory but the language garbage collector manages memory for
the developer.  This avoids many common programming mistakes such as
double free, use after free, etc.

Q: What GC algorithm does Python use?

A: Cpython, a common python interpreter uses several different garbage
collector implementations (see
https://github.com/python/cpython/blob/main/InternalDocs/garbage_collector.md).
One of them is a generational one.

Q: Do page faults work correctly on pipelined processors?

A: Today's CPUs provide what is called "precise" interrupts, which
guarantee that the save process state corresponds to a sequential CPU
that completes one instruction before starting on the next one.
Implementing precise interrupts in a pipelined processor is
nontrivial.

Q: Who keeps track if a page is dirty?

A: The hardware typically keeps track of whether a page has been
written too (dirtied).  For example, the RISC-V maitains a Dirty bit
in the PTE (see figure 3-2 in the xv6 text). Many operating systems
don't make that bit visible to user applications, however; the paper
argues that is a shame because user applications could benefit from
it.

Q: Are data page compression algorithms for VM used in practice?

A: Check out https://en.wikipedia.org/wiki/Virtual_memory_compression
for a history of developments, and recent usages, including Android
(https://developer.android.com/topic/performance/memory-management),
which uses Linux's zram.

Q: Is it possible to combine concurrent and generational garbage collection?

A: Yes,  see, for example: https://dl.acm.org/doi/pdf/10.1145/96709.96735

Q: Why doesn't xv6 support user VM primitives? How would we go about
adding this feature??

A: Because xv6 goal is to be a minimal educational OS. You will
implement, however, some user-level VM primitives in the mmap lab.

Q: How relevant is the information about disk locality (and some of
the other assumptions made in the paper) with the developments of
flash memory?

A: Less so. Access times to flash memory are much lower than to
magnetic disks. Yet, flash memory is still orders of magnitude slower
than RAM, so it still matters.

Q: Would there be a tradeoff between cross-platform compatibility and
user-level algorithms aimed specifically at things like Prot1 vs ProtN?
Or do modern programs write separate low-level code for each, or do
modern OSes all implement a similar set of primitives?

A: Modern OSes implement a similar set of primitives; check out mmap,
munmap, sigaction, and related systems calls (e.g., run ``man mmap''
on the command line).

Q: How often does checkpointing happen? Every time a thread needs
writes to memory, does the OS have to checkpoint by saving the
writable main memory space for the program and restart all threads?:

A: It is up to the application to chose how often to
checkpoint---checkpointing every write doesn't make sense because it
is too costly; you should think more in terms of many minutes time
frame. For example, you may want to checkpoint a long-running compute
application periodically so that you don't have to start from scratch
in case the computer crashes.

Q: How exactly is data compressed and uncompressed in the
 data-compression paging scheme?

A: Using a compression algorithm. zram (see above) uses zstd
(https://en.wikipedia.org/wiki/Zstd).

Q: I'm also not clear about intuition behind why we translate between
32-bit and 64-bit addresses for pointers to extend addressability.

A: This example is a bit arcane given that today pointers on most CPU
are 64 bits.

Q: What exactly is a mutator and a collector?

A: This is garbage-collector jargon: the mutator is an application
program (say a python program) that has objects and read/writes them,
and the collector is a component of the runtime doing the garbage
collection.

Q: How does the OS guarantee security when the user mode can specify a
fault handler?

A: The kernel forwards the page faults to the process who experienced
the fault.  Thus, a process sees only its own page faults and can
modify only its own address space.  If the handler has a bug, then the
process may crash, but only that processes crashes.

Q: When are persistent stores used?

A: A file system is an example of a persistent store.  The persistent
store in the paper extends persistence to objects of a running
program, so that the developer doesn't explicitly have to persist
objects (i.e., invoke file system calls).  It is not a super popular
idea currently but some systems provide it.

Q: How much do vm techniques affect database implementations
currently?

A: Databases commonly use mmap to map databases files into the address
space of the database server so that the database can rely on the OS
page cache for caching blocks of the file (instead of having to
implement its own buffer cache and potentially suffer double
buffering). There are some interesting critiques of using mmap for
databases; for example, see https://db.cs.cmu.edu/mmap-cidr2022/.

Q: How are persistent stores that haven't been saved to the disk recovered in
the instance of a crash?

A: Often they support transactions to update a group of objects
atomically.  The transaction system typically uses logging.  From
today's paper perspective crash-safety is an orthogonal issue.