Suppose I have some asm.js code, probably created by emscripten. Suppose it has some kind of rather large heap allocated structure, which gets returned by a asm.js function as a pointer that is picked up by some JavaScript library to be wrapped in a nice JavaScript object. Fine so far.
But what happens if that object goes out of scope and gets garbage collected. Right now, the asm.js code has no way of knowing about that, so the memory of the structure will remain allocated, causing a memory leak.
Is there some way to add a finalizer to a JavaScript object from within JavaScript?
Such a finalizer could be used to deallocate the memory in asm.js, thus avoiding the memory leak. So far I couldn't find a documented i.e. portable way to achieve this, but perhaps I've been looking in the wrong places.
Coming back to this question, I found another answer pointing out that there is a specification for weak references and finalization which some browsers implement. The central component for finalization is FinalizationRegistry.
So depending on which browsers you target, this may be possible now. If you need to support browsers without this feature, using explicit release calls, it might be possible to use the finalizers where supported to detect memory leaks (i.e. objects not explicitly released in JavaScript code) and let the developer know so they can fix this.
The simple answer is that there is no support for this.
Since asm.js code needs to manage its own memory, everything that interacts with objects stored on the asm side need to respect the memory manager that asm uses rather than the memory manager that the browser uses. The best that you can do is to explicitly call a method on any object referencing internal asm memory whenever you create or destroy a reference to it.
Related
I'm working with some code in NodeJS, and some objects (i.e, 'events') will be medium-lived, and then discarded.
I don't want them becoming a memory burden when I stop using them, and I want to know if there is a way to mark an object to be garbage-collected by the V8 engine. (or better yet- completely destroy the object on command)
I understand that garbage collection is automatic, but since these objects will, 60% of the time, outlive the young generation, I would like to make sure there is a way they don't camp out in the old-generation for a while after they are discarded, while avoiding the inefficiency of searching the entire thing.
I've looked around, and so far can't find anything in the NodeJS docs. I have two main questions:
Would this even be that good? Would it be worth it to be able to 'mark' large amounts of unused objects to be gc'ed? (possibly 100+ at a time)
Is there even a way to do this?
Anything (speculation, hints, articles) would be appreciated. Thanks!
(V8 developer here.) There's no way to do this, and you don't need to worry about it. Marking works the other way round: the GC finds and marks live objects. Dead objects are never marked, and there's no explicit act of destroying them. The GC never even looks at dead objects. Which also means that dead objects are not a burden.
"Garbage collector" really is a misleading term: it doesn't actually find or collect garbage; instead it finds non-garbage and keeps it, and everything it hasn't found it just ignores by assuming that the respective memory regions are free.
In theory, there could be a way to manually add (the memory previously occupied by) objects to the "free list"; but there's a fundamental problem with that: part of the point of automatic memory management is that automating it provides better security and stability than relying on manual memory management (with programmers being humans, and humans making mistakes). That means that by design, a GC can't trust anyone else to declare objects as unreachable; it would always insist on verifying that claim -- which is equivalent to disregarding it, as the only way to verify it is to run a full regular GC cycle.
Is there any kind of assertion that I can make to verify that a particular object can be GC'ed in Javascript? The purpose is to have a unit test that asserts a memory leak is fixed.
at this point I don't know of any direct language support for this - I don't think Javascript has weak references or finalizers, which is how I probably would have done this in Java or C#.
You cannot have any javascript code that detects if a specific object can be GCed. The very code that would test it would keep it from being garbage collected because that code would, by definition, have a reference to it and the garbage collector will not GC something that still has a live reference to it.
The things you can do to verify that there is no memory leak:
Devise a test that runs the offending code over and over and measure the total memory usage of the browser to verify that the memory usage it not going up and up and up.
Assign a gigantic property value to the object (e.g. a mongo string) that is so large that you can clearly see if these objects are leaking in total memory usage.
Use various developer tools (which vary by browser) to look at the browser memory usage in finer detail.
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?
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.
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;
Is it possible to count created objects and variables in javascript?
I am using Google Chrome to analyse my web app. But to debug and find the objects that causes "Memory Leak" is not so easy (at least for me). So I want to know all objects and variables that are created on the current page so I can know if they are removed.
No, you can't do that in Chrome (or any other major browser). You can use Chrome's "memory" page (chrome://memory/) to get some idea what's going on, but it's not down to the object level, and it's important to understand that garbage collection does not happen synchronously or immediately. The browser / JavaScript engine may well allocate memory, use it for some JavaScript objects, and then later correctly understand that those objects aren't used anymore, but keep the memory handy for future use.
Instead, what you can do is study how JavaScript works in detail, which tells you what will (usually) be kept in memory, and why. Understand how closures work (disclosure: that's a post on my anemic little blog), and understand how IE doesn't handle circular references between DOM elements and JavaScript objects well (specifically, it doesn't clean them up well when nothing refers to either of them anymore, which is otherwise not normally a problem). And in general, don't worry too much about it until/unless you have a specific issue to address. (Which absolutely happens, but not as much as people sometimes think.)
Let's say I have the code provided in this tutorial.
How would I modify this so that the Point C++ object that is created has its destructor called and is deleted from memory when the GC for V8 destroys the JavaScript wrapper?
You want to create a Persistent handle and make it weak (v8::Persistent::MakeWeak(data, cb)). In the callback you can delete the C++ object. As usual with a garbage collector, the exact time at which weak-reachability will be determined is dependent on when GC is performed. Native resources may therefore be freed much later than you expect. You can inform V8 about the amount of native resources you are holding (v8::AdjustAmountOfExternalAllocatedMemory).
node's "ObjectWrap" encapsulates the bidirectional native/JS object mapping and weak callback: https://github.com/ry/node/blob/master/src/node_object_wrap.h