Re:Ruby Garbage Collection: Still Not Ready for Production
by nostrademons on Friday March 28, 2014 @03:48PM
(#7489551)
Reference counting is also the reason why Python requires a GIL. Incrementing a reference count is an opportunity for a race condition (another thread could read the refcount in between your read and write), which means that every reference count needs to be protected by a lock. Either you do fine-grained locking for each object, or you add a GIL for the whole interpreter. The former will absolutely kill performance (not only do you need to increment a refcount with every assignment or function call, you need to take a lock). The latter makes the whole interpreter thread-hostile.
[ Parent
| on HN ]
Re:Ruby Garbage Collection: Still Not Ready for Production
by teacup50 on Saturday March 29, 2014 @12:40AM
(#7491437)
You're off in the weeds. A refcount can be incremented/decremented with a simple atomic compare-and-swap, and that's exactly what most refcounting systems do.
It's not free, but it's damn close to it.
Re:Ruby Garbage Collection: Still Not Ready for Production
by herokusaki on Saturday March 29, 2014 @05:19AM
(#7491816)
If that is the case then why doesn't Python do it? I mean this as a real question; I genuinely don't know.