Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!convex!drivax.UUCP!holloway
From: holloway@drivax.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: Gulam/Developers kit
Message-ID: <-166600@drivax.UUCP>
Date: Wed, 27-May-87 13:07:00 EDT
Article-I.D.: drivax.-166600
Posted: Wed May 27 13:07:00 1987
Date-Received: Wed, 10-Jun-87 06:18:48 EDT
References: <12530002@acf4.UUCP>
Lines: 24
Nf-ID: #R:acf4.UUCP:-1253000200:drivax.UUCP:-166600:37777777600:1278
Nf-From: drivax.UUCP!holloway    May 27 12:07:00 1987


In article <12530002@acf4.UUCP> slavin@acf4.UUCP (Slaveman) writes:

>Before I started running the compiler I used the 'mem' command in gulam and
>got about 151K chunk free, and when I was done, I was somehow down to a 
>measly 68K, not enough for exec to execute anything.

GULAM reports the size of the largest chunk of memory left - you might still
have 151K free, of which 68K is the largest chunk available. This is memory
fragmentation, and is caused when programs use Malloc() to allocate small
blocks rather than doing one Malloc of about a hundred Kilobytes or so,
and allocating smaller structures from that using internal routines.

Also, it looks as if the compiler isn't freeing some of the memory it uses -
otherwise, the fragmentation would fix itself when the program finished. But
there's nothing you can do about it, short of rebooting the machine. It
certainly isn't a problem with Gulam - except that Gulam uses memory even
when another program is running over it, so you lose that memory right there.

- Bruce
-- 
Bruce Holloway - Relapsed Newsaholic         {seismo,sun}!amdahl!drivax!holloway
"Everything should be made as complex as possible - esp. if you're paid hourly."
What Irony - 75                      - "The Personal Diaries of Albert Einstein"