Talk:Reference counting

Since when has reference counting been called "garbage collection"?
Since when has reference counting been called "garbage collection"?

I thought that the taxonomy was:
 * Memory management
 * Manual
 * Automatic
 * Garbage collection
 * Reference counting
 * Region inference
 * etc...


 * Academic literature has always called RC and tracing forms of GC. See http://gchandbook.org/ --31.53.77.28 (talk) 21:42, 1 February 2020 (UTC)

Reasons why reference counting is not garbage collection

 * There's no "collector". In garbage collection there's code the purpose of which is detect and collect unused memory. This process typically runs in a separate thread, but it needs not. In reference counting there's no such code.


 * The nearest equivalent with reference counting is the code that recursively decrements objects when the reference count of a parent reaches zero. In particular, this look is the source of naive reference counting's worst case unbounded pause times. --31.53.77.28 (talk) 21:47, 1 February 2020 (UTC)


 * It's not automatic. In reference counting the counts are incremented/decremented explicitly by the programmer, or implicitly by linking it to variable scope. Should this be considered "automatic" then all stack based languages would be doing garbage collection, but this is not the usual definition. — Preceding unsigned comment added by 212.163.50.211 (talk) 09:24, 23 April 2012 (UTC)


 * Reference counting usually is automatic (e.g. in Python, Mathematica and Erlang). Some languages allow reference counting to be used manually (e.g. shared_ptr in C++) at the peril of the programmer. --31.53.77.28 (talk) 21:47, 1 February 2020 (UTC)

Perl use Reference counting
I think it should be added that Perl also uses Reference Counting with no cycle detection. Programmers should deal with cycles via proxy objects or something similar.

MacOSX Objective-C/Cocoa Reference Counting
Obj-C/cocoa also uses reference counting, however it should be explicitly noted that reference counting in obj-C/cocoa is done manually by the programmer, which means that the overzealous count updates with list traversals don't happen in this language (for other reasons too, such as encapsulation, so for example an NSArray object would handle traversals and counts of items it owns without ever incrementing them. If you pull an object from an array, you increment its count manually to retain that you are now responsible for it, which is necessary anyway).

It should be noted that reference counting can be a form of garbage collection if it is done automatically. If automatic, then it's like a constant cycle of black-grey-white listing that automatically collects 'white' objects once they become unreachable. It should further be noted that by doing manual reference counting, you can avoid the (expensive) need to copy objects that are passed to functions or methods, since the methods increment their reference counts upon accepting them, so even if the previous owner decrements the count the object won't be prematurely dealloced and produce a dangling pointer for the current owner. Done this way, it can actually reduce the cost of manual memory management (by reducing the effective number of allocs required, since you no longer have to alloc copied objects because you don't need to copy them under normal circumstances).

ww
wwww —Preceding unsigned comment added by 116.228.222.34 (talk) 03:08, 19 March 2009 (UTC)
 * Wwww, to yourself! ... said: Rursus ( m bork³ ) 20:27, 29 September 2009 (UTC)

COM
The COM section kind of a little contradicts itself by saying that:
 * demonstrating the viability of reference counting in large-scale systems

while next explaining that
 * Bugs caused by incorrect reference counting in COM systems are notoriously hard to resolve

and then explaining that
 * Microsoft has abandoned reference counting in favor of tracing garbage collection for the .NET Framework.

The information is of course all true, except not very balanced. I think that "demonstrating the viability" is an advertizing statement, while "notoriously" demonstrate a detractor opinion. Could the truth be that a non-flawed system of perfect programmer discipline could theoretically use a reference counted distributed object system ("MiddleWare") of large scale, but that in real life of stressed careless programmers, this is an ephemeral state, and that then only a few fully trusted applications can be used. ... said: Rursus ( m bork³ ) 20:27, 29 September 2009 (UTC)

Disk Operating Systems
The term "disk operating system" keeps appearing in this article, but I also keep wondering if this term isn't obsolete and it should refer simply to "operating systems"? 84.209.121.30 (talk) 20:33, 16 June 2010 (UTC)

Fragmentation
The problem of fragmentation isn't mentioned at all in the article (it's only listed in the "Issues" at the bottom of the page). It would be great if somebody knowledgeable adds info about it. Ivant (talk) 21:34, 28 December 2011 (UTC)

reference counting requires every memory-managed object to reserve space for a reference count
The statement "reference counting requires every memory-managed object to reserve space for a reference count" isn't true. In Apple's Objective C implementation, the reference count is stored in a global hash table (see this forum post, for example) and then only for reference counts greater than 1.

--212.140.132.200 (talk) 12:49, 10 January 2012 (UTC)

Myths in the advantages section
The advantages section currently lists several myths. I have added to them. Here's a list:

Reference counting does not reclaim objects as soon as they can no longer be referenced. Doing so requires solving the halting problem in the general case.

Reference counting is not inherently incremental because decrements avalanche.

The claim that reference counting is simple is subjective. The mark-sweep GC in HLVM is less than 20 lines of code.

Tracing GC systems do not generally use finalizers for the destruction of scarce non-memory resources. For example, neither the JVM nor .NET do this.

The implication that determinism is an advantage of reference counting over tracing GC is dubious. Thread-safe reference counting with atomic decrements is non-deterministic in general because threads race to decrement to zero.

Statements about the regularity of GC cycles in tracing collectors as a function of free memory are pure speculation.

The article claims that tracing GC requires more space to be efficient compared to reference counting. Perhaps that is true under certain circumstances but I do not believe it is true in general. In particular, scope-based reference counting such as `shared_ptr` in C++ keeps floating garbage to the end of scope and, consequently, can have much higher memory requirements that generational garbage collection.

Finally, the discussion of functional programming languages is bogus. Almost all major FPLs (SML/NJ, MLton, OCaml, F#, Scala, Haskell, SBCL) use generational garbage collection with pointer bump allocators. Mathematica and Erlang are the only FPLs I can think of that can use reference counting and both are notoriously slow.

External links modified
Hello fellow Wikipedians,

I have just added archive links to 1 one external link on Reference counting. Please take a moment to review my edit. If necessary, add after the link to keep me from modifying it. Alternatively, you can add to keep me off the page altogether. I made the following changes:
 * Added archive https://web.archive.org/20110609033837/http://developer.apple.com:80/technologies/ios5/ to http://developer.apple.com/technologies/ios5/

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Cheers.—cyberbot II  Talk to my owner :Online 12:17, 1 January 2016 (UTC)

Definition of a Reference Cycle
Hi, I'm a student. I'm having difficulty finding an accessible definition of a reference cycle. If a kind soul could link a page to a reference cycle or expand on the concept here on this page, it would help me and other students. 75.118.76.100 (talk) 16:06, 7 December 2022 (UTC)