[crankshaft] Make the for-in slow path compatible with the other compilers.

[crankshaft] Make the for-in slow path compatible with the other compilers.

So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.

BUG=v8:3650, v8:4715
LOG=n

Committed: https://crrev.com/3251a03e81b99bcab20d9d2a7c3fb899b0b64ffb
Cr-Commit-Position: refs/heads/master@{#33599}

[Benedikt Meurer, 2016-01-29 05:42:56]

Description was changed from

==========
[crankshaft] Make the for-in slow path compatible with the other compilers.

So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map before accessing the
enum cache.

BUG=v8:3650,v8:4715
LOG=n
==========

to

==========
[crankshaft] Make the for-in slow path compatible with the other compilers.

So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.

BUG=v8:3650,v8:4715
LOG=n
==========

[Benedikt Meurer, 2016-01-29 06:35:35]

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

[Benedikt Meurer, 2016-01-29 06:35:36]

Hey Yang,

This is the Crankshaft fix for for-in that Jakob was looking into yesterday.
Please take a look.

Thanks,
Benedikt

[Yang, 2016-01-29 06:43:18]

On 2016/01/29 06:35:36, Benedikt Meurer wrote:
> Hey Yang,
> 
> This is the Crankshaft fix for for-in that Jakob was looking into yesterday.
> Please take a look.
> 
> Thanks,
> Benedikt

lgtm.

[Benedikt Meurer, 2016-01-29 06:43:42]

The CQ bit was checked by bmeurer@chromium.org

[commit-bot: I haz the power, 2016-01-29 06:43:46]

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

[commit-bot: I haz the power, 2016-01-29 07:50:14]

Description was changed from

==========
[crankshaft] Make the for-in slow path compatible with the other compilers.

So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.

BUG=v8:3650,v8:4715
LOG=n
==========

to

==========
[crankshaft] Make the for-in slow path compatible with the other compilers.

So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.

BUG=v8:3650,v8:4715
LOG=n
==========

[commit-bot: I haz the power, 2016-01-29 07:50:16]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-01-29 07:51:05]

Description was changed from

==========
[crankshaft] Make the for-in slow path compatible with the other compilers.

So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.

BUG=v8:3650,v8:4715
LOG=n
==========

to

==========
[crankshaft] Make the for-in slow path compatible with the other compilers.

So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.

BUG=v8:3650,v8:4715
LOG=n

Committed: https://crrev.com/3251a03e81b99bcab20d9d2a7c3fb899b0b64ffb
Cr-Commit-Position: refs/heads/master@{#33599}
==========

[commit-bot: I haz the power, 2016-01-29 07:51:06]

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