Re: [Gc] Article about memory fragmentation

--===============1903520627158852919==
Content-Type: multipart/alternative; boundary=001a1130d05aecba70053e76589e

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

On Mon, Oct 10, 2016 at 10:57 AM, Paul Bone <[email protected]> wrote:

> > If a page is "nearly full" then it is skipped, on the assumption that it
> > takes a lot of time for little benefit (speed/space tradeoff).
>
> That's a reasonable assumption.  Has anyone tested different policies here?
> As I understand it, sweeping should be relatively fast, especially for
> mostly
> full pages.  It starts by checking the mark bits (a medium-sized but
> sequential memory read) and finding any unmarked objects it threads them
> together in a linked list (writes to a number of different cache lines).
>
>     SweepCost    = ReadMarkBits + N*WriteLinks
>     SweepBenifit = N
>
> Sweeping a mostly full page is the cheapest sweep, but has little benifit.
> Sweeping a mostly empty page has a higher cost (but writes are amortized if
> there is more than one per cache line) and a great benifit.  It seems that
> skipping mostly full objects mostly reduces how frequently sweeping is
> required, and only affects the cost/benifit of sweeping slightly.  Please
> tell me if you disagree, this is the most I've actually worked with memory
> management.
>

It looks as if this feature was added in version 5.0, and then the
implementation changed to the current one in version 6.0.

Those are quite some time ago (I couldn't immediately find a dated release
list, but I think 5.0 was around 2000?), and computers have changed a lot,
so the same assumptions might not apply now. It might be worth someone
revisiting it.

--001a1130d05aecba70053e76589e
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 10:57 AM, 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"">&gt; If a page is &qu=
ot;nearly full&quot; then it is skipped, on the assumption that it<br>
&gt; takes a lot of time for little benefit (speed/space tradeoff).<br>
<br>
</span>That&#39;s a reasonable assumption.=C2=A0 Has anyone tested differen=
t policies here?<br>
As I understand it, sweeping should be relatively fast, especially for most=
ly<br>
full pages.=C2=A0 It starts by checking the mark bits (a medium-sized but<b=
r>
sequential memory read) and finding any unmarked objects it threads them<br=
>
together in a linked list (writes to a number of different cache lines).<br=
>
<br>
=C2=A0 =C2=A0 SweepCost=C2=A0 =C2=A0 =3D ReadMarkBits + N*WriteLinks<br>
=C2=A0 =C2=A0 SweepBenifit =3D N<br>
<br>
Sweeping a mostly full page is the cheapest sweep, but has little benifit.<=
br>
Sweeping a mostly empty page has a higher cost (but writes are amortized if=
<br>
there is more than one per cache line) and a great benifit.=C2=A0 It seems =
that<br>
skipping mostly full objects mostly reduces how frequently sweeping is<br>
required, and only affects the cost/benifit of sweeping slightly.=C2=A0 Ple=
ase<br>
tell me if you disagree, this is the most I&#39;ve actually worked with mem=
ory<br>
management.<br></blockquote><div><br></div><div>It looks as if this feature=
 was added in version 5.0, and then the implementation changed to the curre=
nt one in version 6.0.</div><div><br></div><div>Those are quite some time a=
go (I couldn&#39;t immediately find a dated release list, but I think 5.0 w=
as around 2000?), and computers have changed a lot, so the same assumptions=
 might not apply now. It might be worth someone revisiting it.</div><div><b=
r></div></div></div></div>

--001a1130d05aecba70053e76589e--

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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWxvcGVy
cyBtYWlsaW5nIGxpc3QKZGV2ZWxvcGVyc0BsaXN0cy5tZXJjdXJ5bGFuZy5vcmcKaHR0cHM6Ly9s
aXN0cy5tZXJjdXJ5bGFuZy5vcmcvbGlzdGluZm8vZGV2ZWxvcGVycwo=

--===============1903520627158852919==--