Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spidermonkey ran out of memory #8

Open
baccigalupi opened this issue Apr 22, 2010 · 7 comments
Open

spidermonkey ran out of memory #8

baccigalupi opened this issue Apr 22, 2010 · 7 comments

Comments

@baccigalupi
Copy link

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:

@caseyhoward
Copy link

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?

@baccigalupi
Copy link
Author

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?

@caseyhoward
Copy link

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.

@baccigalupi
Copy link
Author

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

@smparkes
Copy link

smparkes commented Jul 5, 2010

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.

@baccigalupi
Copy link
Author

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.

@smparkes
Copy link

smparkes commented Jul 6, 2010

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 ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants