[Gen]

I have maybe a week before I'll be busy again with the general flow of work, so let's keep the ball rolling by starting a discussion regarding memory management.

Now, before we can have a general resource manager, we need a means to manage memory. Smart pointers is a good start on this, however we may want to access things from a pool at times, or store different objects or even individual attributes in containers in memory for access later on for the purposes of caching different assets at runtime (like, say, virtual texturing where we would have many smaller tiles loaded into memory that are then pushed into VRAM when they're needed).

So here's an initial proposal.

As it stands, we now have smart pointers with reference counting. We should automatically delete most objects once their reference count reaches zero, since a lot of objects we don't want to keep in memory at all times. There can be exceptions though, for things like cached data.

One idea would be to store all objects in unique pools for different purposes, using MEPointer as an interface to add and remove things from the pool. Each pool could be allocated at the global scope, either as a static member of a class or as a global variable, with MEPointer taking an optional additional parameter in its constructor for what memory pool the pointer should be allocated in. It could work something like this:

MEMemPool gBadnikPool;
void MEBadnik::newBadnik(MEModel &badnikModel)
{
    MEPointer<MEBadnik> badnik = new MEPointer<MEBadnik>(gBadnikPool); // Allocate our new badnik in the global badnik memory pool
    badnik->mModel = badnikModel;
}

void MEBadnik::killBadnik(long poolLocation)
{
    gBadnikPool.destroyAt(poolLocation); // Assume gBadnikPool will call our deconstructor for MEBadnik, thus deallocating the badnik at this specific location in the pool, and dereferencing its model asset.
}

There's several other means of managing memory here, and how this could potentially interface with the memory manager.

I'm hereby opening the floor to discussion with regards to how the memory manager should be designed and implemented. Do note that the memory manager will mostly be used for caching different data, helping to instance assets that have already been loaded into memory.

This post has been edited by Gen: 14 April 2012 - 09:12 PM

[erbuka]

Do we really need smart pointers and reference count? I was thinking that the memory manager should only hold the information about all allocated resources:

class MEResource
{
public:
	MEResource(void);
	~MEResource(void);
	
	virtual unsigned int GetUsedSystemMemory() = 0; 
};

MEResource::MEResource(void)
{
	MEMemoryManager::AddResource(this);
}


MEResource::~MEResource(void)
{
	MEMemoryManager::RemoveResource(this);
}

All the resources inherits from the MEResource class. The default constructor/destructor tells the memory manager that something is being allocated. Subclasses should extend MEResource like this:

class ByteBuffer : public MEResource {
private:
	char * data;	
	int size;
	char staticData[16];
public:
	ByteBuffer(int size) {
		this->data = new char[size];
		this->size = size;
		ZeroMemory(this->data, size);
	}
	
	~ByteBuffer() {
		delete[] this->data;
	}

	unsigned int GetUsedSystemMemory() {
		return sizeof(*this) + size;
	}
};

And about the memory manager, it could be something like this:

class MEMemoryManager
{
private:

	static std::vector<MEResource*> resources;

	MEMemoryManager(void);

	static void AddResource(MEResource * resource);
	static void RemoveResource(MEResource * resource);
public:
	
	static unsigned int GetUsedSystemMemory();

	~MEMemoryManager(void);

	friend class MEResource;
};

[Gen]

erbuka, on 15 April 2012 - 07:29 AM, said:

Do we really need smart pointers and reference count? I was thinking that the memory manager should only hold the information about all allocated resources:

Smart pointers with reference counting tends to come in handy a lot of the time for mitigating memory leakage. Just because you know when to delete something in code, doesn't necessarily mean some other random coder will.

Regarding memory manager, different memory management techniques have proven performance benefits with regards to execution time and reducing memory fragmentation. This is especially important when we'll likely be caching a lot of geometry and texture data in system memory at some point in time.

[Relick]

Bit of an old topic, but I thought I'd bring it up again as it is pretty important. What Gen posted in the first post, is the best option for this IMO.

Also I think we should consider to start implementing it at the same time we implement model loading - so its easier to manage and then its also done ready for level loading/phsyics etc.