[fpc-devel] removed MaxAvail,MemAvail,HeapSize

[Konstantin Münning]

Jonas Maebe wrote:
> 
> On 23 mei 2005, at 02:29, Konstantin Münning wrote:
> 
>>> 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.
> 
> The only way to know that is to perform getmem's with every increasing 
> values until one fails.

I was not implying that a getmem(maxavail) must work under any 
circumstances on a multitasking OS. But as the OS knows at a given point 
what the maximum availible memory for a single allocation call is, so 
could a program running on that OS.

>> Most programs work most of the time except under heavy load. That's not
>> a good argument.
> 
> 
> I beg you pardon? I think the argument that most programs do not work 
> well under heavy load is an extremely bad argument to encourage even 
> more buggy programming.

Please don't understand me wrong - I don't encourage the use of these 
functions. I'm only speaking about compatibility to old code which was 
there and is now missing.

But back to the argument - as on a multitasking system ANY memory 
allocation could fail at ANY time, if this was so severe, none of these 
OSes should be accepted by the community as they are buggy. But as you 
see everybody seems to live happily with this as the chances these 
failures to happen are acceptable low. So allowing old programs 
initially designed for other environments to "live" with the same 
limits, that's OK I think.

And as to buggy programming - what can you really do when a getmem 
fails? Even doing fancy tricks with exceptions and such will not help. 
If you haven't added some "own" memory management (like garbage 
collection) to free some "unneeded" memory in such a case there are only 
two things you can do - wait until there is the requested memory 
avalable and allowing by this your program to hang indefinitely or fail 
in some more or less informative way. Show me one program which can run 
without the required memory and does not fail in any way. Are you still 
considering it buggy programming?

>> Please let it be the programmers choice
>> what to do and how to handle this.
> 
> Only using tools that make sense, everything else would be snake oil 
> (and in reality nothing would be handled).
> 
>> A compiler should be providing the
>> means, not taking them away.
> 
> It should not provide known defunct means.

It's not the means but the way you are using them. Would you then remowe 
the Reset/Rewrite functions as well? In many (old) programs they are 
used to check for presence of file(s) to prevent overwriting by first 
trying to open them and if this fails then the file can be written... 
But as in a multitasking environment the file can appear just between 
the Reset and the Rewrite - well, bad bug. There are the means to do 
this right by the proper OS functions so maybe this should be enforced 
as well!?

(I hope I haven't brought you to another "imrpovement" idea ;-))

>> Anybody writing a program knows that there
>> may be flaws.
> 
> 
> No, if you use RTL routines, you expect them to work.

(see above)

>> A warning (with an advice how to make it better) should
>> still be the best for this.
> 
> 
> People don't read the manual.

Well, then they maybe will not know about the existence of the function 
:-). Still a compiler warning for deprecated functions would be nice.

>> {$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.
> 
> The above code is not used to check whether there's still enough free 
> memory left, it's only used to calculate how much memory is used by the 
> compiler.

I just picked one.

>> 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.
> 
> 
> You can make a unit which contains a dummy memavail and maxavail which 
> always return a value of 1GB or so, then your program will also always 
> work except under heavy load (if that is really what you want). There's 
> no use in investing lots of time in making very complex routines to 
> query all sorts of information from the OS and then have it fail in 
> exactly the same circumstances as when you return a plain constant.

I mentioned the plain constant alernative in one of my first mails as it 
depends on the assumptions you make. Its about compilability of old code 
and this would also do but a better function would reduce the 
unavoidable failures to a minimum.

The -So loading of a compatibility unit is probably the best solution here.

Konstantin.