WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
75588
unshift/pop fifo may consume excessive memory
https://bugs.webkit.org/show_bug.cgi?id=75588
Summary
unshift/pop fifo may consume excessive memory
Gavin Barraclough
Reported
2012-01-04 16:58:42 PST
Array object commonly store data in a vector, consisting of a portion that is in use, a pre-capacity (m_indexBias) and a post-capacity (the delta between m_length and m_vectorLength). Calls to pop with grow the post-capacity, and the current algorithm for increasePrefixVectorLength (used by unshift) will never stink the post-capacity, so a unshift/pop fifo may consume an inordinate amount of memory, whilst having a relatively small active length.
Attachments
Fix
(15.40 KB, patch)
2012-01-04 17:15 PST
,
Gavin Barraclough
sam
: review+
webkit-ews
: commit-queue-
Details
Formatted Diff
Diff
simple micro-benchmark
(5.85 KB, application/x-javascript)
2012-01-04 17:17 PST
,
Gavin Barraclough
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Gavin Barraclough
Comment 1
2012-01-04 17:15:27 PST
Created
attachment 121188
[details]
Fix
Gavin Barraclough
Comment 2
2012-01-04 17:17:03 PST
Created
attachment 121189
[details]
simple micro-benchmark Since unshift is not covered by our standard benchmarks, I've written a trivial micro-benchmark. Should no significant impact, 19.3s total runtime -> 19.2s.
Early Warning System Bot
Comment 3
2012-01-04 17:29:48 PST
Comment on
attachment 121188
[details]
Fix
Attachment 121188
[details]
did not pass qt-ews (qt): Output:
http://queues.webkit.org/results/11115011
Gavin Barraclough
Comment 4
2012-01-05 00:02:20 PST
Fixed in
r104120
.
Csaba Osztrogonác
Comment 5
2012-01-05 02:51:43 PST
Comment on
attachment 121188
[details]
Fix View in context:
https://bugs.webkit.org/attachment.cgi?id=121188&action=review
> Source/JavaScriptCore/runtime/JSArray.cpp:827 > -void JSArray::unshiftCount(ExecState* exec, int count) > +void JSArray::unshiftCount(ExecState* exec, unsigned count)
After this change the following assert is always true: ASSERT(count >= 0); It caused build breakage in debug mode: cc1plus: warnings being treated as errors ../../../../Source/JavaScriptCore/runtime/JSArray.cpp: In member function ‘void JSC::JSArray::unshiftCount(JSC::ExecState*, unsigned int)’: ../../../../Source/JavaScriptCore/runtime/JSArray.cpp:831: error: comparison of unsigned expression >= 0 is always true ../../../../Source/JavaScriptCore/runtime/JSArray.cpp:832: error: comparison of unsigned expression >= 0 is always true
> Source/JavaScriptCore/runtime/JSArray.h:261 > + unsigned m_indexBias; // The number of JSValue sized blocks before ArrayStorage.
After this change the following assert is always true: ASSERT(m_indexBias >= 0); It caused build breakage in debug mode: cc1plus: warnings being treated as errors ../../../../Source/JavaScriptCore/runtime/JSArray.cpp: In member function ‘void JSC::JSArray::unshiftCount(JSC::ExecState*, unsigned int)’: ../../../../Source/JavaScriptCore/runtime/JSArray.cpp:831: error: comparison of unsigned expression >= 0 is always true ../../../../Source/JavaScriptCore/runtime/JSArray.cpp:832: error: comparison of unsigned expression >= 0 is always true
Csaba Osztrogonác
Comment 6
2012-01-05 03:33:32 PST
Buildfix landed in
http://trac.webkit.org/changeset/104136
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug