>>> So far, so good. But how does the GC know how long each chunk of
>>> garbage-to-collect is?
>>
>> The GC engine needs to know quite a bit about the objects it's scanning
>> - how big they are, where their pointer fields are, etc. It also usually
>> needs access to each thread's stack, to see what local variables are
>> pointing to objects. And so on and so forth. There's a /reason/ why it's
>> usually hard-coded into the language run-time system rather than being
>> an add-on library.
>
> You didn't quite /exactly/ answer my question :-P
>
> My point here being that without any per-object memory overhead in
> addition to the raw data, you can't do any dynamic memory management at
> all. Whether that overhead is accounted for in the language run-time or
> an added library is quite irrelevant in that respect.

OK. Well typically each object has some overhead that tells you which 
class it belongs to. Typically the GC engine is going to go off that 
information, so you're arguably not adding any additional cost there. 
Typically each object just gets one pointer wider.

Whether a static allocator can match that or not is open to debate. In 
particular, I'd imagine a static allocator might have O(N) cost per 
/free block/, whereas a typical GC implementation doesn't need to track 
free blocks at all...

Post a reply to this message