Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!ninja!killer!chasm
From: chasm@killer.DALLAS.TX.US (Charles Marslett)
Newsgroups: comp.sys.atari.st
Subject: Re: Malloc (was Re: Another great quote from Mr. Good)
Summary: Can someone explain the problem here?
Message-ID: <5283@killer.DALLAS.TX.US>
Date: 24 Aug 88 07:23:02 GMT
References: <1116@atari.UUCP} <692@auvax.UUCP} <1121@atari.UUCP> <402@clio.math.lsa.umich.edu>
Distribution: comp
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 48

In article <402@clio.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) writes:
> I get the feeling that there really is no solution at this point. How can you
> have two different versions of Malloc/Free in the same system? Consider how
> this would work. Assume a new ROM with TOS and GEMDOS that use the new, fixed
> Malloc. Consider starting an old application from this new GEM desktop. Both
> memory allocators will have to be rewritten to know exactly what each other
> is doing, or you get programs tromping all over each other. And since you really
> can't change the old version of Malloc, what you're really going to have to do
> is write the new Malloc such that it allocates memory in such a way that the
> old Malloc will honor its allocations. Anything using the old Malloc will still
> eat up memory, will still need to be freed in the correct order or else you
> lose. It'd be pretty gross. Having two incompatible memory allocators active
> in the same system just can't be a good idea... It's not just a question of
> a single program only sticking to one version - it's a question of many
> programs being able to be loaded up arbitrarily, bearing in mind that the OS
> itself is probably using the new allocator.
>                                Howard Chu

I fail to see the problem -- I am almost always running with three malloc's
active at a time now, so four is not such an unreasonable leap of faith.

The obvious way is to have a Malloc_new that allocates two kinds of blocks:
real ones and Malloc_old blocks that are really double blocks (one that is
contiguous with the previous Malloc_old and the other that is used to keep
track of it).  The only reason for two schemes is that the garbage collection
and overhead of the remote header may get expensive.  Then if a program uses
the old Malloc function, his memory may get fragmented and he may have the
same old problems (but we want to be compatible, right (:^) ... and if the
program uses only the new functions memory does not fade away.

An alternative is to use Malloc_old as the master Malloc, and have some kind
of initialization call that would tell Malloc_new to grab all available memory
-- one big Malloc, so we can't return it in the wrong order (:^) -- and parcel
it out using a reasonable algorithm.  This is in fact what my programs do now
-- I let MWC grab what it need to support the run time library, then I gram
all that is left (less several hundred bytes, just in case) and from then
on run my own memory allocator.  Not a crash in a million mallocs!

So what am I missing?  I admit there are probably problems with running
a shell that uses one Malloc underneath a shell using the other (spawning
subprocesses is a really nasty problem with this scheme, but it never
really worked before, so I see that as not much of a real problem), is
there another?

Enquiring minds want to know!

Charles Marslett
chasm@killer.dallas.tx.us