Switch to work list loop for CC

[shwestrick]

The previous CC implementation traced the memory graph via a simple recursive loop. This works fine for well-parallelized benchmarks, where it's essential to avoid deep data structures to ensure good span. But of course, it's not difficult to cook up an example to blow up the C stack during CC and lead to a crash.

This patch fixes the issue with an explicit work list, where work is enqueued onto the list, and we loop over the list to trace the memory graph. The work-list data structure is a simple list-of-chunks with LIFO ordering. We amortize additions and deletions by allocating and freeing chunks on demand.

After some initial testing, it doesn't look like this affects the performance of CC too much (both time and space), which is expected. It just removes the bad worst-case behavior.

[shwestrick]

I did a quick performance comparison today just to be sure, and results are below. In general, the change is not noticeable. There's a bit of increased space usage on dedup-strings and triangle-count, but I'm not too worried about it. The work-list approach is still a net win: not only does it eliminate the bad worst-case behavior, it also opens up new possibilities for future optimizations and algorithmic improvements. For example, with the explicit work-list, we could incrementalize CC fairly easily. I'm interested in looking into this in the near future.

[shwestrick]

I believe the space increase on these benchmarks is due to the space cost of the explicit work-list, which doesn't exactly match the (previous) call-stack-based DFS space usage. E.g. imagine tracing an array of N pointers. The new explicit work-list will first add N objects before tracing any one of them. This could be fixed in the future by more generally allowing for work-list entries of the form (objptr, offset) where the offset indicates where to continue from in that object. This would then exactly match the call-stack-based DFS space usage.