Generate specialized constructor code for constructing simple objects

Generate specialized constructor code for constructing simple objects.

For objects which only have simple assignments of the form this.x = ...; a specialized constructor stub is now generated. This generated code allocates the object and fills in the initial properties directly. If this fails for some reason code continues in the generic constructor stub which in turn might pass control to the runtime system.

Added counter to see how many objects are constructed using a specialized stub.

The specialized stub is only implemented for ia32 architecture in this change. For x64 and ARM the generic construct stub is used.

Committed: http://code.google.com/p/v8/source/detail?r=2753

[Mads Ager (chromium), 2009-08-25 10:25:50]

LGTM

I think the generated code can be tweaked a bit more.

http://codereview.chromium.org/174392/diff/1019/23
File src/ia32/stub-cache-ia32.cc (right):

http://codereview.chromium.org/174392/diff/1019/23#newcode1744
Line 1744: // this.x = ...; in their body.
simple assignments of the form ... in their body?

http://codereview.chromium.org/174392/diff/1019/23#newcode1757
Line 1757: // code for function thereby hitting the break points.
for function -> for the function

http://codereview.chromium.org/174392/diff/1019/23#newcode1758
Line 1758: // the function when constructing the object.
Delete this line?

http://codereview.chromium.org/174392/diff/1019/23#newcode1770
Line 1770: // edi: constructor
Remove these two lines here since they are repeated below after the actual test
that ebx is a map.

http://codereview.chromium.org/174392/diff/1019/23#newcode1792
Line 1792: ExternalReference new_space_allocation_top =
The actual allocation of an object (not the initialization) could be factored
out.  We use the same code for allocating floating-point numbers I think?

http://codereview.chromium.org/174392/diff/1019/23#newcode1809
Line 1809: __ mov(Operand(edx, JSObject::kPropertiesOffset), ebx);
I guess you could just use Factory::empty_fixed_array() in these two lines
without loading it into ebx first.

http://codereview.chromium.org/174392/diff/1019/23#newcode1819
Line 1819: // Point to the first in-object property.
Load the address of the first in-object property into edx?

http://codereview.chromium.org/174392/diff/1019/23#newcode1821
Line 1821: __ xor_(Operand(edx), Immediate(kHeapObjectTag));  // Clear the heap
tag.
heap -> heap-object.

http://codereview.chromium.org/174392/diff/1019/23#newcode1826
Line 1826: // Use esi for holding undefined.
Do you need this?  The mov instructions should be able to use the handle
directly?

http://codereview.chromium.org/174392/diff/1019/23#newcode1849
Line 1849: __ mov(ebx, Operand(ecx, edi, times_4, -kPointerSize));
Isn't the value of ebx known at compile time? In that case it seems that you can
calculate the offset at compile time instead of at runtime?

http://codereview.chromium.org/174392/diff/1019/23#newcode1858
Line 1858: __ add(Operand(edx), Immediate(kPointerSize));
Instead of updating edx in each iteration, couldn't you compute the offset at
compile-time (iteration in the loop * kPointerSize) for the store instructions?

http://codereview.chromium.org/174392/diff/1019/23#newcode1884
Line 1884: // Jump to the generic stub in case the specialized code cannto
handle the
cannot

[Søren Thygesen Gjesse, 2009-08-25 12:22:27]

This tweaking made the code for the constructor function (){this.x=1} shrink
from 148 to 139 bytes.

http://codereview.chromium.org/174392/diff/1019/23
File src/ia32/stub-cache-ia32.cc (right):

http://codereview.chromium.org/174392/diff/1019/23#newcode1744
Line 1744: // this.x = ...; in their body.
On 2009/08/25 10:25:50, Mads Ager wrote:
> simple assignments of the form ... in their body?

Done.

http://codereview.chromium.org/174392/diff/1019/23#newcode1757
Line 1757: // code for function thereby hitting the break points.
On 2009/08/25 10:25:50, Mads Ager wrote:
> for function -> for the function

Done.

http://codereview.chromium.org/174392/diff/1019/23#newcode1758
Line 1758: // the function when constructing the object.
On 2009/08/25 10:25:50, Mads Ager wrote:
> Delete this line?

Done.

http://codereview.chromium.org/174392/diff/1019/23#newcode1770
Line 1770: // edi: constructor
On 2009/08/25 10:25:50, Mads Ager wrote:
> Remove these two lines here since they are repeated below after the actual
test
> that ebx is a map.

Done.

http://codereview.chromium.org/174392/diff/1019/23#newcode1792
Line 1792: ExternalReference new_space_allocation_top =
On 2009/08/25 10:25:50, Mads Ager wrote:
> The actual allocation of an object (not the initialization) could be factored
> out.  We use the same code for allocating floating-point numbers I think?

And in the generic construct stub. Will do that in a separate change.

http://codereview.chromium.org/174392/diff/1019/23#newcode1809
Line 1809: __ mov(Operand(edx, JSObject::kPropertiesOffset), ebx);
On 2009/08/25 10:25:50, Mads Ager wrote:
> I guess you could just use Factory::empty_fixed_array() in these two lines
> without loading it into ebx first.

This was to avoid having two times empty fixed array in the reloc info. Code
size is 3 bytes less than when loading directly.

http://codereview.chromium.org/174392/diff/1019/23#newcode1819
Line 1819: // Point to the first in-object property.
On 2009/08/25 10:25:50, Mads Ager wrote:
> Load the address of the first in-object property into edx?

Comment changed.

http://codereview.chromium.org/174392/diff/1019/23#newcode1821
Line 1821: __ xor_(Operand(edx), Immediate(kHeapObjectTag));  // Clear the heap
tag.
On 2009/08/25 10:25:50, Mads Ager wrote:
> heap -> heap-object.

Done.

http://codereview.chromium.org/174392/diff/1019/23#newcode1826
Line 1826: // Use esi for holding undefined.
On 2009/08/25 10:25:50, Mads Ager wrote:
> Do you need this?  The mov instructions should be able to use the handle
> directly?

This is to avoid having several undefined in the reloc info. It saves space.

http://codereview.chromium.org/174392/diff/1019/23#newcode1849
Line 1849: __ mov(ebx, Operand(ecx, edi, times_4, -kPointerSize));
On 2009/08/25 10:25:50, Mads Ager wrote:
> Isn't the value of ebx known at compile time? In that case it seems that you
can
> calculate the offset at compile time instead of at runtime?

Thats right. Also changed the code to have ecx point to the first argument
instead of the last, which made the code more readable.

http://codereview.chromium.org/174392/diff/1019/23#newcode1858
Line 1858: __ add(Operand(edx), Immediate(kPointerSize));
On 2009/08/25 10:25:50, Mads Ager wrote:
> Instead of updating edx in each iteration, couldn't you compute the offset at
> compile-time (iteration in the loop * kPointerSize) for the store
instructions?

Done.

http://codereview.chromium.org/174392/diff/1019/23#newcode1884
Line 1884: // Jump to the generic stub in case the specialized code cannto
handle the
On 2009/08/25 10:25:50, Mads Ager wrote:
> cannot

Done.