0

I'm learning Javascript, and in the various texts the authors will speak of javascript using a mark and sweep gc to deallocate objects from memory. They will also speak of how if you set the value a variable references to null it will delete the reference to that value, allowing the allocated space to be set for gc. This SO answer says that you can remove the allocated memory and the reference by setting the value the variable contains to null and then to undefined, effectively removing the allocated space from the heap (if I understood it correctly).

So my question is this: Is it possible to write javascript in such a way that you can eliminate gc?

(If it is implementation specific I would like to know if it is possible on v8, though if this is possible on rhino or other js implementations that would be of immense use too)

Judging by projects like LLJS my request isn't too unreasonable, but I'm not entirely sure how the memory module does it.

I've always found it helpful if I explain why I'm asking so here it goes. I really like compilers, and I wanted to write a compile-to-js language that leveraged a static inferred typing system similar to SML. The reason why I wanted to write my own was because I wanted to utilize region inference to determine exactly when objects and variables come out of scope (as much as possible) and upon leaving scope remove it from the heap, thereby eliminating as much gc as possible. This is mostly a research project (read: because I can) so any resources on memory optimization in javascript would also be greatly appreciated!

EDIT: I guess another way to phrase it would be "Is it possible to write js in such a way that the gc will deterministically never run (as much as possible)? If so what techniques would be involved?"

I'm not looking per se for delete because that marks the element for deletion thereby invoking what I wanted to (try to) avoid, I was curious if the implementation's gc would run if I removed all references (and the value) associated with the variable.

Alternatively, paraphrasing from the referenced SO Answer:

x = foo; x = null; x;

Is x still on the heap?

Community
  • 1
  • 1
pensivearchitect
  • 3
  • 3

2 Answers2

0

It's not entirely clear what you're looking for.

The standard Javascript implementations have NO way of manually deallocating memory. You can remove a property with the delete operator, but that just removes the property from the object. It doesn't even free any contents that the property points to (that is left for garbage collection if there are no other references to that data).

Javascript was designed from the ground up to be a garbage collected language. It frees things from physical memory only when the garbage collector runs and that garbage collector finds objects that are unreachable (e.g. there are no references to those objects still in use). The language does not contain commands to free memory.

It is possible (in some JS implementations) to call the GC yourself rather than wait for the JS engine to run it, but it's still using GC to decide what to free.

Responding to the additional things you added to your answer.

To the best I know, javascript only cleans things up when the GC runs. Until then objects are marked such that the GC can see that there are no references to them anywhere, but they aren't actually freed until the GC checks and notices this. Further, local variables in a function scope are themselves a type of object and those are not freed until the GC runs and notices that there are no references to the function scope (in JS, a closure can maintain a reference to a function scope even after the function has completed).

So, in your code example:

x = foo; x = null; x;

x is still alive and occupying some space because it's still in scope and code could still reach it. It's contents will be null which presumably takes no extra space beyond the variable itself, but the space for the variable itself won't be freed until the function context it is in is found to be reference free by the garbage collector.

JS is a garbage collected language. That's when things are actually freed from the heap. There are no instructions in the language to free things anytime sooner.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • So, in other word you use delete and GC frees up memory if no other references to that object are found. So it is possible for the programmer to deallocate objects which in effect leads up to freed memory. – Jani Hyytiäinen Dec 14 '13 at 16:50
  • @JaniHyytiäinen - not really. The `delete` operator is ONLY for removing a property from an object or putting an array element back to an `undefined` state. `delete` doesn't do anything for variables. For those, you set them to `null` or `undefined`. You can read [this article](http://perfectionkills.com/understanding-delete/) if you want to understand `delete`. It is ONLY possible for a javascript developer to remove a reference to an object. If there are then no other references to that object, the GC willl clean it up. – jfriend00 Dec 14 '13 at 17:11
  • @pensivearchitect - I added some more comments to my answer. – jfriend00 Dec 15 '13 at 00:24
-2

The delete keyword will trigger garbage collection by the browser. Be aware that it deletes entire chains of objects unless you nullify object references.

var o = {...};

delete o;
Greg Burghardt
  • 1
  • See [this article](http://perfectionkills.com/understanding-delete/) if you want to read how `delete` is supposed to be used. It's primarily for removing properties from an object. And, using it does not trigger garbage collection any more than anything else you do. – jfriend00 Dec 14 '13 at 17:13
  • 1
    That's a great blog post, jfriend00. I didn't see in the post how this ties into garbage collection, though. I have written code before where I delete a property of an object, which itself references many other objects, and I notice a slight pause in the browser. It makes me think the garbage collector kicks in to inspect the object being deleted in order to free up memory (as well as a spike in processor usage). I've never found any evidence to support this, however. Just anecdotal "huh, that's strange..." cases. – Greg Burghardt Dec 16 '13 at 21:14
  • I just gave you that link because of the context in which your answer used the `delete` operator. When the GC runs is entirely implementation dependent and will vary from one browser to the next (it is not the subject of any standards document). JS engines generally delay GC until the current thread of execution is done so they can avoid interfering with runtime performance and so they can do one sweep of all changes from the last code that ran, not many. But, there certainly could be conditions where they run something during execution. – jfriend00 Dec 16 '13 at 21:22