The allocation sites scratchpad becomes a heap data structure.

The allocation sites scratchpad becomes a heap data structure.

BUG=
R=mstarzinger@chromium.org, mvstanton@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=19189

[mvstanton, 2014-02-06 13:46:37]

Just a question about write barriers (below), and I'd suggest to run tests with
nosnapshot. Then LGTM.

https://codereview.chromium.org/143153008/diff/30001/src/heap.cc
File src/heap.cc (right):

https://codereview.chromium.org/143153008/diff/30001/src/heap.cc#newcode3626
src/heap.cc:3626: allocation_sites_scratchpad_length_, site);
So both the scratchpad and the AllocationSite are in old space, what should the
write barrier behavior be?

[Hannes Payer (out of office), 2014-02-06 13:51:24]

https://codereview.chromium.org/143153008/diff/30001/src/heap.cc
File src/heap.cc (right):

https://codereview.chromium.org/143153008/diff/30001/src/heap.cc#newcode3626
src/heap.cc:3626: allocation_sites_scratchpad_length_, site);
On 2014/02/06 13:46:37, mvstanton wrote:
> So both the scratchpad and the AllocationSite are in old space, what should
the
> write barrier behavior be?

The allocation site may be on an evacuation candidate, i.e., the allocation site
may move after the scratchpad bookkeeping.

[Michael Starzinger, 2014-02-07 09:45:11]

LGTM.

[Hannes Payer (out of office), 2014-02-07 09:55:04]

Committed patchset #2 manually as r19189 (presubmit successful).