[heap] Don't allocate immovable code in LO space during serialization

[heap] Don't allocate immovable code in LO space during serialization

Background: the first page of each space is implicitly immovable.
Recently, our builtin code objects have reached a size at which we
fill up the first page of code space during initialization. Once
that occurs, newly requested allocations of immovable code are
allocated in a large object space page of 512K.

This CL mitigates these effects by simply marking pages as immovable
during snapshot creation instead of going into LO space.

On snapshot builds, this should just work: deserialized pages are
trimmed and marked immovable when deserialization finishes.

However, non-snapshot builds and allocations of immovable CEntryStub
code at runtime are still affected.

BUG=v8:5831
Review-Url: https://codereview.chromium.org/2635973002
Cr-Commit-Position: refs/heads/master@{#42411}
Committed: https://chromium.googlesource.com/v8/v8/+/47684fe852eb4f2de546b656b8268d0a161b57c9

[jgruber, 2017-01-16 17:00:19]

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

[commit-bot: I haz the power, 2017-01-16 17:00:28]

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, 2017-01-16 17:03:30]

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

[commit-bot: I haz the power, 2017-01-16 17:03:31]

Dry run: Try jobs failed on following builders:
  v8_linux_mips64el_compile_rel on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...)

[jgruber, 2017-01-17 08:07:48]

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

[commit-bot: I haz the power, 2017-01-17 08:07:52]

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

[jgruber, 2017-01-17 08:15:15]

Description was changed from

==========
[heap] Don't allocate immovable code in LO space during serialization

BUG=
==========

to

==========
[heap] Don't allocate immovable code in LO space during serialization

Background: the first page of each space is implicitly immovable.
Recently, our builtin code objects have reached a size at which we
fill up the first page of code space during initialization. Once
that occurs, newly requested allocations of immovable code are
allocated in a large object space page of 512K.

This CL mitigates these effects by simply marking pages as immovable
during snapshot creation instead of going into LO space.

On snapshot builds, this should just work: deserialized pages are
trimmed and marked immovable when deserialization finishes.

However, non-snapshot builds and allocations of immovable CEntryStub
code at runtime are still affected.

BUG=v8:5831
==========

[commit-bot: I haz the power, 2017-01-17 08:34:12]

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

[commit-bot: I haz the power, 2017-01-17 08:34:13]

Dry run: This issue passed the CQ dry run.

[jgruber, 2017-01-17 08:37:34]

jgruber@chromium.org changed reviewers:
+ hpayer@chromium.org, mlippautz@chromium.org

[jgruber, 2017-01-17 08:37:35]

No tests since we don't seem to have a setup that can conveniently test snapshot
creation.

We should still come up with a good solution for the non-snapshot case at some
point.

[Michael Lippautz, 2017-01-17 12:08:12]

On 2017/01/17 08:37:35, jgruber wrote:
> No tests since we don't seem to have a setup that can conveniently test
snapshot
> creation.
> 
> We should still come up with a good solution for the non-snapshot case at some
> point.

lgtm from my side

[jgruber, 2017-01-17 12:55:19]

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

[commit-bot: I haz the power, 2017-01-17 12:55:26]

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

[jgruber, 2017-01-17 13:21:56]

Added a test (with hacky fake snapshot-creation). Hannes, PTAL.

[commit-bot: I haz the power, 2017-01-17 13:25:13]

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

[commit-bot: I haz the power, 2017-01-17 13:25:14]

Dry run: This issue passed the CQ dry run.

[Hannes Payer (out of office), 2017-01-17 14:13:25]

lgtm

[jgruber, 2017-01-17 14:18:21]

The CQ bit was checked by jgruber@chromium.org

[jgruber, 2017-01-17 14:18:21]

The patchset sent to the CQ was uploaded after l-g-t-m from
mlippautz@chromium.org
Link to the patchset: https://codereview.chromium.org/2635973002/#ps40001
(title: "Add test")

[commit-bot: I haz the power, 2017-01-17 14:18:26]

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, 2017-01-17 14:19:59]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1484662701267290,
"parent_rev": "c2e8cb195afff01d47ce16f32f17a4a768166035", "commit_rev":
"47684fe852eb4f2de546b656b8268d0a161b57c9"}

[commit-bot: I haz the power, 2017-01-17 14:20:03]

Description was changed from

==========
[heap] Don't allocate immovable code in LO space during serialization

Background: the first page of each space is implicitly immovable.
Recently, our builtin code objects have reached a size at which we
fill up the first page of code space during initialization. Once
that occurs, newly requested allocations of immovable code are
allocated in a large object space page of 512K.

This CL mitigates these effects by simply marking pages as immovable
during snapshot creation instead of going into LO space.

On snapshot builds, this should just work: deserialized pages are
trimmed and marked immovable when deserialization finishes.

However, non-snapshot builds and allocations of immovable CEntryStub
code at runtime are still affected.

BUG=v8:5831
==========

to

==========
[heap] Don't allocate immovable code in LO space during serialization

Background: the first page of each space is implicitly immovable.
Recently, our builtin code objects have reached a size at which we
fill up the first page of code space during initialization. Once
that occurs, newly requested allocations of immovable code are
allocated in a large object space page of 512K.

This CL mitigates these effects by simply marking pages as immovable
during snapshot creation instead of going into LO space.

On snapshot builds, this should just work: deserialized pages are
trimmed and marked immovable when deserialization finishes.

However, non-snapshot builds and allocations of immovable CEntryStub
code at runtime are still affected.

BUG=v8:5831

Review-Url: https://codereview.chromium.org/2635973002
Cr-Commit-Position: refs/heads/master@{#42411}
Committed:
https://chromium.googlesource.com/v8/v8/+/47684fe852eb4f2de546b656b8268d0a161...
==========

[commit-bot: I haz the power, 2017-01-17 14:20:05]

Committed patchset #3 (id:40001) as
https://chromium.googlesource.com/v8/v8/+/47684fe852eb4f2de546b656b8268d0a161...