radical ideas about GC and ARC : need to be time driven?

via Digitalmars-d digitalmars-d at puremagic.com
Tue May 13 01:57:17 PDT 2014


On Monday, 12 May 2014 at 04:22:21 UTC, Marco Leise wrote:
> On the positive side the talk about Rust, in particular how
> reference counted pointers decay to borrowed pointers made me
> think the same could be done for our "scope" args. A reference
> counted slice with 3 machine words could decay to a 2 machine
> word "scoped" slice. Most of my code at least just works on the
> slices and doesn't keep a reference to them.

I wouldn't mind banning slices on the heap, but what D needs is 
to ban having pointers to internal data outlive allocation base 
pointers. I think that is a bad practice anyway and consider it 
to be a bug. If you can establish that constraint then you can 
avoid tracing pointers to non-aligned addresses:

if (addr&MASK==0) trace...

You could also statically annotate pointers to be known as 
"guaranteed allocation base pointer" or " known to be traced 
already" (e.g. borrowed pointers in Rust)

> A counter example
> is when you have something like an XML parser - a use case
> that D traditionally (see Tango) excelled in. The GC
> environment and slices make it possible to replace string
> copies with cheap slices into the original XML string.

As pointed out by others, this won't work for XML. It will work 
for some binary formats, but you usually want to map a stuct onto 
the data (or copy) anyway.

I have little need for slices on the heap... I'd much rather have 
it limited to registers (conceptually) if that means faster GC.




More information about the Digitalmars-d mailing list