DDMD as showcase?

[Paulo Pinto]

Am 11.02.2014 20:58, schrieb Adam Wilson:
> On Tue, 11 Feb 2014 08:33:59 -0800, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 2/11/14, 6:32 AM, Jakob Ovrum wrote:
>>> On Tuesday, 11 February 2014 at 10:29:58 UTC, thedeemon wrote:
>>>> On Tuesday, 11 February 2014 at 04:36:28 UTC, Adam Wilson wrote:
>>>>
>>>>> The GC itself is an orthogonal issue to the compiler. The way I see
>>>>> it, once the compiler can output precise information about the heap,
>>>>> stack, and registers, you can build any GC you want without the
>>>>> compiler requiring any knowledge of the GC.
>>>>
>>>> If you want a fast GC it needs to be generational, i.e. most of the
>>>> times scan just a portion of heap where young objects live (because
>>>> most objects die young), not scan whole heap each time (as in current
>>>> D GC). However in a mutable language that young/old generation split
>>>> usually requires write barriers: compiler must emit code differently:
>>>> each time a pointer field of a heap object is mutated it must check
>>>> whether it's a link from old gen to young gen and remember that link
>>>> (or just mark the page for scanning). So to have a generational GC in
>>>> a mutable language you need to change the codegen as well. At least
>>>> this is how most mature GCs work.
>>>
>>> D code has different allocation patterns from Java and C#. In idiomatic
>>> D, young GC-allocated objects are probably much fewer.
>>
>> I agree this is a good hypothesis (without having measured). My
>> suspicion is a good GC for D is different from a good GC for Java or C#.
>>
>> Andrei
>>
>
> I'm not so sure about that. That might be true for Java but C# is a
> stack based language with value types. However, I think that, as with
> C#, we often forget about the temporaries we implicitly allocate.
> Strings, Arrays, closures (and lambdas in C#),the  ~= operator, etc.
> These highly ephemeral semantics are also quite common in C#. I imagine
> that this makes D's allocation patterns much closer to C# than Java.
>
> I was thinking about this last night and as I continue reading the GC
> Handbook, I think I understand more about why MS did what they did with
> the .NET GC. First of all, they used every algorithm in that book in one
> way or another. For example, the Large Object Heap is a simple
> Mark-Sweep because there tend to be relatively few nodes to check and
> fragmentation is much lower than the ephemeral generations, however,
> they enabled opt-in compaction in the latest release because the large
> size of each node meant that fragmentation became a problem quicker in
> long-running processes.
>
> Also the more I dive into it, the more I think that thread-local GC is a
> bad idea. As I understand it the point is to reduce the overall pause on
> any one thread by reducing the scope of the heap to collect. However, I
> would argue that the common case is that a program has a few threads
> that dominate the majority of running time, with many ephemeral threads
> are created for quick work (an incoming message over a socket for
> example). In this case your main threads are still going to have large
> heaps for the dominate threads and most likely heaps that are never
> collected on the ephemeral threads. This means that a few threads will
> still have noticeable pause times, and we've significantly increased
> compiler complexity to support thread local GC on all threads, and
> probably hammered thread start up time to do it.
>
> I could go on, but my point is that at the end of the day if you want
> performant collections, you end up using every trick in the book. The
> mixture may be slightly different, but I would suggest that the mixture
> is going to be slightly different based on the type of app even using
> the same language, which is why .NET provides two modes for the
> collector, Server and Workstation, and Java has four. So saying that D's
> collector will be different is naturally obvious, but I don't think it
> will be significantly different than C# as implied. We still have
> roughly similar allocation patterns, with roughly similar use cases, and
> will most likely end up building in every algorithm available and then
> tuning it the mixture of those algorithms to meet D's needs.
>

Another thing that you didn't mention is that most GC based environments 
provide tooling for GC tuning, which as far as I am aware, still don't 
exist for D.

Java, .NET and Haskell ones are quite good.

--
Paulo