102 lines
5.2 KiB
Org Mode
102 lines
5.2 KiB
Org Mode
* 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.
|