<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>Being your hero is a good enough reason for me! One little thing that's
driven me, even though it's not really an issue, is the size of the EXE
files that are produced, so I seek to find any little way to shrink
them down without compromising performance in the final binary.<br>
<div><br>
</div><div>What I like about this project is that we all have our little motivators and objectives, and we're free to explore and research. I had an idea to potentially improve the compiler speed on modern systems, but requires a lot of refactoring and I'm currently got my attention focused on researching pure function support.</div><div><br>
</div><div>One drawback with any kind of memory management code is that it can put a lot of space and speed overhead on your project, although it is very useful from a debugging point of view. I've programmed my own ones in the past for C-based test projects that are meant to run for 24 hours sometimes, mostly in response to frequent crashes. It's proven very useful in catching memory leaks and identifying where they are so the memory can be freed properly.</div><div><br>
</div><div>So, long story short... if you find memory that isn't freed, free it (once you check it's not used afterwards), even if the operating system or RTL cleans it up for you.<br>
</div><div><br>
</div><div>Gareth aka. Kit<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Mon 30/07/18 15:05 , "Karoly Balogh (Charlie/SGR)" charlie@scenergy.dfmk.hu sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">Hi,
<br>
<br>
On Mon, 30 Jul 2018, J. Gareth Moreton wrote:
<br>
<br>
<span style="color: rgb(102, 102, 102);">> I would say that that's a little naïve and dangerous to think like that.
</span><br>
<span style="color: rgb(102, 102, 102);">> Sure, Windows might have the means to clean up memory after an
</span><br>
<span style="color: rgb(102, 102, 102);">> application terminates, but not all platforms have such heap
</span><br>
<span style="color: rgb(102, 102, 102);">> deallocation features (e.g. pure DOS, where certain procedures and
</span><br>
<span style="color: rgb(102, 102, 102);">> interrupts remain in memory even after the application terminates...
</span><br>
<span style="color: rgb(102, 102, 102);">> so-called memory-resident programs).
</span><br>
<br>
While I generally agree, in practice it's usually a non-issue.
<br>
<br>
Pure DOS, as in the 16bit target is not supported to run the compiler,
<br>
only via GO32V2, and having DPMI TSRs is... well... :)
<br>
<br>
On Amiga and similar systems, AROS, MorphOS for example, which indeed does
<br>
not free up the memory after a program terminates, I implemented a memory
<br>
pool in the FPC RTL, so all memory is freed anyway during the program's
<br>
exit. Any application which wants to go beyond this behavior for whatever
<br>
of its own reasons is free to use the OS allocation functions directly, or
<br>
implement its own memory manager. The same with open files on this
<br>
platform, actually, which wouldn't be closed without the RTL taking care
<br>
of them. And I also have to manage our own stack, and lets not even
<br>
mention threading... :)
<br>
<br>
The sideeffect is, that this approach silently "fix" the compiler's own
<br>
leaks too, so FPC remains useable on these systems. In general it is much
<br>
safer anyway, because expecting all the broken code out there to get fixed
<br>
for such systems is sadly just naive.
<br>
<br>
Having this said, anyone who still fixes leaks win the compiler will be my
<br>
hero! :)
<br>
<br>
Charlie
<br>
<br>
</blockquote></HTML>