Differences between version 5 and predecessor to the previous major change of GarbageCollection.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 5 | Last edited on Tuesday, October 7, 2003 1:10:18 pm | by GlynWebster | Revert |
| Older page: | version 4 | Last edited on Monday, October 6, 2003 2:08:26 pm | by AristotlePagaltzis | Revert |
@@ -1,13 +1,18 @@
-GarbageCollection means letting the computer track memory usage and free unused blocks automatically. This works surprisingly well, and is used in many ProgrammingLanguages - in just about every very high level language, and also [Java]. Since manually managing memory is notoriously difficult, GarbageCollection can cut a huge portion out of development time and nowadays it won't even negatively impact (infact
, may improve) the performance of an application.
+GarbageCollection means letting the computer track memory usage and free unused blocks automatically. This works surprisingly well, and is used in many ProgrammingLanguages - in just about every very high level language, and also [Java]. Since manually managing memory is notoriously difficult, GarbageCollection can cut a huge portion out of development time and nowadays it won't even negatively impact (in fact
, may improve) the performance of an application.
GarbageCollection protects programmers from
* forgetting to deallocate memory, ie creating memory leaks
* getting in trouble with responsibility, where one part of the code may deallocate a [DataStructure]s still needed by another part
but not from
* filling up all avaliable memory
-* attempting to dereference null pointers or references
+* attempting to dereference null pointers or references [1]
-Antique GarbageCollection systems used reference counting algorithms. However, they need programmer assistance and reduce performance: reference counting code and reference counter data needs to be inserted all over the place, harming cache coherency. On top of that they're unable to reclaim cyclic [DataStructure]s. It is no wonder they have fallen from favour. However, they do have an advantage that more sophisticated approaches cannot offer without great pains, if at all: timely destruction, which means objects get reclaimed as soon as their last referent has vanished. This can be of immense value for ObjectOrientedProgramming under certain circumstances.
+Antique GarbageCollection systems used reference counting algorithms[2]
. However, they need programmer assistance and reduce performance: reference counting code and reference counter data needs to be inserted all over the place, harming cache coherency. On top of that they're unable to reclaim cyclic [DataStructure]s. It is no wonder they have fallen from favour. However, they do have an advantage that more sophisticated approaches cannot offer without great pains, if at all: timely destruction, which means objects get reclaimed as soon as their last referent has vanished. This can be of immense value for ObjectOrientedProgramming under certain circumstances.
''AddToMe: there should probably be separate pages on !ReferenceCounting and !MarkAndSweep, the former having the above paragraph moved to.''
+
+--
+[1] [ML] languages have a interesting (perhaps obvious) way of preventing that: there are no null references, references can only be created by applying a ''ref'' operator to an existing object. If you want an object to be optional there is seperate ''option'' type for expressing that.
+
+[2] Older versions of [Python] (those before 2.1?) used this. I think the excuse was that it was fast.
