Reland "Use off-heap data for type feedback in PolymorphicInstanceCallInstr"

Reland "Use off-heap data for type feedback in PolymorphicInstanceCallInstr"

This reverts commit 2135c8a90f37091536bb6707edc5bf5a48bf315c.
This is a reland of https://codereview.chromium.org/2809583002/

Original text:
We have been using IC data for receiver type info in the
PolymorphicInstanceCallInstr. This is a data structure optimized for access
from hand-coded assembly stubs, and placed on the GC-ed heap, which means it
has to be accessed through handles. With this change we move it to the zone
memory, which means it can be freed without an old-gen GC.  As a side-effect
the zone arrays use exponential growth for amortized constant space allocation
instead of growing by 1 for quadratic allocation when we add classes, further
reducing memory pressure.

R=vegorov@google.com
BUG=

Committed: https://github.com/dart-lang/sdk/commit/694ddfcdd3ae166858a2bf979287b0eefb21814c

[Vyacheslav Egorov (Google), 2017-04-24 13:38:48]

lgtm

[erikcorry, 2017-04-24 13:39:13]

Description was changed from

==========
Reland "Use off-heap data for type feedback in PolymorphicInstanceCallInstr"

This reverts commit 2135c8a90f37091536bb6707edc5bf5a48bf315c.
This is a reland of https://codereview.chromium.org/2809583002/

Original text:
We have been using IC data for receiver type info in the
PolymorphicInstanceCallInstr. This is a data structure optimized for access
from hand-coded assembly stubs, and placed on the GC-ed heap, which means it
has to be accessed through handles. With this change we move it to the zone
memory, which means it can be freed without an old-gen GC.  As a side-effect
the zone arrays use exponential growth for amortized constant space allocation
instead of growing by 1 for quadratic allocation when we add classes, further
reducing memory pressure.

R=vegorov@google.com
BUG=
==========

to

==========
Reland "Use off-heap data for type feedback in PolymorphicInstanceCallInstr"

This reverts commit 2135c8a90f37091536bb6707edc5bf5a48bf315c.
This is a reland of https://codereview.chromium.org/2809583002/

Original text:
We have been using IC data for receiver type info in the
PolymorphicInstanceCallInstr. This is a data structure optimized for access
from hand-coded assembly stubs, and placed on the GC-ed heap, which means it
has to be accessed through handles. With this change we move it to the zone
memory, which means it can be freed without an old-gen GC.  As a side-effect
the zone arrays use exponential growth for amortized constant space allocation
instead of growing by 1 for quadratic allocation when we add classes, further
reducing memory pressure.

R=vegorov@google.com
BUG=

Committed:
https://github.com/dart-lang/sdk/commit/694ddfcdd3ae166858a2bf979287b0eefb21814c
==========

[erikcorry, 2017-04-24 13:39:15]

Committed patchset #2 (id:20001) manually as
694ddfcdd3ae166858a2bf979287b0eefb21814c.

[rmacnak, 2017-04-24 16:52:49]

On 2017/04/24 13:39:15, erikcorry wrote:
> Committed patchset #2 (id:20001) manually as
> 694ddfcdd3ae166858a2bf979287b0eefb21814c.

Just to check, is this zone array (or a malloced copy) referenced from generated
code? We can't generally directly reference the C heap from generated code
because it breaks relocation for AppAOT or AppJIT.

[rmacnak, 2017-04-24 18:17:10]

On 2017/04/24 16:52:49, rmacnak wrote:
> On 2017/04/24 13:39:15, erikcorry wrote:
> > Committed patchset #2 (id:20001) manually as
> > 694ddfcdd3ae166858a2bf979287b0eefb21814c.
> 
> Just to check, is this zone array (or a malloced copy) referenced from
generated
> code? We can't generally directly reference the C heap from generated code
> because it breaks relocation for AppAOT or AppJIT.

Nvm, we don't use a reference to the original IC for the polymorphic instance
call, only a regular instance call.