Fix rare access violation during JS heap serialization.

Fix rare access violation during JS heap serialization.

R=yangguo@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=23488

[Slava Chigrin, 2014-08-27 17:03:15]

vchigrin@yandex-team.ru changed reviewers:
+ yangguo@chromium.org

[Slava Chigrin, 2014-08-27 17:06:01]

https://codereview.chromium.org/510013002/diff/1/src/serialize.cc
File src/serialize.cc (right):

https://codereview.chromium.org/510013002/diff/1/src/serialize.cc#newcode1545
src/serialize.cc:1545: }
Before that sometimes current[repeat_count] can go beyound |end| pointer and
cause access violation if current object placed at the end of page.

[Yang, 2014-08-28 11:31:02]

On 2014/08/27 17:06:01, Slava Chigrin wrote:
> https://codereview.chromium.org/510013002/diff/1/src/serialize.cc
> File src/serialize.cc (right):
> 
> https://codereview.chromium.org/510013002/diff/1/src/serialize.cc#newcode1545
> src/serialize.cc:1545: }
> Before that sometimes current[repeat_count] can go beyound |end| pointer and
> cause access violation if current object placed at the end of page.

lgtm.

[Yang, 2014-08-28 11:45:29]

Committed patchset #1 (id:1) manually as 23488 (presubmit successful).

[Slava Chigrin, 2014-08-28 11:54:03]

On 2014/08/28 11:45:29, Yang wrote:
> Committed patchset #1 (id:1) manually as 23488 (presubmit successful).

Thank you so much for help! I have one little question about serializer: why it
have so big macro CASE_BODY in  Deserializer::ReadChunk? May be using inline
templatized function instead of it can improve readability and have better stack
space usage (due to local variables re-using). It may be important since that
function called recursively, so it may not work well on large heaps...

[Yang, 2014-08-28 11:57:29]

On 2014/08/28 11:54:03, Slava Chigrin wrote:
> On 2014/08/28 11:45:29, Yang wrote:
> > Committed patchset #1 (id:1) manually as 23488 (presubmit successful).
> 
> Thank you so much for help! I have one little question about serializer: why
it
> have so big macro CASE_BODY in  Deserializer::ReadChunk? May be using inline
> templatized function instead of it can improve readability and have better
stack
> space usage (due to local variables re-using). It may be important since that
> function called recursively, so it may not work well on large heaps...

Not sure. If I'm not mistaken, it was an effort to improve performance. I think
the compiler should eliminate the unnecessary if-blocks as dead code, so it
probably doesn't make too much of a difference?