spidermonkey ran out of memory
Opened this issue · 7 comments
We are using Harmony for our unit test and it is awesome! Thanks.
Unfortunately, after adding our last unit test file, our entire suite started failing with 'spidermonkey ran out of memory'. This is probably a garbage collection issue with Johnson, but I wanted to start here in case Harmony does any collection configuration.
Here is our trace:
NoMemoryError in 'TitleBar.js update title form updates on change'
spidermonkey ran out of memory
/Library/Ruby/Gems/1.8/gems/johnson-2.0.0.pre3/lib/johnson/tracemonkey/runtime.rb:49:in evaluate_compiled_script_without_clearing_traps' /Library/Ruby/Gems/1.8/gems/johnson-2.0.0.pre3/lib/johnson/tracemonkey/runtime.rb:49:inevaluate_compiled_script'
/Library/Ruby/Gems/1.8/gems/envjs-0.2.0/lib/envjs/runtime.rb:54:in evaluate' /Library/Ruby/Gems/1.8/gems/envjs-0.2.0/lib/envjs/runtime.rb:267:inextended'
/Library/Ruby/Gems/1.8/gems/johnson-2.0.0.pre3/lib/johnson/tracemonkey/js_land_proxy.rb:16:in call' /Library/Ruby/Gems/1.8/gems/johnson-2.0.0.pre3/lib/johnson/tracemonkey/js_land_proxy.rb:16:insend'
/Library/Ruby/Gems/1.8/gems/johnson-2.0.0.pre3/lib/johnson/tracemonkey/js_land_proxy.rb:16:in send_with_possible_block' /Library/Ruby/Gems/1.8/gems/johnson-2.0.0.pre3/lib/johnson/tracemonkey/runtime.rb:49:inevaluate_compiled_script_without_clearing_traps'
/Library/Ruby/Gems/1.8/gems/envjs-0.2.0/lib/envjs/env.js:591 [JavaScript]
/Library/Ruby/Gems/1.8/gems/envjs-0.2.0/lib/envjs/env.js:1111 [JavaScript]
none:1 [JavaScript]
/Library/Ruby/Gems/1.8/gems/johnson-2.0.0.pre3/lib/johnson/tracemonkey/runtime.rb:49:in evaluate_compiled_script' /Library/Ruby/Gems/1.8/gems/envjs-0.2.0/lib/envjs/runtime.rb:54:inevaluate'
/Library/Ruby/Gems/1.8/gems/harmony-0.5.4/lib/harmony/page.rb:25:in from_uri' /Library/Ruby/Gems/1.8/gems/harmony-0.5.4/lib/harmony/page.rb:30:infrom_document'
/Library/Ruby/Gems/1.8/gems/harmony-0.5.4/lib/harmony/page.rb:65:in initialize' /Users/ben/dev/cohuman/spec/unit/harmony/title_bar_js_spec.rb:6:innew'
/Users/ben/dev/cohuman/spec/unit/harmony/title_bar_js_spec.rb:6:
I ran into this issue before. I can't remember exactly what caused it and what I did to fix it though. But I'm pretty sure I was using multiple instances of Harmony (and thus multiple instances of Johnson). I updated my code to use the same instance for everything and that fixed it. Is each one of your tests using it's own instance of Harmony?
So, are you saying that we should create one Harmony::Page instance and use it for all of our unit tests?
Is there a clear out all the html and javascript method? Otherwise using one increasingly clogged up object for each of our unit tests would be untenable. They just couldn't be clean unit tests with all the intertest bleeding. Shouldn't each of the page instances be garbage collected after each unit test?
So, are you saying that we should create one Harmony::Page instance and use it for all of our unit tests?
Maybe. All I know is that's what my solution was.
Is there a clear out all the html and javascript method?
I didn't have to worry about that too much, since I wasn't actually testing javascript from a web app. The only reason I had to use harmony instead of johnson was because the javascript I was testing used prototype. I didn't have to worry the HTML and the DOM. As for the javascript, I called delete with all of the objects I created. There has to be a better way, but I couldn't find it.
Shouldn't each of the page instances be garbage collected after each unit test?
I would hope so, but I'm not sure.
I made a pretty different version of the gem that creates a new Johnson runtime for each page. We are talking about also making a version that is configurable, so that there are the benefits of both performance and memory reduction.
Here is the link: http://github.com/baccigalupi/harmony
I don't know that much about the way Harmony does its page stuff, but ...
You can reset/clear a window by setting it's location to "about:blank" (unless Harmony is putting anything in the page?).
It'd be interesting to know how that effects the issue. That actually creates a new window and if there are references to the old one, it won't go away, so it may not help anything (but might tell us something?)
You can also override the SpiderMonkey heap size with the JOHNSON_HEAP_SIZE environment variable.
I don't think harmony is putting anything else into the 'window', so 'about:blank' would reset it. It is creating a new window for each Page object though and adding it to the Johnson runtime. This is what was eating through our memory in unit tests.
Our version of the gem does create a new runtime for each page. It could probably just reset the existing window. Maybe we will do some work with that. We could probably create an object instance pooler and recycle page objects.
We have also been thinking about making a class level method that resets the runtime. That way we could reset it manually every X tests in our suite configuration. That would have it run a little faster while saving on memory.
It is creating a new window for each Page object though and adding it to the Johnson runtime.
And keeping all of them, or is it supposed to be replacing the previous one? If you keep all of them, you'll eat memory like crazy.
Our version of the gem does create a new runtime for each page.
But if those get GC'd, it shouldn't be an issue ...