Sdk: Allow cleanup of an object through a destructor or dispose method

[DartBot]

_This issue was originally filed by [e-mail]_

---

Dart should have a destructor or dispose method <http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx>, for when an object is marked to be collected.

To give a use case where this would be useful lets say you had a Texture class which contains a WebGLTexture. When you're done using
the WebGLTexture it should be disposed of by calling deleteTexture
through a WebGLRenderingContext. So if you were sharing this Texture
between other objects it isn't entirely clear when its okay to call
deleteTexture. A destructor or dispose method would provide a clear place to call deleteTexture safely.

Having a destructor or dispose method could also be of use for those trying to embed Dart in a C/C++ program.

[sethladd]

_Removed Type-Defect label._
_Added Type-Enhancement, Area-Library, Library-Core, Triaged labels._

[DartBot]

_This comment was originally written by [e-mail]_

---

Another use case of this is when wrapping JavaScript objects as Dart objects that have to retain a reference to the wrapped object. For instance:

class EditSession {
  js.Proxy sessionProxy;

  EditSession.proxy(js.Proxy session) {
    sessionProxy = session;
  }

  // ...

  void dispose() {
    js.release(sessionProxy);
  }
}

Right now you have to basically manually do garbage collection on Javascript objects that need to have a longer life time.

[lrhn]

Preferably, I'd like to not make garbage collection visible.

Right now, the spec does not say anything about garbage collection. If an object is no longer reachable, the spec doesn't say what should happen to it. It is a valid implementation to keep it alive forever (it's just not very memory efficient).
That makes garbage collection an implementation detail.

If we start making it visible when an object is no longer reachable, by calling a dispose method, then we either get unpredictable behavior, or we have to specify when this callback should happen, which will only put restrictions on what the VM can do (and will likely be hard or impossible in dart2js code for a long time, depending on which GC-related features goes into ES6).

[giovannicandido]

Another use case is when you create a class to represent a dom object. The class old a reference to the Element in the page and when is disposed the dom element should be removed.

[DartBot]

_This comment was originally written by [e-mail]_

---

Please implement it to make possible RAII, it's important for server-side.

[DartBot]

_This comment was originally written by @Emasoft_

---

Garbage collection should not be visible. But you must be able to manually destroy any object exacly like the Garbage collector would do. In this way the Garbage collector will have one less object to worry about.
The ability to manually destroying object instantly is ESSENTIAL for many algorithms and patterns. Not only for RAII (Resource Acquisition Is Initialization) techniques for servers, but also for many game loops where immediate destruction of objects is essential to keep the number of objects in memory constant at any time and consequently always contained inside the cache, for assuring decent performances.
Note that what is required is not to "flag" an object to be "ready" to be collected, but to collect it straight and directly, removing it immediately from memory without calling the garbage collector at all, but just updating its object graph to remove the reference just before the destruction.
Of course destroying an object would be unsafe without an ARC (Automatic Reference Counting) system, so Dart should also implement it. In this way the user would be able to check for references before destroying the object, like this:

if(sessionProxy.referenceCount == 0)
{
    js.destroy(sessionProxy);
}

[Enelar]

We could make transparent week ptr syntax. I mean, standard technique for implementing manual destruction in gc languages, its to create shared object, which containing single reference to payload.
You could ether remove that reference(set to null), or wait for last reference to container disappear. (Then payload would gc correctly).

It could be compromise, afa it had lenient syntax. ( object.member thanslates to VM as _object_container_1234_.reference.member ).
object = null (_object_container_1234_.reference = null), or destroy object would give such opportunity, without breaking ES5.

So, it acts like regular object reference, (you should compare with null), but also changes shared to all references, which pretty much similar to real destruct.

In other words - GC threats objects with no references as removed, by reversing this idea (removed object would have no references), we bringing almost RAII.

[lifenautjoe]

What happened to this?

[lrhn]

There are no current plans to add something like this to the Dart language.

The primary reasons is that it won't be easy (or perhaps even possible_ to compile it to JavaScript. Even the JavaScript WeakMap doesn't provide a callback when an object is no longer reachable. So, the feature would be VM only.

We could still do that, but it adds complexity to the memory model.

So, for now, this feature is not seen as important enough to be on our list of priorities.

[lifenautjoe]

Got it.

Thanks for clarifying !

On Fri, 25 Jan 2019 at 14:49, Lasse R.H. Nielsen [e-mail]
wrote:

There are no current plans to add something like this to the Dart language.

The primary reasons is that it won't be easy (or perhaps even possible_ to
compile it to JavaScript. Even the JavaScript WeakMap doesn't provide a
callback when an object is no longer reachable. So, the feature would be VM
only.

We could still do that, but it adds complexity to the memory model.

So, for now, this feature is not seen as important enough to be on our
list of priorities.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/sdk/issues/3691#issuecomment-457578178, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AMJb5V92ygeo3LGw63m4Sm21DB_rtPEZks5vGwtggaJpZM4E3-Il
.

[truongsinh]

With FFI being available https://github.com/dart-lang/sdk/issues/34452, I think destructor should get back to the spotlight.
cc @lrhn @mraleph @sjindel-google

[mraleph]

@lrhn JS is on the way to get WeakReference, see proposal here.

@truongsinh dart:ffi would most likely have a feature like finalizers - but it would not be a generic destructor like language feature.

[dcharkes]

Issue tracking dart:ffi finalizers: https://github.com/dart-lang/sdk/issues/35770