Thread overview
[Dlang-study] Safe Memory Management and Ownership.
Jun 19, 2018
xray
Jul 10, 2018
Chris M.
Sep 28, 2018
Olivier FAURE
June 19, 2018
Hi there,

I have been through the discussions on the forum regarding scope, ownership, GC and so on.  After a serious thought about this, I'd like to discuss about a possible solution for this matter. My concern is to know if my solution could work and to discuss the possible impact on the current D language.


After watching the Dconf 2018 session about "Safe Memory Management", I told myself that, if D can guarantee an exception in the case we delete an already deleted object, then it's a major step forward. So let's assume that.

Now, let's distinguish two kind of references, one being "owner" of the object it targets, and other that are smooth references to the same object.

We could say that a given object will always belong to one and only one owner. This owner will be in charge of deleting the object.

There will be 2 cases. If the owner is a local variable, as soon as the variable is out of scope, the object is deleted. If the owner is an attribute of a extra object, the deletion happens after the extra object is deleted.

The syntax could look like it (don't pay much attention to the key word I use, it's only to illustrate).


void main()
{
   auto r := new Rectangle(5,6); // r owns the object.
   auto r4 := new Rectangle(8,7); // r4 owns the object.
   auto f = new Foo();

   // now r2 owns the object. Deletion still happens when r2 is out of scope.
   auto r2 := r;

   auto r3 = r2; // Smooth reference

   // fonction1 only borrow the object, so it will not delete it.
   fct1( r2 );

   auto rr := f.fct2( in r2 );

   // We can STILL use r3 at our own risk (we don't know the r2's destiny).
   // Considering the design and UT will prevent bugs.

   auto w = r3.getWidth(); // An exception is raised if r3 is not valid.

   f.fct3( in r2 ); // Compilation error, we cannot give what we no longer own.

   f.fct3( in rr ); // Ok.

   // implicit code :
   // delete r4;
   // delete f , then f deletes rr by owership.
}

class Foo
{
   Rectangle my_r;

   out Rectangle fct2( in Rectangle r )
   {
       return out r;
   }

   fct3( in Rectangle r )
   {
      this.my_r := r; // Foo is the owner of r now.
   }

}

This way, all the libraries would explicitly tell where the memory is managed. All classes could keep their attribute objects under management if they are designed to.

I cannot see a case where we could miss a memory deallocation because the compiler will add the delete for us at the expected spot.

Of course, we can easily run into invalid smooth references (kind of NPE). But if D provides safe memory management, well, we can handle it.

Tell me guys what you think :)







_______________________________________________
Dlang-study mailing list
Dlang-study@puremagic.com
http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study


July 10, 2018
On Tuesday, 19 June 2018 at 16:38:19 UTC, xray wrote:
> Hi there,
>
> I have been through the discussions on the forum regarding scope, ownership, GC and so on.  After a serious thought about this, I'd like to discuss about a possible solution for this matter. My concern is to know if my solution could work and to discuss the possible impact on the current D language.
>
> [...]

If you haven't noticed already nobody visits these parts :). May want to repost in General if you want more notice.

As for your idea, I do see merit in it especially if we want safe MM (this is essentially how Rust handles it though it looks a little more lax). I wonder how it could fit in with dip25 and dip1000.
_______________________________________________
Dlang-study mailing list
Dlang-study@puremagic.com
http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study


September 28, 2018
On Tuesday, 19 June 2018 at 16:38:19 UTC, xray wrote:
> Now, let's distinguish two kind of references, one being "owner" of the object it targets, and other that are smooth references to the same object.

What you're describing is essentially unique pointers.

There are implementations of the concept in D (eg automem's Uniqute), but I think they're all hard to write @safe code against, because they don't interact with scope too well, or something in that vein. DIP-1000 is meant to address that problem.
_______________________________________________
Dlang-study mailing list
Dlang-study@puremagic.com
http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study