Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!decvax!decwrl!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: GEMDOS memory allocation
Message-ID: <525@atari.UUCP>
Date: Tue, 20-Jan-87 14:40:15 EST
Article-I.D.: atari.525
Posted: Tue Jan 20 14:40:15 1987
Date-Received: Wed, 21-Jan-87 22:03:51 EST
References: <8701190836.AA05609@ucbvax.Berkeley.EDU>
Organization: Atari Corp., Sunnyvale CA
Lines: 32

*** FLAME ON ***

> has anyone looked into the way that GEMDOS manages memory? 
> ...
> does anyone have any idea where GEMDOS keeps its list?

PLEASE don't go around publishing internal addresses like this requests,
since such addresses are GUARANTEED to change and BREAK programs which
count on them.  Some parts of an operating system are hidden from
view ON PURPOSE, so the OS can be sure that its data structures will
not be fooled with by user programs.

The correct procedure in this kind of situation is to say, "Gee, Atari,
I lose memory over time.. I wonder if there's a problem in the memory
allocator?  Here is an example program which demonstrates the problem..."
I know we won't always have a fix for the problem by next week, but
f**king around with GEMDOS' internal structures will cause more trouble
than it's worth.

*** FLAME OFF ***

As it happens, we know that memory gets fragmented strangely, and the
limit on memory blocks you can Malloc is a function of statically-allocated
data structures.  In future ROMs, we may increase the limit, but we
can't get rid of it without a new, more fragile memory allocator (one which
assumes that you haven't changed memory locations immediately before and
after blocks you allocated).

/----------------------------------------------\
| Opinions expressed above do not necessarily  |  -- Allan Pratt, Atari Corp.
| reflect those of Atari Corp. or anyone else. |     ...lll-lcc!atari!apratt
\----------------------------------------------/