[SoC 2007] Custom Memory Heaps and Object Allocators

[c4llidus]

Thanks for the input btmorex,
My understanding of the mechanism of delete is that the version with size_t is implicitly called if it is defined, this is certainly the case with the exaple code I have created. It sounds like your referring to the no-throw version of delete defined as :-

void operator delete(void*, const nothrow_t&) throw();

This indeed needs to be called explicitly as you describe. The overload of single parameter delete works as expected and is employed to direct deallocations to the global allocator presently. The lack of size info is going to be a pain for some allocator types though.

I'm pretty sure you can overload the nothrow versions too. afaik, you can't overload placement versions. For example, this is from the <new> header on my system:

Code: Select all

/** These are replaceable signatures:
 *  - normal single new and delete (no arguments, throw @c bad_alloc on error)
 *  - normal array new and delete (same)
 *  - @c nothrow single new and delete (take a @c nothrow argument, return
 *    @c NULL on error)
 *  - @c nothrow array new and delete (same)
 *
 *  Placement new and delete signatures (take a memory address argument,
 *  does nothing) may not be replaced by a user's program.
*/
void* operator new(std::size_t) throw (std::bad_alloc);
void* operator new[](std::size_t) throw (std::bad_alloc);
void operator delete(void*) throw();
void operator delete[](void*) throw();
void* operator new(std::size_t, const std::nothrow_t&) throw();
void* operator new[](std::size_t, const std::nothrow_t&) throw();
void operator delete(void*, const std::nothrow_t&) throw();
void operator delete[](void*, const std::nothrow_t&) throw();

// Default placement versions of operator new.
inline void* operator new(std::size_t, void* __p) throw() { return __p; }
inline void* operator new[](std::size_t, void* __p) throw() { return __p; }

// Default placement versions of operator delete.
inline void  operator delete  (void*, void*) throw() { }
inline void  operator delete[](void*, void*) throw() { }

Of particular note: "Placement new and delete signatures (take a memory address argument, does nothing) may not be replaced by a user's program."

yes, the placement version of delete can't be overloaded and is only ever called by the compiler in very specific situations, or explicitly. The nothrow versions can be overloaded but they need to be called explicitly afaik.

If defined then the version of delete taking the second std::size_t parameter is invoked via a standard 'delete some_pointer;', the value of the second parameter being generated by the wonderful power of compiler magic, or not in this case

[steven]

I hope you DON'T use a heap per thread because I found a bad news.

I was looking how to make my Memory Mgr thread safe.

So I thought TWO seconds and I said to myself I should "use a heap for each thread" ... Seems obvious, no?

I thought about that one year ago but hadn't the time to implement it.

Now after simple google I fall on THAT : http://www.patentstorm.us/patents/7111294.html
A patent issued on sept 06 on "thread-specific heap"

What the f***...
Are the legislators so stupid they can't see what is obvious!

America will fall because of all those legislations.

[c4llidus]

Wow , thanks for the input, hummm I'll have to give that some brain time, i wander how specific it is. Maybe it wont apply to having a load of small heaps some of which just happen to belong to thread A and some to thread B. I also think that HOARD and maybe Heap Layers both use this technique

I agree with you on the software patent stuff, complete lunacy.

[steven]

@c4llidus Your implementation is very probably different enough that you will not be liable. Microsoft is using some specific ideas (shared memory, threadnew, ...). I didn't see anything about policy btw.

The underlying work seems to be http://www.cs.purdue.edu/homes/hosking/ ... sgaard.pdf

What drives me mad is that I don't have the time to review all the existing patents in the world each time I write a single line of code and verify that I don't breach a patent!

[c4llidus]

@steven Yeah, I agree, I didn't even think of looking for this sort of thing. Im guessing it can be a real easy gotcha

[Project5]

Hoard does use a per thread heap, and if I recall correctly is older than that Patent. You'd need to read it through to check that some of the Hoard guys aren't on the author list though.

--Ben

[c4llidus]

Well I guess GSoC 07 is mostly over now, its been fun Of course there is still a lot to do to this project yet and I'm looking forward to continuing work on it and involvement with OGRE

@project5 thanks for the confirmation, I have emailed Emery Berger (main author of HOARD) during this project with a few questions, so I'll fire off another mail to get info on this.

Whats been done:
- A main generic memory manager to handle ::new/::delete and to back up specific allocators.
- A small object specific allocator policy
- Thread safe memory profiling framework
- Memory allocator framework
- Inheritable base class for easy use

What needs to be done:
- optimisation to the allocators
- per-thread stuff, see wiki
- plenty of bug fixing im sure
- refactoring of MemProfileManager to make it more robust
- simplification of the interaction between memory profilers and the manager
- hooking up more OGRE objects to use specific allocators, I have tried this with the smallAllocPolicy and SceneNode and Renderable objects

Anyone who would like to give feedback on this would be very welcome, the project is still under heavy development though so expect stuff to change.

[xavier]

What's the current status on this?

[sinbad]

I'm chasing Tim up on this, he had said he'd wanted to carry on, but I know he moved house, got engaged and has a fairly busy final year so was giving him a bit of space initially.

[sinbad]

He's still intending on continuing with it, but has just way too much work on at uni apparantly. Hopefully in the new year, but in the meantime if you want to get involved that's good.

[danien]

Just a couple of things to add:

1) The delete keyword always calls the single argument version of operator delete. Overloaded operator delete functions are automatically called when the object's constructor throws an exception while using a corresponding operator new with the same argument signature. See http://www.parashift.com/c++-faq-lite/d ... #faq-11.14 (Problem #1)

2) I tried to implement a memory allocator framework that allowed run-time plugin allocators but came across an issue with deferred instantiation of static objects which I'm not sure how to resolve.

Code: Select all

// From FreeImage, TagLib.cpp
TagLib& 
TagLib::instance() {
	static TagLib s;
	return s;
}

Instead of exposing the static instance of TagLib as a global, it was placed inside a global accessor function, allowing it to be created only when the function is first called. While this avoids the issue of un-guaranteed order of initialization of static objects, it also means that construction and destruction order are now harder to "match up".

For example, suppose we have the following:

Code: Select all

// Install our memory allocator at run-time.
oldAllocator = SetMemoryAllocator( myAllocator );
...

// Someone calls TagLib::instance for the very first time.
TagLib::instance(); // This creates the static instance of TagLib using our custom allocator.
...

// Shutting down. Uninstall our custom allocator. Or perhaps someone switches to another allocator.
SetMemoryAllocator( oldAllocator );
...

// Program ends and the C/C++ run-time cleans up, destroying all static objects.
// The static instance of TagLib will now be destructed and its memory freed using the old allocator (or a different one)!!!

Hope someone can come up with a better design that prevents this. In the meantime, I think I'll have to switch back to compile-time determination of allocators.

[sinbad]

You might want to try SVN branch 'v1-6', I've been incorporating a new memory allocator framework there based on a mixture of influences, including last years GSoC work. See this thread.

[danien]

Thank you. I'll check that out.