d future or plans for d3

[Adam Wilson]

On Sun, 18 Dec 2011 23:43:04 -0800, Jacob Carlborg <doob at me.com> wrote:

> 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.

Cool, I didn't know that. Thanks for the heads up, i'm still working hard  
at understanding D's rather large set of capabilities. :-)

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/