Instantiate instance templates instead of doing construct calls

Instantiate instance templates instead of doing construct calls

This reduces the calls to V8 to create new wrappers. We also don't rely
on invoking the function anyways, but instead cache results.

BUG=
R=verwaest@chromium.org

Committed: https://crrev.com/5800d1a48a2f4c2aab7cf875b164b08328c7acf4
Cr-Commit-Position: refs/heads/master@{#378497}

[Toon Verwaest, 2016-03-01 17:20:08]

lgtm

[jochen (gone - plz use gerrit), 2016-03-01 17:29:18]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2016-03-01 17:29:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1747293002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1747293002/1

[haraken, 2016-03-01 17:33:48]

LGTM

[commit-bot: I haz the power, 2016-03-01 18:57:10]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-03-01 18:58:24]

Description was changed from

==========
Instantiate instance templates instead of doing construct calls

This reduces the calls to V8 to create new wrappers. We also don't rely
on invoking the function anyways, but instead cache results.

BUG=
R=verwaest@chromium.org
==========

to

==========
Instantiate instance templates instead of doing construct calls

This reduces the calls to V8 to create new wrappers. We also don't rely
on invoking the function anyways, but instead cache results.

BUG=
R=verwaest@chromium.org

Committed: https://crrev.com/5800d1a48a2f4c2aab7cf875b164b08328c7acf4
Cr-Commit-Position: refs/heads/master@{#378497}
==========

[commit-bot: I haz the power, 2016-03-01 18:58:31]

Patchset 1 (id:??) landed as
https://crrev.com/5800d1a48a2f4c2aab7cf875b164b08328c7acf4
Cr-Commit-Position: refs/heads/master@{#378497}

[Ken Russell (switch to Gerrit), 2016-03-02 19:23:47]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1753363002/ by kbr@chromium.org.

The reason for reverting is: It looks like this caused the
WebglConformance.conformance_misc_expando_loss test to start failing (only on
Win x64, strangely). This test verifies that expando properties added to
JavaScript instances which are kept alive via hidden properties are preserved
during GC:
https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20x64%20Debug%20%...

In the future it would be really helpful if you filed bugs about changes like
this so that lands, reverts and re-lands were all referenced from one place.
.

[jochen (gone - plz use gerrit), 2016-03-02 21:27:29]

On 2016/03/02 at 19:23:47, kbr wrote:
> A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1753363002/ by kbr@chromium.org.
> 
> The reason for reverting is: It looks like this caused the
WebglConformance.conformance_misc_expando_loss test to start failing (only on
Win x64, strangely). This test verifies that expando properties added to
JavaScript instances which are kept alive via hidden properties are preserved
during GC:
> 

Can you help me understand how you came to this conclusion? I'm not sure I
understand the test output, but it looks like it's just timing out, or am I
missing some error message?

I looked at the test source, but it does a bunch of stuff, so I'm not sure where
to start debugging

https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20x64%20Debug%20%...
> 
> In the future it would be really helpful if you filed bugs about changes like
this so that lands, reverts and re-lands were all referenced from one place.
> .

This change is just inlining code - and we have a bunch of layout tests that
cover persistence of properties across GC... It didn't seem like this would
warrant a bug.