[m-dev.] [Gc] Article about memory fragmentation

[Bruce Hoult]

On Mon, Oct 10, 2016 at 10:57 AM, Paul Bone <paul at bone.id.au> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20161010/503b945b/attachment-0001.html>