[fpc-devel] removed MaxAvail,MemAvail,HeapSize
jonas at zeus.ugent.be
Mon May 23 01:16:28 CEST 2005
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
> 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
> 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".
More information about the fpc-devel