Copy-on-write class table for concurrent reading.

Copy-on-write class table for concurrent reading.

Make ClassTable::At thread safe by keeping old copies of the class table.
They can be safely deallocated during the stop-the-world phase of GC.

This avoids making a copy for every sweeper task, and is the first step towards removing the fake Isolate workaround.

R=iposva@google.com

Committed: https://code.google.com/p/dart/source/detail?r=43048

[koda, 2015-01-12 19:19:29]

Note that this uses MallocGrowableArray, which is currently under review:
https://codereview.chromium.org/850473002/

[Ivan Posva, 2015-01-20 22:46:45]

LGTM -ip

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

https://codereview.chromium.org/816773005/diff/60001/runtime/vm/class_table.c...
runtime/vm/class_table.cc:20: old_tables_(new
MallocGrowableArray<RawClass**>()),
Wondering why you decided on MallocGrowableArray vs chaining through the first
entry?

[koda, 2015-01-21 14:36:09]

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

https://codereview.chromium.org/816773005/diff/60001/runtime/vm/class_table.c...
runtime/vm/class_table.cc:20: old_tables_(new
MallocGrowableArray<RawClass**>()),
On 2015/01/20 22:46:45, Ivan Posva wrote:
> Wondering why you decided on MallocGrowableArray vs chaining through the first
> entry?

1. To avoid yet another ad hoc linked list implementation, of which we already
have many. MallocGrowableArray is reusable and did not add any new logic.

2. The entry for class id 0 being NULL rather than a random next-pointer helps
debugging. Alternatively, having the next pointer separately before class id 0
would complicate scaling+offset computation in generated code.

[koda, 2015-01-21 18:13:17]

Committed patchset #4 (id:60001) manually as r43048 (presubmit successful).