[serializer] reorder some bytecodes to free up large blocks.

[serializer] reorder some bytecodes to free up large blocks.

R=vogelheim@chromium.org

Committed: https://crrev.com/03996851f4d736bd12f57a7a5fb241b375fa2995
Cr-Commit-Position: refs/heads/master@{#37178}

[vogelheim, 2016-06-22 09:22:32]

lgtm

I have some questions, though...

https://codereview.chromium.org/2083303002/diff/1/src/snapshot/deserializer.cc
File src/snapshot/deserializer.cc (right):

https://codereview.chromium.org/2083303002/diff/1/src/snapshot/deserializer.c...
src/snapshot/deserializer.cc:772: if (write_barrier_needed &&
isolate->heap()->InNewSpace(hot_object)) {
I don't understand this change.

(This looks perfectly sensible, but I just don't get why this is needed and how
it relates to the other parts of this CL.)

https://codereview.chromium.org/2083303002/diff/1/src/snapshot/serializer-com...
File src/snapshot/serializer-common.h (right):

https://codereview.chromium.org/2083303002/diff/1/src/snapshot/serializer-com...
src/snapshot/serializer-common.h:207: // 0xf0..0xff unused.
Just so I understand this... The whole point is to get these 16 continuous
values unused; presumably with an upcoming change that will use this block?

[Yang, 2016-06-22 09:43:02]

https://codereview.chromium.org/2083303002/diff/1/src/snapshot/deserializer.cc
File src/snapshot/deserializer.cc (right):

https://codereview.chromium.org/2083303002/diff/1/src/snapshot/deserializer.c...
src/snapshot/deserializer.cc:772: if (write_barrier_needed &&
isolate->heap()->InNewSpace(hot_object)) {
On 2016/06/22 09:22:31, vogelheim wrote:
> I don't understand this change.
> 
> (This looks perfectly sensible, but I just don't get why this is needed and
how
> it relates to the other parts of this CL.)

This is just a drive-by fix to adapt this to what we have in other places.

https://codereview.chromium.org/2083303002/diff/1/src/snapshot/serializer-com...
File src/snapshot/serializer-common.h (right):

https://codereview.chromium.org/2083303002/diff/1/src/snapshot/serializer-com...
src/snapshot/serializer-common.h:207: // 0xf0..0xff unused.
On 2016/06/22 09:22:31, vogelheim wrote:
> Just so I understand this... The whole point is to get these 16 continuous
> values unused; presumably with an upcoming change that will use this block?

Yes. I have some ideas I want to play around with. There is also this fairly
large block of 0x7f..0x7f.

[Yang, 2016-06-22 09:43:05]

The CQ bit was checked by yangguo@chromium.org

[commit-bot: I haz the power, 2016-06-22 09:43:09]

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

[commit-bot: I haz the power, 2016-06-22 10:12:23]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-22 10:14:50]

Description was changed from

==========
[serializer] reorder some bytecodes to free up large blocks.

R=vogelheim@chromium.org
==========

to

==========
[serializer] reorder some bytecodes to free up large blocks.

R=vogelheim@chromium.org

Committed: https://crrev.com/03996851f4d736bd12f57a7a5fb241b375fa2995
Cr-Commit-Position: refs/heads/master@{#37178}
==========

[commit-bot: I haz the power, 2016-06-22 10:14:51]

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