unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Weak references and GC
@ 2005-09-07 22:43 Neil Jerram
  2005-09-09 23:00 ` [solved] " Neil Jerram
  0 siblings, 1 reply; 2+ messages in thread
From: Neil Jerram @ 2005-09-07 22:43 UTC (permalink / raw)


I'm having trouble with lists (actually source code expressions) that
are weakly stored in several places and never being GC'd.  I wondered
if anyone on the list might be able to spot a problem in the following
description.

This is to do with my work on breakpoints, so each list here is a read
code expression that the user wants to set a breakpoint on.

Each such list is stored:

- in the source weak hash (scm_source_whash), which is used for
  storing source properties, including the breakpoint flag

- in a weak hash (created by make-object-property) that I use for
  mapping each list to my breakpoint object

- in a guardian (greedy, because I'm using Guile 1.6 and greedy is the
  default there), so I can discover when the list is GC'able

- as an element in a weak vector which hangs off the breakpoint
  object, so I can reference from the breakpoint to the source
  expression.

These should all be weak references, but it appears that the list is
never GC'd - by which I mean that

- the guardian never returns the list to me when I call it

- the relevant weak hash and vector cells never disappear (or change
  to #f).

Any ideas?  I'm pretty certain that the list is GC'able apart from
these weak references.

I wonder about the details of the interaction between the guardian and
the weak references.  What I would like to happen is this:

- The first time that the list is deemed to be GC'able, the guardian
  is flagged to return it (when called), and the list then becomes
  non-GC'able.  The weak hash and vector cells should _not_ be cleared
  at this point.

- Some time after the guardian has been called, and dropped the list
  reference, the GC is run again.  The list is deemed to be GC'able
  again, and this time there is no guardian, so the weak hash and
  vector cells are cleared and the list is freed.

Does anyone know if this matches what the code implements?  (I'm not
suggesting that it doesn't - I haven't bothered to look and try to
work it out yet.)

Final question: are there any cunning techniques for debugging why an
object is not GC'd?

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [solved] Re: Weak references and GC
  2005-09-07 22:43 Weak references and GC Neil Jerram
@ 2005-09-09 23:00 ` Neil Jerram
  0 siblings, 0 replies; 2+ messages in thread
From: Neil Jerram @ 2005-09-09 23:00 UTC (permalink / raw)


Neil Jerram <neil@ossau.uklinux.net> writes:

> I'm having trouble with lists (actually source code expressions) that
> are weakly stored in several places and never being GC'd.  [...]

For anyone interested... the thing preventing GC was a closure created
in an environment that included the source code expression as a local
variable.  Even though the closure's code did not reference the
variable, the closure's environment still includes that variable and
its value, and so protects the value from GC.

          Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-09-09 23:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-07 22:43 Weak references and GC Neil Jerram
2005-09-09 23:00 ` [solved] " Neil Jerram

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).