[fpc-pascal] ReAllocMem problem (?)

mm mm10 at ellipsa.net
Sat Mar 12 21:46:15 CET 2005


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
badly 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 terminate 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 would be dead since long 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 big
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







More information about the fpc-pascal mailing list