21. Memory protection

21.1. Introduction

.intro: This is the design of the memory protection module.

.readership: Any MPS developer; anyone porting the MPS to a new platform.

.overview: The memory protection module ensures that the mutator sees a consistent view of memory during incremental collection, by applying protection to areas of memory, ensuring that attempts to read or write from those areas cause protection faults, and implementing the means for the MPS to handle these faults.

21.2. Requirements

.req.consistent: Must ensure that the mutator sees a consistent view of memory during incremental collection: in particular, the mutator must never see objects in oldspace. (Otherwise there’s no way for the MPS to interface with uncooperative code.)

.req.prot.read: Should allow collections to proceed incrementally, by read-protecting pages that are not consistent from the mutator’s point of view. (This is the only way for the MPS to meet real-time requirements on pause times.)

.req.prot.write: Should allow the MPS to maintain remembered sets for segments that it has scanned, by write-protecting pages in these segments. (This improves performance by allowing the MPS to avoid scanning these segments again.)

.req.fault.handle: If the module implements protection, it must also provide a mechanism for handling protection faults. (Otherwise the MPS cannot take the correct action: that is, fixing references in a read-protected segment, and discarding the remembered set from a write-protected segment. See TraceSegAccess().)

21.3. Design

.sol.sync: If memory protection is not available, the only way to meet .req.consistent is to ensure that no protection is required, by running the collector until it has no more incremental work to do. (This makes it impossible to meet real-time requirements on pause times, but may be the best that can be done.)

.sol.fault.handle: The protection module handles protection faults by decoding the context of the fault (see design.mps.prmc.req.fault.addr and design.mps.prmc.req.fault.access) and calling ArenaAccess().

21.4. Interface

void ProtSetup(void)

.if.setup: Called exactly once (per process) as part of the initialization of the first arena that is created. It must arrange for the setup and initialization of any data structures or services that are necessary in order to implement the memory protection module.

Size ProtGranularity(void)

.if.granularity: Return the granularity of protection. The base and limit arguments to ProtSet() must be multiples of the protection granularity.

void ProtSet(Addr base, Addr limit, AccessSet mode)

.if.set: Set the protection of the range of memory between base (inclusive) and limit (exclusive) to forbid the specified modes. The addresses base and limit are multiples of the protection granularity. The mode parameter contains the AccessWRITE bit if write accesses to the range are to be forbidden, and contains the AccessREAD bit if read accesses to the range are to be forbidden.

.if.set.read: If the request is to forbid read accesses (that is, AccessREAD is set) then the implemntation may also forbid write accesses, but read accesses must not be forbidden unless AccessREAD is set.

.if.set.noop: ProtSet() is permitted to be a no-op if ProtSync() is implemented.

void ProtSync(Arena arena)

.if.sync: Ensure that the actual protection (as determined by the operating system) of every segment in the arena matches the segment’s protection mode (seg->pm).

.if.sync.noop: ProtSync() is permitted to be a no-op if ProtSet() is implemented.

21.5. Implementations

.impl.an: Generic implementation in protan.c.

.impl.an.set: ProtSet() does nothing.

.impl.an.sync: ProtSync() has no way of changing the protection of a segment, so it simulates faults on all segments that are supposed to be protected, by calling TraceSegAccess(), until it determines that no segments require protection any more. This forces the trace to proceed until it is completed, preventing incremental collection.

.impl.an.sync.issue: This relies on the pool actually removing the protection, otherwise there is an infinite loop here. This is therefore not compatible with implementations of the protection mutator context module that support single-stepping of accesses (see design.mps.prmc.req.fault.step).

.impl.ix: POSIX implementation.

.impl.li: Linux implementation. See design.mps.protli.

.impl.w3: Windows implementation.

.impl.xc: OS X implementation.