NEW 166847
GC barrier shouldn't need any fences 
https://bugs.webkit.org/show_bug.cgi?id=166847
Summary GC barrier shouldn't need any fences
Filip Pizlo
Reported 2017-01-09 09:59:29 PST
My initial implementation of the retreating wavefront barrier required a store-load fence. This is not necessary if you do some double-buffering.
Attachments
work in progress (41.40 KB, patch)
2017-01-09 10:58 PST, Filip Pizlo 		no flags
DetailsFormatted DiffDiff
all of the optimizations _except_ the rescan/fence removal (32.38 KB, patch)
2017-01-09 20:18 PST, Filip Pizlo 		no flags
DetailsFormatted DiffDiff
it seems to work (74.53 KB, patch)
2017-01-09 20:57 PST, Filip Pizlo 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Filip Pizlo
Comment 1 2017-01-09 10:58:09 PST
Created attachment 298366 [details] work in progress I ought to be able to benchmark this soon.
Radar WebKit Bug Importer
Comment 2 2017-01-09 13:47:56 PST
<rdar://problem/29934388>
Filip Pizlo
Comment 3 2017-01-09 20:18:02 PST
Created attachment 298439 [details] all of the optimizations _except_ the rescan/fence removal
Filip Pizlo
Comment 4 2017-01-09 20:56:46 PST
It appears that the barrier based on the rescan bit is best for programs that repeatedly store into the same object. The barrier based on an optimized, and inlined, store-load fence is best for programs that obey the generational hypothesis. I think that the latter kind of barrier is also giving better splay-latency numbers. I'm going to create a new bug for the optimized (but not rescan log) barrier, and get that landed. I'll leave this bug in limbo for now. It seems like it's sometimes, but not always, a good idea.
Filip Pizlo
Comment 5 2017-01-09 20:57:52 PST
Created attachment 298443 [details] it seems to work But it doesn't seem as good as the TSO barrier, after the TSO barrier gets all of the other optimizations.
Note You need to log in before you can comment on or make changes to this bug.