Re: Value reference counting

[Thiago Jung Bauermann <thiago.bauermann@gmail.com>]

Em Sexta-feira 17 Julho 2009 16:04:18 Daniel Jacobowitz escreveu:
> On Fri, Jul 17, 2009 at 12:53:52PM -0600, Tom Tromey wrote:
> > This will work fine for Python.  Also, I think that this model is
> > clearer than what I did.
> >
> > It seems to me that at this point, release_value is doing a walk of a
> > linked list for no particular benefit.  Suppose we deleted release_value
> > and replaced all calls to it with calls to value_incref?
> >
> > This might result in some values living slightly longer than they
> > otherwise would have (they will live until free_all_values, whereas
> > currently they will be deleted at value_free time, which might or might
> > not be sooner).
> >
> > The only thing I could think of is whether this would affect watchpoint
> > operation, since IIUC the watchpoint code examines all_values.  But, if
> > this problem exists, it could be worked around by examining the
> > reference count of values on the chain.
> >
> > What do you think?
>
> I had a good reason this would leak values for watchpoints, but now I
> can't get it to work out.  Still, it makes me nervous.

Watchpoints hold their own references to values. Other than that, IMHO if 
watchpoint code causes values to be leaked, that is a bug, not a special 
feature which should be respected... WDYT?

> free_all_values can have a very long interval.  But it looks like
> breakpoint commands always run it, so not unbounded user behavior.
> What about breakpoint conditions?  Is anything released and free'd
> during a condition check going to linger until we stop?

I don't like the idea of having the GC being ran at unpredictably long 
intervals. Aren't we aiming at debugging big fat apps with big insane 
debugging sessions afterall?
-- 
[]'s
Thiago Jung Bauermann