[Gc] Strange issues
Emmanuel Stapf [ES]
manus at eiffel.com
Thu Jan 5 18:46:18 PST 2006
> I expect the collector should try to follow this pointer
> starting with the
> current = *current_p;
> statement around line 784 in mark.c. It would be interesting
> to see if that is ever executed with current_p == 0xc0562c.
> If you get there, the next question is whether
> HC_PUSH_CONTENTS results in the referenced object getting
> marked (testable with the
> GC_is_marked() function), and if not, why not.
As far as I can tell, it is not marked. I did:
To find this out. Since it is a macro it makes it harder to debug since everything
has to be onde in assembly code. To make my life easier I've compiled the
preprocessor output. And as far as I can tell, when my hit my breakpoint for
0xc0562c, in the following macro:
# define PUSH_CONTENTS_HDR(current, mark_stack_top, mark_stack_limit, \
source, exit_label, hhdr) \
int displ; /* Displacement in block; first bytes, then words */ \
int map_entry; \
displ = HBLKDISPL(current); \
map_entry = MAP_ENTRY((hhdr -> hb_map), displ); \
displ = BYTES_TO_WORDS(displ); \
The value of `map_entry' is 0x2 and `displ' is 3488 so it only do the call to
`displ -= map_entry;'
And later on, it exits when processing the macro SET_MARK_BIT_EXIT_IF_SET. So does
it mean it is marked and therefore nothing should get collected?
More information about the Gc