On 31/05/2010 20:26, Marco Túlio Gontijo e Silva wrote:
http://people.debian.org/~marcot/mem2.png
(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
a line.
Yes, I understand that. What I'm suggesting is that we might want to
tune the size at which we consider an object to be of "medium" size.
We must say that anyting larger than a line is medium, so that we can
bound the number of lines we consider to be non-empty due to
conservative marking, as you explained above. Another reason is that we
want to guarantee to allocate a small object in the next allocation
area, if it doesn't fit in the current one (an allocation area may be as
small as a single line). But, we may choose the boundary for medium
objects to be smaller than a whole line: e.g. 75% of a line. I don't
know whether that would be an improvement, but it's certainly something
that we could measure.
(if this still doesn't make sense, don't worry about it, it's a minor
point anyway and we can return to it later).
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
