On Sun, 12 Apr 2009 21:13:09 +0400, Leandro Lucarella <llu...@gmail.com> wrote:
Robert Jacques, el 11 de abril a las 01:05 me escribiste:
On Fri, 10 Apr 2009 23:04:16 -0400, Leandro Lucarella
<llu...@gmail.com> wrote:
>I hope I can come up with something useful with my thesis (improving
D's
>GC) and I can contribute that. Right now all my energies are focused on
>that, and I'm very close to the point to finally start playing with
>alternate implementations.
>
>BTW, is there any real interest in adding some more power to the GC
>implementator to allow some kind of moving or generational collector?
Yes.
>Here are some good starting points on how to allow better GC support
in D:
>http://d.puremagic.com/issues/show_bug.cgi?id=679
I think this should be less a spec issue and more a library issue and
core.memory seems to already have a BlkAttr.NO_MOVE, which covers memory
pinning.
This is just a flag. You need extra information for knowing actually when
to set that flag. And for that, you need some type information. A cell
can
be moved when you know everything pointing to it is an actual pointer, so
you can safely overwrite it with the new location.
>http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=35426
Well, making the GC type aware/semi-precise (i.e. providing support for
moving/copying collectors) seems like the most important change,
Exactly.
The change to support concurrent GCs, effects both performance and code
gen significantly. Also, if D's thread model supports thread-local
heaps, the need for a concurrent GC is vastly reduced (its only
a benefit to the shared heaps (mutable and immutable), while most
objects would are on the thread-local heaps).
I think I'll target D1 for now. The reasons are:
* Stability
* Free compilers availability (you know what kind of free I'm talking
about =)
* Programs availability (I'm trying to gather programs to make a
benchmark
suite, without much success unfortunately, only Leonardo Maffi answered
my request for examples[1], and what I need the most are *real*
programs)
So for know, I'm not considering anything of that. The only thing I'm
vaguely considering is thread-specific heaps, to allow lock-free
allocation. This has some disadvantages too, so it's low priority for me
right now.
[1] http://proj.llucax.com.ar/blog/dgc/blog/post/-1382f6a3
With "thread-local by default" policy, D2 may be *much* more suitable for your
research, so think twice.
