Add support for extended constant pool arrays.

Add support for extended constant pool arrays.

This CL adds support for ConstantPoolArrays which contain an extended section.
This will be used to enable larger constant pools than can be addressed by a
single ldr with immediate offset instruction (which has a limit of a 4KB range).
Extended constant pools will have a small section, which is addressable via a
single ldr instruction, and an extended section, which will require a multi-
instruction sequence to load from.

Currently, no code uses the extended ConstantPoolArray's - this change will
be made in a followup CL.

A number of changes are made to the ConstantPoolArray object in order to
support this:
  - Small section layout is now entirely defined by the small layout bitmaps.
  - The ConstantPoolArray no longer extends FixedArrayBase since the length
    field is not useful for extended layouts.
  - Enums are used to represent the type of an entry and the layout section.
  - An iterator can be used to iterate through all elements of a given type.
  - A number of tests were added for these features.

R=ulan@chromium.org

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

[rmcilroy, 2014-05-29 11:06:48]

Ulan, could you please take a look.  Sorry about the large CL, but I had to
change the way iteration of the constant pool's worked to support the extended
section cleanly.

Michael, I cced you in case you are interested in the changes being made to the
constant pool for your work on the feedback vector.

[ulan, 2014-06-02 12:32:57]

I like the heap pointer iterator! Looks good overall, small suggestions below.

https://codereview.chromium.org/304143002/diff/20001/src/factory.cc
File src/factory.cc (right):

