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).
2) It would be cleaner to have a function in mem.c which packages all of the logic (rather than calling garbage_collect directly).
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.
Marc
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?