Bug 77488

Summary: Replace JSArray destructor with finalizer
Product: WebKit Reporter: Mark Hahnenberg <mhahnenberg>
Component: JavaScriptCoreAssignee: Mark Hahnenberg <mhahnenberg>
Severity: Normal CC: dglazkov, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Description Flags
Patch ggaren: review+, webkit.review.bot: commit-queue-

Description Mark Hahnenberg 2012-01-31 16:03:37 PST
We want JSArray to be in the imminent no-destructor heap, and the only thing preventing us from doing so is the SparseArrayValueMap pointer in JSArray. We can instead add a finalizer whenever we allocate one of these maps, which is very rarely so the performance hit should be negligible. There is also a void* subclassData, but any classes that use this should have destructors anyways.
Comment 1 Mark Hahnenberg 2012-01-31 17:02:34 PST
Created attachment 124854 [details]
Comment 2 Geoffrey Garen 2012-01-31 17:36:35 PST
Comment on attachment 124854 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=124854&action=review

> Source/JavaScriptCore/runtime/JSArray.cpp:314
> +    if (!map) {
>          map = m_sparseValueMap = new SparseArrayValueMap;
> +        globalData.heap.addFinalizer(this, finalize);

m_sparseValueMap can oscillate between null and non-null. In such a case, this code will register one finalizer for each oscillation, which will result in a double delete.

Please write a test case for this condition.

You can fix this by setting thisObject->m_sparseValueMap to 0 after deleting it, adding a comment that the finalizer can run more than once, or by never setting m_sparseValueMap to 0, even if it becomes empty.
Comment 3 Mark Hahnenberg 2012-02-01 13:17:57 PST
Created attachment 125001 [details]
Comment 4 Geoffrey Garen 2012-02-01 13:45:50 PST
Comment on attachment 125001 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=125001&action=review


> Source/JavaScriptCore/runtime/JSArray.cpp:203
> +void JSArray::finalize(JSCell* cell)

Please add a comment here noting that this function can be called more than once, so a future developer doesn't add unsafe code.
Comment 5 WebKit Review Bot 2012-02-01 14:12:26 PST
Comment on attachment 125001 [details]

Attachment 125001 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11393541

New failing tests:
Comment 6 Mark Hahnenberg 2012-02-01 14:15:58 PST
Committed r106496: <http://trac.webkit.org/changeset/106496>