[elements] Precisely estimate elements size for large-object limits

[elements] Precisely estimate elements size as last resort

In case of an allocation failure in for-in over holey elements, use precise
number of elements to allocate a smaller buffer for the collected indices.

Drive-by-fix: make is_the_hole accept the isolate for faster checks.

BUG=chromium:609761
Committed: https://crrev.com/14c6a651d1c04c90379299e577dd8e187967f5a9
Cr-Commit-Position: refs/heads/master@{#41010}

[Camillo Bruni, 2016-06-07 13:29:43]

Description was changed from

==========
[elements] Precisely estimate elements size for large-object limits

For in on holey elements that exceed the large-object limit should be precisely
estimated to avoid generating too much garbage. The existing strategy of just
shrinking after collecting does not work in this case as large-objects cannot
be partially freed. This CL tries to lower the estimate by preciesly counting
the number of elements in a holey backing store if it exceeds the larg object
limit.

BUG=chr:609761
==========

to

==========
[elements] Precisely estimate elements size for large-object limits

For in on holey elements that exceed the large-object limit should be precisely
estimated to avoid generating too much garbage. The existing strategy of just
shrinking after collecting does not work in this case as large-objects cannot
be partially freed. This CL tries to lower the estimate by preciesly counting
the number of elements in a holey backing store if it exceeds the larg object
limit.

Drive-by-fix: make is_the_hole accept the isolate for faster checks.

BUG=chr:609761
==========

[Camillo Bruni, 2016-06-07 13:45:31]

cbruni@chromium.org changed reviewers:
+ ishell@chromium.org, mlippautz@chromium.org

[Camillo Bruni, 2016-06-07 13:45:31]

mlippautz@ PTAL at the large object space limit check in elements.cc:990+
ishell@ PTAL

[Igor Sheludko, 2016-06-07 14:50:01]

https://codereview.chromium.org/2041963003/diff/1/src/elements.cc
File src/elements.cc (right):

https://codereview.chromium.org/2041963003/diff/1/src/elements.cc#newcode993
src/elements.cc:993: if (kind() == FAST_HOLEY_ELEMENTS) {
FAST_HOLEY_DOUBLE_ELEMENTS ?

https://codereview.chromium.org/2041963003/diff/1/src/elements.cc#newcode1011
src/elements.cc:1011: Subclass::GetMaxNumberOfEntries(*object, *backing_store);
It does not have to be called for holey kinds. Maybe you can even move this code
to Estimate... function.

[Michael Lippautz, 2016-06-07 17:28:27]

Looking good, just waiting for the performance investigation

https://codereview.chromium.org/2041963003/diff/1/src/elements.cc
File src/elements.cc (right):

https://codereview.chromium.org/2041963003/diff/1/src/elements.cc#newcode1015
src/elements.cc:1015: // If we overestimate the result list size we might end up
in old space
s/old space/large object space/

[Igor Sheludko, 2016-07-14 15:11:56]

Description was changed from

==========
[elements] Precisely estimate elements size for large-object limits

For in on holey elements that exceed the large-object limit should be precisely
estimated to avoid generating too much garbage. The existing strategy of just
shrinking after collecting does not work in this case as large-objects cannot
be partially freed. This CL tries to lower the estimate by preciesly counting
the number of elements in a holey backing store if it exceeds the larg object
limit.

Drive-by-fix: make is_the_hole accept the isolate for faster checks.

BUG=chr:609761
==========

to

==========
[elements] Precisely estimate elements size for large-object limits

For in on holey elements that exceed the large-object limit should be precisely
estimated to avoid generating too much garbage. The existing strategy of just
shrinking after collecting does not work in this case as large-objects cannot
be partially freed. This CL tries to lower the estimate by preciesly counting
the number of elements in a holey backing store if it exceeds the larg object
limit.

Drive-by-fix: make is_the_hole accept the isolate for faster checks.

BUG=chromium:609761
==========

[Igor Sheludko, 2016-07-14 15:12:53]

lgtm

[Yang, 2016-07-28 10:56:40]

On 2016/07/14 15:12:53, Igor Sheludko wrote:
> lgtm

Can we get this up to shape and land this to address the bug?

[Michael Lippautz, 2016-08-02 19:23:36]

On 2016/07/28 10:56:40, Yang wrote:
> On 2016/07/14 15:12:53, Igor Sheludko wrote:
> > lgtm
> 
> Can we get this up to shape and land this to address the bug?

lgtm on the LO space checks.

[Camillo Bruni, 2016-11-14 16:00:34]

Description was changed from

==========
[elements] Precisely estimate elements size for large-object limits

For in on holey elements that exceed the large-object limit should be precisely
estimated to avoid generating too much garbage. The existing strategy of just
shrinking after collecting does not work in this case as large-objects cannot
be partially freed. This CL tries to lower the estimate by preciesly counting
the number of elements in a holey backing store if it exceeds the larg object
limit.

Drive-by-fix: make is_the_hole accept the isolate for faster checks.

BUG=chromium:609761
==========

to

==========
[elements] Precisely estimate elements size as last resort

In case of an allocation failure in for-in over holey elements, use precise
number of elements to allocate a smaller buffer for the collected indices.

Drive-by-fix: make is_the_hole accept the isolate for faster checks.

BUG=chromium:609761
==========

[Camillo Bruni, 2016-11-14 16:01:47]

The CQ bit was checked by cbruni@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-14 16:02:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-14 16:06:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-14 16:06:27]

Dry run: Try jobs failed on following builders:
  v8_win_nosnap_shared_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...)
  v8_win_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/17832)

