[johnson-talk] spidermonkey ran out of memory :(

[Kane Baccigalupi]

We are using Johnson via Harmony to run javascript unit tests in our
Sinatra app. It was all working great until we added our last test
file. Now, the suite ends with either a Segmentation fault in env.js
or a NoMemoryError.

It looks like there is no garbage collection between our tests. Are
there any configuration options in Johnson to increase Spidermonkey
memory or alternately trigger collection?


Here is oure 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:in `evaluate_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:in
`extended'
/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:in `__send__'
/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:in `evaluate_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:in
`evaluate'
/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:in
`from_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:in
`new'
/Users/ben/dev/cohuman/spec/unit/harmony/title_bar_js_spec.rb:6:


--
Subscription settings: http://groups.google.com/group/johnson-talk/subscribe?hl=en

[mynyml]

jbarnette mentioned smparkes might have added an option to increase
memory size.

On a side note, the error message is lying.. harmony forces the
tracemonkey engine. I wonder if actually using spidermonkey could
serve as a temporary workaround for your case?

[Steven Parkes]

> jbarnette mentioned smparkes might have added an option to increase
> memory size.

You can set the size with the "size"/:size key when you create the runtime, or you can set JOHNSON_HEAP_SIZE in the environment if you haven't set it a size option. (The env string is parsed with Integer, so you can use hex notation like "0x2000000" which happens to be the default: 32M).

I did a lot a GC work a little while ago, while working on the Capybara envjs driver. At that time, I think I pretty much got rid of any GC issues with envjs itself. There's some chance some crept back in, but the changes since then have been pretty minor, so I'm thinking that's not likely (but could be wrong).

There are two garbage collectors running here: Ruby's and SpiderMonkey's. It's possible, to some extent, to force both of them. There's a gc method in the Johnson API to get SM's GC run. Ruby's GC can be subject to ghosting: stack variables that used to hold references that are no longer valid for that but haven't been scrubbed. I don't know if SM is subject to that ...

The biggest issue I came up with was with multiple windows in envjs. The capy tests showed this in spades: windows were never getting gc'd and since they hold most everything, there was never anything released. I think those references are fixed in envjs/capy but if it's an issue, you might need to make sure other code doesn't keep any references (if you're using multiple windows).

> On a side note, the error message is lying.. harmony forces the
> tracemonkey engine. I wonder if actually using spidermonkey could
> serve as a temporary workaround for your case?

There's only one runtime now. The old runtime we called 'spidermonkey' doesn't exist anymore and you always get the new runtime. We're planning on renaming before 2.0 gets cut so it's all spidermonkey. tracemonkey is more a release/branch name than a project name.

[Kane Baccigalupi]

Thanks, we set the ENV constant, and now have our suite up and running again. 

I wanted to experiment with the gc command, but I couldn't find it in the ruby source code. Is it a C method? Is there any documentation or any other details on how to call and use it?

-- Kane

[Steven Parkes]

> Is it a C method? Is there any documentation or any other details on how to call and use it?

Yes, it's implement in C and we're a little weak on docs right now.

From JS: Johnson.runtime.gc()

[Kane Baccigalupi]

Awesome. Thanks