Associative Arrays and Interior Pointers

[Leandro Lucarella]

dsimcha, el 10 de mayo a las 18:04 me escribiste:
> == Quote from Sean Kelly (sean at invisibleduck.org)'s article
> > dsimcha wrote:
> > >
> > > 2.  Other than its abysmal interaction with the current GC and the lack of
> > > ability to iterate using ranges, the current AA implementation actually seems
> > > pretty good.  One way to remedy a large portion of the GC issues without a
> > > massive overhaul of the GC would be to introduce a feature into the GC where a
> > > block of memory can be flagged as NO_INTERIOR.
> > Neat idea.  Some GCs (like the Boehm GC) can be set NO_INTERIOR
> > globally, but it never crossed my mind to do this per block.  For
> > certain data structures, this might be pretty useful.
> 
> I get the impression that D's GC will always have a significant degree of
> conservatism.  Of course, there's always unions, but unioning a pointer type w/ a
> non-pointer type is such an edge case that, if this is the only thing that's
> conservative, then the GC can be considered precise for all practical purposes.
> For now, I'd love to see this added, because it would be an extremely "cheap" way
> to solve a lot of annoying problems.

I really like the idea of NO_INTERIOR too. I don't think it's possible to
be the default because if that is the case you can't have array slices
and/or pointers to a member of a struct/class. But I think it's great for
very special cases (specially to implement high performance data
structures) to be able to instruct the GC to discard interior pointers.

> A few questions:
> 1.  (For Leonardo, especially):  Is the GC likely to get precise enough in the
> near future that something like this would end up being considered a piece of cruft?

I'm sorry, but I finally decided to add concurrency to the current GC. The
main idea is to reduce (almost vanish) pauses. If is not too hard, and
time help, I'll try to add some preciseness if it only involves changes in
the internal runtime, but I honestly don't think I'll have the time.

I'm talking about finishing my thesis here. When it's finished I think and
hope to keep working on the D GC...

> 2.  Other than that, is there any reason this should not go in?

I don't see any reason, is a backward compatible change.

> 3.  Sean, if you're seriously thinking of putting this in in the near future, let
> me know so I can fix that patch, too.  I did it the same way as my other GC patch,
> with no whitespace, so the line numbers might be screwy here, too.

I think it would be great to have a centralized place where to put this
improvements. This is another situation where I think Tango vs. Phobos
issue is killing D. When I started my work in the thesis I had to decide
whether to work with Phobos or Tango. I finally decided for Tango, because
is the only option for LDC and because is way better organized (and more
receptive to patches). But I hate knowing that my work will be available
(in the best case) only for people using Tango.

I hate to see the D "community" fragmented.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Estamos cantando a la sombra de nuestra parra
una canción que dice que uno sólo conserva lo que no amarra