Skip to content

V
V8
Switch branch/tag
  1. 02 Nov, 2017 5 commits
    • Andreas Haas's avatar
      [wasm] Improve stack check in the interpreter · 793c52ed
      Andreas Haas authored 
      The existing stack check only checked the number of stack frames on the
stack, not the actual size of the stack frames. In the test case, each
stack frame is huge, and the interpreter runs out of memory before the
stack check stops the execution. With this change we take the size of
the value stack and the size of the control stack and compare their sum
to the stack limit of V8. Note that this stack limit is kind of
arbitrary, because the stack space of the interpreter is not on the
actual runtime stack but allocated in zone memory, and the stack check
exists to simulate stack overflows in compiled code, not to prevent
actual stack overflows.

R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-778917

Bug: chromium:778917
Change-Id: Ife47631fcb1a178a68facab1e42c0069b12c0155
Reviewed-on: https://chromium-review.googlesource.com/744003
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49071}
      793c52ed
    • Benedikt Meurer's avatar
      Disable --string-slices. · fd5b067f
      Benedikt Meurer authored 
      This is an experiment to quantify the impact of SlicedStrings on both
performance and memory usage. The intention is to get Canary coverage
for the experiment and then decide how to proceed.

Bug: v8:7025
Change-Id: Ied548cd9e2fab127c1ad2aea3e60b2615d3de663
Reviewed-on: https://chromium-review.googlesource.com/750082
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49070}
      fd5b067f
    • Yang Guo's avatar
      Perform stack check on Proxy call trap. · 1e77461d
      Yang Guo authored 
      Proxy's call trap can be used to cause recursion.

R=bmeurer@chromium.org, tebbi@chromium.org

Bug: chromium:779344
Change-Id: I19c989f618f7230028ebe18c3415bc3f4bd72b93
Reviewed-on: https://chromium-review.googlesource.com/743782Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49069}
      1e77461d
    • Benedikt Meurer's avatar
      Reintroduce compile-time --string-slices flag. · 781f7685
      Benedikt Meurer authored 
      This partially reverts commit aaebbbaa,
which removed the --string-slices flag. We reintroduce the flag as a
build time flag for an experiment to gather information of how much
SliceStrings help with throughput and effective memory use.

Bug: v8:7025
Change-Id: I529da91bb7501fe93d83891abf560710f3ecb9d0
Reviewed-on: https://chromium-review.googlesource.com/750681Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49068}
      781f7685
    • Benedikt Meurer's avatar
      [builtins] Support two byte strings in StringEqual builtin. · f597eec1
      Benedikt Meurer authored 
      This CL adds support for two byte string comparisons to the StringEqual
builtin, which so far was bailing out to the generic %StringEqual
runtime function whenever any two-byte string was involved. This made
comparisons that involved two-byte strings, either comparing them to
one-byte strings or comparing two two-byte strings, up to 3x slower than
if only one-byte strings were involved.

With this change, all direct string (SeqString or ExternalString)
equality checks are roughly on par now, and the weird performance cliff
is gone. On the micro-benchmark from the bug we go from

  stringEqualBothOneByteSeqString: 162 ms.
  stringEqualTwoByteAndOneByteSeqString: 446 ms.
  stringEqualOneByteAndTwoByteSeqString: 438 ms.
  stringEqualBothTwoByteSeqString: 472 ms.

to

  stringEqualBothOneByteSeqString: 151 ms.
  stringEqualTwoByteAndOneByteSeqString: 158 ms.
  stringEqualOneByteAndTwoByteSeqString: 166 ms.
  stringEqualBothTwoByteSeqString: 160 ms.

which is the desired result. On the esprima test of the
web-tooling-benchmark we seem to improve by 1-2%, which corresponds to
the savings of going to the runtime for many StringEqual comparisons.

Drive-by-cleanup: Introduce LoadAndUntagStringLength helper into the CSA
with proper typing to avoid the unnecessary shifts on 64-bit platforms
when keeping the length tagged initially in StringEqual.

Bug: v8:4913, v8:6365, v8:6371, v8:6936, v8:7022
Change-Id: I566f4b80e217513775ffbd35e0480154abf59b27
Reviewed-on: https://chromium-review.googlesource.com/749223Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49067}
      f597eec1
  3. 01 Nov, 2017 5 commits
  5. 31 Oct, 2017 18 commits
  7. 30 Oct, 2017 12 commits