Virtual Memory

Virtual memory management.


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.




Enumeration Type Documentation

JitAllocatorOptions : uint32_tenumstrong

Options used by JitAllocator.


No options.


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.

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.

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.


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.


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.


Use a custom fill pattern, must be combined with kFlagFillUnusedMemory.