Warp wrote:
>   It's impossible for a reference counter to overflow.

Unless your reference counter is smaller than the size of a pointer. 
Yes, you can build a reference counting system that doesn't overflow, by 
allocating a huge amount of space to a counter that is usually less than 
4 bits. But since you *still* need some other sort of garbage collection 
anyway, why would you waste that much space?

>>You can allocate 100,000 individual objects and 
>>free them all with one instruction.
> 
>   Assuming no memory fragmentation, of course.

How do you think allocation in a garbage collected system works? Of 
*course* there's no fragmentation.

>   Besides, a reference-counting system doesn't have to *free* the
> objects immediately when the last reference dies. It can mark the
> object as "to be freed" and put it somewhere to wait.

Um, why would it have to "put it somewhere"? The problem isn't "freeing 
the object". The problem is running through all the pointers in the 
object whose reference went to zero and marking those as freed also.

Once you do what you describe, then you've lost the simplicity of 
reference counting, and now you're doing some other sort of garbage 
collection. (Which sort depends on how/when you free the objects.)

And you still haven't solved the major problem, which is that reference 
counting DOES NOT WORK.  Reference counting, even with sufficiently 
large counters, does not free all the garbage, even if you do it 
inefficiently.

>   Btw, how does the GC engine know that the object is not used anymore?

There are a number of ways, from simplistic to convoluted. Generally, GC 
engines assume they can find the live pointers.

If you're actually interested in the topic, there are good references 
freely available. If you're just interested in arguing, I'm not.

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message