<br><br><div class="gmail_quote">2013/6/20 Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I will study your implementation soon.  I do have a few comments at this point:<br>
<br>
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).<br>

</blockquote><div><br></div><div>Yeah!</div><div><br></div><div>I'm not quite clear about how to extract this information, feel free to give me pointers on this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2) It would be cleaner to have a function in mem.c which packages all of the logic (rather than calling garbage_collect directly).<br></blockquote><div><br></div><div>What do you mean?</div><div><br></div><div>You mean.. that this heap scanning could be done without a call to garbage_collect being made?</div>

<div><br></div><div>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!<br><br>That should imply a huge performance improvement too, which would be welcome of course, as currently resolving the root graph tree could take minutes.<br>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>

</blockquote><div><br></div><div>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.</div>
<div>
<br></div><div><br></div><div><br></div><div>I'm glad this functionality is maturing now and think its usefulness is clear already.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888">Marc<br></font></span></blockquote><div><br></div><div>Brgds, Mikael</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888">
</font></span><div class="HOEnZb"><div class="h5"><br>
On 2013-06-18, at 6:36 PM, Mikael <<a href="mailto:mikael.rcv@gmail.com">mikael.rcv@gmail.com</a>> wrote:<br>
<br>
><br>
><br>
> 2013/6/19 Mikael <<a href="mailto:mikael.rcv@gmail.com">mikael.rcv@gmail.com</a>><br>
><br>
><br>
> 2013/6/19 Mikael <<a href="mailto:mikael.rcv@gmail.com">mikael.rcv@gmail.com</a>><br>
><br>
><br>
> Space for improvement or things to note are:<br>
><br>
><br>
> [..]<br>
><br>
>  * 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.<br>


><br>
>    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?<br>


><br>
>  * 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.<br>
><br>
><br>
><br>
> Feedback?<br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>