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

On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
> ...

@nogc itself does not help here as this code will still be affected by stop-the-world. Those issues are related, but not directly.

It will help to avoid memory leaks when you switch the GC off though.

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

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.

--
Paulo

On 2013-07-10 08:00:42 +0000, Manu <turkeyman@gmail.com> said:

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

There's two ways to implement ARC. You can implement it instead of the GC, but things with cycles in them will leak. You can implement it as a supplement to the GC, where the GC is used to collect cycles which ARC cannot release. Or you can implement it only for a subset of the language by having a base reference-counted class and things derived from it are reference counted.

The two first ideas, which implement ARC globally, would have to call a function at each and every pointer assignment. Implementing this would require a different codegen from standard D, and libraries compiled with and without those calls on pointer assignment would be incompatible with each other.

On the other end, having a reference counted base class is of more limited utility because you can't reuse D code that rely on the GC if your requirement does not allow the GC to run when it needs too. But it does not create codegen fragmentation.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Wednesday, 10 July 2013 at 10:49:04 UTC, Dicebot wrote:
> On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
>> ...
>
> @nogc itself does not help here as this code will still be affected by stop-the-world. Those issues are related, but not directly.
>
> It will help to avoid memory leaks when you switch the GC off though.

Of Course, I never said stop the world only affected certain parts of the program. ? Having a nogc allows one to use only those functions and disable the gc and not worry about running out of memory.

e.g., import @nogc std.string; only imports nogc functions. Can disable the gc, use reference counting and write a RT app. (it would be better to specify the module as @nogc then all imports can only import @nogc functions)

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

I personally think memory management should be up to the programmer with some sort of GC as a fallback, ideally optional... maybe even selectable at run-time.

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

On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
> most functions may actually be @nogc

Most functions can't be @nogc because they throw exceptions.

Kagamin:

> Most functions can't be @nogc because they throw exceptions.

Probably about half of my functions/metods are tagged with "nothrow". And as ".dup" becomes nothrow and few more functions become nothrow (iota, etc), that percentage will increase. I have also proposed to add to Phobos some nonthrowing functions, like a maybeTo, that help increase the percentage of nothrow functions:

http://d.puremagic.com/issues/show_bug.cgi?id=6840

Bye,
bearophile

On Wednesday, 10 July 2013 at 13:00:53 UTC, Kagamin wrote:
> On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
>> most functions may actually be @nogc
>
> Most functions can't be @nogc because they throw exceptions.

I think I mentioned before, elsewhere, that @nogc could allow exceptions. No one who is sensitive to memory usage is going to use exceptions for anything other than exceptional circumstances, which perhaps don't need the same stringent memory control and high performance as the normal code path.


How much of the exception model would have to change in order to free them from the GC? I don't see high performance as a concern for exceptions so even an inefficient situation would be fine.