🚀 go-pugleaf

In article <1992Sep27.021335.15685@midway.uchicago.edu>, pynq@midway.uchicago.edu writes:
> Speaking of DJGCC, I recently realized something very interesting:
> 
> 	"You don't need malloc!"
> 
> All you have to do is declare a big array (make it 128 megabytes in size)
> (e.g., for character strings, I just do a "char theData[128*1024*1024];")
> and then let GO32 manage it for you.  You can declare as many of these
> big arrays as you want, for each possible data type, and as long as the
> the total amount of space that you actually use doesn't exceed 128M,
> you're golden.

It doesn't sound to me like you're entirely "letting GO32 manage
it for you"; you're still maintaining an array (and presumably a
few pointers) "for each possible data type".

> Basically, what you are doing is throwing the memory management task back to
> the operating system, where it belongs.  IMHO, malloc() and its ilk are
> all a big kludge, forcing the application to do what ought to be done by
> the OS.

You're confusing malloc's semantics with its implementation.  Its
semantics are simple, straightforward, and very much in the Unix
tradition: I want a pointer to this many bytes.  You can also say
(with free) that you're done with some memory.  Not only do these
simple semantics cover a wide range of needs adequately well,
they are also sufficient to allow considerably more sophisticated
underlying management than is typically attempted.  (Steve
Clamage made several good points along these lines in a recent
comp.lang.c thread under the Subject: "Suggestion for an
alternative pointer/handle/memory consept".)

If you want better memory management, you either have to
introduce more (not fewer) primitives for the programmer to
explicitly use (e.g. the Mac's handle locking and unlocking
calls), or use a different language which worries about memory
allocation for you.  If you don't have a way of saying you're
done with some memory, or a language or a garbage collector which
figures it out, there's no way the OS or hardware is going to be
able to do the management it sounds like you're clamoring for.

I will admit that many existing malloc implementations are not
what they could be.  (The biggest deficiencies tend to be the
numerous failure modes in the face of easy-to-make programming
errors; traditional implementations are overly fragile in this
regard.  There was a nice paper on malloc issues, called I
believe "A good malloc is hard to find," written by I believe
Phong Vo and perhaps others, presented at I believe the Summer
'85 Usenix.)  There is no particular reason, however, why a
malloc implementation, in conjunction with OS-level memory
management functions, could not provide sophisticated and
fine-grained management of allocated objects.

I don't think that hauling around multi-megabyte objects within
your program will let the OS or memory management hardware do a
particularly good job of managing that memory (especially in the
face of competing processes): those huge chunks are hardly
fine-grained.

If you really wanted to throw your allegedly kludgey malloc
implementation away, and instead do all of your allocation from a
single huge char array, you could encapsulate the allocation
cleanly, and ensure a bit more portability to boot, with the
following code fragments:

	static char theData[128*1024*1024];
	static char *p = theData;

	void *malloc(size_t size)
	{
	void *ret = p;
	p += size;
	return ret;
	}

	void free(void *p)
	{
	}

This implementation doesn't check for exhaustion of the 128 meg
allocation buffer, because that will clearly never happen :-).
Arranging for it to check, and implementing calloc() and
realloc(), are left as exercises for the reader.

> A note to new readers:  the weasely :-) symbol is frowned upon in this
> group.  Any questions, see Phil Gustafson who will gladly rearrange your
> diodes for you.
> 			- From the AFU FAQ -

Oh, perhaps your proposal wasn't serious at all.

					Steve Summit
					scs@adam.mit.edu