[fpc-devel] Why/how does the compiler have a non-trivial numberofmemory leaks after over two decades of development?
J. Gareth Moreton
gareth at moreton-family.com
Mon Jul 30 14:45:58 CEST 2018
I would say that that's a little naïve and dangerous to think like that.
Sure, Windows might have the means to clean up memory after an application
terminates, but not all platforms have such heap deallocation features
(e.g. pure DOS, where certain procedures and interrupts remain in memory
even after the application terminates... so-called memory-resident
programs).
Even if all blocks are freed when the compiler finishes its work, memory
leaks may still cause problems with sufficiently large projects that are
being compiled in one go. The more leaks you have, the more likely you're
going to hit an out of memory situation, especially as you can't really
control the target platforms in regards to how they have their physical and
virtual memory and page files configured.
A lot of the issues do come about from the fact that Free Pascal has a lot
of legacy code and started life as a 16-bit Turbo Pascal project (it was
first made because Turbo Pascal was being discontinued so Borland could
focus on Windows development, and it didn't have 32-bit support). Free
Pascal is advanced enough now that a lot of the features could be rewritten
to use more robust and self-contained features, but it's going to be a long
job.
I've made some suggestions to major improvements, especially to speed or
reducing the size of the compiler's binary (and the size of the binaries
that it generates), but Florian has turned down some of the patches either
because it's too experimental (my Deep Optimizer prototype) or
overcomplicates the codes (I replaced a large case block for the x86
peephole optimiser with a custom-made binary search system, which was
slightly faster but wasn't obvious in its function and would silently break
if it wasn't sorted properly).
I would say that trying to minimise the reliance on global variables would
be a big improvement to the node builder, because that would allow it to be
multi-threaded. *makes note of a possible future area of research!*
Gareth aka. Kit
On Mon 30/07/18 13:40 , "Thorsten Engler" thorsten.engler at gmx.net sent:...
Freeing memory is irrelevant if your process is going to exit anyway right
after freeing it. The OS doesn’t care about any memory your process has
allocated at that time. All pages go back into the available pool.
...
_______________________________________________
fpc-devel maillist - fpc-devel at lists.freepascal.org [1]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Links:
------
[1] mailto:fpc-devel at lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180730/afe01011/attachment.html>
More information about the fpc-devel
mailing list