Re: [Gc] Article about memory fragmentation

Bruce Hoult <[email protected]> Mon, 10 Oct 2016 13:07:15 +1300
Newsgroups gmane.comp.lang.mercury.devel,gmane.comp.programming.garbage-collection.boehmgc
Message-ID <CAMU+EkxFfcEsbaxtpqgjKbfnu1LcL4E3Rh4EZDLbjCY3Yr4zNg@mail.gmail.com>
--===============4937644904500658036==
Content-Type: multipart/alternative; boundary=089e01161dfae5140b053e778aa5

--089e01161dfae5140b053e778aa5
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 10, 2016 at 12:40 PM, Paul Bone <[email protected]> wrote:

> On Sat, Oct 08, 2016 at 10:32:33PM +1100, Paul Bone wrote:
> >
> > 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.
> >
>
> I received some feedback via twitter regarding the Memory Pool System
> (MPS),
> another GC for uncooperative environments.
>
> https://twitter.com/glaebhoerl/status/784737682706538496
>
> IIRC we've tried this in the past and found that it didn't perform as well
> as BDWGC.  But I wasn't involved with Mercury at the time and things may
> have changed.  @glaebhoerl provided this link
> https://gitlab.com/embeddable-common-lisp/ecl/issues/126 suggesting that
> it
> might be worth a look as ti may perform better.  I know very little about
> MPS so there's not much I can say about this.  But I said I'd pass the
> information on to the other Mercury devs.
>
>
The Dylan programming language has had several implementations, using a
variety of GCs:

Gwydion Dylan, originally at CMU on HP/UX, subsequently on probably every
popular Unix-like, has always used BDWGC.

Open Dylan, nee Functional Developer, nee Harlequin Dylan was developed at
Harlequin, who also developed the Memory Pool System. Open Dylan started on
Windows as a native compiler, and has been ported to 32 bit x86 Linux, also
as a native compiler. These versions use MPS. It has also been ported to
other platforms/CPUs and to 64 bit using a C back end. This uses BDWGC.

MPS was said to have 30 man-years of development work in it at the point
that Harlequin spun it off. The overall Dylan enviroment was over 100 man
years. (MPS was also used in Harlequin's ML and Lisp products, and maybe
others)

There is no doubt that MPS is very flexible, and can use a variety of
different allocation and collection techniques, both precise and
conservative.

I don't recall MPS benchmarking any better than BDWGC with Open Dylan.
Maybe the memory use is lower, but I'm not sure about that. There's
probably some data in the Dylan newsgroup or mailing list somewhere, but
it's a few years now since I've been actively involved.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Oct 10, 2016 at 12:40 PM, Paul Bone <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D"">On Sat, Oct 08, 2016 =
at 10:32:33PM +1100, Paul Bone wrote:<br>
&gt;<br>
&gt; I investigated an issue with memory fragmentation in BDW GC and Mercur=
y and<br>
&gt; it proved to be quite interesting, so I wrote it up as a blog post.<br=
>
&gt;<br>
<br>
</span>I received some feedback via twitter regarding the Memory Pool Syste=
m (MPS),<br>
another GC for uncooperative environments.<br>
<br>
<a href=3D"https://twitter.com/glaebhoerl/status/784737682706538496" rel=3D=
"noreferrer" target=3D"_blank">https://twitter.com/<wbr>glaebhoerl/status/<=
wbr>784737682706538496</a><br>
<br>
IIRC we&#39;ve tried this in the past and found that it didn&#39;t perform =
as well<br>
as BDWGC.=C2=A0 But I wasn&#39;t involved with Mercury at the time and thin=
gs may<br>
have changed.=C2=A0 @glaebhoerl provided this link<br>
<a href=3D"https://gitlab.com/embeddable-common-lisp/ecl/issues/126" rel=3D=
"noreferrer" target=3D"_blank">https://gitlab.com/embeddable-<wbr>common-li=
sp/ecl/issues/126</a> suggesting that it<br>
might be worth a look as ti may perform better.=C2=A0 I know very little ab=
out<br>
MPS so there&#39;s not much I can say about this.=C2=A0 But I said I&#39;d =
pass the<br>
information on to the other Mercury devs.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>The Dylan programming language has had several implementation=
s, using a variety of GCs:</div><div><br></div><div>Gwydion Dylan, original=
ly at CMU on HP/UX, subsequently on probably every popular Unix-like, has a=
lways used BDWGC.</div><div><br></div><div>Open Dylan, nee Functional Devel=
oper, nee Harlequin Dylan was developed at Harlequin, who also developed th=
e Memory Pool System. Open Dylan started on Windows as a native compiler, a=
nd has been ported to 32 bit x86 Linux, also as a native compiler. These ve=
rsions use MPS. It has also been ported to other platforms/CPUs and to 64 b=
it using a C back end. This uses BDWGC.</div><div><br></div><div>MPS was sa=
id to have 30 man-years of development work in it at the point that Harlequ=
in spun it off. The overall Dylan enviroment was over 100 man years. (MPS w=
as also used in Harlequin&#39;s ML and Lisp products, and maybe others)</di=
v><div><br></div><div>There is no doubt that MPS is very flexible, and can =
use a variety of different allocation and collection techniques, both preci=
se and conservative.</div><div><br></div><div>I don&#39;t recall MPS benchm=
arking any better than BDWGC with Open Dylan. Maybe the memory use is lower=
, but I&#39;m not sure about that. There&#39;s probably some data in the Dy=
lan newsgroup or mailing list somewhere, but it&#39;s a few years now since=
 I&#39;ve been actively involved.</div><div><br></div></div></div></div>

--089e01161dfae5140b053e778aa5--

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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWxvcGVy
cyBtYWlsaW5nIGxpc3QKZGV2ZWxvcGVyc0BsaXN0cy5tZXJjdXJ5bGFuZy5vcmcKaHR0cHM6Ly9s
aXN0cy5tZXJjdXJ5bGFuZy5vcmcvbGlzdGluZm8vZGV2ZWxvcGVycwo=

--===============4937644904500658036==--