www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC - Latest idea

reply Arcane Jill <Arcane_member pathlink.com> writes:
..and this is a good one.

The biggest problem with a custom allocator is knowing WHEN to run the
deallocator. When is the object no longer reachable? How can you ever know?

If I gave Int a custom allocator, for example, it could be made secure. But the
price of that is that everyone would have to explicitly delete all of their
Ints, or they'd get a memory leak - and that's W-A-Y too messy. I can't expect
people to do that.

But it would be S-o-o-o much simpler if the garbage collector could just TELL ME
that it was no longer reachable. The GC has all the functionality built in,
after all.

I think it would just be a small change. As in:

BEFORE - if a class overrides new(), the GC ignores all references returned from
its constructor.

AFTER - if a class overrides new(), the GC adds it to it's list of things to
look out for. When it goes out of reach, it calls the object's destructor - but
NOT the class's deallocator. That is, and should remain, the responsibility of
the custom allocator.

If anyone does an explicit delete then the destructor and the deallocator are
both called immediately (in that order). Otherwise, if it just goes out of
scope, the destructor but not the deallocator is called.

That way, everyone is happy - because, you see, within ~this(), we can add the
object's address to the allocator's list of things to be cleaned up, and the
allocator can do it's cleanup later, as and when it decides, but at least then
it would KNOW that it was safe to do so.

This strategy makes more sense to me than any I can think of (including the
current strategy).

I'm not sure about this, but I think that, under the current strategy, if you
explicitly call delete(), it must result in a call to both the destructor AND
the deallocator, which makes having two separate functions a bit pointless.

In other words - I don't want the GC to go around calling my custom delete(),
but I *DO* want it to call ~this(). Can we do that?

If we can, everything gets a whole lot simpler - and we won't need global new or
global delete either, so we can then drop that idea. Simple.

Arcane Jill
Jun 09 2004
parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
IIRC custom allocators where added to the language for people that 
didn't want the garbage collector to be looking at the allocated memory 
(like for game and real time development) mostly for performance reasons.


-- 
Julio CÚsar Carrascal Urquijo
http://jcesar.f2o.org/
Jun 09 2004