Where reference counting is stored - C

caferias <caferias1977@hotmail.com> wrote:
> Hello, I have been looking where Objective-C store reference counting.
> I supposed that it was an object attribute, but it doesn't appear in
> the debugger. Some suggestions?

For reasons related to memory savings, thread safety, and history,
refcounts are stored in a global hash table, not inline with the object
itself.

If you want to get an object's refcount (do this as a debugging aid only,
and even then you should use it extremely sparingly!) you can simply use
the -retainCount message to ask it.

--
Michael Ash
Rogue Amoeba Software

caferias <caferias1977@hotmail.com> wrote:
> Hello, I have been looking where Objective-C store reference counting.
> I supposed that it was an object attribute, but it doesn't appear in
> the debugger. Some suggestions?

In Objective-C as implemented by some compilers, such as POC (portable
object compiler), the reference count is an instance variable of Object.

Basically, when an assignment is made, such as

a = b;

The compiler will produce code to update a->_refcnt and b->_refcnt.

Regards,

In article <1154773850.483385.280780@i42g2000cwa.googlegroups.com>,
caferias <caferias1977@hotmail.com> wrote:
>Hello, I have been looking where Objective-C store reference counting.
>I supposed that it was an object attribute, but it doesn't appear in
>the debugger. Some suggestions?

The Objective-C language as such has not traditionally included any
particular memory management facilities, which have instead been left to
class libraries to define and implement. Initially, this led to objects'
lifecycles having to be managed manually by the programmer.

To address this, there have been several attempts, more or less
successful to date, to assist Objective-C developers in managing object
lifecycles (and as part of that, memory use).

NeXT, who had one if the biggest code- and developer bases using
Objective-C, introduced reference counting (including a delayed-release
facility) in the NSObject class and its related class library (the
OpenStep frameworks, and its continuation, Apple's Cocoa frameworks).
NeXT/Apple's classes tend to keep the reference count external to the
object itself, in a separate hashtable. While there are some rules to be
kept in mind when using this, NeXT/Apple's reference counting has
succeeded in removing the major burden from the programmer. This is
handled entirely by the class library itself, and requires no changes to
the Objective-C language, runtime system or compiler.

Separately, the GNU Objective-C runtime includes support for using the
Boehm-Demers-Weiser conservative garbage collector, if the gcc Objective-C
compiler has been compiled with support for this; this, of course, doesn't
use reference counting at all, but instead includes changes both to the
compiler and the runtime system.

David Stes' 'Portable Object Compiler' (POC) (which implements an older
dialect of Objective-C and adds a few incompatible features of its own)
includes compiler-generated reference counting, which will, when used,
include the reference count as an instance variable in each object. POC
also allows using the Boehm conservative garbage collector to manage
object lifecycles.

The most widely used approach of the ones mentioned above has been the
NeXT/Apple one of using essentially manual reference counting, with
assistance from the class library.


Best wishes,

// Christian Brunschen

Christian Brunschen schrieb:

> NeXT/Apple's classes tend to keep the reference count external to the
> object itself, in a separate hashtable.
this shouldnt stay without comment because the impression of
inefficiency comes up quickly.
actually the external hashtable is just the very default
implementation of the framework and is off course slow
and should be avoided for all objects that frequently
need refcounting by doing the refcounting with an instance
variable...

guenther

In article <eb7jjp$akq$1@news.r-kom.de>,
guenther <guenther@onevision.de> wrote:
>Christian Brunschen schrieb:
>
>> NeXT/Apple's classes tend to keep the reference count external to the
>> object itself, in a separate hashtable.
>this shouldnt stay without comment because the impression of
>inefficiency comes up quickly.
>actually the external hashtable is just the very default
>implementation of the framework and is off course slow
>and should be avoided for all objects that frequently
>need refcounting by doing the refcounting with an instance
>variable...

That is't entirely true.

The default implementation with a separate hashtable can be optimized to
only start recording objects in the hash table once the reference count
goes _above_ 1; so any newly created object that has a reference count of
1 never gets put into the table, only a subsequent retain message would
place it there. An existing object's absence from the hash table would
simultaneously imply that that object has a reference count of 1.

