Make TemplateLiteral hashing algorithm more memory efficient

Make TemplateLiteral hashing algorithm more memory efficient

Previously, a separate string to be hashed (in order to help determine the need to
use a cached Template Call Site) was built up by joining UTF8 spans within a template.

Now, the hash key is generated from the original spans, removing the need to allocate a new
buffer and copy bytes into it.

BUG=

[caitp (gmail), 2014-11-27 00:31:03]

caitpotter88@gmail.com changed reviewers:
+ arv@chromium.org, dslomov@chromium.org, rossberg@chromium.org

[caitp (gmail), 2014-11-27 00:31:03]

PTAL --- as suggested in crrev.com/745233002, it changes the hashing strategy to
build rolling hashes from each string component.

Tests pass on debug, so I think this should be a pretty trivial refactoring (but
it does mean adding 2 static helpers to StringHasher).

[Dmitry Lomov (no reviews), 2014-11-27 07:23:05]

very nice. lgtm % style nits

https://codereview.chromium.org/765473006/diff/1/src/objects-inl.h
File src/objects-inl.h (right):

https://codereview.chromium.org/765473006/diff/1/src/objects-inl.h#newcode6727
src/objects-inl.h:6727: DCHECK(chars && length > 0);
Style nit: chars != nullptr.

Why 'length > 0', not 'length >= 0'?

https://codereview.chromium.org/765473006/diff/1/src/objects-inl.h#newcode6738
src/objects-inl.h:6738: DCHECK(chars && length > 0);
Ditto

[Dmitry Lomov (no reviews), 2014-11-27 07:49:58]

https://codereview.chromium.org/765473006/diff/1/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/765473006/diff/1/src/parser.cc#newcode5350
src/parser.cc:5350: *hash = running_hash;
Note that the actual hash value you get here is different from the hash of the
string computed by ComputeUtf8Hash, but that is ok since this hash is used
consistently in templates.

Probably add a comment explaining this.

[caitp (gmail), 2014-11-27 14:44:49]

https://codereview.chromium.org/765473006/diff/1/src/objects-inl.h
File src/objects-inl.h (right):

https://codereview.chromium.org/765473006/diff/1/src/objects-inl.h#newcode6727
src/objects-inl.h:6727: DCHECK(chars && length > 0);
On 2014/11/27 07:23:05, Dmitry Lomov (chromium) wrote:
> Style nit: chars != nullptr.
> 
> Why 'length > 0', not 'length >= 0'?

Well there's no harm in it being an empty loop, but that path wouldn't be taken
as WriteUtf16() asserts that length > 0, I thought it would be good to keep the
assertions similar.

Done

https://codereview.chromium.org/765473006/diff/1/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/765473006/diff/1/src/parser.cc#newcode5350
src/parser.cc:5350: *hash = running_hash;
On 2014/11/27 07:49:58, Dmitry Lomov (chromium) wrote:
> Note that the actual hash value you get here is different from the hash of the
> string computed by ComputeUtf8Hash, but that is ok since this hash is used
> consistently in templates.
> 
> Probably add a comment explaining this.

Done

[Dmitry Lomov (no reviews), 2014-11-27 15:19:18]

lgtm

[Dmitry Lomov (no reviews), 2014-11-27 15:19:21]

The CQ bit was checked by dslomov@chromium.org

[commit-bot: I haz the power, 2014-11-27 15:19:55]

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

[commit-bot: I haz the power, 2014-11-27 15:47:47]

Committed patchset #2 (id:20001)

[arv (Not doing code reviews), 2014-12-01 15:27:02]

LGTM

Thanks. My earlier comment was not only about memory usage. I feel like the
usage of UTF8 and UTF16 is suspicious. I'll file a new bug.