Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the difference between Python GC reference counting and Objective-C's ARC? [closed]

I was reading about memory management for various languages and the fact that Objective-C doesn't have managed memory because it causes stutters in the UX of the mobile apps.

I know ARC doesn't deal with circular reference, while Python's GC does.

I know that ARC is not a garbage collector at all and so it does not stop the execution of the main program to perform the memory management.

Could Python use a hybrid approach? Take some of the advantages of ARC and at the same time run the GC less often (or for a shorter period of time) so that it can still deal with circular references?

Or as anything like that being attempted within the Python community?

EDIT: I know Python uses reference counting, but as far as I know the objects whose reference drops to 0 are not immediately removed from memory (which ARC does). I am wondering if an immediate release of the memory occupied by that object could make Python more suitable in low memory environments, and because in that case the GC would possibly run less often, it would cause less threads interruptions. Both things would be ideal for a mobile application as far as UX.

like image 590
Gabriel Avatar asked Mar 24 '23 02:03

Gabriel


1 Answers

As far as I can tell, Objective-C's ARC gives, in the end, the same thing as CPython's reference counting, minus the circular reference handling. ARC is merely a fancy new name that was (re)invented to mean that the Objective-C compiler, rather than the programmer, inserts the reference counting code automatically.

Let us assume for the purpose of this answer that CPython could be rewritten in Objective-C (which is unrealistic). What you'd get by using ARC over explicit reference counting is:

  • Simpler code.

  • No cyclic collection.

  • Guaranteed correct code. There are a few known, and probably some unknown, issues with reference counting in CPython that can lead to crashes in some extremely unlikely cases; some of Lib/test/crashers/ are based on this.

  • Slightly slower code. Indeed, a compiler is usually not as smart as a human in finding cases where we don't actually need to manipulate the reference counter.

As a PyPy developer, I can report my own experience: we tried at some point in the past to do the same, i.e. have reference counting code inserted automatically during compilation. However we abandoned this approach because without advanced optimizations you get seriously slower code. Instead we use some simple "real" garbage collection (GC) system now; it gives better performance than even CPython's reference counting. So my own advice for compiler-makers would be that if you want a compiler that can insert the necessary code automatically, you'd be much better off using any of a number of better GCs. Last I checked however, LLVM's support was still almost null in this regard.

like image 73
Armin Rigo Avatar answered Apr 20 '23 00:04

Armin Rigo