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

armv6 performance regression #1188

Closed
Nibbler999 opened this issue Mar 18, 2015 · 6 comments
Closed

armv6 performance regression #1188

Nibbler999 opened this issue Mar 18, 2015 · 6 comments

Comments

@Nibbler999
Copy link
Contributor

I have an iojs app that sends images over websockets (socket.io + ws module as client). As of iojs 1.5.1 this started maxing out the CPU instead of taking ~5%. I narrowed it down using the nightlies:

v1.5.1-nightly20150308fe36076c78 - 08-Mar-2015 02:20 - not affected
v1.5.1-nightly20150309030a92347d - 09-Mar-2015 17:30 - affected

Latest nightly is still affected.

strace shows hundreds of cacheflush calls in the affected builds but none in the unaffected builds.

cacheflush(0x34f1baa0, 0x34f1bae8, 0, 0x1, 0x34f1bacc) = 0
cacheflush(0x34f1bb40, 0x34f1bb70, 0, 0x1, 0x34f1bb5c) = 0
cacheflush(0x34f1bbc0, 0x34f1bc6c, 0, 0x1, 0x34f1bc48) = 0
cacheflush(0x34f1bcc0, 0x34f1bd08, 0, 0x1, 0x34f1bcec) = 0
cacheflush(0x34f1bd60, 0x34f1bdd4, 0, 0x1, 0x34f1bdb8) = 0
cacheflush(0x34f1be20, 0x34f1be94, 0, 0x1, 0x34f1be74) = 0
@Fishrock123
Copy link
Contributor

https://jenkins-iojs.nodesource.com/job/iojs+release+nightly/102/ Looks like that build was these changes..

@Nibbler999
Copy link
Contributor Author

Reverting #1085 fixes the problem.

@bnoordhuis
Copy link
Member

Changes between those nightlies:

030a923 benchmark: chunky http client benchmark variation
1a3ca82 http_client: ensure empty socket on error
8670613 node_crypto_bio: adjust external memory size
f8c893d doc: fix confusion markdown in util.markdown
cf565b5 fs: fix .write() not coercing non-string values
4bd3620 url: remove redundant assignment in url.parse

The cacheflush system calls are emitted by V8 when code is generated or moved. If reverting 8670613 fixes it, then I speculate that the calls to v8::Isolate::AdjustAmountOfExternalAllocatedMemory() trigger pathological behavior in V8's GC.

/cc @indutny

@indutny
Copy link
Member

indutny commented Mar 18, 2015

@bnoordhuis looks like a v8 bug to me. It seems that it is moving lots of small Code chunks for some reason. I guess it might be beneficial to report this bug to the v8 issue tracker and revert the 8670613 for now.

@bnoordhuis
Copy link
Member

Looking at it again, I think there is an in retrospect rather obvious bug in 8670613... I'll submit a PR and cross-reference this issue.

bnoordhuis added a commit to bnoordhuis/io.js that referenced this issue Mar 18, 2015
Fix a bug where a size_t was negated and passed to a function that takes
an int64_t.  It works by accident when sizeof(size_t) == sizeof(int64_t)
but it causes the value to underflow when size_t is a 32 bits type.

v8::Isolate::AdjustAmountOfExternalAllocatedMemory() is the function I'm
talking about.  The goal of that call is to tell V8 that some memory has
been freed but due to that underflow, we were actually reporting that we
had just allocated gigabytes of memory.  It set off a garbage collector
frenzy and essentially brought the VM to a standstill.

Fixes: nodejs#1188
PR-URL: nodejs#1192
Reviewed-By: Fedor Indutny <[email protected]>
@Nibbler999
Copy link
Contributor Author

Fix confirmed, thanks.

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

4 participants