[gambit-list] (##resolve-referencing-objects obj) => list of the objects that reference obj implementation, feedback welcome.

Mikael mikael.rcv at gmail.com
Thu Jun 20 10:50:47 EDT 2013


2013/6/20 Marc Feeley <feeley at 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 at gmail.com> wrote:
>
> >
> >
> > 2013/6/19 Mikael <mikael.rcv at gmail.com>
> >
> >
> > 2013/6/19 Mikael <mikael.rcv at 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?
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130620/195e0e12/attachment.htm>


More information about the Gambit-list mailing list