5.2 KiB
Malloc
Not needed: The provided pseudocode outlines a modified implementation of jemalloc’s memory mapping routines, adapted to work with a custom malloc(sz) allocator. Instead of relying on traditional operating system mechanisms like mmap, the memory allocation is handled using MALLOC(size) -> refer pseudo code implementation.
which refers to a simplified allocator defined earlier. This custom allocator manages a preallocated memory region, aligns the requested size, decrements a memory counter, and returns a pointer with enforced bounds for memory safety. This approach is especially suited for constrained or security-focused environments such as CHERI, where strict control over memory access and deterministic allocation behavior is essential.
The os_pages_map function simulates jemalloc’s low-level page mapping routine. It first checks if a specific address is requested in case relevant to CheriABI where such behavior is disallowed and returns NULL.
If memory overcommitment is allowed it forces the commit flag to true. It then allocates memory using the custom MALLOC(size) function and validates whether the returned pointer matches the requested address (if one was provided). If there’s a mismatch, it unmaps (i.e calling FREE() -> ref algorithm) the memory and returns NULL; otherwise, it returns the allocated pointer.
The pages_map function is a simplified variant that ignores alignment and address constraints. It directly allocates the requested memory size using the internal allocator and returns the result. This is appropriate in scenarios where alignment is either managed elsewhere or not critical.
This approach mentioned above is embeded inside jemallocs strategy of managing memory through arenas and size classes. In jemalloc, memory is divided into chunks, which are further subdivided into runs and regions to handle allocations of various sizes efficiently. By aligning sizes and managing allocations within predefined structures, jemalloc minimizes fragmentation (source: http://hydra.azilian.net/Papers/jemalloc.pdf)
Not needed: The pages_commit_impl function emulates memory commitment, a feature in systems that support lazy memory allocation. It reallocates memory using MALLOC(size) and checks whether the returned pointer matches the expected address. If not, it unmaps the memory and signals failure by returning true; otherwise, it indicates success by returning false.
Not needed: Collectively, these routines demonstrate how jemalloc can be adapted to operate atop a custom memory allocator instead of relying on the OS. This enables jemalloc to function in specialized environments that require stricter memory controls, such as embedded systems or capability-based architectures, while still maintaining its structure and allocation policies.
Free
The os_pages_unmap algorithm represents a customized abstraction of jemallocs memory unmapping routine, designed to integrate with the previously defined simplified free(ptr) implementation. In conventional jemalloc configurations, os_pages_unmap would invoke low-level system calls such as munmap to release virtual memory pages back to the operating system. However, in this adapted version, the function instead delegates the deallocation to a higher-level FREE(addr) -> Point to algorithm implementation
Not needed: routine, which encapsulates memory management within a user-defined allocator, rather than relying on direct interaction with the operating system.
The function begins by enforcing two invariants through assertions: first, that the input address addr is aligned to the operating system's page size (os_page), and second, that the size of the memory region is also a multiple of os_page. These alignment checks are critical for maintaining consistency with jemalloc’s internal page-based memory management semantics and ensuring compatibility with the allocator's expectations.
Following these checks, the memory at the specified address is deallocated via the FREE(addr) operation. As previously defined in the free(ptr) pseudocode, this involves retrieving the size of the allocated region through bounds metadata (reference section) and invoking an internal unmap routine to mark the region as available.
The following changes done to free is embedded inside jemallocs deallocation mechanism, where metadata associated with each allocation (such as size and location) is used to efficiently return memory to the appropriate arena or pool. jemalloc maintains separate metadata structures to track allocations, allowing for quick deallocation and reuse of memory blocks without significant overhead.
Not needed: This design enables jemalloc to operate seamlessly in environments where standard system-level memory operations are either restricted or abstracted away, such as in sandboxed, embedded, or capability-based systems like CHERI.
Not needed: Overall, this approach demonstrates how jemalloc’s modular architecture can be extended to support alternative memory management strategies. By redirecting low-level memory operations to custom allocators, developers can adapt jemalloc to function effectively in constrained or security-critical execution contexts, without compromising on its underlying allocation model or safety guarantees.