<div dir="ltr">Good article, as far as it goes, but it just .. stops .. before the interesting analysis.<div><br></div><div>Btw "uncorrectable" should be "uncollectable".</div><div><br></div><div>Almost all those block sizes have excellent utilization ratios. A moving collector could scarcely do better!</div><div><br></div><div>But there's definitely room for improvement with the 32 byte size. </div><div><br></div><div>I'm very curious what the memory allocation pattern in that makes you end up with so many blocks with so few live objects.</div><div><br></div><div>My best guess is that at some point you actually did have 60 MB of 32 byte objects, but then most of them became unreachable. But you're the one who can gather the object lifetime data.</div><div><br></div><div>In a long-running program, you'd expect that space to get used again, multiple times, so it's not really a problem.</div><div><br></div><div>But it can also be that there is a usage peak for some object size during program startup, and then they are not needed again. Unfortunately, there's very little that a non-moving GC can do about that.</div><div><br></div><div>It might be possible to do something about that at a user level though: if there are interspersed allocations of short lived and long lived (or pemanent) objects of the same size, then you could pre-allocate a number of objects (4 KB worth or some multiple) and put them in your own freelist or some other collection, and then replace the current GC_malloc of them with taking one from the pre-allocated list. You could do this for either the short-lived or the long-lived objects, but I suspect that the long-lived ones might give the easiest benefit. Get them all onto the same memory pages, that will stay reasonably full, and let entire pages of short-lived objects get GC'd and those pages reused for objects of other sizes.</div><div><br></div><div>The GC can't be some kind of oracle and predict these usage patterns, but you might be able to.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 9, 2016 at 12:32 AM, Paul Bone <span dir="ltr"><<a href="mailto:paul@bone.id.au" target="_blank">paul@bone.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
This is a cross post as both communities will probably be interested.<br>
<br>
I investigated an issue with memory fragmentation in BDW GC and Mercury and<br>
it proved to be quite interesting, so I wrote it up as a blog post.<br>
<br>
<a href="http://paul.bone.id.au/2016/10/08/memory-fragmentation-in-boehmgc/" rel="noreferrer" target="_blank">http://paul.bone.id.au/2016/<wbr>10/08/memory-fragmentation-in-<wbr>boehmgc/</a><br>
<br>
I also learnt a fair amount about the collector in the process, and<br>
explained that in the article too.  It may be interesting if you're curious<br>
about how allocation works in the collector.<br>
<br>
Please let me know if I've gotten anything wrong, or of course if you have<br>
any other comments.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Paul Bone<br>
<a href="http://paul.bone.id.au" rel="noreferrer" target="_blank">http://paul.bone.id.au</a><br>
______________________________<wbr>_________________<br>
bdwgc mailing list<br>
<a href="mailto:bdwgc@lists.opendylan.org">bdwgc@lists.opendylan.org</a><br>
<a href="https://lists.opendylan.org/mailman/listinfo/bdwgc" rel="noreferrer" target="_blank">https://lists.opendylan.org/<wbr>mailman/listinfo/bdwgc</a><br>
<br>
--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
</font></span></blockquote></div><br></div>