On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis
wrote:
One advantage of using smart pointers with a GC is that the GC
can then clean up circular references, and you don't
necessarily even need weak pointers (though there are bound to
be cases where they'd still be desirable). But the GC isn't
required to solve the problem. It just makes it so that if you
do end up with a circular reference problem, it'll fix itself.
Yes, in general ownership should not be circular at all. It
should be a DAG growing from the current actor/process/stack in
an unbroken chain of ownership-references.
This should not be conflated with references on the GC heap. In a
pure object oriented GC world objects are created and never cease
to exist, but when they are no longer reachable the computer can
recycle the technical address (but not the conceptual identity).
Conceptually automatic garbage collection (like mark/sweep) can
be viewed as a memory optimization for our non-ideal computers
that would not be needed on a turing machine where you have an
endless amount of memory.
So I don't think there are _good_ reasons to call
finalizers/destructors on the GC heap, it's a sign of a bad model
where the responsibilities are unclear. GC objects should only
"own" memory on the GC heap.
Example:
An initial GC file object should just represent the resource
identity (URI/filepath), and the open/close actions should be
handled by ownership tracking references rooted in the
actors/processes that actually are responsible for accessing it.
I think the viewpoint that ownership is rooted in actors and not
in objects is a better and more performant view than the
"finalizer" view. However if the system allows actors to become
unreachable the runtime might need a collection cycle for the
actors themselves...
