Some questions about GHC source code and wiki
Marco Túlio Gontijo e Silva
marcot at debian.org
Mon May 31 15:26:34 EDT 2010
Excerpts from Marco Túlio Gontijo e Silva's message of Qui Mai 27 08:48:34 -0300 2010:
> Excerpts from Simon Marlow's message of Qui Mai 27 05:38:16 -0300 2010:
> > We might consider "medium" objects to be any object that is larger than,
> > say 75% of a line. The point is we want to avoid having objects that
> > are nearly a line size being allocated in the same way as small objects,
> > because one of these objects will almost always cause allocation in the
> > current line to fail, which might waste up to a line's worth of memory
> > in the current line. That's what I menat by fragmentation.
> Immix handles that using conservative marking, that is, it always assumes that
> the object will use the next Line too. If we're allocating objects in
> sequence, that's not a problem. It'll only ignore the first Line of each hole
> (sequence of lines), so I don't think this generates a lot of fragmentation,
> and the small objects can have the size of a line.
> I tried to explain that in my last e-mail, but maybe I wasn't clear. Or maybe
> you understood me, and I'm not understanding you now, but this approach seems
> to solve the issue of objects with the same size of a line.
As I thought maybe I wasn't being clear about this, I made a small draw of what
(source code: http://people.debian.org/~marcot/mem2.hs )
This image contains three scenarios of allocations using Immix. In the first,
all objects are allocated once, so there's no fragmentation.
In the second, the objects are allocated each one in one line, without leaving
the next line free. This is not what is proposed in the conservative marking
on Immix, and that's not what I'm suggesting.
In the third, the objects are allocated in groups, and the first line of each
hole is not used, because it may contain a part of the object in the previous
line. A line is considered empty unless it has an object *starting* in it. In
this image, the 2nd line, the 6th, the 8th and the 10th line are free, but no
object will be allocated starting in it, because of conservative marking. This
can cause fragmentation, generating different types of holes: the hole the in
2nd line is big, in the 6th line is medium and in the 8th line is small.
With this conservative marking approach, there's no need to distinct objects
much smaller than a line of objects almost the size, or with the same size, of
Hope it's more clear now.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cvs-ghc/attachments/20100601/e2a755b4/signature-0001.bin
More information about the Cvs-ghc