Virtual memory management.

Overview

AsmJit's virtual memory management is divided into two main categories:

Low level API that provides cross-platform abstractions for virtual memory allocation. Implemented in VirtMem namespace.
High level API that makes it very easy to store generated code for execution. See JitRuntime, which is used by many examples for its simplicity and easy integration with CodeHolder. There is also JitAllocator, which lays somewhere between RAW memory allocation and JitRuntime.

Namespaces

VirtMem

Classes

struct JitAllocator::Impl

struct JitAllocator::CreateParams

struct JitAllocator::Statistics

class JitAllocator

class JitRuntime

struct VirtMem::Info

struct VirtMem::DualMapping

struct VirtMem::HardenedRuntimeInfo

class VirtMem::ProtectJitReadWriteScope

Enumerations

enum JitAllocatorOptions : uint32_t

Enumeration Type Documentation

JitAllocatorOptions : uint32_tenumstrong¶

Options used by JitAllocator.

Constant	Description
kNone	No options.
kUseDualMapping	Enables the use of an anonymous memory-mapped memory that is mapped into two buffers having a different pointer. The first buffer has read and execute permissions and the second buffer has read+write permissions. See VirtMem::allocDualMapping() for more details about this feature. Remarks Dual mapping would be automatically turned on by JitAllocator in case of hardened runtime that enforces `W^X` policy, so specifying this flag is essentually forcing to use dual mapped pages even when RWX pages can be allocated and dual mapping is not necessary.
kUseMultiplePools	Enables the use of multiple pools with increasing granularity instead of a single pool. This flag would enable 3 internal pools in total having 64, 128, and 256 bytes granularity. This feature is only recommended for users that generate a lot of code and would like to minimize the overhead of `JitAllocator` itself by having blocks of different allocation granularities. Using this feature only for few allocations won't pay off as the allocator may need to create more blocks initially before it can take the advantage of variable block granularity.
kFillUnusedMemory	Always fill reserved memory by a fill-pattern. Causes a new block to be cleared by the fill pattern and freshly released memory to be cleared before making it ready for another use.
kImmediateRelease	When this flag is set the allocator would immediately release unused blocks during `release()` or `reset()`. When this flag is not set the allocator would keep one empty block in each pool to prevent excessive virtual memory allocations and deallocations in border cases, which involve constantly allocating and deallocating a single block caused by repetitive calling `alloc()` and `release()` when the allocator has either no blocks or have all blocks fully occupied.
kCustomFillPattern	Use a custom fill pattern, must be combined with `kFlagFillUnusedMemory`.