Path: utzoo!attcan!uunet!ns-mx!iowasp!deimos.cis.ksu.edu!rutgers!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!nikhefh!t68
From: t68@nikhefh.nikhef.nl (Jos Vermaseren)
Newsgroups: comp.sys.atari.st
Subject: Re: 40-Folder Bug
Message-ID: <807@nikhefh.nikhef.nl>
Date: 16 Mar 90 09:27:08 GMT
References: <2105@onion.reading.ac.uk> <1375@lzsc.ATT.COM> <1482@electro.UUCP> <1990Mar15.160939.16350@murdoch.acc.Virginia.EDU>
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 56

In article <1990Mar15.160939.16350@murdoch.acc.Virginia.EDU>, gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes:
> 
> >In one program I had Malloced more than 100 memory blocks of 16 Kbytes
> >(clearly a Mega-ST).
> 
> All the descriptions of Malloc() that I've ever seen include the
> information that you should not malloc more than 20 blocks per
> process. This is a fundamental limitation, and Atari never said they
> removed it. You should Malloc bigger blocks and then parcel out
> sub-blocks, see dLibs' malloc() for an example.
> 

In the days of youthful enthousiasm I disassembled and discompiled
GEMDOS. It turns out that the OS-pool is a common area for all
internal headers. They are sitting there in the order that they are
needed. In the old version it was impossible to really return these
blocks to the pool, and because these blocks have different sizes there
would be a horrible mess and once you allocated a block for a malloc
header it could only be used as such afterwards.
There was room for a little over 200 malloc blocks or a little over
40 pairs of folder blocks (each folder needed two).
So having more than 200 mallocs going at the same time would transform
the 40 folder bug into a 2 folder bug (I tried this out once by running
only on a floppy with a little program that did this type of malloccing).

In TOS1.4 the blocks are returned to the pool (as far as I understand,
because I haven't disassembled that one). This is a great improvement.
In addition the folder blocks are released when they aren't needed
anymore (that was the main part of the 40-folder bug).
That I am greatful for.

Apparently now the rule is to limit the malloc calls to 'not too many'
because the mechanism that returns the blocks to the pool has rather
poor behaviour in the limit that the number of malloc blocks is
large. I found this experimentally because I had a large file in an
editor, and after its garbage collections after a global replace
were rather funny. So the first suspect was the editor. But on other
systems it behaved properly, so this made GEMDOS suspect.

The size of 16 Kbytes was taken with great care:
If the blocks are too large there is inefficient use of memory when
the last block is allocated.
If they are too small you need too many of them.
Other problem if they are too large: This size keeps the time of the
tasks in the own garbage collections quite reasonable, so you never
notice them at all.
Problem with dynamic sizes: You need more code and it is slower.
In micro computers you want too keep the size of your tools as
small as possible.The 16K worked perfectly till the garbage collections
of GEMDOS gave it some annoyance factor.

This was what I was trying to explain, but I admit I was a little
terse about it. Over the whole TOS 1.4 is a great improvement, but
I believe there is still room for a TOS 2.0

Jos Vermaseren