mnemosyne-backend 0.5.0

Memory backend contracts for the Mnemosyne allocator
Documentation
  • Coverage
  • 86.67%
    26 out of 30 items documented0 out of 9 items with examples
  • Size
  • Source code size: 112.5 kB This is the summed size of all the files inside the crates.io package for this release.
  • Documentation size: 1.0 MB This is the summed size of all files generated by rustdoc for all configured targets
  • Ø build duration
  • this release: 3s Average build duration of successful builds.
  • all releases: 4s Average build duration of successful builds in releases after 2024-10-23.
  • Links
  • ryancinsight/Mnemosyne
    1 0 1
  • crates.io
  • Dependencies
  • Versions
  • Owners
  • ryancinsight

Low-level OS page allocation backend mapping interface.

The crate is organized by concern so each leaf owns one backend responsibility:

  • [mapping] owns the [MemoryBackendWrapper] struct shape and the single impl MemoryBackend for MemoryBackendWrapper block. allocate / deallocate bodies are inline here; make_guard, page_reset, and decommit delegate into the per-concern helpers in [guard] and [reset] via #[inline(always)] static-dispatch calls.
  • [guard] owns do_make_guard — the per-method helper for PROT_NONE / PAGE_NOACCESS guard-region installation — called by the make_guard entry in [mapping]'s impl block.
  • [reset] owns do_page_reset and do_decommit — the per-method helpers for content-discard and commit-charge release — called by the page_reset and decommit entries in [mapping]'s impl block.
  • [recorders] owns the telemetry counters, the [BackendMemoryStats] snapshot, and the per-concern unit tests for the record_* family.
  • [backends] owns the per-OS / per-platform backend implementations (UnixBackend, WindowsBackend, and the CUDA variants).

Public re-exports at the crate root keep the canonical mnemosyne_backend::CudaUnifiedBackend, MemoryBackendWrapper, and backend_memory_stats paths while backend-specific helpers live under [backends].