Continuing from where we left of last time, I would like to discuss how we can build growing allocators using a virtual memory system. This post describes how to build a stack-like allocator that can automatically grow up to a given maximum size.
Before we can delve into the inner workings of growing allocators, I would like to explain the concept of virtual memory and discuss what it is, why it is needed, and what we can use it for.
As promised last time, today we will see how pool allocators can help with allocating/freeing allocations of a certain size, in any order, in O(1) time.
Last time, we were looking at a linear allocator, probably the simplest of all memory allocators. This time, we will detail how to implement a non-growing stack-like allocator, along with conventional use-cases.
During the next few weeks, I’d like to detail how the memory allocators inside Molecule work, starting with a simple, non-growing linear allocator today in order to cover some base first.
This is the final installment in a series of posts about Molecule’s memory system. Today, we are going to look at the final piece of the puzzle, glueing together different things like raw memory allocation, bounds checking, memory tracking, and more.
In the last few installments of the Memory system series, we were mostly concerned with how ordinary memory allocation using new and delete works internally, and how we can build our own tools to provide additional functionality. One thing we haven’t discussed yet are the memory arenas which are responsible for actually allocating memory, while providing additional things like bounds checking, memory tracking, etc.
Continuing from where we left off last time, we’re about to optimize our NewArray and DeleteArray function templates for POD-types this time. Let’s start easy by talking about the implementation itself first, and then putting pieces of the puzzle together one by one. Following is the implementation of the function templates NewArrayPOD and DeleteArrayPOD:
In the last installment of the memory system series, we covered how new, delete, and their variants work. This time, we’re going to build our own little toolset which allows us to create new instances (or arrays of instances) of any type using custom allocator classes in a standards-compliant way. Be prepared for some function templates, type-based dispatching, template magic, and nifty macros.
Before we can really delve into the inner workings of the Molecule Engine’s memory system, we need to cover some base ground first. Today, we’re taking a very thorough look at new, delete, and all their friends. There are some surprising subleties involved, and judging from the interviews I conducted, sometimes even senior level staff messes up questions regarding the inner workings of new and delete.
