Currently back references to regular objects are encoded in terms of
a relative address, index by chunk index and chunk offset.   This
approach has the advantage of avoiding the need for a table of
back-references at deserialization time, but makes strong assumptions
about the way objects are organized in memory (for example, this will
not work if the allocator uses a free list rather than a bump pointer).

I did some quick measurements and found that the absolute number of
objects and back-references is low, suggesting that simply indexing
objects would work with little (or no) observable impact on peak
memory use during deserialization.   Indexing only back referenced
objects is not implemented in this simple CL, but could fairly easily
be added.

Given that the existing mechanism will remain in place, I have
implemented the object index by simply making chunk size one, so
every object lives on its own chunk (with offset zero).   This is
the moral equivalent to indexing each object but is a more minimal
change.  Directly encoding an object index will be more efficient,
the trade off made here is just to keep the change absolutely minimal.

If using an object index becomes the default, this can be optimized
first by only using an index for each object that is actually back-
referenced (about half of all objects in my measurements), and more
aggressively, a technique like register allocation could be used at
serialization time to limit the number of indices to the maximum
number of outstanding back-references at any time (basically a live-
range analysis of back-references).

Bug: v8:9533
Change-Id: I1b7ae87e954f67f6405c2bbdf3b4a4f385af8579
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030742
Commit-Queue: Steve Blackburn <steveblackburn@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66154}