New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2013
Cc:
HW: ----
NextAction: ----
OS: ----
Priority: ----
Type: ----



Sign in to add a comment

Memory black hole for a loop above a certain number of iterations

Reported by glath...@yahoo.fr, Apr 4 2013

Issue description

Here is a loop:

for (var i = NITER; i--;) // up to about 375: no problem! starting with 400: sucks the whole system memory
    var X = dftreal1024static( x );

where dftreal1024static is a flat implementation of the Discrete Fourier Transform. All code and details are available at the links further below.

.

ISSUE: above a certain value of NITER (about 400 on my system), V8 swallows the whole system memory, and must be stopped before it completes the loop.

To be more precise: V8's system memory consumption increases linearly with time.

But when NITER is small enough (<=375 on my system), the system memory consumption remains quite constant, the speed of execution is excellent and everything is fine.

.

V8: version 3.17.16 (candidate)
System: Linux Ubuntu 12.04 on a Thinkpad T420s

.

Details:

The whole .js code is at:
https://github.com/glathoud/flatorize/blob/master/v8_dftreal1024static.js

with a convenience .sh wrapper:
https://github.com/glathoud/flatorize/blob/master/d8_dftreal1024static.sh

and here is the context, which led me to find this issue:
http://glat.info/flatorize
 
Owner: yangguo@chromium.org
Status: Accepted
I couldn't reproduce the memory issue, but at a certain point dftreal1024static is optimized, and the optimizing compiler, for some reason, takes forever.
Cc: jkummerow@chromium.org
I take part of my comment back. I was able to reproduce the memory issue. I suspect a worst case scenario for the algorithm in HGraph::MergeRemovableSimulates().

Part of the stack trace:

#4  0x0805a187 in v8::internal::FatalProcessOutOfMemory(char const*) ()
#5  0x08055ce8 in v8::internal::Malloced::New(unsigned int) ()
#6  0x08291ea1 in v8::internal::Zone::NewExpand(int) ()
#7  0x0811405c in v8::internal::Zone::New(int) ()
#8  0x08366901 in v8::internal::HValue::SetOperandAt(int, v8::internal::HValue*) ()
#9  0x08368db7 in v8::internal::HSimulate::MergeInto(v8::internal::HSimulate*) ()
#10 0x0811d7c3 in v8::internal::HGraph::MergeRemovableSimulates() ()
#11 0x081446c0 in v8::internal::HGraph::Optimize(v8::internal::SmartArrayPointer<char>*) ()
#12 0x0808b8fb in v8::internal::OptimizingCompiler::OptimizeGraph() ()
#13 0x0808cbc0 in v8::internal::GenerateCode(v8::internal::CompilationInfo*) ()
#14 0x0808fb8b in v8::internal::Compiler::CompileLazy(v8::internal::CompilationInfo*) ()


Comment 4 by glath...@yahoo.fr, Apr 4 2013

Thanks a lot for the very quick reaction.
Status: Fixed
Fixed in r14169. Thanks for the report!

Comment 6 by glath...@yahoo.fr, Apr 19 2013

I see the fix is now part of the bleeding_edge branch. Now I just tried to find out whether stable branch was updated with the fix. Two questions:

 * is this the right place to look at: http://upstream-tracker.org/changelogs/v8/current/changelog.html ?

 * if yes, then it seems that r14169 has not been merged yet into it. Could it be merged any time soon ?

Sorry for the impatience. I am eager to run the tests again on a stable branch, and update the results in the article. The results should be very good :)
We decided not to merge this back to Chrome 26. The Canary shipping today will include the fix, and once it proved itself, we will merge it back so that Chrome 27 stable will include the fix as well.
@6:
That upstream-tracker.org link seems to provide the commit messages of V8's trunk branch. Whether that's the "right place to look at" depends on what you're looking for. Either way it's a third-party site with no relation to the V8 project.

r14169 has been on the trunk branch for a while, but trunk is not a "stable branch". Not every single change is mentioned in the trunk commit messages.

The fix is currently being shipped in Chrome's Canary and Dev channels. We are considering merging it back to the M27 release (V8 3.17 branch) which is currently in beta. Since we are very conservative about back merges and this is not a security issue, it will most likely not be merged back to Chrome M26 (current stable version).

Comment 9 by glath...@yahoo.fr, Apr 19 2013

Fine, thanks for all the details!

Comment 10 by glath...@yahoo.fr, Jun 6 2013

I've updated the results for Chrome 27 and V8 3.19.10
http://glat.info/flatorize/#push-all

Summary of the results: Good job!
Glad we could help!

Sign in to add a comment