Hi Simon. Excerpts from Simon Marlow's message of Qui Jun 03 06:34:25 -0300 2010: > On 03/06/2010 00:12, Marco Túlio Gontijo e Silva wrote: (...) > >> From rts/sm/Sweep.c: (...) > >> *line_last = 0; (...) > use "NULL" rather than "0".
In this case I'm doing I would have to do a type cast, because line_last is a pointer to StgWord. Do you think "(StgWord) NULL" is better than "0"? > What are "line_first" and "line_last"? Global variables? We should > avoid globals because it will make the code hard to parallelise. Yes, I was doing that only to tests if my ideas would work. I changed them to local variables of sweep(). (...) > > I'm considering the 8 words pointed by a byte in the bitmap. I thought > > that if the bit was set to 0, that space in the block was free and I could > > write in them, but it seems that this assumption is not valid. What am I > > doing wrong? > > Remember that we're only marking the first word of an object, so the > object will extend into successive words. This is why we need > conservative marking, or something similar. Thanks, that helped me a lot. My main mistake until now was thinking that the bitmap was indexed by byte, that is, that it had the type char. When I noticed the bitmap was actually indexed by StgWord, all my tests that previously were causing segfaults started to work. I reported about what I've done in my blog[0]. I think the part 1 of one of your e-mails is done, freeing memory in units of lines. Now I'm planning to focus on part 2, allocating new lines. I'm currently studying the allocation part of the code, in alloc_for_copy from Evac.c, then I went to GCThread.h, but it seems that make it uses the free lines is going to require a much bigger change than what I've done till now. Am I on the right track? (...) > > (...) > > > > One minor thing I noticed is that, in evacuate, gct->evac_gen and bd->gen > > are > > not always set. What is the scenario behind the situation in that they're > > not > > set? > > I'm not sure I understand - could you explain what you mean by "not > set"? Do you mean that bd->gen does not point to a valid generation? Yes, and sometimes I think I saw them being NULL. If I have any test case I'll post here. Now my focus in other parts of the code, so I can't really reproduce when they were "unset". BTW, I had a problem running the test of nofib/gc/fibheaps. My output is attached. Greetings. 0: http://marcotmarcot.wordpress.com/2010/06/04/summer-of-code-weekly-report-4/ (...) -- marcot http://wiki.debian.org/MarcoSilva
log
Description: Binary data
signature.asc
Description: PGP signature
_______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
