Thanks Simon and Duncan.<br><br>I&#39;m still trying to wrap my head around this so I have some questions below.<br><br><div class="gmail_quote">On Fri, Sep 25, 2009 at 6:58 AM, Simon Marlow <span dir="ltr">&lt;<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On 25/09/2009 14:25, Jason Dagit wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
<br>
On Fri, Sep 25, 2009 at 4:34 AM, Simon Marlow &lt;<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a><br></div><div><div></div><div class="h5">
&lt;mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>&gt;&gt; wrote:<br>
<br>
    On 24/09/2009 04:57, Jason Dagit wrote:<br>
<br>
        I ran this more with normal builds and just the GC statistics.<br>
          Here is<br>
        what we see:<br>
        unmodified darcs:<br>
        469 MB total memory in use (3 MB lost due to fragmentation)<br>
        Total time   26.51s  ( 29.76s elapsed)<br>
        Productivity  85.6% of total user, 76.2% of total elapsed<br>
<br>
        469 MB total memory in use (3 MB lost due to fragmentation)<br>
        Total time   26.59s  ( 32.47s elapsed)<br>
        Productivity  85.6% of total user, 70.1% of total elapsed<br>
<br>
        469 MB total memory in use (3 MB lost due to fragmentation)<br>
        Total time   26.54s  ( 29.95s elapsed)<br>
        Productivity  85.5% of total user, 75.8% of total elapsed<br>
<br>
        With my patch applied:<br>
        554 MB total memory in use (4 MB lost due to fragmentation)<br>
        Total time   23.30s  ( 31.56s elapsed)<br>
        Productivity  83.1% of total user, 61.3% of total elapsed<br>
<br>
        554 MB total memory in use (4 MB lost due to fragmentation)<br>
        Total time   22.85s  ( 26.33s elapsed)<br>
        Productivity  82.9% of total user, 71.9% of total elapsed<br>
<br>
        554 MB total memory in use (4 MB lost due to fragmentation)<br>
        Total time   22.88s  ( 26.38s elapsed)<br>
        Productivity  82.8% of total user, 71.8% of total elapsed<br>
<br>
        Now that the profiler is disabled the productivity with my<br>
        changes is<br>
        less, the run-time is maybe improved by 2-3 seconds, and the memory<br>
        usage has increased by almost 100 megs.  I can only assume that the<br>
        profiling is interfering with my results a fair bit.<br>
<br>
<br>
    The profile graphs in your previous message showed a residency of<br>
    around ~30M before your patch, and ~6M after your patch.  Which<br>
    seems like a worthwhile saving.  I presume those graphs were from a<br>
    different test case?  If not, then something very strange is going<br>
    on.  If they are from a different test case, then do the numbers<br>
    stand up when using the non-profiled darcs?<br>
<br>
<br>
Thanks for trying to help me understand the profiling.<br>
<br>
My test case has not changed at all.  The only thing I&#39;ve been changing<br>
is the darcs source code.<br>
<br>
Do you have suggestions on determining which strange thing may be happening?<br>
</div></div></blockquote>
<br>
Well, if the heap profile is showing a ~30M residency and yet the runtime is using 500MB, there&#39;s about 400MB unaccounted for.<br>
<br>
Ah - so one problem is that the contents of ByteStrings are not accounted for in the heap profile, for unpleasant technical reasons to do with the way they&#39;re stored.  Unfortunately it&#39;s not easy to fix, because the GC doesn&#39;t retain information about which ByteStrings are live, only that the 4KB block in which they live is still alive.<br>
</blockquote><div><br>Does this also mean that the space consumed by ByteStrings is not considered for the purposes of memory pressure?  I&#39;ve always noticed that darcs tends to allocate a lot of virtual memory, and now this discussion makes me wonder if that&#39;s partially because the GC isn&#39;t collecting ByteStrings as eagerly as it does other garbage?  If this is the case, is there a way to specify the memory pressure of a value?  Basically, I&#39;m saying, &quot;Can I give hints to the GC about the relative need to collect something once it becomes garbage?&quot;<br>
<br>Or perhaps I&#39;m completely misunderstanding the problem here.<br><br>I&#39;ve been looking at taking some dynamic library injection code that Ian wrote for linux and porting it to OS X so that I can track how much memory we allocate via mmap (which I believe should catch everything that is unaccounted for in this case).<br>
<br>Is there a way to convince the RTS to collect more eagerly or run any finalizers (or whatever it would take) to get any ByteStrings cleaned up more eagerly?  This might make for a nice experiment.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
The underlying problem in your example may be fragmentation, due to the way that ByteStrings are pinned and hence hold on to the whole 4KB block in which they were allocated until they die.  Duncan has been thinking about how to improve the situation, but I&#39;m not sure of the current status - Duncan?<br>
</blockquote><br>What is it about fragmentation that is an issue?  We are definitely using a lot of bytestrings and a lot of mmap memory.  If you told me that the GC simply isn&#39;t tracking this memory in the heap profile then it makes a lot of sense what I&#39;m seeing.  If you&#39;re suggesting something else is going on in addition to the deficient tracking then I need to spend some time understanding the problem better.<br>
<br>Thanks,<br>Jason<br></div>