• Sean Kelly (7/7) Sep 15 2005 From my reading of the GC code, mark (in gcx.d) seems like it's intended...
• Sean Kelly (9/13) Sep 15 2005 It looks like other parts of the GC code expect ptop to point beyond the
• Sean Kelly (7/20) Sep 16 2005 A final follow-up. It looks like mark is being called correctly. I was...

Sean Kelly <sean f4.ca> writes:

From my reading of the GC code, mark (in gcx.d) seems like it's intended to scan
all addresses from p1 to p2, inclusive.  But it will never scan p2, as the for
loop does a traditional less-than comparison (so only the range [p1..p2) is
scanned).  Am I currect in assuming this is a bug?  If so, the comparison should
be changed to less-equal and a check for pbot|ptop == null should be added
before the loop (as mark is called with null pointers occasionally).


Sean

Sean Kelly <sean f4.ca> writes:

In article <dgcpf0$25lu$1 digitaldaemon.com>, Sean Kelly says...
From my reading of the GC code, mark (in gcx.d) seems like it's intended to scan
all addresses from p1 to p2, inclusive.  But it will never scan p2, as the for
loop does a traditional less-than comparison (so only the range [p1..p2) is
scanned).  Am I currect in assuming this is a bug?

It looks like other parts of the GC code expect ptop to point beyond the
scannable range as well, so perhaps I'm wrong (the variable name led me to
believe that it pointed to a valid memory location).  However, if this is true,
the use of the CONTEXT structure might be off by one.  Assuming, that is, that
the stack base or Eip might point to GCed memory (not likely, though I don't
quite understand why Ebp is scanned either so who knows).  I just want to sort
out how mark is intended to be called either way.


Sean

Sean Kelly <sean f4.ca> writes:

In article <dgcr1j$272r$1 digitaldaemon.com>, Sean Kelly says...
In article <dgcpf0$25lu$1 digitaldaemon.com>, Sean Kelly says...
From my reading of the GC code, mark (in gcx.d) seems like it's intended to scan
all addresses from p1 to p2, inclusive.  But it will never scan p2, as the for
loop does a traditional less-than comparison (so only the range [p1..p2) is
scanned).  Am I currect in assuming this is a bug?

It looks like other parts of the GC code expect ptop to point beyond the
scannable range as well, so perhaps I'm wrong (the variable name led me to
believe that it pointed to a valid memory location).  However, if this is true,
the use of the CONTEXT structure might be off by one.  Assuming, that is, that
the stack base or Eip might point to GCed memory (not likely, though I don't
quite understand why Ebp is scanned either so who knows).  I just want to sort
out how mark is intended to be called either way.

A final follow-up.  It looks like mark is being called correctly.  I was thrown
off because ptop refers to a valid allocated memory address (so far as I can
tell) but it will never be allocated to.  The code that scans registers might be
a tad off, but the missed addresses are either covered by the other scan (scack
vs. register or vice-versa) or they simply don't matter (the stack bottom).


Sean