Xref: utzoo comp.windows.ms:794 comp.lang.c++:4262
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!haven!umd5!jonnyg
From: jonnyg@umd5.umd.edu (Jon Greenblatt)
Newsgroups: comp.windows.ms,comp.lang.c++
Subject: Re: Glockenspiel C++ (Memory allocation for C++ in general)
Message-ID: <5158@umd5.umd.edu>
Date: 3 Aug 89 22:30:28 GMT
References: <5157@umd5.umd.edu>
Reply-To: jonnyg@umd5.umd.edu (Jon Greenblatt)
Organization: University of Maryland, College Park
Lines: 36

In article <5157@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes:
>
>1: Usage of too many memory handles. I plan to put in a memory allocator
>	I wrote for Xlisp to get around this problem.
>
>
>						JonnyG.


	Would anyone have a use for the memory allocator when I port it?
I was able to crash windows very easily be creating too many C++ objects.
CommonView allocates a new block of memory from windows everytime memory is
needed or a new object is created. Any real app would blow away windows under
this usage. The default is to allocate memory from the local heap but there
are provisions to allocate from the global heap. There are problems and
inefficiencies associated with both types of allocations when a lot of
space is used or too many handles are used. My system uses 4-7 bytes of
extra storage for each item allocated which is much lower than the overhead
for global storage. Local storage in MS Windows is more efficient than
global but it is easy to blow an application out of the water when too much
is allocated (No warnings, MS Windows dies completely). Handles to memory
still have to be stored even with local memory so there is still overhead.

	Other systems may be able to take advantage of this type allocator.
Since apps under oops may have a tendency to use a lot of small chunks of
dynamicaly allocated memory, my small memory allocator may prove usefull
on other architectures. Under UNIX and most C based systems memory is allocated
using a leat square algorithm. Where as this algoithm is fast, it wastes
a lot of memory when creating a lot of small incongruent objects.

	I know I am not the first to come up with the better allocator but I
have been using this under Xlisp for a few months and it preforms very
efficiently. I have put this out in PD domain before and am willing to do
so again. Any takers?

						JonnyG.