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
Closed

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

DartBot opened this issue Jun 16, 2012 · 13 comments

Comments

@DartBot
Copy link

@DartBot DartBot 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
Copy link
Member

@sethladd sethladd commented Jun 16, 2012

@DartBot
Copy link
Author

@DartBot DartBot 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
Copy link
Member

@lrhn lrhn 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
Copy link

@giovannicandido giovannicandido 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
Copy link
Author

@DartBot DartBot 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
Copy link
Author

@DartBot DartBot 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
Copy link

@Enelar Enelar 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
Copy link

@lifenautjoe lifenautjoe commented Jan 24, 2019

What happened to this?

@lrhn
Copy link
Member

@lrhn lrhn 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
Copy link

@lifenautjoe lifenautjoe commented Jan 25, 2019

@truongsinh
Copy link

@truongsinh truongsinh commented Sep 18, 2019

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

@mraleph
Copy link
Member

@mraleph mraleph 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
Copy link
Contributor

@dcharkes dcharkes 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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet