[gambit-list] Any procedure/debug way to see what objects reference an object?

Mikael mikael.rcv at gmail.com
Tue Jun 18 12:30:46 EDT 2013

2013/6/18 Marc Feeley <feeley at iro.umontreal.ca>

> It is not in Gambit, but it would be easy to modify the GC to do this.


Three q:s on how to do this -

I'm reading mem.c right now and it looks like the mark_array() procedure
would be the place to put this check in.

The GC copy phase is about changing every object reference to a new one.
So, if during the mark phase I'd print out the ___SCMOBJ of the referencing
object, that would change during the GC.

 * Where in mem.c is the copy phase implemented? I can't find it or any
reference to it in ___garbage_collect , that would not be the section "Move
the stack", would it??

 * Could I safely run ___garbage_collect up to where the copy begins and
then just return() it right there as to keep the validity of the references
of the referencing objects I found?

>  By the way, your proposed API is not quite right because the references
> can be in non Scheme objects (for example global variables, a stack frame,
> a C allocated object).  Also, it could be that the object is a ___STILL
> object that has a non-zero reference count.

That would be cool - the objects I'm looking to track references of are
deep in the Scheme logics only and unrelated with any FFI or other special
object management. So I'd guess the place to check for the object would be
in the loop in mark_array:

  while (n > 0)
      ___WORD obj = *start;

      [Here - row 2100]

      if (___MEM_ALLOCATED(obj))
          ___WORD *body;
          ___WORD head;
          int head_typ;
          int subtype;

 * Last, in mark_array, can I easily detect the object reference to the
object whose content is being marked here, or do I need to add this as
another argument to mark_array?

>   So a leak is possible if there's a missing reference count "decrement"
> in the code.

Ah right - the nature of this memory leak is not such. The only ___STILL
variables I have are u8vectors , and the issue I have is that some
procedures and vectors fill up the heap -

##serial-number-to-object-table is growing up to heap overflow!

> Marc
Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130618/02a6b8dd/attachment.htm>

More information about the Gambit-list mailing list