<div dir="ltr"><div>That's good news.<br></div><div><br></div><div>I don't think the first idea will do very much as there are other references to the final "HomeModInfo" not stored in the HPT. <br></div><div><br></div><div>Have you constructed a time profile to determine why the runtime is higher? With the second approach you are certainly trading space usage for repeating work.</div><div><br></div><div>If you actually do have a forest, then ideally you would replace the ModDetails after it will never be used again.</div><div><br></div><div>You are likely also missing other patches important for memory usage.<br></div><div><br></div><div>* <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12582">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12582</a></div><div>* <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12347">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12347</a></div><div><br></div><div>I can't comment about the 17 HPT, what do the retainer stacks look like in ghc-debug? <br></div><div><br></div><div>PS.  Please use eventlog2html so the profiles are readable! You can use it on .hp profiles.<br></div><div><br></div><div>Cheers,</div><div><br></div><div>Matt<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 23, 2025 at 3:19 AM Erdi, Gergo <<a href="mailto:Gergo.Erdi@sc.com">Gergo.Erdi@sc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-1393113127520851258">





<div lang="EN-GB" style="overflow-wrap: break-word;">
<p style="font-family:Arial;font-size:9pt;color:rgb(49,113,0);margin:5pt;font-style:normal;font-weight:normal;text-decoration:none" align="Left">
PUBLIC<br>
</p>
<br>
<div>
<div class="m_-1393113127520851258WordSection1">
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">Hi Matt & Zubin,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">Thanks for the help on this so far!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">I managed to hack the linked MR onto 9.8.4 (see
<a href="https://gitlab.haskell.org/cactus/ghc/-/tree/cactus/backport-13675" target="_blank">https://gitlab.haskell.org/cactus/ghc/-/tree/cactus/backport-13675</a>) and basically it seems to do what it says on the tin on a small example (see attached heap profile examples
 for typechecking 4313 modules), but I am unsure how to actually use it.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">So my understanding of the improvement here is that since now there is only one single HPT [*], I should be able to avoid unnecessary ballooning by
 doing two things:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<ul style="margin-top:0in" type="disc">
<li class="m_-1393113127520851258MsoListParagraphCxSpFirst" style="margin-left:0in">
<span style="font-size:10pt;font-family:"Arial",sans-serif">Evicting `HomeModInfo`s wholesale from the HPT that are not going to be needed anymore, because I am done with all modules that would transitively depend on them. This
 of course only makes sense when typechecking a forest.<u></u><u></u></span></li><li class="m_-1393113127520851258MsoListParagraphCxSpLast" style="margin-left:0in">
<span style="font-size:10pt;font-family:"Arial",sans-serif">Replacing remaining `HomeModInfo`s with new ones that contain the same ModInterface but the ModDetails is replaced with a fresh one from initModDetails.<u></u><u></u></span></li></ul>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">The attached `-after` profile shows typechecking with both of these ideas implemented. The first one doesn’t seem to help much on its own, but it’s
 tricky to evaluate that because it is very dependent on the shape of the workload (how tree-y it is). But the second one shows some serious promise in curtailing memory usage. However, it is also very slow – even on this small example, you can see its effect.
 On my full 35k+ module example, it more than doubles the runtime.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">What would be a good policy on when to replace ModDetails with thunks to avoid both the space leak and excessive rehydration churn?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">Also, perhaps unrelated, perhaps not – what’s with all those lists?!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">            Gergo<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif">[*] BTW is it normal that I am still seeing several (17 in a small test case involving a couple hundred modules) HPT constructors in the heap? (I hacked
 it locally to be a datatype instead of a newtype just so I can see it in the heap). I expected to see only one.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>>
<br>
<b>Sent:</b> Tuesday, January 21, 2025 8:24 PM<br>
<b>To:</b> ÉRDI Gergő <<a href="mailto:gergo@erdi.hu" target="_blank">gergo@erdi.hu</a>><br>
<b>Cc:</b> Zubin Duggal <<a href="mailto:zubin@well-typed.com" target="_blank">zubin@well-typed.com</a>>; Erdi, Gergo <<a href="mailto:Gergo.Erdi@sc.com" target="_blank">Gergo.Erdi@sc.com</a>>; Montelatici, Raphael Laurent <<a href="mailto:Raphael.Montelatici@sc.com" target="_blank">Raphael.Montelatici@sc.com</a>>; GHC Devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
<b>Subject:</b> [External] Re: GHC memory usage when typechecking from source vs. loading ModIfaces<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">Thanks Gergo, I think that unless we have access to your code base or a realistic example then the before vs after snapshot will not be so helpful. It's known that `ModDetails` will leak space like this.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Let us know how it goes for you.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Cheers,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Matt<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Jan 17, 2025 at 11:30 AM ÉRDI Gergő <<a href="mailto:gergo@erdi.hu" target="_blank">gergo@erdi.hu</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">On Fri, 17 Jan 2025, Matthew Pickering wrote:<br>
<br>
> 1. As Zubin points out we have recently been concerned with improving the memory usage<br>
> of large module sessions (#25511, !13675, !13593)<br>
> <br>
> I imagine all these patches will greatly help the memory usage in your use case.<br>
<br>
I'll try these out and report back.<br>
<br>
> 2. You are absolutely right that ModDetails can get forced and is never reset.<br>
> <br>
> If you try !13675, it should be much more easily possible to reset the ModDetails by<br>
> writing into the IORef which stores each home package.<br>
<br>
Yes, that makes sense.<br>
<br>
> 3. If you share your example or perhaps even a trace from ghc-debug then I will be<br>
> happy to investigate further as it seems like a great test case for the work we have<br>
> recently been doing.<br>
<br>
Untangling just the parts that exercise the GHC API from all the other <br>
in-house bits will be quite a lot of work. But if just a ghc-debug <br>
snapshot of e.g. a small example from scratch  vs. from existing ModIfaces <br>
would be helpful (with e.g. the top HscEnv at the time of finishing all <br>
typechecking as a saved closure), I can provide that no prob.<br>
<br>
Thanks,<br>
        Gergo<u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>

<hr>This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries together with Standard Chartered Bank’s Privacy Policy via our public website.<br>

<hr>This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries together with Standard Chartered Bank’s Privacy Policy via our main Standard Chartered PLC (UK) website at sc. com<br>
</div>

</div></blockquote></div>