Re: RFC: reference counting for value

[Tom Tromey <tromey@redhat.com>]

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

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

Daniel> Would it?  We need to be able to fetch the contents in response to a
Daniel> request from the bitfield, so everything needed to unlazy would
Daniel> have to be in the shared structure; I guess that's address and length,
Daniel> here.  Also lval type.  Would we have to duplicate these in the value
Daniel> and the shared contents?

I hadn't been thinking about the lazy case, but after thinking about
it a bit, it still doesn't seem so bad to me.

Yeah, you'd have to push this stuff into the contents (lval type?  I
dunno).

Something like

struct value_contents
{
  enum lval_type lval : 8;
  unsigned int lazy : 1;
  unsigned int refcount : 23;  // or whatever
  CORE_ADDR address;
  gdb_byte contents[1];  // should perhaps use the aligner stuff from before
};

struct value
{
...
  struct value_contents *contents;
}

value::offset would continue to be an offset into the contents; when
doing something like a field reference, we'd make a new reference to
'contents' and set the offset in the new value appropriately.

For unavailable pieces, we'd also stick the validity bitmap (or
something) into value_contents.

Daniel> If two values have a shared contents structure, I'm not sure
Daniel> what point there is having them different value structures in
Daniel> the first place.

To act as a content cache, so we can avoid duplicating large contents
when copying (and slicing, etc) values and avoid (as in your case)
redundant fetches.

Some other caching approach may work just as well.  That's how I
understand the parent-pointer idea as well -- a specialized cache.

I'm not really wedded to this.  I'm not even sure I want to get rid of
val_print -- I find it to be a strange wart, but it would probably be
a lot of work for not much benefit (unless it really does simplify the
unavailable piece thing).

Tom