Re: alloca / _alloca / dynamic stack memory
Michael Crawley wrote:
The factory model will not work as you suggested. The developer has to know
the difference between allocating on the stack from allocating on the heap.
Dynamic stack allocation is scoped to a specific stack frame. I am
opperating under the assumption our developers have taken CIS101 Introduction
to Programming after graduating from a graduate-level masters program or
better ;-)
Lets say a class is to be allocated dynamically all of the time...perhaps it
has a private/protected destructor, it would be nice to pick and choose which
memory allocator to use at runtime to best suite your needs.
I can think of almost no reason why a particular type should always be
allocated dynamically. This particularly applies to 'value' types like
strings.
If you need to
use this class for a good while or need to be able to pass the object between
threads, then the standard operator new or a new operator that takes a memory
pool of some sort as an argument would do. If we only need to use it within
the current function and we are sure there is enough room on the stack, then
lets not compete for a lock in malloc or a shared heap...lets allocate it on
the stack if each thread does not have their own heap.
Ok, but this is just a very bizarre syntax for allocating it on the
stack in the first place. Why not just:
String s("Perfect");
Hell, the compiler even takes care of calling the destructor for you!
It's also exception safe.
Another way of looking at it is if I sometimes need 1 to 10 bytes and other
times I need 2000+ bytes, I need to find the best place for memory.
This isn't the case you've described so far, seemed to be about
allocating single objects. All non-array objects are of fixed size, so I
can only assume you are talking only about arrays here.
I
usually start by finding a memory allocator with the least amount of
contention.
If you want low contention on heap allocations, you have the option of
an allocator optimized for multithreaded use (e.g. Hoard, google's
TCMalloc, a lock free allocator (e.g.
http://www.cs.chalmers.se/~dcs/nbmalloc.html)).
Defined below is the general direction that I am trying to go. Whether a
class is allocated dynamically on the default heap, a specified heap, or on
the current thread's stack, I want to present all three mechanisms in a
consistant manner for other developers.
class _StackAlloc{};
const _StackAlloc StackAlloc; // Used only to resolve overloaded
method/operator
void* Object::operator new(size_t size, const _StackAlloc& stackAlloc)
{
// Allocation on stack
// ...
// Return Pointer to allocated memory
__asm push pointer onto stack;
__asm jmp (return address); // Jump out of the current stack frame
};
You're obviously going to have to be very careful about alignment.
operator new automatically returns memory suitably aligned for anything
(within reason - SSE style things may need aligned_malloc).
// Calls destructor, but does not free memory until the
// current function returns
void Object::Dispose(const StackAlloc& stackAlloc)
{
// Invoke Distructor
this->~Object(); // Virtual Base destructor
// Perform other operations specific to this
// memory allocation method
// ...
};
class String : public Object
{
public:
// ...
private:
~String(){...}; // Means this type can only be on allocated on dynamic
memory
};
int main()
{
String str("bad"); // Compiler error, cannot access private distructor
That seems to be a big problem. I can't imagine what benefit you think
you are getting from preventing this code, in favour of the machination
below.
String* str1 = new(Heap) String("better"); // Ok
String* str2 = new String("better"); // Ok
String* str3 = new(StackAlloc) String("better"); // OK, faster than
str1/str2
str1->Dispose(Heap);
delete str2; // or maybe str2->Dispose();
str3->Dispose(StackAlloc);
That code will leak memory if any of those allocations fail. One of
C++'s great advantages over other languages is stack based allocation,
with automatic destructor calls. Fighting that is a good way of
castrating the language.
A class that might potentially be useful, is a variable sized array
class that uses the stack (e.g. the equivalent of C99's variable length
arrays). That can be done by writing a custom stack standard allocator
and using it with std::vector. e.g.
template <class T>
class stack_allocator: public std::allocator<T>
{
//constructors, rebind, etc.
T* allocate(std::size_t N)
{
//work out alignment of T, perhaps with boost::align_of
//allocate suitably aligned stack memory, and return it.
}
void deallocate(T* p)
{
//nothing to do!
}
};
typedef std::vector<std::string,
stack_allocator<std::string> > stack_sv;
stack_sv v(n); //n not too big
Alternatively, a specific stack_vector template could be written, with a
private copy constructor and assignment operator to prevent mistakes.
Tom