Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow cleanup of an object through a destructor or dispose method #3691

Closed
DartBot opened this issue Jun 16, 2012 · 13 comments

Comments

@DartBot
Copy link

commented Jun 16, 2012

This issue was originally filed by Don.J.Olmstea...@gmail.com


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

This comment has been minimized.

Copy link
Member

commented Jun 16, 2012

@DartBot

This comment has been minimized.

Copy link
Author

commented Apr 8, 2013

This comment was originally written by zef...@gmail.com


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

This comment has been minimized.

Copy link
Member

commented Aug 26, 2013

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

This comment has been minimized.

Copy link

commented Jun 15, 2014

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 has been minimized.

Copy link
Author

commented Sep 7, 2014

This comment was originally written by norman...@gmail.com


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

@DartBot

This comment has been minimized.

Copy link
Author

commented Oct 23, 2014

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

This comment has been minimized.

Copy link

commented Mar 9, 2016

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.

@lrhn lrhn added the core-m label Aug 11, 2017

@floitschG floitschG added core-n and removed core-m labels Aug 31, 2017

@matanlurey matanlurey closed this Jun 21, 2018

@lifenautjoe

This comment has been minimized.

Copy link

commented Jan 24, 2019

What happened to this?

@lrhn

This comment has been minimized.

Copy link
Member

commented Jan 25, 2019

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

This comment has been minimized.

Copy link

commented Jan 25, 2019

@truongsinh

This comment has been minimized.

Copy link

commented Sep 18, 2019

With FFI being available #34452, I think destructor should get back to the spotlight.
cc @lrhn @mraleph @sjindel-google

@mraleph

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2019

Issue tracking dart:ffi finalizers: #35770

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.