https://codereview.chromium.org/304143002/diff/20001/src/factory.cc#newcode134
src/factory.cc:134: Handle<ConstantPoolArray>
Factory::NewExtendedConstantPoolArray(
Instead of passing this long list arguments around, what if we introduce
a class NumberOfEntries that stores "int number_of_entries[4]"?

The this function would look like:
NewExtendedConstantPoolArray(NumberOfEntries small, NumberOfEntries extended);

Constant pool would have a method:
NumberOfEntries ConstantPoolArray::number_of_entries(Section section);

This would also simplify SizeFor* methods.

https://codereview.chromium.org/304143002/diff/20001/src/objects-inl.h
File src/objects-inl.h (right):

https://codereview.chromium.org/304143002/diff/20001/src/objects-inl.h#newcod...
src/objects-inl.h:2237: int index = 0;
How about iterating over types and sections in this and other functions?

Something like this (modulo needs enum casts):

for (int s = 0; s <= section; ++s) {
  for (int t = 0; t < type; ++t) {
    index += number_of_entries(t, s);
  }
}

https://codereview.chromium.org/304143002/diff/20001/src/objects-inl.h#newcod...
src/objects-inl.h:2317: if (index >= first_index(INT64, section) &&
int t = 0;

while (last_index(t, section) < index) ++t;

return t;

https://codereview.chromium.org/304143002/diff/20001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/304143002/diff/20001/src/objects.cc#newcode9980
src/objects.cc:9980: if (number_of_entries(CODE_PTR, SMALL_SECTION) > 0) {
Type type[] = {CODE_PTR, HEAP_PTR};
Address value[] = {<illegal builtin entry>, <undefined>};

for (int section = 0; section <= final_section(); ++section) {
  for (int i = 0; i < 2; ++i) {
    if (number_of_entries(type[i], section) > 0) {
      int offset = OffsetOfElementAt(first_index(type[i], section));
      MemsetPointer(
        HeapObject::RawField(this, offset),
        value[i],
        number_of_entries(type[i], section));
    }
  }
}

https://codereview.chromium.org/304143002/diff/20001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/304143002/diff/20001/src/objects.h#newcode3265
src/objects.h:3265: offset += kInt64Size * Min(Max(0, index - first_index(INT64,
section)),
int t = 0;
while (last_index(t, section) < index) {
   offset += entry_size(t) * number_of_entries(t, section);
   ++t;
}
offset += entry_size(type) * (index - first_index(t, section));

[mvstanton, 2014-06-02 13:14:00]

Just as a DBC: this is great. I'm thinking to be able to use these handy
ConstantPoolArrays as elements in the feedback vector when feedback for a
particular node (say a LoadIC) would like to store code addresses as well as
object pointers. You've solved a thorny problem and type vector code could
piggy-back on that.

[rmcilroy, 2014-06-03 12:32:27]

Thanks for the review Ulan, PTAL.

https://codereview.chromium.org/304143002/diff/20001/src/factory.cc
File src/factory.cc (right):

https://codereview.chromium.org/304143002/diff/20001/src/factory.cc#newcode134
src/factory.cc:134: Handle<ConstantPoolArray>
Factory::NewExtendedConstantPoolArray(
On 2014/06/02 12:32:58, ulan wrote:
> Instead of passing this long list arguments around, what if we introduce
> a class NumberOfEntries that stores "int number_of_entries[4]"?
> 
> The this function would look like:
> NewExtendedConstantPoolArray(NumberOfEntries small, NumberOfEntries extended);
> 
> Constant pool would have a method:
> NumberOfEntries ConstantPoolArray::number_of_entries(Section section);
> 
> This would also simplify SizeFor* methods.

Good idea - done.

https://codereview.chromium.org/304143002/diff/20001/src/objects-inl.h
File src/objects-inl.h (right):

https://codereview.chromium.org/304143002/diff/20001/src/objects-inl.h#newcod...
src/objects-inl.h:2237: int index = 0;
On 2014/06/02 12:32:58, ulan wrote:
> How about iterating over types and sections in this and other functions?
> 
> Something like this (modulo needs enum casts):
> 
> for (int s = 0; s <= section; ++s) {
>   for (int t = 0; t < type; ++t) {
>     index += number_of_entries(t, s);
>   }
> }

Done (but only iterating through types).

https://codereview.chromium.org/304143002/diff/20001/src/objects-inl.h#newcod...
src/objects-inl.h:2317: if (index >= first_index(INT64, section) &&
On 2014/06/02 12:32:58, ulan wrote:
> int t = 0;
> 
> while (last_index(t, section) < index) ++t;
> 
> return t;

Done.

https://codereview.chromium.org/304143002/diff/20001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/304143002/diff/20001/src/objects.cc#newcode9980
src/objects.cc:9980: if (number_of_entries(CODE_PTR, SMALL_SECTION) > 0) {
On 2014/06/02 12:32:58, ulan wrote:
> Type type[] = {CODE_PTR, HEAP_PTR};
> Address value[] = {<illegal builtin entry>, <undefined>};
> 
> for (int section = 0; section <= final_section(); ++section) {
>   for (int i = 0; i < 2; ++i) {
>     if (number_of_entries(type[i], section) > 0) {
>       int offset = OffsetOfElementAt(first_index(type[i], section));
>       MemsetPointer(
>         HeapObject::RawField(this, offset),
>         value[i],
>         number_of_entries(type[i], section));
>     }
>   }
> }

Done.  I'm not convinced this is clearer though.

https://codereview.chromium.org/304143002/diff/20001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/304143002/diff/20001/src/objects.h#newcode3265
src/objects.h:3265: offset += kInt64Size * Min(Max(0, index - first_index(INT64,
section)),
On 2014/06/02 12:32:58, ulan wrote:
> int t = 0;
> while (last_index(t, section) < index) {
>    offset += entry_size(t) * number_of_entries(t, section);
>    ++t;
> }
> offset += entry_size(type) * (index - first_index(t, section));

Done (somewhat differently both to avoid lots of static casts).

[rmcilroy, 2014-06-03 12:35:15]

On 2014/06/02 13:14:00, mvstanton wrote:
> Just as a DBC: this is great. I'm thinking to be able to use these handy
> ConstantPoolArrays as elements in the feedback vector when feedback for a
> particular node (say a LoadIC) would like to store code addresses as well as
> object pointers. You've solved a thorny problem and type vector code could
> piggy-back on that.

Great, sounds good.  Let me know if you would like to have a chat about this
over VC, or in-person the week after next when I'm in Munich.

[ulan, 2014-06-03 14:54:21]

LGTM

> Done.  I'm not convinced this is clearer though.
This seems slightly more readable to me, but that's subjective. I don't have
strong preference on this, feel free to land the previous version of
ClearPtrEntries.

[rmcilroy, 2014-06-03 16:22:22]

Committed patchset #5 manually as r21653 (presubmit successful).