U0179@DGOGWDG5.BITNET ("GWDGV1::WHUEBNER") (03/19/90)
Hello 'Netters',
Because of the second 'offical' Patch for the TOS 1.4 version I have
investigated some time to analyse the new/old problems with the memory
management routines within the new TOS releases.
The so called '40 folder bug' is really fixed but...:
...there are some NEW errors/problems within these routines!
The biggest one was the totaly wrong code for the 'post garbage collection' of
memory descriptors (Allan Pratt fix this with 'poolfix3' patch).
Some background information:
In the new version of TOS (1.4,1.6,x.x?) the handling of the system internal
memory (pool) has completly changed. Now there can be up to four memory
descriptors (MDs) placed within one pool block. Those special pool blocks
are not more available for other purposes like folder descriptions etc.
until all four MD's within this MD container are released (I have named those
special pool blocks 'MD container').
A MD is need by GEMDOS to describe the usage (allocated,free), location, size
and ownership of (user) memory chunks.
MD's are registered (with regard of there usage state) in two memory management
lists (the ALLOCATED and the FREE list). The roots of these lists are registered
within a structure called 'memory parameter block'(MPB). In this MPB is a third
information located, the ROVING pointer. This pointer is used to avoid the
concentration of small blocks at the front of the memory space after repeatedly
using of allocation/free user memory. For more information of the theorie of
memory management implementation see: Donald E. Knuth, The Art of Computer
Programming, Volume 1, Chapter 2.5 with exercise 6 (First fit method with a
roving ptr). A MD becomes unused if two free (user) memory chunks (with its
own MD's) are consecutive so that its memory could be described by one common
MD.
After some alloc/free operations there could be some MD containers exist, wich
contains one,two,three or four placeholders for unused MD's.
Assumed,
at any time, one will open a new file, this needs at least one WHOLE pool block,
but there are only some (partionally) filled MD containers available, what
could we do ? Right, we could try to compact MD containers so that we get
one pool block with four unused MD's.
.. and this should be done by the erronous implemented routine. Some
errors of this routine are:
a) the implemented algorithms locks itself to find MD container
with unused MD's with a smaller unused count as at there first hit,
b) if they found only one MD container with unused MD's in it, they
treat the next pool block (REGARDLESS of its usage eg. file,folder
etc. descriptor!!) as MD container and destroyes its contents,
c) after moving MD's between MD container they forgot to update the
roving pointer, so that this pointer will point into the desert.
THIS IS A NEW ERROR OF TOS 1.4/1.6 AND HAVE NOTHING TO DO WITH THE OLD KNOWN 40
FOLDER PROBLEM.
The usage of Allans POOLFIX3 patch it strongly recomended! By the way, Allan,
your patch should save all registers like the ROM GEMDOS handler do it.
If somewhat is interested in the replacement (within (ep)rom) code, please let
me know. I think, I could publishing this code here without problems because
I am using a totaly different algorithms. Any comments, ATARI?
Now the other errors/problems (not complete!) I have found through the journey
of the TOS 1.4 memory management :
- mshrink: call of mshrink with newsize=0, the MD of this memory
space will be released within pool but forgotten to be unlinked from
allocated list.
- ptermres: the information of the memory allocated by this process
will be released from the allocated chain but not within pool.
- the message: *** OUT OF INTERNAL MEMORY also displayed, if the
memory management encounters errors within pool management, then
the usage of FOLDRxxx is not the right way to correct this problem.
- some 'dead code' within routines wich never be reached.
- some 'optimizing' modifications made by atari forces that the new
code really becomes 'un-optimized'.
(In german: der Schuss ging nach hinter los - I do not know the
english equivalent, sorry). In some routines they change register
usage against 'in-direct' access of routine parameters, this will
be one processor cmd less, but on the other side each reference
of a parameter will we longer (size&time)! See malloc, pool
allocation code and so on.
- malloc: there is no need to look for the largest memory block
available if we use this function for really allocating memory.
- malloc: if you got via malloc(..-1..) the information, that there
is stil memory available, for example 500000 bytes, and you request
400000 bytes of it, you should get it (I mean). This needs one
additional MD for the remaining memory space. If the pool is full,
GEMDOS gives you NO memory in this situation! Why? I think, GEMDOS
should give at this point the totaly remaining memory to the user.
If the user request more after this, the information call of
malloc(..-1..) should return zero and the allocation request also
fails.
To correct all these problems one have to publish the total memory management
code. If I do it here, (I assume) I get problems with ATARI's copyrights.
Winfried Huebner
+--------------------------------------------+
| BITNET: U0179 at DGoGWDG5 (W.Huebner) |
| VAXMAIL: PSI%45551032808::GWDGV1::WHUEBNER |
| West Germany |
+--------------------------------------------+--------------------+
| All opinions are my own, and not necessarily always correct ... |
| You know >>> NOBODY IS PERFECT <<< |
+-----------------------------------------------------------------+