Hi David,
>Just out of curiosity, how does the GC know when to collect destroy stuff?
The basic answer is when the system cannot regenerate a pointer to an
object, the object is garbage. Garbage collectable systems are those
which obey some rules that allow this property to be inferred from
something reasonably simple. Typically, this is just "having no
pointers" to the object.
> Is it when your data stops being referenced by some variable or
>something of the like? Because in such case it would seem (and it
>probably is) trivially simple to keep stuff in memory for as long as
>necessary by just keeping a list/array/vector/<insert favourite data
>struct here> of objects you don't want GCed yet.
The problem David Young has is that the Poplog garbage collector is a
_relocating_ collector. In other words the pointer values are
changed during garbage collection - disrupting his strategy of
passing pointer offsets. There is no mechanism in Poplog for
protecting an object against relocation and it would be technically
demanding to do such a thing.
The root cause of the difficulty is that pointer offsets are not a
recognized data type in Poplog. This is a long standing omission of
a "well-known" [*] requirement. The result is that there is no
representation of external pointer offsets either.
[*] "Well-known" in this context means that you have put up with one
of my extended rants about garbage collection. Other "well-known"
requirements include cooperation with manual deallocation, the
ability to perform speculative garbage collection, a key-specific
post-GC hook, pointer elision, pointer replacement, pointer reversal,
and proper monitoring tools.
--
Steve
|