Skip to content

V
V8
Switch branch/tag
  1. 13 Aug, 2018 2 commits
  3. 09 Aug, 2018 2 commits
  5. 08 Aug, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: Reland "[turboassembler] Introduce hard-abort mode" · a27871d5
      Junliang Yan authored 
      Port d324382e

and

Port bd3f0a68

Original Commit Message:

    This is a reland of a462a785

    Original change's description:
    > [turboassembler] Introduce hard-abort mode
    >
    > For checks and assertions (mostly for debug code, like stack alignment
    > or zero extension), we had two modes: Emit a call to the {Abort}
    > runtime function (the default), and emit a debug break (used for
    > testing, enabled via --trap-on-abort).
    > In wasm, where we cannot just call a runtime function because code must
    > be isolate independent, we always used the trap-on-abort behaviour.
    > This causes problems for our fuzzers, which do not catch SIGTRAP, and
    > hence do not detect debug code failures.
    >
    > This CL introduces a third mode ("hard abort"), which calls a C
    > function via {ExternalReference}. The C function still outputs the
    > abort reason, but does not print the stack trace. It then aborts via
    > "OS::Abort", just like the runtime function.
    > This will allow fuzzers to detect the crash and even find a nice error
    > message.
    >
    > Even though this looks like a lot of code churn, it is actually not.
    > Most added lines are new tests, and other changes are minimal.
    >
    > R=mstarzinger@chromium.org
    >
    > Bug: chromium:863799
    > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
    > Reviewed-on: https://chromium-review.googlesource.com/1142163
    > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#54592}

R=clemensh@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I60023470fa07576fd313f628ade06e279d5f4927
Reviewed-on: https://chromium-review.googlesource.com/1165822
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54980}
      a27871d5
  7. 07 Aug, 2018 2 commits
    • Michael Starzinger's avatar
      [wasm] Support concurrent patching of jump table. · 7579b1e3
      Michael Starzinger authored 
      This adds initial support for concurrently patching jump table slots. It
is needed once different Isolates share code (for the --wasm-shared-code
feature). We need to ensure that instructions holding the target address
within a jump table slot do not cross cache-line boundaries. To do this,
the jump table has been split into consecutive pages.

Note that this also adds a stress test for multiple threads hammering at
a single slot concurrently. The test is currently limited to the ia32
and the x64 architecture, but will be extended to cover others. The test
reliably triggers tearing of the target address on almost every run of
the test and hence serves to prevent regressions.

R=clemensh@chromium.org
TEST=cctest/test-jump-table-assembler
BUG=v8:8018

Change-Id: Ife56bbb61ffcae5d8906ca7b8c604b195603707c
Reviewed-on: https://chromium-review.googlesource.com/1163664
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54942}
      7579b1e3
    • Ivica Bogosavljevic's avatar
      MIPS: Disable Word32SarWithWord32Shl on MIPSr1 · 65624c9e
      Ivica Bogosavljevic authored 
      MIPSr1 doesn't support SEB and SEH instructions and this
causes test InstructionSelectorTest.Word32SarWithWord32Shl to fail.

This CL disables this test on MIPSr1.

TEST=unittests/InstructionSelectorTest.Word32SarWithWord32Shl

Change-Id: I284a85210bd0d38374ca339671643560e8a305e2
Reviewed-on: https://chromium-review.googlesource.com/1164363Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#54939}
      65624c9e
  9. 02 Aug, 2018 3 commits
  11. 01 Aug, 2018 4 commits
  13. 31 Jul, 2018 2 commits
  15. 26 Jul, 2018 5 commits
  17. 24 Jul, 2018 6 commits
  19. 23 Jul, 2018 3 commits
  21. 20 Jul, 2018 5 commits
    • Sigurd Schneider's avatar
      Speculatively revert "[turboassembler] Introduce hard-abort mode" · 039c18e1
      Sigurd Schneider authored 
      This reverts commit a462a785.

Reason for revert: Breaks a TurboAssembler test:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726

Original change's description:
> [turboassembler] Introduce hard-abort mode
> 
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
> 
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
> 
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}

