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

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

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