[fpc-devel] Why/how does the compiler have a non-trivial number of memory leaks after over two decades of development?

[Florian Klämpfl]

Am 30.07.2018 um 02:58 schrieb Ben Grasset:
> 
> This raises a couple of big questions:
> 
> Considering that FPC provides optional built-in memory tracking that will take you directly to the exact source line 
> number of a leak, the fact that there's so many either means people have simply not been doing leak checks on the 
> compiler at all, or have just been actively ignoring them. Neither of those are "good news", but which is it?
> 
> Secondly, are there any plans to try to clean up and refactor the compiler codebase in general? 

There are a lot of plans.

But a compiler is an incredible complex piece of software, imo not comparable with other software, rewriting some parts 
might be useful but reducing complexity is normally not possible.

> After diving in to take 
> a look at where some of these leaks originated, it's not at all surprising they exist. The entire compiler essentially 
> seems to revolve around "nodes" and various subclasses of them, that are created in too many different places and ways 
> to count, and cannot be tracked in any meaningful way. This kind of tree design is perfectly valid and relatively 
> common, but the way FPC does it leaves more than a few things to be desired.
> 
> I was even able to successfully actually fix some of the leaks, but others boiled down to a "node" being created as a 
> local variable in the middle of some 1000+ line method, getting assigned to the "left" or "right" property of some other 
> globally visible node, and then never being freed.

I am aware of this, but I consider it as minor. The only way to get around this would be add to each node an owner field 
and set it to current_procinfo and track all nodes in current_procinfo and clean them together with the 
current_procinfo. Question is: what do we gain? The compiler consumes more memory because of the tracking and it is 
slower because of the tracking. Cleaner code? Well, the OS cleans up memory anyways when the process exits.


I were even thinking along lines Torsten mentioned (not to free any memory, but let the OS do its job) as memory is 
during compilation often not a problem, cpu speed is.