TBR=mstarzinger@chromium.org,clemensh@chromium.org

Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:863799
Reviewed-on: https://chromium-review.googlesource.com/1145431
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54597}
      039c18e1
    • Caitlin Potter's avatar
      [runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases · b6f7ea58
      Caitlin Potter authored 
      As discussed in
https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#,

this CL introduces a new bytecode (CloneObject), and a new IC type.

In this prototype implementation, the type feedback looks like the
following:

Uninitialized case:
  { uninitialized_sentinel, uninitialized_sentinel }
Monomorphic case:
  { weak 'source' map, strong 'result' map }
Polymorphic case:
  { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value }
Megamorphic case:
  { megamorphic_sentinel, cleared_Value }

In the fast case, Object cloning is done by allocating an object with
the saved result map, and a shallow clone of the fast properties from
the source object, as well as cloned fast elements from the source object.
If at any point the fast case can't be taken, the IC transitions to the
slow case and remains there.

This prototype CL does not include any TurboFan optimization, and the
CloneObject operation is merely reduced to a stub call.

It may still be possible to get some further improvements by somehow
incorporating compile-time boilerplate elements into the cloned object,
or simplifying how the boilerplate elements are inserted into the
object.

In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/
by about 8x, with substantial improvements over the Babel and ObjectAssign scores.

R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org
BUG=v8:7611

Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e
Reviewed-on: https://chromium-review.googlesource.com/1127472
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54595}
      b6f7ea58
    • Clemens Hammacher's avatar
      [turboassembler] Introduce hard-abort mode · a462a785
      Clemens Hammacher authored 
      For checks and assertions (mostly for debug code, like stack alignment
or zero extension), we had two modes: Emit a call to the {Abort}
runtime function (the default), and emit a debug break (used for
testing, enabled via --trap-on-abort).
In wasm, where we cannot just call a runtime function because code must
be isolate independent, we always used the trap-on-abort behaviour.
This causes problems for our fuzzers, which do not catch SIGTRAP, and
hence do not detect debug code failures.

This CL introduces a third mode ("hard abort"), which calls a C
function via {ExternalReference}. The C function still outputs the
abort reason, but does not print the stack trace. It then aborts via
"OS::Abort", just like the runtime function.
This will allow fuzzers to detect the crash and even find a nice error
message.

Even though this looks like a lot of code churn, it is actually not.
Most added lines are new tests, and other changes are minimal.

R=mstarzinger@chromium.org

Bug: chromium:863799
Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
Reviewed-on: https://chromium-review.googlesource.com/1142163
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54592}
      a462a785
    • Michael Starzinger's avatar
      [wasm] Remove some dead module decoder entry points. · bced36d2
      Michael Starzinger authored 
      R=clemensh@chromium.org
BUG=v8:7754

Change-Id: Ia4c2fb2d87c8a5de96fa9f1f0621d21ae3eda611
Reviewed-on: https://chromium-review.googlesource.com/1145181Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54591}
      bced36d2
    • Marja Hölttä's avatar
      [iwyu] api.h iwyu · ff5cafd0
      Marja Hölttä authored 
      This reduces the build steps from touching api.h: 269 -> 156

BUG=v8:7754,v8:7490

Change-Id: I75abaeea4cc78027a47304ff9b9f6b12bdb2b75e
Reviewed-on: https://chromium-review.googlesource.com/1144929Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54583}
      ff5cafd0
  23. 19 Jul, 2018 1 commit
    • Leszek Swirski's avatar
      [sfi] Remove SFI function identifier field · c941f11a
      Leszek Swirski authored 
      Remove the function identifier field from SharedFunctionInfo. This field
would store one of a) the function's inferred name, b) the "builtin
function id", or c) debug info. We remove these in turn:

a) The function's inferred name is available on the ScopeInfo, so like
   the start/end position we read it off either the ScopeInfo (for
   compiled functions) or the UncompiledData (for uncompiled functions).

   As a side-effect, now both UncompiledData and its subclass,
   UncompiledDataWithPreparsedScope, contain a pointer field. To keep
   BodyDescriptors manageable, we introduce a SubclassBodyDescriptor
   which effectively appends two BodyDescriptors together.

