Clients of JSArray::tryCreateUninitializedRestricted() should invoke the mutatorFence().

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Mark Lam]

Clients of JSArray::tryCreateUninitializedRestricted() creates a partially initialized JSArray, with the contract that it will take care of filling in all the missing indexed properties before unleashing the newly created array on the world.  We intentionally do not unconditionally write barrier newly created arrays and rely on an owner object (or GC root) that it gets put into to scan it.  That said, there's no guarantee that we won't reach a GC safe point while the newly created array is still on the stack before it gets put into an owner object (or GC root).  

We should ensure that all stores into the array are properly completed before that GC safe point.  Hence, we should invoke the mutatorFence() after the client of JSArray::tryCreateUninitializedRestricted() finishes initializing the array.

[Radar WebKit Bug Importer]

<rdar://problem/56486552>

[Mark Lam]

Created attachment 381501 [details]
work in progress for EWS testing.

[Mark Lam]

Created attachment 381513 [details]
proposed patch.

[Saam Barati]

Comment on attachment 381513 [details]
proposed patch.

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

> Source/JavaScriptCore/ChangeLog:18
> +        That said, there's no guarantee that we won't reach a GC safe point with the
> +        newly created array is on the stack before it gets put into an owner object
> +        (or GC root).

how does a safe point not do the required fencing?

I think this is necessary because when we store the array into another object. But I don't think it's necessary for this reason.

[Mark Lam]

(In reply to Saam Barati from comment #4)
> I think this is necessary because when we store the array into another
> object. But I don't think it's necessary for this reason.

Thanks for the review.  I've fixed the comment.

Landed in r251456: <http://trac.webkit.org/r251456>.