<HTML>
<div>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).<br>
<br>
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.</div><div><br>
</div><div>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.</div><div><br>
</div><div>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).<br>
</div><div><br>
</div><div>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!*<br>
</div><div><br>
</div><div>Gareth aka. Kit</div><div><span style="font-weight: bold;"><br>
</span></div><div><span style="font-weight: bold;"><br>
</span></div><div><span style="font-weight: bold;">On Mon 30/07/18 13:40 , "Thorsten Engler" thorsten.engler@gmx.net sent:</span></div><div><span style="font-weight: bold;"></span></div><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"><defanged_meta http-equiv="Content-Type" content="text/html; charset=utf-8"><defanged_meta name="Generator" content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:PMingLiU;
panose-1:2 2 5 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@PMingLiU";
panose-1:2 2 5 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.gmail-
{mso-style-name:gmail-;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></defanged_meta></defanged_meta><defanged_meta http-equiv="Content-Type" content="text/html; charset=utf-8"><defanged_meta name="Generator" content="Microsoft Word 15 (filtered medium)"><defanged_body link="blue" vlink="purple" lang="EN-AU"><div class="WordSection1">...<span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> <br>
</o:p></span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">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.<o:p>
</o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> ...</o:p></span><defanged_meta http-equiv="Content-Type" content="text/html; charset=utf-8"><defanged_meta name="Generator" content="Microsoft Word 15 (filtered medium)"><defanged_body link="blue" vlink="purple" lang="EN-AU">
</defanged_body></defanged_meta></defanged_meta><br>
<defanged_meta http-equiv="Content-Type" content="text/html; charset=utf-8"><defanged_meta name="Generator" content="Microsoft Word 15 (filtered medium)"><defanged_body link="blue" vlink="purple" lang="EN-AU"></defanged_body></defanged_meta></defanged_meta></p></div>_______________________________________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a><br>
</defanged_body></defanged_meta></defanged_meta></blockquote></HTML>