Hi Simon. Excerpts from Simon Marlow's message of Qui Mai 27 05:38:16 -0300 2010: > On 27/05/2010 00:08, Marco Túlio Gontijo e Silva wrote: > > > I've made some patches to GHC to correct these issues. I don't know if > > you're > > willing to recieve these kind of small patches, but I'll send them anyway. > > I didn't see any patches - did you forget to attach them?
I didn't intend to attach them, but to send them afterwards. I was waiting for GHC to build correctly before I send them. They were sent now to the list. (...) > > Ok. There's also the corner case where the object starts in the beginning > > of > > the Line, in which we can consider the next Line to be empty, but probably > > it's > > not an issue to ignore this one. > > That's a worthwhile optimisation, I think. > > 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. > > Anyway, this is proposed in the Immix paper. In their terms, they mark only > > the one Line for small objects and they don't mark the last Line of medium > > objects, and ignore the first Line of each role in allocation. > > I suggest we allocate medium objects in a separate space entirely, and > maybe just copy them as normal, rather than using mark/sweep on them. You mean there will be two types of blocks: blocks with small objects allocated on the free lines and blocks of medium objects? (...) > If you're a bit lost, one way to get acquainted is to start adding print > statements to the code so you can get a better idea of what's going on > at each point. e.g., you might want to try printing out each object as > it is evacuated. I find this kind of hands-on approach much more > illuminating than staring at the code. Good suggestion, I'll start doing that. Greetings. (...) -- marcot http://wiki.debian.org/MarcoSilva
signature.asc
Description: PGP signature
_______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
