On 03/06/2010 00:12, Marco Túlio Gontijo e Silva wrote:
Hi.
Another section of questions:
From rts/sm/Evac.c:
(...)
Changing evacuate() to take an (StgClosure **) rather than
returning the new pointer seems attractive, because we can avoid
writing back the pointer when it hasn't changed (eg. for a static
object, or an object in a generation> N). However, I tried it and
it doesn't help. One reason is that the (StgClosure **) pointer
gets spilled to the stack inside evacuate(), resulting in far more
extra reads/writes than we save.
This comment seems to be outdated, since evacuate doesn't take a StgClosure
**. Should it be removed, and maybe something added in it's place?
Yes, it's outdated. However, I have a significant branch of the GC in
development right now, so for the time being let's keep non-essential
changes to a minimum to avoid conflicts. (I think I may have fixed the
comment in my branch, in fact).
The mark_stack is used only for compaction, right? So why can't the code in:
No, it's used for marking, which includes both mark-sweep and mark-compact.
(...)
I first started wanting to enable mark_stack only in compact because it was
giving me a segfault in my changes to sweep. The algorithm in sweep is similar
to immix, so I thought it'd be easier to start changing the sweep to free
lines. I tried to make a list of free lines, using the following:
From rts/sm/Sweep.c:
(...)
for (i = 0; i< BLOCK_SIZE_W / BITS_IN(W_); i++)
{
if (bd->u.bitmap[i] != 0) resid++;
else line_found(bd->start + 8 * i);
}
(...)
static void
line_found(StgPtr start)
{
if(!line_first)
line_first = start;
// Includes a pointer to the next line
if(line_last)
*line_last = (StgWord) start;
line_last = start;
// Finalizes the list
*line_last = 0;
}
For style guidelines, see
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Conventions
In particular, please use explicit braces, as in
if(!line_first) {
line_first = start;
}
Also, use "NULL" rather than "0".
What are "line_first" and "line_last"? Global variables? We should
avoid globals because it will make the code hard to parallelise.
With this I got:
circsim: internal error: scavenge_mark_stack: unimplemented/strange closure
type -308026752 @ 0x7fa4ee0641c0
(GHC version 6.13.20100524 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
So I thought I should just remove the whole mark_stack code in sweep, and that
was the motivation.
Don't just give up when you get a crash - debug it with gdb and try to
understand what went wrong.
Then I tried to comment only the call to scavenge_mark_stack:
(...)
From rts/sm/Scav.c:
(...)
if (mark_stack_bd != NULL&& !mark_stack_empty()) {
// scavenge_mark_stack();
// work_to_do = rtsTrue;
}
But it gave different problems in different places, so I think I'm messing up
with things by writing in what I suppose were free lines. Notice 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.
(...)
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?
Cheers,
Simon
I'm thinking about start writing in the wiki some of the conclusions I'm
getting to, but I'd be glad to have them reviewed by someone with a better
knowleged of the GC. What's the procedure? Should I write them there and ask
for a review latter, send the proposed changes to someone to review and update
there only after the review or just write there and people will be mailed about
the change and will review without need of my report?
Greetings.
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
