..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

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/