AminetAminet
Search:
84451 packages online
About
Recent
Browse
Search
Upload
Setup
Services

util/sys/Alloc32P.lha

Mirror:Random
Showing:i386-amithlongeneric
No screenshot available
Short:Alloc32P - AllocMem/AllocVec patch V2.0
Author:Andreas_Kleinert at t-online.de
Uploader:Andreas_Kleinert t-online de
Type:util/sys
Architecture:m68k-amigaos
Date:1997-10-11
Download:http://aminet.net/util/sys/Alloc32P.lha - View contents
Readme:http://aminet.net/util/sys/Alloc32P.readme
Downloads:6540

 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.


Contents of util/sys/Alloc32P.lha
 PERMSSN    UID  GID    PACKED    SIZE  RATIO     CRC       STAMP          NAME
---------- ----------- ------- ------- ------ ---------- ------------ -------------
[generic]                 1638    3534  46.3% -lh5- 87b1 Oct  2  1997 Alloc32P/Alloc32P.readme
[generic]                 2369    3992  59.3% -lh5- 0804 Oct  2  1997 Alloc32P/AllocP
[generic]                 2266   11174  20.3% -lh5- ddfb Oct  2  1997 Alloc32P/AllocP.c
[generic]                  390     835  46.7% -lh5- b7a4 Aug  1  1997 Alloc32P/AllocP.info
[generic]                  987    1776  55.6% -lh5- 0da6 Oct  2  1997 Alloc32P/AllocP.o
[generic]                  115     141  81.6% -lh5- c18b Aug 16  1997 Alloc32P/SCOPTIONS
[generic]                  101     163  62.0% -lh5- 62c9 Oct  2  1997 Alloc32P/smakefile
---------- ----------- ------- ------- ------ ---------- ------------ -------------
 Total         7 files    7866   21615  36.4%            Oct 11  1997

Aminet © 1992-2024 Urban Müller and the Aminet team. Aminet contact address: <aminetaminet net>