`free` operator

Jorge jorge at jorgechamorro.com
Sat Oct 27 03:39:19 PDT 2012


On 26/10/2012, at 01:16, Isaac Schlueter wrote:

> It'd be really nice if JS had a way to explicitly delete an object.
> 
> Occasionally, in complex programs, you can find yourself with a
> situation where a certain type of object is leaking.  However, even if
> you track down what the object is, and find the exact point in your
> program where you ought to have no references to it, it's not always
> obvious to know what might be holding a reference still.  It's
> tempting to do this, and newcomers often think that this helps, but of
> course, it does nothing:
> 
> function doStuff() {
>  // some object that we're doing stuff with...
>  someObject.someMethod()
> 
>  // now we know we're done, and there should be no refs.
>  // but, there are, and they're leaking.
>  // I know!  I'll do this:
>  delete someObject
>  // surprise! that does nothing.
> }
> 
> What do you folks think about a "free" operator (or something like it)
> that would actually do what `delete` looks like it does?
> 
> var obj = {}
> var foo = { ref: obj }
> var obj2 = obj
> free obj  // obviously this syntax probably won't work, since 'free'
> is not a reserved word already
> assert(obj === undefined)
> assert(foo.ref === undefined)
> assert(obj2 === undefined)
> 
> So, any references to the freed object would be set to undefined, and
> presumably at some point, the GC will harvest it.
> 
> 
> Yes, yes, I know, the proper way to fix a memory leak in JS is to
> properly manage references, but sometimes that means rewriting this
> complicated app, and it's leaking memory now, in production.
> 
> 
> Has this been discussed before?

Hi Isaac,

I have some random thoughts about this:

1.- In a program that creates zillions of short lived objects gc()s often take too long, and -I guess- the ability to explicitly free(noLongerWantedObject) could be of great help here, for the GC machinery. So much that the API could perhaps be gc(object) instead of free(object), and destroy it on the fly instead of having to wait for the GC to kick in.

2.- If a frozen objectA holds a reference to objectB, should a call to free(objectB) mutate frozen objectA? Does not sound good...

3.- I have the gut feeling that a free(noLongerWantedObject) could under certain circumstances become insanely expensive, perhaps as long as a gc() call, looking for might-be-references to noLongerWantedObject everywhere.

4.- If you could mutate the object (keeping its identity) to a frozen {} empty object, perhaps you'd get the same functionality you're after in a way that (again, my gut feeling) would be easier to implement, (often) faster to run, and even shimmable:

function empty (object) {
  Object.getOwnPropertyNames(object).forEach({|p| delete p});
  object.__proto__= {}.__proto__;
  Object.freeze(object);
}

On the other hand, I have to say that I sympathize very much with the idea of being able to say "destroy and garbage collect this object right now, no matter what, no matter who else might hold a reference to it". But that's because I don't buy so much the argument "with feature x people are going to shoot themselves in their feet" as "with power comes responsiblity".

Cheers,
-- 
Jorge.


More information about the es-discuss mailing list