Skip to content

V
V8
Switch branch/tag
  1. 21 Nov, 2019 1 commit
  3. 20 Nov, 2019 1 commit
  5. 19 Nov, 2019 1 commit
  7. 15 Nov, 2019 1 commit
  9. 14 Nov, 2019 1 commit
  11. 08 Nov, 2019 1 commit
    • Clemens Backes's avatar
      [utils] Move {WhichPowerOf2} to base::bits · fa056cd0
      Clemens Backes authored 
      {WhichPowerOf2} is basically the same as {CountTrailingZeros}, with a
restriction to powers of two. Since it does not use or depend on any v8
internals, it can be moved to src/base/bits.h.
This CL also changes the implementation to use the CTZ builtin if
available, and falls back to popcnt otherwise.

Drive-by: Make it constexpr, and rename to {WhichPowerOfTwo}.

R=sigurds@chromium.org

Bug: v8:9810, v8:8912
Change-Id: I8368d098f9ab1247f3b9f036f1385a38de10cc6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903966Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64851}
      fa056cd0
  13. 24 Oct, 2019 1 commit
  15. 23 Oct, 2019 1 commit
  17. 22 Oct, 2019 3 commits
  19. 21 Oct, 2019 3 commits
    • Jakob Gruber's avatar
      [regexp] Apply the backtrack limit in jitted code · 0089006f
      Jakob Gruber authored 
      .. similar to how it is applied in the interpreter. We reserve a stack
slot for the backtrack count, increment it on each backtrack, and fail
if the limit is hit.

Bug: v8:9695
Change-Id: I835888c612d6c8bfa2f34e73ab8c8241dcabc6ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864938Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64426}
      0089006f
    • Jakob Gruber's avatar
      [regexp] Add a backtracking limit in the interpreter · 48756fcf
      Jakob Gruber authored 
      V8 uses a backtracking regexp engine, which has the caveat that some
regexp patterns can have exponential runtime behavior when excessive
backtracking is involved.

Especially when regexp patterns are user-controlled, it would be useful
to be able to set an upper limit for a single regexp execution. This CL
takes an initial step in that direction by adding a backtracking limit
(intended to approximate execution time):

- The limit is stored in the JSRegExp's data array.
- A limit can currently only be set through the %NewRegExpWithLimit
runtime function.
- The limit is applied during interpreter execution. When exceeded, the
interpreter stops execution and returns FAILURE (even if continued
execution would at some later point have resulted in SUCCESS).

In follow-up CLs, this mechanism will be extended to work in jitted
regexp code, and exposed through the V8 API.

Bug: v8:9695
Change-Id: Iadb5c100052f4a63b26f1ec49cf97c6713a66b9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864934
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64417}
      48756fcf
    • Jakob Gruber's avatar
      Reland "[regexp] Guarantee an allocated regexp stack" · 8f58c84e
      Jakob Gruber authored 
      This is a reland of 97ed8b27

Original change's description:
> [regexp] Guarantee an allocated regexp stack
> 
> The regexp stack is used during execution of jitted regexp matcher
> code.  Previously, the stack was initially not present / nullptr, and
> we had to explicitly check for this condition and bail out in builtin
> code.
> 
> This CL changes behavior to guarantee a present stack by adding a
> statically-allocated area that is used whenever no
> dynamically-allocated stack exists.
> 
> Change-Id: I52934425ae72cf0e5d13fab2b9d63d37ca76fcf3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852126
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64326}

Change-Id: If345c09bdbfc8dc6b63f016c3f10ffda811bbb6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866771
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64401}
      8f58c84e
  21. 17 Oct, 2019 2 commits
  23. 16 Oct, 2019 2 commits
  25. 11 Oct, 2019 1 commit
  27. 10 Oct, 2019 1 commit
  29. 09 Oct, 2019 1 commit
  31. 08 Oct, 2019 1 commit
  33. 07 Oct, 2019 1 commit
  35. 01 Oct, 2019 2 commits
    • Jakob Gruber's avatar
      Reland "[regexp] Bytecode peephole optimization" · 282a74c7
      Jakob Gruber authored 
      This is a reland of 66129430

Fixed: Unaligned reads, unspecified evaluation order.

Original change's description:
> [regexp] Bytecode peephole optimization
>
> Bytecodes used by the regular expression interpreter often occur in
> specific sequences. The number of dispatches in the interpreter can be
> reduced if those sequences are combined into a single bytecode.
>
> This CL adds a peephole optimization pass for regexp bytecodes.
> This pass checks the generated bytecode for pre-defined sequences that
> can be merged into a single bytecode.
>
> With the currently implemented bytecode sequences a speedup of 1.12x on
> regex-dna and octane-regexp is achieved.
>
> Bug: v8:9330
> Change-Id: I827f93273a5848e5963c7e3329daeb898995d151
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743
> Commit-Queue: Patrick Thier <pthier@google.com>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63992}

Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gcc_rel
Bug: v8:9330,chromium:1008502,chromium:1008631
Change-Id: Ib9fc395b6809aa1debdb54d9fba5b7f09a235e5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1828917Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64064}
      282a74c7
    • Ana Peško's avatar
      Reland "[regexp] Eagerly tier-up for very long strings" · 14ffd21d
      Ana Peško authored 
      This is a reland of cfb60d43

