[fpc-devel] removed MaxAvail,MemAvail,HeapSize

[Jonas Maebe]

On 23 May 2005, at 00:56, Konstantin Münning wrote:

>> No. Either you catch exceptions resulting from a lack of memory and
>> recover, and then you have the same checking as before, except  
>> that  the
>> check happens atomically (by the OS: you ask for more memory and  if
>> there is no more memory, you get an exception).
>
> It seems you are missing a "small" point. Compatibility. With BP7  
> there
> are no exceptions - if you try to allocate more memory than availible
> you get a runtime error. This runtime error can't be switched off like
> IO-errors. OK, there are the exit procedures, but there is no recover.

There was already no compatibility, because maxavail and memavail  
simply worked with the currently allocated memory to the program. So  
if you had bad luck (currently allocated memory was almost used up,  
even though the OS possibly had 2GB free) you would already get the  
message that no more memory was available.

> The structure of a program is completely different when designing  
> it to
> work with exceptions and recovering from these. At least for the
> affected parts.

It is simply impossible to write a program running under a  
multitasking system which has virtual memory 100% exactly the same as  
one running under a single tasking no virtual memory "OS". There are  
other things you have to change as well: assembler code, inline  
machine code statements, mem[] statement (at least if you're not  
working under Dos), ...

> I don't think MaxAvail is so bad that everyone must be enforced to  
> stop
> using it and is not left to choose by himself.

What would you suggest to return under an OS like Windows, Mac OS X  
or Linux? The current "free" memory of the OS? Free memory + buffer  
cache - minimal buffer cache size enforced by the OS? The previous +  
available swap space - "wired" (i.e., not swappable to disk) memory?  
Just a constant? Something different possibly?

And in all cases, the program will still crash occasionally because  
it runs out of memory in certain cases, because the check and the  
allocation do not happen atomically. You can't put something into the  
standard Run Time Library which works "most of the time, except under  
heavy load". Imagine reading the docs and encountering that comment,  
you'd immediately start wondering how many more procedures there are  
which work "most of the time".


Jonas