I just finished writing tests for JavaScript application and I was using Jasmine for the first time. Everything works fine, but I still need to test if application has some memory leaks within. Is it even possible to programmatically check it within my specs? Maybe there is some additional library for this?
Chrome has a non-standard extension of the window.performance API -- (window.performance.memory), where you can measure memory usage.
In order to enable precise memory statistics, you must use this flag: --enable-precise-memory-info
But you also need to force GC to tell whether memory is retained after your test. Because CG doesn't happen instantly.
With Chromium browser, you can run it with a special command flag to expose a method to force GC:
chromium-browser --js-flags='--expose_gc'
This gets you access to the method window.gc().
As I know there is no automatic way to find source of javascript memory leak. Javascript memory leaks is realy nasty thing on which you can waste a lot of time. Recently I was developing very large enterprise web solution as a single page application with almost 1mb of minimized self-written code. Suddenly we realized that our application is leaking hard. I tryied hundreds of technics to find the source of memory leak and the easiest way for me is to use google chrome profiler, take heap snapshot and compare different heap snapshots. Here is more information how to do it :
https://developer.chrome.com/devtools/docs/javascript-memory-profiling
Have a nice week with debugging memory leaks in your app, hope it will take less time that in my case. :)
Related
I am developing a voxel engine in Javascript using Threejs, and I've run into some memory usage problems. The intended environment is within an Electron application, which means I can launch the program with flags (--expose-gc) that enable manual garbage collection with gc().
I noticed that when running the gc() function, much less memory was freed compared to when I clicked the "collect garbage" button in the Memory section of Chrome's developer tools. For example, if the program initially used 2000 MB of memory, after gc() it would free up to 300 MB, but after clicking the aforementioned button, it would free up to 600 MB more, making it about half of what it originally was.
After some digging, I also found out about the --gc-global flag. This would've been perfect, since it behaved in the same way as a manual gc did, but it ran multiple times per second, making my program extremely laggy. I tried controlling the gc rate with --gc-interval, but it didn't affect it at all.
I also found this answer that talked about ProfilerAgent.collectGarbage();, but it always threw a reference error. Additionally, the flag it provided (--debug-devtools-frontend) wasn't recognised by Chrome. That, and the fact that I could find very little info on it outside of the answer, lead me to believe that it's an obsolete feature.
I also profiled the memory usage from the developer tools, and surprisingly, it was much lower compared to the value that Task Manager showed me: it seemed to be unaffected by the leaking memory. This has made it nearly impossible to determine where the memory could be leaking from.
I should also make it clear that while Chrome does garbage-collect on its own, it's far too infrequent, and it rarely does a full gc, meaning that memory usage is about twice of what it could be.
In summary, is there a way to trigger a full garbage collection from either Chrome or nodejs/Electron? Obviously, I'm not concerned about cross-browser support, so any advice would be appreciated.
It turns out that self.gc only collects garbage in the thread/worker it was called from. Running the function in all of my workers freed as much memory as the developer tools garbage collector did.
I am using Chrome v73. I have a memory leak in my web application. I can see all mentioned parameters increasing drastically. I want to know what it is and which one I can refer to and fix accordingly.
Stress testing my Foxx App eventually crashes ArangoDB with a SIGSEGV. Looking at the core file it seems to be related to V8 running out of memory. I'd like to do memory profiling on the heap to help track down potential leaks. Since the V8 engine is an integral part of arangod, how do I access and use the V8 profiler? The node modules that help with this all have C++ modules so they won't run right under Foxx.
Unfortunately, the V8 engine and its garbage collection has some glitches regarding the memory management.
In some cases, it runs in tight loops to squeeze a bit more memory out of the system, sometimes it instantly terminates the process instead of giving its host process a chance to cope with the situation.
This is a problem with which all V8 based solution have to fight - Node.JS too. The V8 team is working on this, and with every version they make progress.
But the end of the road isn't reached yet by now.
Regarding debugging interface which would most probably also provide the memory profiling, we are well aware of that its currently missing and tracking progress on this via the github issue #1538. As resources become available for this topic, we will start working on it.
You probably can use flamgegraphs in some way right now with the aid of the linux kernel, but it seems to be problematic to write the names of the JIT compiled functions required to make this more usefull.
i am stuck with big problem i working on big project that is hanging browser automaticaly javacript executes
"how to detect how much memory javascript is using and clear the memory in regular interval.Is it posible?"
You don't have any way to play with memory. Javascript runs in a sandbox environment, so you have no access to memory management in any way. The garbage collector takes care of this, and you can somehow make it do what you want, but it's random. Don't count on it.
Rather, for your problem, you can use Chrome Inspector's Profiler.
What does it do? Well... it profiles the webpage you're in. You can see how long each function takes, and especially: where is your bottleneck.
Try in Chrome, specifically.
Chrome's V8 has a brilliant generational garbage collector, where three types of polling happens: There are three threads constantly polling the three generation types, and I think they run at 10, 50 and 200 millisecond intervals (I may have got the figures wrong, but they are principally similar, with the time intervals increasing for older generations).
This is aggressive, and ensures that memory usage remains low.
In spite of this, if your code is hogging memory in Chrome, then you can be sure that the issue is with the code. It could be that:
(a) Your code is really unoptimized, or
(b) It is really working on very large data that is probably not best suited for the client (e.g. an excessively heavy page that has tons of widgets, dom nodes etc.)
Care to post some snippets?
It seems that there is a lot of information on memory leaks in IE and how web developers can avoid them, but I can't find much on avoiding leaks in FF. I've found lots of random tips on how end users can tweak their preferences, or tips for extension developers, but little on what I can do as a web developer to make sure my pages don't leak. Am I missing something? It seems lazy to just blame it on the user and say "you've got too many extensions". Or are the major patterns the same as in IE -- circular references and all that?
Also, if anyone knows of any tools to troubleshoot leaks in FF, that would be great. I found this:
https://addons.mozilla.org/en-US/firefox/addon/2490/
But it's apparently just for chrome and extension development.
Outside of the design patterns to favour the only truely safe way is to test your pages thoroughly. To monitor the memory usage of the browser Task Manager is alright but Process Explorer provides more accurate results.
JavaScript is one cause of memory leaks but be careful with flash movies on pages too. Our content team added a movie from our design department that used a thrid party transition affect and this swallowed 10Mb every 20s or so. Just watching the movie loop through it was obvious in TaskManager to see the memory jump when the affect occured and the it never quite release it all back.
You can force to run a Garbage Collector in FireFox. The Garbadge Collector will destroy & release objects that are not used anymore. The only possibility of "Leaking memory" with a Garbage Collector is not a "leak" but a reference which makes no sense: remove all references to objects that you don't want to use.
Read more on this page:
http://adblockplus.org/blog/different-ways-to-force-garbage-collection
A bunch of what you read about how to avoid memory leaks in browsers is about how to avoid things that cause the browser to fail to reclaim memory that it should reclaim.
However, a more substantial problem in many cases is about Web pages holding on to objects that they don't need anymore. It's only the browser's job to reclaim things that are no longer "reachable" -- that is, things that the script / page can't get to anymore. If you're accumulating objects in an array and not removing them when you're done with them, memory usage will go up as the array gets bigger, and there's nothing the browser can do about that.
To phrase that another way: that's an issue of a memory leak in the Web page rather than in the browser. And the tool you want for that is a memory profiling tool to examine the objects that are reachable in your page, so you can tell whether there's stuff in there that you should no longer be holding on to. Writing such a tool for Firefox has been on my list of things to do for a while, but I haven't gotten around to it yet. I think there might be some ongoing work on writing one that integrates into Firebug.
I don't know if there is specific information for Firefox, but the generic tips still apply.
I suggest that you closely examine all loops and recursive functions. Re-use existing objects over creating new ones, and ensure that temporary objects and primitives exit scope so that they can be freed.