This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: reference counting for value
- From: Tom Tromey <tromey at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Tue, 07 Jul 2009 08:25:44 -0600
- Subject: Re: RFC: reference counting for value
- References: <m3tz26k87c.fsf@fleche.redhat.com> <20090707014914.GA30559@caradoc.them.org>
- Reply-to: Tom Tromey <tromey at redhat dot 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