Currently, there are a few places where the JSObject that owns the SparseArrayValueMap is designated as the owner of the SparseArrayEntry write barrier. This is a bug and can result in the GC collecting the SparseArrayEntry even though it is being referenced by the SparseArrayValueMap.
<rdar://problem/20477499>
Created attachment 251362 [details] the patch.
For the record, I made SparseArrayEntry privately inherit WriteBarrier<Unknown> and created differently named setter functions which wraps the WriteBarrier ones, and then did a build to let Clang tell me of every place where SparseArrayEntry::set() is used. That is how I know I've covered all explicit calls to SparseArrayEntry::set(). I also searched for "set(" in JSObject.h/cpp, JSArray.h/cpp, and SparseArrayValueMap.h/cpp, and audited them visually.
Comment on attachment 251362 [details] the patch. r=me
Thanks for the review. Per Michael's offline suggestion, I added a comment to the new test to indicate that it should not crash if the bug is fixed. Landed in r183128: <http://trac.webkit.org/r183128>.