2013/6/20 Marc Feeley <feeley@iro.umontreal.ca>
I will study your implementation soon.  I do have a few comments at this point:

1) It would be nice if there was more information in the resulting list when the reference is not in an object.  For example a string which names the global variable which references the object, a fixnum giving the number of the register which references the object, etc).

Yeah!

I'm not quite clear about how to extract this information, feel free to give me pointers on this.

2) It would be cleaner to have a function in mem.c which packages all of the logic (rather than calling garbage_collect directly).

What do you mean?

You mean.. that this heap scanning could be done without a call to garbage_collect being made?

Sure, if you see a way to split out the "mark" logics to perform only a search for this purpose, then sure that would be the best of course!

That should imply a huge performance improvement too, which would be welcome of course, as currently resolving the root graph tree could take minutes.
 
3) The allocation of the result list by the GC is worrisome, as this may overflow the heap.  I'll have to check how you did it.

Ah right, there could be use of an upper limit there. It's done using malloc/free currently anyhow, which I would fully understand if you see some better way to do it than that.



I'm glad this functionality is maturing now and think its usefulness is clear already.

Marc

Brgds, Mikael
 

On 2013-06-18, at 6:36 PM, Mikael <mikael.rcv@gmail.com> wrote:

>
>
> 2013/6/19 Mikael <mikael.rcv@gmail.com>
>
>
> 2013/6/19 Mikael <mikael.rcv@gmail.com>
>
>
> Space for improvement or things to note are:
>
>
> [..]
>
>  * If when not in a ##resolve-referencing-objects call there'd be any referenced to ___SCMOBJ :s on the heap that are == -1 , there'd be a corresponding number of add_resolved_referencing_object calls made per GC without any corresponding get_next_resolved_referencing_object  calls, causing a serious memory leak.
>
>    Probably we better have a global boolean variable "scanning_for_references" that ##resolve-referencing-objects switches the scanning mode on/off, as to secure against unintended add_resolved_referencing_object calls?
>
>  * There's no handling of malloc() failure on add_resolved_referencing_object , leading to a potential sigsegv. Gambit's other malloc() call does the same though.
>
>
>
> Feedback?
>
>
>