The total CPU overhead of M&S should be proportional to the number of live objects times the rate of object allocation. (Traditionally, collections were trigger

The total CPU overhead of M&S should be proportional to the number of live objects times the rate of object allocation. (Traditionally, collections were triggered every so many allocations or so many bytes allocated, but heuristics based on the amount of free heap would give similar behavior.) The total CPU overhead of reference counting is proportional to the rate of reference creation and destruction. You can really bring this down if your compiler is told or can figure out which references can be borrowed. The best case for reference counting is where the compiler is told (or can infer) which references are borrowed, and the code is written in a style that mostly borrows references, and rarely mutates data structures. One interesting hybrid approach is "one bit reference counting". You have a 1-bit flag in the object header that gets set when a reference to the object gets copied. If a reference gets destroyed, and the object doesn't have the flag set, that means that the referenced object is garbage. Lots of objects never have more than one reference to them, and this little tweak allows for more immediate reclamation of many objects, which allows you to get away with doing tracing GC less often.