Given all of this talk about memory management, it would seem that it's time for people to start putting forward some ideas for improved memory management designs. I've got an idea or two of my own, but I'd like to discuss my ideas before I draft a DIP so I can try to get everything fleshed out and polished.

Anyway the core idea behind my design is that object lifetimes tend to be managed in one of three ways:

1. Tied to a stack frame
2. Tied to an "owner" object
3. Not tied to any one object (managed by the GC)

To distinguish between these types of objects, one could use a set of three storage classes:

1. "scope": refers to stack-allocated memory (which seems to be the original design behind "scope"). "scope" references may not be stashed anywhere where they might become invalid. Since this is the "safest" type of reference, any object may be passed by "scope ref".

2. "owned": refers to an object that is heap-allocated but manually managed by another object or by a stack frame. "owned" references may only be stashed in other "owned" references. Any non-scope object may be passed by "owned ref". This storage class might not be usable in @safe code without further restrictions.

3. GC-managed: the default storage class. Fairly self-explanatory. GC-managed references may not refer to "scope" or "owned" objects.

Besides helping with the memory management issue, this design could also help tame the hairy mess of "auto ref"; "scope ref" can safely take any stack-allocated object, including temporaries, so a function could have "scope auto ref" parameters without needing to be a template function and with greater safety than "auto ref" currently provides.

Do you know this pull?
https://github.com/D-Programming-Language/dmd/pull/1903

On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote:
> Given all of this talk about memory management, it would seem that it's time for people to start putting forward some ideas for improved memory management designs. I've got an idea or two of my own, but I'd like to discuss my ideas before I draft a DIP so I can try to get everything fleshed out and polished.
>
> Anyway the core idea behind my design is that object lifetimes tend to be managed in one of three ways:
>
> 1. Tied to a stack frame
> 2. Tied to an "owner" object
> 3. Not tied to any one object (managed by the GC)
>
> To distinguish between these types of objects, one could use a set of three storage classes:
>
> 1. "scope": refers to stack-allocated memory (which seems to be the original design behind "scope"). "scope" references may not be stashed anywhere where they might become invalid. Since this is the "safest" type of reference, any object may be passed by "scope ref".
>
> 2. "owned": refers to an object that is heap-allocated but manually managed by another object or by a stack frame. "owned" references may only be stashed in other "owned" references. Any non-scope object may be passed by "owned ref". This storage class might not be usable in @safe code without further restrictions.
>
> 3. GC-managed: the default storage class. Fairly self-explanatory. GC-managed references may not refer to "scope" or "owned" objects.
>
> Besides helping with the memory management issue, this design could also help tame the hairy mess of "auto ref"; "scope ref" can safely take any stack-allocated object, including temporaries, so a function could have "scope auto ref" parameters without needing to be a template function and with greater safety than "auto ref" currently provides.

One can already choose their own memory model in their own code. The issue is with the core library and pre-existing code that forces you to use the GC model.

@nogc has been proposed several years ago but not gotten any footing. By having the ability to mark stuff has @nogc phobos could be migrated slowly and, at least, some libraries would be weaned off the GC and available.

I think the use of custom allocators would be better. Plug your own memory management model into D.

IMHO nothing will be done because this kinda talk has been going on for years(nearly a decade it as some posts go back to 2006).

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.

On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote:
> 1. "scope": refers to stack-allocated memory (which seems to be the original design behind "scope"). "scope" references may not be stashed anywhere where they might become invalid. Since this is the "safest" type of reference, any object may be passed by "scope ref".
>
> 2. "owned": refers to an object that is heap-allocated but manually managed by another object or by a stack frame. "owned" references may only be stashed in other "owned" references. Any non-scope object may be passed by "owned ref". This storage class might not be usable in @safe code without further restrictions.

I think merging "scope" and "owned" can be usable enough to be interesting without introducing any new concepts. Simply make it that "scope" in a variable declaration means it is a stack-allocated entity with unique ownership and "scope" as a function parameter attribute is required to accept scope data, verifying no references to it are taken / stored. Expecting mandatory deadalnix comment about lifetime definition ;)

Only thing I have no idea about is if "scope" attribute should be shallow or transitive. Former is dangerous, latter severely harms usability.

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.

On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
> 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.

I think those issues are actually orthogonal. I'd love to have verified @noheap attribute even in my old C code. Sometimes the very fact that allocation happens is more important that algorithm how it is later collected.

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

Yes, this is a common issue not unique to @nogc. I am personally much in favor of having restrictive attributes enabled by default and then adding "mutable" "@system" and "@allowheap" where those are actually needed. But unfortunately there is no way to add something that backwards-incompatible and attribute inference seems the only practical way (though I hate it).

On Wednesday, 10 July 2013 at 08:09:46 UTC, Dicebot wrote:
> Yes, this is a common issue not unique to @nogc. I am personally much in favor of having restrictive attributes enabled by default and then adding "mutable" "@system" and "@allowheap" where those are actually needed. But unfortunately there is no way to add something that backwards-incompatible and attribute inference seems the only practical way (though I hate it).

I thought about allowing attributes to be applied to a whole module, such as:
@safe @nogc module foo_bar;

Then, "@system", "@allowheap" and friends could be used where needed.

On Wednesday, 10 July 2013 at 08:16:55 UTC, Mr. Anonymous wrote:
> I thought about allowing attributes to be applied to a whole module, such as:
> @safe @nogc module foo_bar;
>
> Then, "@system", "@allowheap" and friends could be used where needed.

You can do it, but it is not always possible to "disable" attribute/qualifier.

@safe:
    @system void foo() {} // ok

immutable:
    int a; // oh, where is my "mutable" keyword?

pure:
    void foo(); // oops, no "impure"

If a generic notion becomes accepted that even default behavior should have its own attribute, this will become less of an issue.

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.

--
Paulo