[
https://issues.apache.org/jira/browse/COUCHDB-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15709503#comment-15709503
]
ASF subversion and git services commented on COUCHDB-3245:
----------------------------------------------------------
Commit 1659fda5dd1808f55946a637fc26c73913b57e96 in couchdb-couch's branch
refs/heads/master from [~vatamane]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch.git;h=1659fda ]
Make couchjs -S option take effect
Previously it was used to set JS context's stack chunk size.
Instead, to be effective it should set max GC size of the runtime.
Stack chunk size was set to the recommended value: 8K
This brings back an accidentally reverted commit:
https://github.com/apache/couchdb-couch/commit/62dafe81e13d7f8e27e95057e65f76d534aa2313
by @tilgovi
Reference:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_NewContext
COUCHDB-3245
> couchjs -S option doesn't have any effect
> -----------------------------------------
>
> Key: COUCHDB-3245
> URL: https://issues.apache.org/jira/browse/COUCHDB-3245
> Project: CouchDB
> Issue Type: Bug
> Reporter: Nick Vatamaniuc
>
> currently -S option of couchjs sets stack _chunk_ size for js contexts
> Reference: to
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_NewContext
> Documentation recommends 8K and I have seen cases where it was raised to 1G+
> in production!. That doesn't seem right at all and also probably kills
> performance and eats memory.
> Docs from above say:
> > The stackchunksize parameter does not control the JavaScript stack size.
> > (The JSAPI does not provide a way to adjust the stack depth limit.) Passing
> > a large number for stackchunksize is a mistake. In a DEBUG build, large
> > chunk sizes can degrade performance dramatically. The usual value of 8192
> > is recommended
> Instead we should be setting the max gc value which is set in the runtime
> {{JS_NewRuntime(uint32_t maxbytes)}}
> Experimentally a large maxbytes seems to fix out of memory error caused by
> large views. I suspect that it works because it stops GC. At some point we
> probably drops some object, GC collects them and we crash...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
