This patch does a few things:
o Sometimes programs fail with a "not enough memory" error,
but after calling "avail flush" the same operation does
succeed without problems.
Obviously AllocMem/AllocVec does not force such a "flush"
operation AND tries to allocate memory again, immediately
after the flushing has been done. Why ? Why has the program
to assume, that its allocation did fail, although there may
has been some memory released by the flush ?
This patch does ensure, that AllocMem/AllocVec won't
fail unless there's really no memory available, even
by flushing. This means:
- less "out of memory" failures
- less "bad behaviour" of bad programs, which don't
check results of AllocMem/AllocVec
- no more need to call "avail flush" by hand
from the shell
- thus no more "retry" operations after "avail flush"
- no more unused libraries/devices consuming memory
when it is already low
o (new) AllocMem() and AllocVec() calls are changed into
new-style memory allocation calls
o 32 Byte alignment for new-style memory allocated buffers
o new-style memory allocation does work as follows: each
memory request will be extended by space for certain
administration data, which fulfils several tasks:
- it does contain some information on the allocation,
such as buffer size and various pointers
- imitating an AllocVec allocation
- aligning the actually used buffer pointer to the
next 32 byte boundary (Exec aligns to 8 byte
boundaries, so we add another 24 bytes)
Additionally, this alignment also takes place at the
end of the buffer, where upto 31 bytes may be added,
to align it to the next 32 byte boundary.
So, each memory allocation will at least be 64 bytes
wide.
o delocating a new style buffer works by taking the
information from the extended space (from within
the extra 24 bytes), which does work quite similar
to a common AlloVec call, where the buffer size is
stored before the buffer, too. But with Alloc32P,
this is possible with usual AllocMem() calls as well.
The "size" parameter of a FreeMem(ptr, size) call
will be ignored - or optionally just be used for safety
comparisons.
o basically it does not matter, at which point you start
the patch, since it will recognize, when any program does
try to delocate buffers that had been allocated before the
patch had been running. It then will delocate these
the old way. But it does make sense, to TEST it fromout
the Shell first, and THEN add it to s:startup-sequence
or s:user-startup
Note: Needs V37+ and 68020.
Note: DO NOT RUN MUNGWALL IN PARALLEL - IT WILL NOT
RECOGNIZE THE PATCH AND MAY PRODUCE ENDLESS
MUNGWALL HITS !
(Additionally, this does not make sense anyway,
since the patch may falsify the results out
of testing buggy programs - it may compensate
some of these bugs actually ;)
Usage: Try starting in the Shell/CLI.
If it does run stable, copy it into
your C: directory and add it
somewhere into your s:user-startup
AllocP >NIL: <NIL:
You use this patch at YOUR OWN RISK.
No guarantee for anything.
Source code included.
---
All mentioned trademarks are subject to their owners.
|
aminet net>