This special case of an object being instantiated with a reference count
of 1, used, and then deallocated, is quite common, and with such an
implementation we've done away with needing to allocate any space for the
reference counts of such objects, thus reducing the amount of memory
needed by a potentially significant amount (if the added storage required
for the objects' reference count is a significant portion of the instance
size, and a suitably big number of such objects are created).

Also, keeping the reference count externally permits retrofitting the
reference-counting functionality onto existing classes without having to
add any variables to them, which is also quite cool.

But just as you mentioned, if you know your objects will be referenced a
lot and you need to speed up your reference count management, you can
simply reimplement -retain and -release in your class to use an instance
variable, which will give you the speedup while still interoperating with
the rest of the system.

>guenther

// Christian Brunschen

Christian Brunschen schrieb:
> In article <eb7jjp$akq$1@news.r-kom.de>,
> guenther <guenther@onevision.de> wrote:
>
>>Christian Brunschen schrieb:
>>
>>
>>>NeXT/Apple's classes tend to keep the reference count external to the
>>>object itself, in a separate hashtable.
>>
>>this shouldnt stay without comment because the impression of
>>inefficiency comes up quickly.
>>actually the external hashtable is just the very default
>>implementation of the framework and is off course slow
>>and should be avoided for all objects that frequently
>>need refcounting by doing the refcounting with an instance
>>variable...
>
>
> That is't entirely true.
>
> The default implementation with a separate hashtable can be optimized to
> only start recording objects in the hash table once the reference count
> goes _above_ 1; so any newly created object that has a reference count of
> 1 never gets put into the table, only a subsequent retain message would
> place it there. An existing object's absence from the hash table would
> simultaneously imply that that object has a reference count of 1.
>
> This special case of an object being instantiated with a reference count
> of 1, used, and then deallocated, is quite common, and with such an
> implementation we've done away with needing to allocate any space for the
> reference counts of such objects, thus reducing the amount of memory
> needed by a potentially significant amount (if the added storage required
> for the objects' reference count is a significant portion of the instance
> size, and a suitably big number of such objects are created).
>
> Also, keeping the reference count externally permits retrofitting the
> reference-counting functionality onto existing classes without having to
> add any variables to them, which is also quite cool.
>
> But just as you mentioned, if you know your objects will be referenced a
> lot and you need to speed up your reference count management, you can
> simply reimplement -retain and -release in your class to use an instance
> variable, which will give you the speedup while still interoperating with
> the rest of the system.
>
>
>>guenther
>
>
> // Christian Brunschen
they did a wise design, I know that...

but: did you ever compare/measure the difference?
did you realize that the extrarefcount global hashtable
needs thread locking for any access?
last but not least: how many classes did you ever write
that need the above described benefits?
how many classes did you write that need the speed in
reference counting?
did you implement your general NSRefCountingObject for reuse?

guenther

In article <eb9p13$rgp$1@news.r-kom.de>,
guenther <guenther@onevision.de> wrote:
>Christian Brunschen schrieb:
>> In article <eb7jjp$akq$1@news.r-kom.de>,
>> guenther <guenther@onevision.de> wrote:
>>
>>>Christian Brunschen schrieb:
>>>
>>>
>>>>NeXT/Apple's classes tend to keep the reference count external to the
>>>>object itself, in a separate hashtable.
>>>
>>>this shouldnt stay without comment because the impression of
>>>inefficiency comes up quickly.
>>>actually the external hashtable is just the very default
>>>implementation of the framework and is off course slow
>>>and should be avoided for all objects that frequently
>>>need refcounting by doing the refcounting with an instance
>>>variable...
>>
>> That is't entirely true.

[ deletia ]

>> // Christian Brunschen
>
>they did a wise design, I know that...

Well, my point was that the design has its _advantages_ as well as
disadvantages.

>but: did you ever compare/measure the difference?

No, I've never had a problem with the performance, so it's never been an
issue.

I think that is really the main point: Your advice seemed to be 'always
add a reference-count instance variable to your classes'; I wanted to
point out that there are some useful attributes to the chosen design.
Another point that I forgot to make originally is that for many people,
the disadvantages of that design don't really crop up much; i.e., the
performance implications may, for many people, never crop up. In those
cases, there is no need to move the reference counts into an instance
variable. Just the usual advice against premature optimisation.

[ more deletia ]

>guenther

// Christian