Principle

Design

As we mentioned in user guide, this package speedups python startup by loading python objects from memory mapping, instead of compilation and deserialization from .py[c] files.

There are several factors that block simply memcpy a CPython object to mapped memory.

1. hash randomization in Python. Hash randomization affects memory layout of hash-based container, e.g. dict, so we don't support memory-mapping these types. Instead user could use tuples and construct a dict on demand.

2. ASLR. CPython uses a PyTypeObject* ob_type field to know the type of each object in python. Due to ASLR, the addresses of same type object (e.g. PyLongObject) and constants (e.g. Py_None) are randomly biased in every python instances. To know the type of archived object, addresses of some constants will be stored in the archive, and type pointer will be updated based on ASLR shift.

3. GC

GC issues happen during archive dumping and loading. All archived objects are untracked by PyObject_GC_UnTrack, to prevent being deallocated at the end of dumping stage, their RCs are also biased by 1 to prevent being deallocated in the replayer.

PS: Looking forward to the PEP 683 - Immortal Objects.