Chunk-wise marking stack processing.

Process marking stack chunk-wise.

Prepares for parallel processing of a shared marking stack, but code remains
unsynchronized for now.

Share basic data structures with the StoreBuffer.

BUG=

Committed: https://github.com/dart-lang/sdk/commit/eb1bcef36fe18b07004fe947d79d2ecafc0661a7

[koda, 2015-08-03 17:37:17]

koda@google.com changed reviewers:
+ iposva@google.com

[koda, 2015-08-05 14:02:22]

Updated to simple stack-oriented processing within a single work block.

The number of over/underflow events for my dart2js and splay benchmarks are
~9000 and 21, respectively.

I suggest starting with this simple approach, and then use over/underflow stats
(measured per MB marked, for instance) to ensure good work distribution in a
parallel setting and detect+eliminate degenerate flip-flopping (e.g., "rebase"
the stack if there are too frequent alternating over/underflows).

[koda, 2015-08-05 19:17:00]

On 2015/08/05 14:02:22, koda wrote:
> Updated to simple stack-oriented processing within a single work block.
> 
> The number of over/underflow events for my dart2js and splay benchmarks are
> ~9000 and 21, respectively.
> 
> I suggest starting with this simple approach, and then use over/underflow
stats
> (measured per MB marked, for instance) to ensure good work distribution in a
> parallel setting and detect+eliminate degenerate flip-flopping (e.g., "rebase"
> the stack if there are too frequent alternating over/underflows).

Benchmarks show no significant impact, which is as expected since the marking
order remains the same when using a single task.

PTAL

[koda, 2015-08-06 01:54:20]

Updated with WorkList abstraction.

PTAL

[Ivan Posva, 2015-08-06 07:02:09]

LGTMwC

-Ivan

https://codereview.chromium.org/1271833002/diff/60001/runtime/vm/gc_marker.cc
File runtime/vm/gc_marker.cc (right):

https://codereview.chromium.org/1271833002/diff/60001/runtime/vm/gc_marker.cc...
runtime/vm/gc_marker.cc:202: return work_->Pop();
How about structuring it like below, which to me reads more naturally since it
does not need to negation on the condition:

if (work_->IsEmpty()) {
  .. do all of the block flipping ..
}
return work_->Pop();

https://codereview.chromium.org/1271833002/diff/60001/runtime/vm/store_buffer.h
File runtime/vm/store_buffer.h (right):

https://codereview.chromium.org/1271833002/diff/60001/runtime/vm/store_buffer...
runtime/vm/store_buffer.h:45: RawObject* At(intptr_t index) {
Is this still needed?

[koda, 2015-08-07 12:59:07]

https://codereview.chromium.org/1271833002/diff/60001/runtime/vm/gc_marker.cc
File runtime/vm/gc_marker.cc (right):

https://codereview.chromium.org/1271833002/diff/60001/runtime/vm/gc_marker.cc...
runtime/vm/gc_marker.cc:202: return work_->Pop();
On 2015/08/06 07:02:09, Ivan Posva wrote:
> How about structuring it like below, which to me reads more naturally since it
> does not need to negation on the condition:
> 
> if (work_->IsEmpty()) {
>   .. do all of the block flipping ..
> }
> return work_->Pop();

Done.

https://codereview.chromium.org/1271833002/diff/60001/runtime/vm/store_buffer.h
File runtime/vm/store_buffer.h (right):

https://codereview.chromium.org/1271833002/diff/60001/runtime/vm/store_buffer...
runtime/vm/store_buffer.h:45: RawObject* At(intptr_t index) {
On 2015/08/06 07:02:09, Ivan Posva wrote:
> Is this still needed?

No. Removed.

[koda, 2015-08-07 13:43:12]

Committed patchset #6 (id:100001) manually as
eb1bcef36fe18b07004fe947d79d2ecafc0661a7 (presubmit successful).