On Wednesday, 21 December 2011 at 05:08:27 UTC, Jonathan M Davis
wrote:
On Monday, December 19, 2011 08:54:00 Jacob Carlborg wrote:
The Tango runtime has added a new method in Object, "dispose".
This
method is called when "scope" is used or "delete" is
explicitly called.
I don't know if that would help.
That sounds a lot like using clear, though clear doesn't free
memory unless the finalizer does (and I'm not sure that
managing memory with finalizers actually works right now; there
were issues with that previously - but it might have only been
GC memory, so perhaps malloc and free would still work). The
issue with them is escaping references. You can easily end up
with references to data which has been destroyed. It also makes
them harder to pass around unless you essentially wrap the
container in ref-counted struct.
The lifetime of the container must be managed if you really
want to be able to use custom allocators or have the container
be as efficient as possible with regards to its memory usage in
the general case. With a struct, it manages itself. It can do
whatever it wants to with memory internally, and the
combination of its constructor, postblit constructor, and
destructor allows it to take care of it itself and clean up its
memory when it's destroyed. You also don't have issues of stuff
referring to a container which doesn't exist anymore (unless
you add pointers to the container into the mix and then move or
destroy the container).
With classes, if they're owned by the GC, then it's the GC that
manages their lifetime. It destroys them when they're no longer
referenced and it runs a collection cycle. You have no control
over its lifetime, and even if it tries to manage its memory
internally on some level, that memory won't be cleaned up until
the GC collects the container itself. So, if you want to manage
the lifetime of the class, you can't use a naked reference
anymore. You need a way to get the GC to collect it, or you
need to have it somewhere else other than the GC heap.
If you use something like Scoped, then its lifetime will be
tied to the scope that it's in, but you risk references to it
escaping, and limiting the container to a particular scope
could be far too limiting anyway. That being the case, if you
want to use an allocator other than the GC for the class
itself, then you're probably going to have to stick it in a
struct. That struct could then manage the container's lifetime
on some level. It would probably have to use ref-counting and
then call clear on the container when the ref-count hits zero.
That should then allow the container to at least clean up its
internal memory, assuming that that's not on the GC heap, but
unless you use emplace on non-GC heap memory, the container
itself still can't be collected until the GC collects it (since
clear destroys it but doesn't free its memory). Not to mention,
if you're using a ref-counted struct to hold a class in order
to manage that class' lifetime, why on earth did you make it a
class in the first place?
If what you're suggesting with dispose is that it would act
like clear except that it would actually free the container,
well that pretty much goes against the direction that we've
been trying to go with the GC, which is to not have the
programmer explicitly freeing anything on the GC heap (which is
why delete is being removed from the language).
I really think that if we want deterministic destruction of
containers, they need to be structs. And if we want to use
custom allocators with containers, I don't see how we could
reasonably expect them to be of much use unless we're expecting
that programmers will explicitly call clear on them when
they're done with them. So, while the fact that containers need
to be reference types does imply that classes are the way to
go, I think that we're going to have to go with structs if we
want their memory management to be more efficient than simply
letting the GC handle it.
- Jonathan M Davis
I disagree with the above conclusion. you conflate two issues
that are orthogonal:
a. value vs. ref semantics which is already seemed to be decided
in favor of the latter and hence classes. b. memory and lifetime
management
The containers should allow for (disregard the specifics of the
syntax):
Container a = new(SharedMemAllocator) LinkedList();
Container b = new(MallocAllocator) LinkedList();
Container c = new(GC) LinkedList();
When adding an item to the above containers the relevant
allocator will enact its policy about intermixing with other
allocators - by default the item will be copied if it comes from
a separate allocator. I don't see anything here that forces the
use of structs instead of classes.
