Reference counting has some good properties like not using more memory than needed by the program, it gets rid of a factor 2.0 needed by stop-and-copy. Also, for future extensions, it is nice that it collects dead data immediately if coupled with references and finalizers attached to system resources. For example, you never keep files open longer than you need them.
Going for reference counting means:
- A more difficult runtime where a count is held in the header of a node.
- Implementing ALLOC, INCREF and DECREF operations. In the scheme I envision ALLOC becomes a call, INCREF a series of instructions, DECREF another call. Currently, ALLOC is just returning a pointer followed by an increment.
- Major problems are throughput and memory fragmentation.
Question remains: Is a lot of calls plus INCREF/DECREF operations cheap enough?
(Great. Most current reference counting literature is on Java/C#. So far, RC in Java a low factor overhead, RC in C# makes the code go to a grinding halt. But there are both complex RC implementations for Java, by Bacon and Petrank, and C#, by Joisha, with claim good performance. Also, reference counting lisp?)
(Great. Most current reference counting literature is on Java/C#. So far, RC in Java a low factor overhead, RC in C# makes the code go to a grinding halt. But there are both complex RC implementations for Java, by Bacon and Petrank, and C#, by Joisha, with claim good performance. Also, reference counting lisp?)
It might be interesting to dig around for 1) RC overhead for functional languages vs. imperative languages, if such literature exists; and 2) low compiler overhead "stupid RC tricks" to elide incr/decr operations where possible and convenient.
ReplyDeleteThere is no clarity. Everyone seems to agree that RC has too much overhead until it is implemented to speed up -mostly generational- GC.
ReplyDeleteI don't like any of the solutions at the moment.