On Wednesday, 10 July 2013 at 13:57:50 UTC, John Colvin wrote:
> 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.

Well, you can just throw malloc'ed exceptions. Problem is druntime and Phobos use "new" for exceptions and that is hard wired into GC. That has generally the same issues as global customized "new" allocator hook.

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.

------


2. Tied to an "owner" object

Why not just go manual memory. Just store everything
in a tree-like structure.

SuperOwner
--Child1
--Child2
----SubChild1
----SubChild2
------Container1
------Container2
------TStringList

Freeing a Child2 disposes of everything below.

sclytrack:

> Why not just go manual memory. Just store everything
> in a tree-like structure.
>
> SuperOwner
> --Child1
> --Child2
> ----SubChild1
> ----SubChild2
> ------Container1
> ------Container2
> ------TStringList
>
> Freeing a Child2 disposes of everything below.

Something like this?
http://swapped.cc/?_escaped_fragment_=/halloc#!/halloc

A manual hierarchical allocator is possibly handy to have in Phobos. But it doesn't replace a owning scheme for automatic memory management.

Bye,
bearophile

Am 10.07.2013 15:57, schrieb John Colvin:
> 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.

Who is going to write two versions of the library then?

Throwing exceptions with @nogc pointers floating around would just lead to the same headache as in C++.

--
Paulo

Am Wed, 10 Jul 2013 18:12:42 +0200
schrieb Paulo Pinto <pjmlp@progtools.org>:

> Who is going to write two versions of the library then?
> 
> Throwing exceptions with @nogc pointers floating around would just lead to the same headache as in C++.

This will really be an issue if/once we support systems which just can't run a GC. (Because of really limited memory or because of code size limitations...)

Once we have ARC we might check whether switching all exceptions to ARC would work. If we manage to combine ARC with different custom allocators it can be integrated perfectly with the GC as well, although for an ARC-object allocated from the GC the reference count code would just be no-ops.

On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
>
> 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.

It's possible to use your own memory model, but that doesn't mean it's necessarily convenient or safe, and there's no standardized method of going about it. If it becomes standardized, there's a much higher chance of the core library using it.

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

Memory management and memory allocation are not the same issue; from a purely theoretical standpoint, they're nearly orthogonal, at least without a compacting collector. If the both the GC and the allocators are designed in a sufficiently flexible and modular manner, it would be possible to tie several general-purpose allocators to the GC at once. There are some allocators that can't be shoehorned into the GC model, but those would just return non-GC references.

On Wednesday, 10 July 2013 at 07:59:41 UTC, Dicebot wrote:
> 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 ;)

Most of the functionality of "owned" is redundant, but there are still some corner cases where it could be useful. The idea behind it is to have it function very much like a pointer in C++ code. For non-reference types, you could just use a pointer, but using a pointer with reference types introduces an extra dereference operation to get to the real data.

This is something that could be implemented as a library type rather than an intrinsic part of the language, and that would probably be better because it's really sort of a low-level tool.

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

I'm not sure how shallow "scope" would be dangerous. If a "scope" object contains non-scope references to GC-allocated data, it's perfectly safe to stash those references somewhere because the target of the reference won't be collected. If the object contains "scope" members (if the language even allows that), then references to those members should actually inherit the container's "scope" status, not the members' "scope" status, because "scope" would be "overloaded" in that case to mean "packed into a (potentially heap allocated) object". "scope" is all about where the objects might be allocated, which is not a transitive property.