On Mon, 08 Apr 2013 19:02:19 +0100, Johannes Pfau <[email protected]>
wrote:
Am Mon, 08 Apr 2013 11:57:08 +0100
schrieb "Regan Heath" <[email protected]>:
On Mon, 08 Apr 2013 09:58:15 +0100, Manu <[email protected]> wrote:
> I suspect Andrei for one knows this, and that's why the D
> containers are so... barely existing. The language is not yet ready
> to say with confidence
> how they should look.
That, and before you can design the containers you need a concrete
allocator interface design. Actually, this is likely the same
blocker for GC-free D as well.
D should have a set of global allocator hooks. If it did, you could
easily catch unexpected allocations in tight loops and realtime
code. If it did, GC-free D would be trivial - just replace the
default GC based allocator with a malloc/free one, or any other
scheme you like.
IIRC stuff like closures and dynamic array appending rely on a gc and
it wouldn't be trivial to change that to a normal alloc/free allocator.
True, my comment actually contained 2 ideas, neither of which I explained
properly :p
Idea #1. Have alloc/realloc/free hooks for use /with/ the GC. Allowing
Manu to catch unexpected allocations, or provide the GC with memory from a
pre-allocated block etc. In this case we'd probably want the allocator to
control when the GC performed collection - to avoid it in realtime code.
I think this rather simple idea would give a lot more control and
flexibility to applications with realtime requirements. As Manu himself
said (IIRC) he doesn't mind the GC, what he minds is the hidden
allocations which themselves cause a delay, and I would imagine he would
mind even more if a collection was triggered by one :p
Idea #2. Replace the GC with allocators. In this case, as you say,
without a GC we would have problems catching the 'free' for objects like
closures and arrays (as we'd have no reference to them in user code upon
which to call 'destroy' or similar.
So, we'd either have to replace the GC with reference counting /and/ have
some compiler support for triggers on references leaving scope, for
example. Or, we could require code to call 'destroy' on everything to be
freed and force users to keep references to closures and arrays and
'destroy' them.
There are likely cases where the user code never sees the closure
reference, in this case the allocator itself could perform some object
tracking. We could aid this by having an allocation 'type' allowing the
allocator to track only closure or array allocations - for example, and
ignore user allocations where it assumes the user code will call 'destroy'
on the reference (as delete/free would be called in C/C++).
A good & simple start would be a -vgc switch, similar to -vtls which
prints out all hidden memory allocations. Custom allocators are still
important for the library (toString etc). Apart from that I would just
stay away from language features which allocate. For example instead of
using the concatenate operators I'd just use something like appender
(which should then support custom allocators).
Did you see Manu's problem case? I can't recall the method name but it
was not one which suggested it would allocate, and it didn't in the
general case but in a very specific case it did. As it stands, it's very
hard to tell which language features allocate (without code inspection of
the compiler and standard library) so it's hard to avoid.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
