Re: alloca / _alloca / dynamic stack memory

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Read my second post under Doug Harrison where I talk about the prepending
memory header, how we plan to get rid of the Dispose/DisposeArray methods,
and some more justification for this approach. I talk about how to keep the
same new/delete semantics.

If we have a type called Foo that dynamically allocates an internal variable
on the heap, then to allocate Foo the default new operator needs to be called
twice...two calls are being made to malloc indirectly...the thread will
contend with a shared lock twice. If we used new(StackAlloc) or new(Heap),
the thread may only hit one lock during allocation (assuming the heap passes
is exclusive to the current thread). This should introduce a small perf tune
if done thousands of times. So even though the size is fixed, it may help to
use new(StackAlloc) or new(Heap).



"Tom Widmer [VC++ MVP]" wrote:

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

.

Relevant Pages

  • Re: mex-file and reference
    ... Since my program uses a big structure defined in C to handle every meaningful variables, I thinks it is why references are used. ... "A pointer has its own memory address and size on the stack, whereas a reference shares the same memory address but also takes up some space on the stack. ... Heap access is NOT slower than stack ... However, once allocation is done, accessing both heap and stack ...
    (comp.soft-sys.matlab)
  • Memory problems - WinDbg and SOS: Who recognizes this pattern?
    ... Last night I managed to get a memory dump using ADPlus and I analyzed it ... ephemeral segment allocation context: none ... Large object heap starts at 0x0a0d0030 ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Tip Required on Dynamic Memory Allocation in Server Applications ...
    ... a memory allocation failure after 300 usages of the string ... Suggestions where given to pre-reserve the size of the heap, ... My program works untill 200-300 requests are ...
    (microsoft.public.win32.programmer.kernel)
  • Re: function "&" for strings type cause memory problem.
    ... > and I allocate the large object in heap memory in previous case. ... Memory allocation is always a risk. ... There is no difference between stack and heap here. ...
    (comp.lang.ada)
  • Re: Competing criteria
    ... solution to "not heap allocation" is to define a reasonable maximum count ... memory allocation will not fail due to memory fragmentation, ... If you have some memory left over, you might want to switch to making a heap request when your preallocated buffers are exhausted, in this case since you are now allowed to fail, you are ok. ... To the degree that you can't preallocate as efficiently as you think you might be able to use the heap, consider that the cost for getting the guarantee. ...
    (comp.lang.c)