Re: [Gc] Article about memory fragmentation

--===============7545120398079922194==
Content-Type: multipart/alternative; boundary=001a1130d1c4bd596e053e5fd706

--001a1130d1c4bd596e053e5fd706
Content-Type: text/plain; charset=UTF-8

Good article, as far as it goes, but it just .. stops .. before the
interesting analysis.

Btw "uncorrectable" should be "uncollectable".

Almost all those block sizes have excellent utilization ratios. A moving
collector could scarcely do better!

But there's definitely room for improvement with the 32 byte size.

I'm very curious what the memory allocation pattern in that makes you end
up with so many blocks with so few live objects.

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.

In a long-running program, you'd expect that space to get used again,
multiple times, so it's not really a problem.

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.

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.

The GC can't be some kind of oracle and predict these usage patterns, but
you might be able to.

On Sun, Oct 9, 2016 at 12:32 AM, Paul Bone <[email protected]> wrote:

>
> This is a cross post as both communities will probably be interested.
>
> I investigated an issue with memory fragmentation in BDW GC and Mercury and
> it proved to be quite interesting, so I wrote it up as a blog post.
>
> http://paul.bone.id.au/2016/10/08/memory-fragmentation-in-boehmgc/
>
> I also learnt a fair amount about the collector in the process, and
> explained that in the article too.  It may be interesting if you're curious
> about how allocation works in the collector.
>
> Please let me know if I've gotten anything wrong, or of course if you have
> any other comments.
>
> Cheers.
>
>
> --
> Paul Bone
> http://paul.bone.id.au
> _______________________________________________
> bdwgc mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/bdwgc
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

--001a1130d1c4bd596e053e5fd706
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Good article, as far as it goes, but it just .. stops .. b=
efore the interesting analysis.<div><br></div><div>Btw &quot;uncorrectable&=
quot; should be &quot;uncollectable&quot;.</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&#39;s definit=
ely room for improvement with the 32 byte size.=C2=A0</div><div><br></div><=
div>I&#39;m very curious what the memory allocation pattern in that makes y=
ou 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&#39;re the=
 one who can gather the object lifetime data.</div><div><br></div><div>In a=
 long-running program, you&#39;d expect that space to get used again, multi=
ple times, so it&#39;s not really a problem.</div><div><br></div><div>But i=
t can also be that there is a usage peak for some object size during progra=
m startup, and then they are not needed again. Unfortunately, there&#39;s v=
ery 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 peman=
ent) objects of the same size, then you could pre-allocate a number of obje=
cts (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 taki=
ng 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 mig=
ht 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&#39;d and those pages reused for objects of other sizes.</div><div><br><=
/div><div>The GC can&#39;t be some kind of oracle and predict these usage p=
atterns, but you might be able to.</div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Sun, Oct 9, 2016 at 12:32 AM, Paul Bone <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">pau=
[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"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=3D"http://paul.bone.id.au/2016/10/08/memory-fragmentation-in-boehmg=
c/" rel=3D"noreferrer" target=3D"_blank">http://paul.bone.id.au/2016/<wbr>1=
0/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.=C2=A0 It may be interesting if you&#39;r=
e curious<br>
about how allocation works in the collector.<br>
<br>
Please let me know if I&#39;ve gotten anything wrong, or of course if you h=
ave<br>
any other comments.<br>
<br>
Cheers.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
Paul Bone<br>
<a href=3D"http://paul.bone.id.au" rel=3D"noreferrer" target=3D"_blank">htt=
p://paul.bone.id.au</a><br>
______________________________<wbr>_________________<br>
bdwgc mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><=
br>
<a href=3D"https://lists.opendylan.org/mailman/listinfo/bdwgc" rel=3D"noref=
errer" target=3D"_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>

--001a1130d1c4bd596e053e5fd706--

--===============7545120398079922194==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWxvcGVy
cyBtYWlsaW5nIGxpc3QKZGV2ZWxvcGVyc0BsaXN0cy5tZXJjdXJ5bGFuZy5vcmcKaHR0cHM6Ly9s
aXN0cy5tZXJjdXJ5bGFuZy5vcmcvbGlzdGluZm8vZGV2ZWxvcGVycwo=

--===============7545120398079922194==--