Bug 167208 – The mutator needs to fire a barrier after memmoving stuff around in an object that the GC scans

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Filip Pizlo]

We didn't used to need these kinds of barriers, but now we do!

It used to be that if you moved a value from one place to another in the same object then there is no need for a barrier because the generational GC would have no need to know that the referent still continues to refer to the same referee.

But the concurrent GC might scan that object as the mutator moves pointers around in it. If the ordering is right, this could mean that the collector never sees some of those pointers. This can be fixed by adding a barrier.

This bug covers the most obvious cases I found.  There may be more and I'll continue to audit.

[Filip Pizlo]

Created attachment 299257 [details]
the patch

[Radar WebKit Bug Importer]

<rdar://problem/30101860>

[Saam Barati]

Comment on attachment 299257 [details]
the patch

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

> Source/JavaScriptCore/runtime/JSArray.cpp:1027
> +        vm.heap.writeBarrier(this);

Maybe just do this if we're Contiguous?

> Source/JavaScriptCore/runtime/JSArray.cpp:1179
> +        vm.heap.writeBarrier(this);

Maybe just do this if we're Contiguous?

[Filip Pizlo]

(In reply to comment #3)
> Comment on attachment 299257 [details]
> the patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=299257&action=review
> 
> > Source/JavaScriptCore/runtime/JSArray.cpp:1027
> > +        vm.heap.writeBarrier(this);
> 
> Maybe just do this if we're Contiguous?
> 
> > Source/JavaScriptCore/runtime/JSArray.cpp:1179
> > +        vm.heap.writeBarrier(this);
> 
> Maybe just do this if we're Contiguous?

That would be a branch, and the barrier's amortized cost is about the cost of a branch.

[Filip Pizlo]

Landed in https://trac.webkit.org/changeset/210935