|
 |
Darren New <dne### [at] san rrcom> wrote:
> > Sorry, can't help responding to this: If your reference counter variable
> > size is the same as your native pointer size, it can *never* overflow.
> Yes, but that's very inefficient, especially if you have objects that
> are persisted elsewhere (e.g., if you have objects distributed across
> many computers, or stored in named files, or in an OO database).
Oh, of course handling more data than the natural pointer size of the
system is very efficient. It's just the reference counter which is
inefficient because it has to be able to count more than the natural
word size. Everything else is efficient even though everything else
also needs to handle values larger than the natural word size. Yes,
makes sense. Or then not.
Besides, not everything *has* to be reference-counted.
> Most
> reference-counted systems allocate between five and eight bits for
> reference counts.
Doesn't sound like a very smart thing to do. Sounds like over-optimization.
> Incidentally, that's another reason reference counting
> isn't used much - the size penalty.
And incidentally many (most? all?) garbage-collected languages will force
every single class to be allocated dynamically (which will add at the
very least the type or size of the object to be stored alongside it
so that it can be properly freed), which in turn forces every object
to be handled through at least one reference (which will add the size
of a pointer to the total memory consumption of the object), plus they
also usually automatically make every object dynamically bound (which
will add at least the size of some kind of pointer to the total memory
consumption of the object).
Even by a rather conservative estimate we could estimate that each
object requires at least 12 bytes of overhead in such a language. But
of course that is nothing to worry about. The size of a reference count
on the other hand is something to be very worried about.
--
- Warp
Post a reply to this message
|
|
