d future or plans for d3

[Jacob Carlborg]

On 2011-12-19 00:19, Adam Wilson wrote:
> On Sun, 18 Dec 2011 15:02:17 -0800, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 12/18/2011 11:53 PM, Vladimir Panteleev wrote:
>>> On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
>>>> That is an interesting opportunity. At any rate, I am 100% convinced
>>>> precise GC is the only way to go, and I think I've convinced Walter to
>>>> a good extent as well.
>>>
>>> Sacrificing something (performance, executable size) for something else
>>> is not an unilateral improvement.
>>
>> It is an unilateral improvement if both options are kept open. I don't
>> see a reason to cease support for the current GC model.
>>
>> Furthermore, a generational GC performs much better than a simple
>> mark-sweep GC.
>
> It seems to that we are really dancing around the potential solution. A
> pluggable GC interface that allowed the developer to choose the right GC
> for the task, or no GC at all. Imagine if all the developer had to do is
> set a compiler switch and the compiler automatically linked in the
> correct GC for the job. D could ship with a default GC then others could
> write different GC's based on different paradigms or their own needs. It
> would be a piece of work to get the interfaces right, but definitely
> worth it in the long run.
>
> Theoretically this would also give the developer the ability to link in
> multiple collectors and switch between them during program execution,
> provided the working set data was stored in a common format; although I
> have never heard of a use case for such a capability. I imagine that it
> could be useful if your application needs a low power state and you
> wanted to use a more power-efficient GC over a more precise one. I'm
> just theorizing here though. I'm sure their are technical snags that
> would prevent this from happening.
>
> I think supporting a NoGC environment is a good idea in the long run as
> their are cases to be made for manual memory management, but it also
> shouldn't be our first goal. GC's are were the value is.
>

It's already possible to plug different GC's at link time.

-- 
/Jacob Carlborg