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

util/boot/AllocP.lha

Mirror:Random
Showing:m68k-amigaosppc-amigaosppc-morphosi386-arosi386-amithlonppc-warpupppc-powerupgeneric
No screenshot available
Short:AllocP - BetterAlloc (AllocMem/AllocVec patch) V2.01
Author:thor at math.tu-berlin.de
Uploader:thor math tu-berlin de
Type:util/boot
Version:2.01
Architecture:m68k-amigaos
Date:1997-10-16
Download:http://aminet.net/util/boot/AllocP.lha - View contents
Readme:http://aminet.net/util/boot/AllocP.readme
Downloads:1675
(with the friendly permission of the original author, Andreas Kleinert)

_____________________________________________________________________________

New in release 2.01:

	- Added a workarount for stupid "SaferPatches" clones.

_____________________________________________________________________________

New in release 2.00:

	- Rewritten in assembly language, much shorter file
	- Tries a partial flush first, instead of removing
	  all libraries on failure.
	- Removed unnecessary AllocVec patch since it calls
	  AllocMem anyways.

_____________________________________________________________________________

AllocP will be part of a major memory defragmentizer project still to be
published, called PoolMem. Please stay tuned!
_____________________________________________________________________________

 Sometimes programs fail with a "not enough memory" error,
 but after calling "avail flush" the same operation does
 succeed without problems.

 
 If AllocMem routine in the ROMs did not find enough memory,
 it tries to flush disk based libraries and devices and,
 afterwards, tries again to reallocate the memory.
 However, due to a design flaw of the AllocMem() routine,
 this memory flushing does not have the desired result some-
 times - even though the libraries have been informed to
 remove themselves, the memory is not available directly
 afterwards. The AllocMem() call will fail anyways, EVEN THOUGH 
 the requiested memory will be available immediatly after completion 
 of AllocMem().
 The reasons for this strange behaiviour are rather technical 
 and explained below, for the interested user.


 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

 Note:  Works now for all operating systems and all CPUs,
	is no longer restricted to V37 or MC'20.

 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

 You use this patch at your own risk.
 No guarantee for anything.
 Source code in assembly language included, requires the DevPac assembler
 and my macro package at dev/asm/DvPkMacros.lha at the AmiNet.


 All mentioned trademarks are subject to their owners.
_____________________________________________________________________________

The design flaw in AllocMem():

	When looking closely at the ROM routine of AllocMem(), you'll
	notice that a memory flush is TRIED if the first allocation
	failed. 
	Why does AllocMem then fail, even though if enough memory
	is available?

	Consider the following situation:
	A library has launched a sub-task for control of some of its
	features. This sub-task could be used for disk I-O, for example.

	If this hypothetical library has to be expunged, it can't do
	this on its own because this will release memory of the sub-task
	which is still running. This sub-task must be informed somehow
	that its memory must go. While this is in principle simple to do -
	just send a message to the sub task - the library can't wait for
	an answer of the sub-task because this would brake the Forbid()
	state, which is illegal at this point of the operation.
	The only solution for the library is to leave the memory flush
	to the sub task and to return to the low-memory handler of exec
	WITHOUT trying to remove itself - leaving this to its sub-task.
	
	On the other hand, since multitasking is still forbidden, there
	is NO chance that this subtask will actually get a chance to 
	remove the library, leaving it in memory and causing the 
	allocation failure. EVEN THOUGH the library was informed to
	get removed, there is no chance of doing this while flushing.

	However, as soon as exec leaves the AllocMem routine, multi-
	tasking will be turned on again, thus causing a task switch to
	the subtask and NOW causing the removal of the library - to late
	to have any effect.

	AllocP tries to avoid this situation by calling AllocMem a
	second time.


_____________________________________________________________________________

                        The THOR-Software Licence


This License applies to the computer programs known as "AllocP".
The "Program", below, refers to such program.


The programs and files in this distribution are freely distributable
under the restrictions stated below, but are also Copyright (c)
Thomas Richter.


Distribution of the Program by a commercial organization without written
permission from the author to any third party is prohibited if any payment
is made in connection with such distribution, whether directly
(as in payment for a copy of the Program) or indirectly (as in payment
for some service related to the Program, or payment for some product
or service that includes a copy of the Program "without charge";
these are only examples, and not an exhaustive enumeration of prohibited
activities). However, the following methods of distribution involving
payment shall not in and of themselves be a violation of this restriction:


(i) Posting the Program on a public access information storage and
retrieval service for which a fee is received for retrieving information
(such as an on-line service), provided that the fee is not
content-dependent (i.e., the fee would be the same for retrieving the same
volume of information consisting of random data).



(ii) Distributing the Program on a CD-ROM, provided that the files
containing the Program are reproduced entirely and verbatim on such
CD-ROM, and provided further that all information on such CD-ROM be
redistributable for non-commercial purposes without charge.



Everything in this distribution must be kept together, in original
and unmodified form.




Limitations.

THE PROGRAM IS PROVIDED TO YOU "AS IS," WITHOUT WARRANTY. THERE IS NO
WARRANTY FOR THE PROGRAM, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE ENTIRE
RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD
THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
SERVICING, REPAIR OR CORRECTION.



IF YOU DO NOT ACCEPT THIS LICENCE, YOU MUST DELETE ALL FILES CONTAINED IN
THIS ARCHIVE.

_____________________________________________________________________________

Thomas,

	October 1997


Contents of util/boot/AllocP.lha
 PERMSSN    UID  GID    PACKED    SIZE  RATIO     CRC       STAMP          NAME
---------- ----------- ------- ------- ------ ---------- ------------ -------------
[generic]                  179     208  86.1% -lh5- 390d Oct 14  1997 AllocP/AllocP
[generic]                 1511    4405  34.3% -lh5- 3917 Oct 14  1997 AllocP/AllocP.asm
[generic]                 3063    6943  44.1% -lh5- f5fb Oct 14  1997 AllocP/AllocP.readme
[generic]                  377     856  44.0% -lh5- 76da Oct 11  1997 AllocP/AllocP.readme.info
---------- ----------- ------- ------- ------ ---------- ------------ -------------
 Total         4 files    5130   12412  41.3%            Oct 16  1997

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