[Camillo Bruni, 2016-11-15 13:54:04]

The CQ bit was checked by cbruni@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-15 13:54:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-15 14:22:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-15 14:22:09]

Dry run: This issue passed the CQ dry run.

[Michael Lippautz, 2016-11-15 16:14:12]

still lgtm

only looked at factory and object allocation

[Camillo Bruni, 2016-11-15 17:17:18]

cbruni@chromium.org changed reviewers:
+ bmeurer@chromium.org

[Camillo Bruni, 2016-11-15 17:17:19]

bmeurer@ PTAL src/compiler/.*

[Benedikt Meurer, 2016-11-15 17:20:36]

LGTM on compiler.

[Jakob Kummerow, 2016-11-15 18:24:36]

jkummerow@chromium.org changed reviewers:
+ jkummerow@chromium.org

[Jakob Kummerow, 2016-11-15 18:24:37]

The diff from patch set 5 -> 7 LGTM.

[Camillo Bruni, 2016-11-15 18:27:29]

The CQ bit was checked by cbruni@chromium.org

[Camillo Bruni, 2016-11-15 18:27:29]

The patchset sent to the CQ was uploaded after l-g-t-m from ishell@chromium.org
Link to the patchset: https://codereview.chromium.org/2041963003/#ps120001
(title: "add missing method on string wrapper")

[commit-bot: I haz the power, 2016-11-15 18:27:39]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-15 18:30:40]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-11-17 22:35:00]

Description was changed from

==========
[elements] Precisely estimate elements size as last resort

In case of an allocation failure in for-in over holey elements, use precise
number of elements to allocate a smaller buffer for the collected indices.

Drive-by-fix: make is_the_hole accept the isolate for faster checks.

BUG=chromium:609761
==========

to

==========
[elements] Precisely estimate elements size as last resort

In case of an allocation failure in for-in over holey elements, use precise
number of elements to allocate a smaller buffer for the collected indices.

Drive-by-fix: make is_the_hole accept the isolate for faster checks.

BUG=chromium:609761

Committed: https://crrev.com/14c6a651d1c04c90379299e577dd8e187967f5a9
Cr-Commit-Position: refs/heads/master@{#41010}
==========

[commit-bot: I haz the power, 2016-11-17 22:35:02]

Patchset 7 (id:??) landed as
https://crrev.com/14c6a651d1c04c90379299e577dd8e187967f5a9
Cr-Commit-Position: refs/heads/master@{#41010}