From: Yukihiro Matsumoto <matz@...>
Date: 2007-05-22T15:44:20+09:00
Subject: Re: IRHG - GC Questons:

Hi,

In message "Re: IRHG - GC Questons:"
    on Tue, 22 May 2007 15:34:55 +0900, Charles Thornton <ceo@hawthorne-press.com> writes:

|1) Why is there a SOURCE_FILENAME Hash Table in GC?
|     What is the underlying GC Operation that needs to know
|      source filenames?

No, GC does not need to know source file names.  We need.  It's in
gc.c just because gc.c contains all memory handling.

|2) I assume that "gc_mark_all()" code below means that
|    you only call  "gc_mark_children" if  an object is NOT
|   Marked already?   This seems to run counter to what I
|   expected.  I would think that only the children of a marked
|   object should be marked??
|
|      while (p < pend) {
|        if ((p->as.basic.flags & FL_MARK)
|        && (p->as.basic.flags != FL_MARK)) {
|          gc_mark_children((VALUE) p, 0);
|          }
|        p++;
|       }

It's calling gc_mark_children() if FL_MARK flag is set AND flag bits
are NOT equal to FL_MARK (other bits should be set for marking).
obj->flags == FL_MARK means finalizer is reserved to be called on obj.

|3) I assume that "gc_mark_rest()" copies the <mark_stack> to
|    a temporary stack to process it, and init's the mark_stack to
|    receive more entries from the mark rest processing?

Yes.

							matz.