[fpc-devel] removed MaxAvail,MemAvail,HeapSize

[Konstantin Münning]

Jonas Maebe wrote:
> 
> 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.

You are right. I assumed something like that when I looked at the values
of maxavail but hadn't investigated further and that's how the possible
flaw I mentioned in one of my first mails could look like.

>> 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),
> ...

The only assembler code I had to change was the one I had binary patched
for 32-bit operation. This and mem[] statements must be adjusted anyway
when trying to run on different architectures. So that's not the
trouble. I am still very happy with my units which allow me to write my
programs to run in 16 bit DOS real mode, DOS protected mode and Linux
without changing the main code and this including the GUI (VGA - X11).
Only the device drivers must be rewritten, of course ;-).

>> 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?

I have written in my previous mail(s) that I think the best return value
would be the biggest value with which a getmem would be successful if
memory conditions haven't changed inbetween. As this might be difficult
to implement on all supported OSes something between this and the "old"
one should do.

As I said before - adding an otherwise imperative error handling like
exceptions is still possible in addition to the old code.

By the way, I have never had a noticeable bug in a program (and some of
them are controlling machines running 24/7) because of the discussed
possibility. OK, they are not doing extensive memory
allocation/deallocation but also the possible danger is confined to
non-critical areas - a shortened item list for example would hurt nobody
:-).

> 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".

Most programs work most of the time except under heavy load. That's not
a good argument. Most small (C) programs don't do any memory
availability checks at all. Look at most of the command line tools on
any OS ;-). Of course I would like to have any code behave perfect under
any condition but it has always been a tradeoff between effort
(=expense) and impact. But when there is no memory left and you need
some you can't behave perfect. Please let it be the programmers choice
what to do and how to handle this. A compiler should be providing the
means, not taking them away. Anybody writing a program knows that there
may be flaws. A warning (with an advice how to make it better) should
still be the best for this.

By the way, I've found the following code in compiler/cclasses.pas when
I searched for the whereabouts of maxavail/memavail and there were some
more like this in the sources:

{$ifdef HASGETHEAPSTATUS}
        status:=GetFPCHeapStatus;
        startmem:=status.CurrHeapUsed;
{$else HASGETHEAPSTATUS}
        startmem:=memavail;
{$endif HASGETHEAPSTATUS}

I'm not sure if I understand it right as GetHeapStatus is not documented
well (I've found no reference for the meaning of the fields of the
returned record) but it seems that someone repaced here memavail with
another code which does about the same and has therefore the same flaw.

I would hapily contribute the code for a better MemAvail/MaxAvail
function if that's the problem. I would like to be able to use the
latest compiler which now I definitely can't as I must have the BP7
compatibility which is very good in 1.0.10.
-- 
Konstantin