b) The builtin function id is < 255, so we can steal a byte from
   expected no. of properies (also <255) and store these together.
   Eventually we want to get rid of this field and use the builtin ID,
   but this is pending JS builtin removal.

   As a side-effect, BuiltinFunctionId becomes an enum class (for better
   storage size guarantees).

c) The debug info can hang off anything (since it stores the field it
   replaces), so we can attach it to the script field instead.

This saves a word on compiled function (uncompiled functions
unfortunately still have to store it in UncompiledData).

Bug: chromium:818642
Change-Id: I8b4b3a070f0fe328aafcaeac58842d144d12d996
Reviewed-on: https://chromium-review.googlesource.com/1138328Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54543}
      c941f11a
  25. 17 Jul, 2018 1 commit
  27. 16 Jul, 2018 3 commits
    • Leszek Swirski's avatar
      [sfi] Remove SFI function literal id field (reland^2) · 5dee5ade
      Leszek Swirski authored 
      SharedFunctionInfos store their original function literal's id. This is
also their index in the Script's SFI list.

The function literal id is only needed for lazy compilation and live edit,
and access only has to be fast in the former. So, we can move the SFI
function literal id field to UncompiledData, and if patching with live
edit, or discarding compiled code, we can perform a slower linear search
through the Script's SFI list.

This is a reland of
 1) https://chromium-review.googlesource.com/1082480 and
 2) https://chromium-review.googlesource.com/1128854
the differences being:
 1) caching the literal id on UncompiledData rather than always linearly
    searching the SFI list, and removing the unused runtime-liveedit.cc
    file instead of fixing it to support this change.
 2) clearing padding on UncompiledData now that it has 3 int32 fields,
    making its end unaligned on x64.

TBR=yangguo@chromium.org,marja@chromium.org,ulan@chromium.org,cbruni@chromium.org

Bug: chromium:818642
Change-Id: I58dcb12a2a60a680f662568da428e01189c62638
Reviewed-on: https://chromium-review.googlesource.com/1138325Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54473}
      5dee5ade
    • Sigurd Schneider's avatar
      Revert "[sfi] Remove SFI function literal id field" · 58578584
      Sigurd Schneider authored 
      This reverts commit 1d4a1172.

Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/21989

Original change's description:
> [sfi] Remove SFI function literal id field
> 
> SharedFunctionInfos store their original function literal's id. This is
> also their index in the Script's SFI list.
> 
> The function literal id is only needed for lazy compilation and live edit,
> and access only has to be fast in the former. So, we can move the SFI
> function literal id field to UncompiledData, and if patching with live
> edit, or discarding compiled code, we can perform a slower linear search
> through the Script's SFI list.
> 
> This is a reland of
> https://chromium-review.googlesource.com/c/v8/v8/+/1082480
> but caching the literal id on UncompiledData rather than always linearly
> searching the SFI list. Also, removes the unused runtime-liveedit.cc file
> instead of fixing it to support this change.
> 
> Bug: chromium:818642
> Change-Id: I977bcca0dc72903ca476a7079d156cc8bbe88fde
> Reviewed-on: https://chromium-review.googlesource.com/1128854
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54464}

TBR=ulan@chromium.org,marja@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,cbruni@chromium.org,leszeks@chromium.org,verwaest@chromium.org

Change-Id: Icee5ee3ab7688b93e2963f91debed65a58164534
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:818642
Reviewed-on: https://chromium-review.googlesource.com/1138276Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54466}
      58578584
    • Leszek Swirski's avatar
      [sfi] Remove SFI function literal id field · 1d4a1172
      Leszek Swirski authored 
      SharedFunctionInfos store their original function literal's id. This is
also their index in the Script's SFI list.

The function literal id is only needed for lazy compilation and live edit,
and access only has to be fast in the former. So, we can move the SFI
function literal id field to UncompiledData, and if patching with live
edit, or discarding compiled code, we can perform a slower linear search
through the Script's SFI list.

This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/1082480
but caching the literal id on UncompiledData rather than always linearly
searching the SFI list. Also, removes the unused runtime-liveedit.cc file
instead of fixing it to support this change.

Bug: chromium:818642
Change-Id: I977bcca0dc72903ca476a7079d156cc8bbe88fde
Reviewed-on: https://chromium-review.googlesource.com/1128854Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54464}
      1d4a1172