[fpc-pascal] ReAllocMem problem (?)

[Marcel Martin]

Micha Nelissen wrote:

> 
> The problem with your approach is: how do you know whether the 

> memory was extended, or left alone because there was no memory 

> available to extend it ? In general, shortage of memory produces 

> a runtime error, but this is configurable by a global var.


No, that's easy. If the returned pointer is nil, it signals
the problem. But returning a nil pointer doesn't mean losing
the pointed memory area. We can save the pointer value before
calling ReAllocMem (in such situation, Delphi 5 returns a nil
pointer but the memory area is not lost).
The problem comes overall from the fact that ReAllocMem was
poorly designed (presumably by Microsoft, but I don't know).
But, now, it is as it is and we live with that. ReAllocMem
shouldn't destroy anything just because it cannot increase
something.
For instance, in my program Primo (Primality certification,
written with Delphi 5), if such a problem occurs (OutOfMemory),
Primo will close down but BEFORE, it will try to save data in
order to not lose all the work already done [*]. Now, if the
memory manager kills the addresses of the created objects, no
more things can be saved.

[*] Well, Primo automatically saves the work in progress every
10 minutes but anyway (I will be died otherwise. Some Primo users
reported certification running times greater than 4000 hours :-)

>>There is an other thing I didn't notice yesterday when I sent my
>>post. SysReAllocMem makes use of MemoryManager.AllocMem instead of 
>>MemoryManager.GetMem, i.e., SysReAllocMem fills up with 0s the
>>new allocated memory (whereas the ReAllocMem doc says "only the
>>used memory is initialized, extra memory will not be zeroed out").
>>
> 
> Not zeroing it would trigger a bug in the compiler, so I left it 

> in. (Can not remember precisely, but the context was an array of 

> pointers that is realloc'ed, needing the new entries to be 

> zero/nil).


It would have been preferable to try to fix this particular bug
otherwise. The fact that the blocks of memory are set to 0 is
a big waste of time. In the big integer library [*] I am adapting
to Free Pascal (and not only big integers, but also polynomials
over GF(2), big real/complex floats), the routines make lots of
memory 'reallocations'.

[*] BTW, congratulations for the 1.9.8 version. At the moment
the running times I get are slightly better than those got with
Delphi. Not much better but better anyway ;-)

Well, if you cannot change this, you cannot. Currently, I only
use ReAllocMem when the memory size decreases, otherwise I put
a BUGGY_REALLOCMEM directive in the code that enables the use
of GetMem and Move instead of ReAllocMem. Using GetMem and Move
is not really slower than the current behaviour of ReAllocMem
when the memory size increases. And, this way, I am sure (well,
almost) that the content of the memory area I want to increase
won't be destroyed.

mm