Lumberyard memory management

I'm not a Lumberyard dev and I'm not too familiar with how Unreal handled memory allocations but I believe the answer is that Lumberyard does offer a lot of control over C++ memory allocations. I agree there's not a lot of information on how different types of allocators work though even in the actual code. I haven't tested the performance of the Lumberyard memory allocation system either but in theory it looks like it should be much faster and work well with multiple threads. Lumberyard does have a few default allocators that can be specified but in a multi-threaded environment you may prefer having more allocators to reduce the chance of synchronization conflicts. The pool allocators in Lumberyard are probably much faster than a generic Garbage Collector due to reduced synchronization issues but I'm guessing the memory usage is higher than a generic Garbage Collector as a result. There is some garbage collection functionality in the Lumberyard allocators based on what I've seen in the code.

If you look in /dev/Code/Framework/AzCore/AzCore/Memory/PoolAllocator.h you can get a general idea on how to create additional allocators, pool allocators for small objects in the example below. Every Class usually has an AZ_CLASS_ALLOCATOR macro which overloads all the new/delete calls to use a certain allocator. You also may want to use "aznew", which is recommended in the code somewhere, instead of "new" when doing allocations which includes some extra debugging information based on compile settings I think but I haven't looked into the specifics. I usually use my own pool allocator base class just to reduce some needless redundancy like providing a description for every unique allocator and to cut down on the name length of the class being inherited. The last InitPool function I added below is just a custom one I use to configure the allocator during creation since in my case I only used it to allocate a single class type so the size was always the same. I think 4096 was the max/default page size for pool allocators but you can pre-allocate a few pages as well if needed in the Create function which usually needs called in the System Component initialization or before the allocator would ever get used for obvious reasons.

    class YourNamespace::PoolAllocatorBase : public AZ::ThreadPoolBase<AZ::ThreadPoolAllocator>
{
public:
const char* GetDescription() const override
{
return "Generic thread safe pool allocator for small objects";
}
};
class YourNamespace::YourPoolAllocator : public YourNamespace::PoolAllocatorBase
{
public:
AZ_TYPE_INFO(YourPoolAllocator, "{Insert Unique UUID Here}")
AZ_CLASS_ALLOCATOR(YourPoolAllocator, AZ::SystemAllocator, 0)
public:
const char* GetName() const override
{
return "YourNamespace::YourPoolAllocator";
}
};
class YourNamespace::YourClass
{
public:
AZ_TYPE_INFO(YourClass, "{Insert Unique UUID Here}")
AZ_CLASS_ALLOCATOR(YourClass, YourPoolAllocator, 0)
...
};
template<typename PoolName, typename PoolData>
void InitPool(AZ::u32 numPages = 0)
{
PoolName::Descriptor cDesc;
cDesc.m_pageSize = 4096;
cDesc.m_numStaticPages = numPages;
cDesc.m_minAllocationSize = sizeof(PoolData);
cDesc.m_maxAllocationSize = sizeof(PoolData);
AZ::AllocatorInstance<PoolName>::Create(cDesc);
}