Re: RFC: reference counting for value

[Tom Tromey <tromey@redhat.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> I am trying to resurrect an old patch of Vladimir's, which gives
Daniel> bitfield values a parent pointer.  We fetch the parent once, instead
Daniel> of once per bitfield.  That raised an interesting question:

Tom> +  /* The reference count.  A value that is still on the `all_values'
Tom> +     list will have a reference count of 0.  A call to `release_value'
Tom> +     will increment the reference count (and remove the value from the
Tom> +     list, the first time).  A call to `value_free' will decrement the
Tom> +     reference count, and will free the value when there are no more
Tom> +     references.  */
Tom> +  int refcount;
Tom> +
Tom> /* Register number if the value is from a register.  */
Tom> short regnum;
Tom> 

Daniel> If we release_value the parent every time we create a child, and
Daniel> value_free it every time we collect a child, the parent will be freed
Daniel> as soon as its last child is.  This is a change in the value behavior,
Daniel> because otherwise it would hang around until value_free_to_mark or
Daniel> free_all_values.

Daniel> Is this going to bite us?

Yes, I think so.

Daniel> We could, instead, record release_value
Daniel> references separately from parent references and leave the value on
Daniel> the chain.  But if it doesn't matter, I'd rather not.

Another idea I've been kicking around a bit is to also reference count
the contents.  This would solve this particular problem without
needing a bitfield->parent reference, as the two would just share some
structure.

My reasons for considering this change are, first, it would be more
memory-efficient in some value_copy cases; and, second, I think it
would let us merge val_print and value_print.

I was also thinking that it would help with properly implementing
unavailable pieces via DW_OP_piece (I thought: removing val_print
would make it simpler to handle all this via the value API, and
structure sharing seemed necessary for removing val_print), but now
I'm not as sure.  It is probably just as easy to pass a "valid" bitmap
through the val_print hierarchy.

BTW, I have not checked in the value reference counting patch.  I plan
to it until I've dealt with the python/varojb regression it
introduces.

Tom