Bug 75588

Summary: unshift/pop fifo may consume excessive memory
Product: WebKit Reporter: Gavin Barraclough <barraclough>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ossy
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 75140    
Attachments:
Description Flags
Fix
sam: review+, webkit-ews: commit-queue-
simple micro-benchmark none

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-
simple micro-benchmark (5.85 KB, application/x-javascript)
2012-01-04 17:17 PST, Gavin Barraclough
no flags
Gavin Barraclough
Comment 1 2012-01-04 17:15:27 PST
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
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
Note You need to log in before you can comment on or make changes to this bug.