Where reference counting is stored - C

This is a discussion on Where reference counting is stored - C ; 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?...

+ Reply to Thread
Results 1 to 8 of 8

Where reference counting is stored

  1. Default Where reference counting is stored

    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?


  2. Default Re: Where reference counting is stored

    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

  3. Default Re: Where reference counting is stored

    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,


  4. Default Re: Where reference counting is stored

    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

  5. Default Re: Where reference counting is stored

    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

  6. Default Re: Where reference counting is stored

    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

  7. Default Re: Where reference counting is stored

    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

  8. Default Re: Where reference counting is stored

    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

+ Reply to Thread

Similar Threads

  1. Garbage Collector Reference Counting
    By Application Development in forum CSharp
    Replies: 9
    Last Post: 12-02-2007, 06:23 PM
  2. Reference counting
    By Application Development in forum Idl-pvwave
    Replies: 2
    Last Post: 09-20-2007, 03:13 PM
  3. Reference counting
    By Application Development in forum c++
    Replies: 2
    Last Post: 07-30-2007, 07:36 AM
  4. Replies: 6
    Last Post: 03-17-2005, 10:03 PM
  5. Debugging reference counting
    By Application Development in forum Graphics
    Replies: 1
    Last Post: 07-29-2003, 08:24 AM