Memory management design

[Paulo Pinto]

On Wednesday, 10 July 2013 at 11:38:35 UTC, JS wrote:
> On Wednesday, 10 July 2013 at 10:56:48 UTC, Paulo Pinto wrote:
>> On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
>>> On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote:
>>>> On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
>>>>> On 10 July 2013 17:53, Dicebot <public at dicebot.lv> wrote:
>>>>>
>>>>>> On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>
>>>>>> I am pretty sure stuff like @nogc (or probably @noheap. or 
>>>>>> both) will have
>>>>>> no problems in being accepted into the mainstream once 
>>>>>> properly
>>>>>> implemented. It is mostly a matter of volunteer wanting to 
>>>>>> get dirty with
>>>>>> the compiler.
>>>>>>
>>>>>
>>>>> I'd push for an ARC implementation. I've become convinced 
>>>>> that's what I
>>>>> actually want, and that GC will never completely satisfy my 
>>>>> requirements.
>>>>>
>>>>> Additionally, while I can see some value in @nogc, I'm not 
>>>>> actually sold on
>>>>> that personally... it feels explicit attribution is a 
>>>>> backwards way of
>>>>> going about it. ie, most functions may actually be @nogc, 
>>>>> but only the ones
>>>>> that are explicitly attributed will enjoy that 
>>>>> recognition... seems kinda
>>>>> backwards.
>>>>
>>>> That is the approach taken by other languages with untraced 
>>>> pointers.
>>>>
>>>> Actually I prefer to have GC by default with something like 
>>>> @nogc where it really makes a difference.
>>>>
>>>> Unless D wants to cater for the micro-optimizations folks 
>>>> before anything else, that is so common in the C and C++ 
>>>> communities.
>>>>
>>>
>>> It's not about any micro-optimizations. Many real time 
>>> applications simply can't use D because of it's stop the 
>>> world GC(at least not without a great amount of work or 
>>> severe limitations).
>>>
>>> By having a @nogc attribute people can start marking their 
>>> code, the sooner the better(else, at some point, it because 
>>> useless because there is too much old code to mark). @nogc 
>>> respects function composition... so if two functions do not 
>>> rely on the gc then if one calls the other it will not break 
>>> anything.
>>>
>>> So, as libraries are updated more and more functions are 
>>> available to those that can't use gc code, making D more 
>>> useful for real time applications. If custom allocation 
>>> methods ever come about then the @nogc may be obsolete are 
>>> extremely useful depending on how the alternate memory models 
>>> are implemented.
>>>
>>> Code that only use stack allocation or static heap allocation 
>>> have no business being lumped in with code that is gc 
>>> dependent.
>>
>> I do agree D needs something like @nogc, something like 
>> untraced pointer as I mentioned.
>>
>> What I am speaking against is making GC a opt-in instead of 
>> the default allocation mode.
>>
>
> I agree but it's not going to happen ;/
>
>> In such case it looks more as a workaround instead of fixing 
>> the real problem, which is having a better GC.
>>
>> Note that by GC, I also mean some form of reference counting 
>> with compiler support to minimize increment/decrement 
>> operations.
>
> I don't know if that is a solid statement. ARC is pretty 
> different from AGC.

Reference counting is pretty much seen as a primitive form of 
garbage collection in the CS literature.

In some books it is usually the first chapter, hence the way I 
phrased my comment.


--
Paulo