Re: alloca / _alloca / dynamic stack memory

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. 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.

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. I
usually start by finding a memory allocator with the least amount of
contention. If a heap is not associated on a per thread basis, the next best
thing is the stack. However, stack memory is usually very limited, so it may
not be an option is some cases. However, when I need 1 to 10 bytes, the
stack should do just fine. However, the dynamic stack memory can only be
used within the current function...once the function returns, the allocated
memory should be reclaimed.

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
};

// 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
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);

// ...

return 0;
};

"Igor Tandetnik" wrote:

Michael Crawley <MichaelCrawley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Dynamic stack allocation is nice for performance tuning. If an
object is going to be short-lived and is very small, it would be
ideal to not allocate memory from a lock-based memory allocator like
malloc(size_t)

So at this point, why not declare it as a local variable?

Even if you succeed in your endeavor, imagine the user's surprise when
this innocent-looking code breaks:

MyObj* factory() { return new MyObj; }

MyObj* p = factory();
// Do something to p
delete p;

Of course since MyObj was allocated on the stack inside factory, the
memory is reclaimed as soon as factory() returns (without running
MyObj's destructor, to boot). The rest of the code cheerfully works with
garbage.


Can you show a use case where implementing operator new as _alloca might
be beneficial?
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925



.

Relevant Pages

  • 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: C++ Garbage Collector on VMS?
    ... case of a reference counting system, have a non-zero reference count) as ... to the beginning of the heap, updating the pointers to the objects as it ... (segregating allocation areas by type/size can help a lot there, ... any way with GC-controlled memory). ...
    (comp.os.vms)
  • Re: function "&" for strings type cause memory problem.
    ... > its execution state i. Si/|Si| is an average object size. ... >> and I allocate the large object in heap memory in previous case. ... One can ignore allocation issues as long as ... > the heap can be enlarged on demand while the stack not, ...
    (comp.lang.ada)