Std Phobos 2 and logging library?

[Denis Koroskin]

On Sun, 12 Apr 2009 21:13:09 +0400, Leandro Lucarella <llucax at 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  
>> <llucax at 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.