Original change's description:
> [regexp] Eagerly tier-up for very long strings
> 
> For very long subject strings, the regexp interpreter is currently much slower
> than the native machine code execution. This CL implements eager tier-up to the
> compiler to avoid the performance penalty for subject strings of length greater
> than 1000.
> 
> Change-Id: I244ccbd60255e0f3bedc493b1cc3d25cdd42133e
> Bug: v8:9566
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1829273
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Ana Pesko <anapesko@google.com>
> Cr-Commit-Position: refs/heads/master@{#64046}

Bug: v8:9566
Change-Id: I81a10728c64ce3b35258c31eb8178e458d3de205
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1832167Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#64063}
      14ffd21d
  37. 30 Sep, 2019 3 commits
  39. 27 Sep, 2019 2 commits
  41. 26 Sep, 2019 2 commits
    • Clemens Backes [né Hammacher]'s avatar
      Revert "[regexp] Bytecode peephole optimization" · 05eda1ac
      Clemens Backes [né Hammacher] authored 
      This reverts commit 66129430.

Reason for revert: Fails on gcc: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/3394

Original change's description:
> [regexp] Bytecode peephole optimization
> 
> Bytecodes used by the regular expression interpreter often occur in
> specific sequences. The number of dispatches in the interpreter can be
> reduced if those sequences are combined into a single bytecode.
> 
> This CL adds a peephole optimization pass for regexp bytecodes.
> This pass checks the generated bytecode for pre-defined sequences that
> can be merged into a single bytecode.
> 
> With the currently implemented bytecode sequences a speedup of 1.12x on
> regex-dna and octane-regexp is achieved.
> 
> Bug: v8:9330
> Change-Id: I827f93273a5848e5963c7e3329daeb898995d151
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743
> Commit-Queue: Patrick Thier <pthier@google.com>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63992}

TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com

Change-Id: Ie526fe3691f6abdd16b51979000fdafb7afce8ef
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9330
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826727Reviewed-by: 's avatarClemens Backes [né Hammacher] <clemensb@chromium.org>
Commit-Queue: Clemens Backes [né Hammacher] <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63998}
      05eda1ac
    • Patrick Thier's avatar
      [regexp] Bytecode peephole optimization · 66129430
      Patrick Thier authored 
      Bytecodes used by the regular expression interpreter often occur in
specific sequences. The number of dispatches in the interpreter can be
reduced if those sequences are combined into a single bytecode.

This CL adds a peephole optimization pass for regexp bytecodes.
This pass checks the generated bytecode for pre-defined sequences that
can be merged into a single bytecode.

With the currently implemented bytecode sequences a speedup of 1.12x on
regex-dna and octane-regexp is achieved.

Bug: v8:9330
Change-Id: I827f93273a5848e5963c7e3329daeb898995d151
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63992}
      66129430
  43. 25 Sep, 2019 1 commit
  45. 24 Sep, 2019 2 commits
  47. 19 Sep, 2019 1 commit
    • Jakob Gruber's avatar
      [build] Define V8_TARGET_OS_ and consider it in x64 codegen · 99d31b43
      Jakob Gruber authored 
      This CL allows us to distinguish between the host- and target OS. The
host OS is defined by V8_OS_ macros (e.g. V8_OS_WIN). The target OS is
defined by V8_TARGET_OS_ macros (e.g. V8_TARGET_OS_WIN).

V8_TARGET_OS_ macros are defined by gn, based on the `target_os` gn
variable. If a V8_TARGET_OS_ is set, we also define V8_HAVE_TARGET_OS
(this determines fall-back behavior in V8; if it is not defined, we set
V8_TARGET_OS_ to equal the equivalent V8_OS_ define).

Besides adding the defines, this CL also adds logic to consider the
target OS in codegen. Specifically, x64 builds now look at the
V8_TARGET_OS_WIN define instead of V8_OS_WIN or _WIN64. This
effectively makes cross-compilation to x64 Windows in mksnapshot
possible.

In future work, we could add similar support for cross-compiling to
other platforms such as ia32 Windows.

Bug: v8:9736,chromium:803591
Change-Id: I689f3de8c206b743c4bef703f5ade0bba32ce995
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809374Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63892}
      99d31b43
  49. 16 Sep, 2019 1 commit
  51. 13 Sep, 2019 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [regexp] Consolidate calls to jitted irregexp and regexp interpreter · 2afe87cd
      Milad Farazmand authored 
      Port 213504b9

Original Commit Message:

    The code fields in a JSRegExp object now either contain irregexp
    compiled code or a trampoline to the interpreter. This way the code
    can be executed without explicitly checking if the regexp shall be
    interpreted or executed natively.
    In case of interpreted regexp the generated bytecode is now stored in
    its own fields instead of the code fields for Latin1 and UC16
    respectively.
    The signatures of the jitted irregexp match and the regexp interpreter
    have been equalized.

R=pthier@google.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: Ia2a80ce927afa644441c0749add0fc35111eb720
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803657Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63773}
      2afe87cd
  53. 12 Sep, 2019 1 commit
    • Patrick Thier's avatar
      [regexp] Secure interpreter dispatch. · 67a70d7e
      Patrick Thier authored 
      Currently the dispatch table could be accessed out of bounds if something
is wrong with the generated bytecode.
OOB access of the dispatch table can lead to jumps to arbitrary addresses
in the code space.

This CL prevents this issue by changing the following:
BYTECODE_MASK now filters out all bits not currently used for bytecodes.
All unused slots between the last actually defined bytecode and
BYTECODE_MASK are now filled with BREAK Bytecodes (invalid operation).
This way we can not access out of bounds of the dispatch table if
something is broken/tampered with, preventing jumps to arbitrary code.

Bug: v8:9699
Change-Id: Ibce591ae94b52472ba74a9fd0666e55185af7b2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795349
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63708}
      67a70d7e
  55. 09 Sep, 2019 1 commit