Skip to content

V
V8
Switch branch/tag
  1. 27 Oct, 2020 1 commit
  3. 09 Jun, 2020 1 commit
    • Clemens Backes's avatar
      [utils] Add OwnedVector::NewForOverwrite · ff2e485f
      Clemens Backes authored 
      The existing {OwnedVector::New} value-initializes all elements, which
means zeroing them in case on integral types. In many cases though we
know that we will overwrite the content anyway, so the initialization is
redundant.
In the case of assembly buffers for wasm compilation, this zeroing
showed up with several percent of execution times for some benchmarks.

Hence this CL introduces a new {OwnedVector::NewForOverwrite} (along the
lines of {std::make_unique_for_overwrite}), which only
default-initializes the values (meaning no initialization for integral
values).

R=thibaudm@chromium.org

Bug: v8:10576
Change-Id: I8d2806088acebe8a264dea2c7ed74b0423671d4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237140
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68268}
      ff2e485f
  5. 22 Apr, 2020 1 commit
    • Jakob Gruber's avatar
      Reland "[snapshot] Extract more files" · d587f67a
      Jakob Gruber authored 
      This is a reland of 5c4b8056

Original change's description:
> [snapshot] Extract more files
>
> This moves:
>
> - ExternalReferenceEncoder to codegen/external-reference-encoder.h
> - SerializerDeserializer to snapshot/serializer-deserializer.h
> - Checksum() to snapshot/snapshot-utils.h
>
> serializer-common.h and .cc are removed.
>
> Tbr: clemensb@chromium.org,ulan@chromium.org
> Bug: v8:10416
> Change-Id: I36a242dcc1ad8833374aa567f73e0d4a75632c58
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144118
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67281}

Tbr: delphick@chromium.org,clemensb@chromium.org,ulan@chromium.org
Bug: v8:10416
Change-Id: I6f6a1017435db185778ed931e1ddb13d8d5e920e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157384Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67298}
      d587f67a
  7. 21 Apr, 2020 2 commits
  9. 06 Feb, 2020 1 commit
  11. 13 Jan, 2020 1 commit
    • Pierre Langlois's avatar
      [arm64][builtins] Allow simulator instructions in builtins. · d0650ae1
      Pierre Langlois authored 
      Simulator-specific instructions are very useful, we can:

  - Place breakpoints that enable the simulator's interactive debugger, allowing
    us to see registers, the stack and print JS objects.

  - Enable and disable simulator tracing dynamically.

  - Call printf() directly, as the simulator cannot easily support its calling
    convention.

However these tools are not available when generating builtins. The reason is
that when cross-compiling, builtins are generated for real hardware but may
still run inside the simulator on the host if we have a custom snapshot. Using
the `v8_embed_script` GN option will do that for example but embedders may also
do this with the V8 API.

mksnapshot cannot tell the difference between generating code for a simulator
build and a cross-build. If we change this, we can allow us to use
simulator-specific features in builtins in simulator builds.

So in this patch we:

  - Introduce a --target_is_simulator mksnapshot flag to drive the
    enable_simulator_code Assembler option.

  - Make sure the assembler respect the option instead of the USE_SIMULATOR
    macro.


Change-Id: I7a7249f514427c1a2518a1af3679679596a72c7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991497Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#65734}
      d0650ae1
  13. 07 Jan, 2020 1 commit
  15. 14 Nov, 2019 1 commit
  17. 04 Nov, 2019 1 commit
    • Dan Elphick's avatar
      Reland "Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE" · 352bbb12
      Dan Elphick authored 
      This is a reland of 855591a5

Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.

Original change's description:
> Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
>
> [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Creates an allow-list of builtins that can still go in code_space
> including all TFJ builtins and a small manual list that should be pared
> down in the future.
>
> For builtins that go in RO_SPACE a Code object is created that contains an
> immediate trap instruction. Generally these Code objects are still no
> smaller than CODE_SPACE Code objects because of the Code object alignment
> requirements. This will hopefully be addressed in a follow-up CL either by
> relaxing them or removing the instruction stream completely.
>
> In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
> increases by the same amount.
>
> Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64700}

Change-Id: I4eeb7dab3027b42fa58c5dfb2bad9873e9fff250
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893192
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64728}
      352bbb12
  19. 31 Oct, 2019 2 commits
  21. 18 Oct, 2019 2 commits
    • Sathya Gunasekaran's avatar
      Revert "[builtins] Move non-JS linkage builtins code objects into RO_SPACE" · f1ebde88
      Sathya Gunasekaran authored 
      This reverts commit 83f8464f.

Reason for revert: speculative revert for blink linux failure
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/1272

Original change's description:
> [builtins] Move non-JS linkage builtins code objects into RO_SPACE
> 
> Creates an allow-list of builtins that can still go in code_space
> including all TFJ builtins and a small manual list that should be pared
> down in the future.
> 
> For builtins that go in RO_SPACE a Code object is created that contains
> no code at all (shrinking its size from 96 bytes to 64 bytes on x64),
> but is there to allow the runtime to continue to work since it expects
> a Code object.
> 
> This reduces code_space from ~152k to ~40k (-112k) and increases
> read_only_space from 33k to 108k (+75k) in the snapshot.
> 
> Bug: v8:7464, v8:9821, v8:9338, v8:8127
> Change-Id: Icc8bfc722bb267a2bcc17e2f1e27bef7f02f2376
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795358
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64377}

TBR=mstarzinger@chromium.org,jgruber@chromium.org,delphick@chromium.org

Change-Id: I4cf38e9370280acdd2de718ca527776ebc509003
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7464, v8:9821, v8:9338, v8:8127
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868621Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64383}
      f1ebde88
    • Dan Elphick's avatar
      [builtins] Move non-JS linkage builtins code objects into RO_SPACE · 83f8464f
      Dan Elphick authored 
      Creates an allow-list of builtins that can still go in code_space
including all TFJ builtins and a small manual list that should be pared
down in the future.

For builtins that go in RO_SPACE a Code object is created that contains
no code at all (shrinking its size from 96 bytes to 64 bytes on x64),
but is there to allow the runtime to continue to work since it expects
a Code object.

This reduces code_space from ~152k to ~40k (-112k) and increases
read_only_space from 33k to 108k (+75k) in the snapshot.

Bug: v8:7464, v8:9821, v8:9338, v8:8127
Change-Id: Icc8bfc722bb267a2bcc17e2f1e27bef7f02f2376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795358
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64377}
      83f8464f
  23. 10 Sep, 2019 1 commit
  25. 23 Jun, 2019 1 commit
  27. 17 Jun, 2019 1 commit
  29. 13 Jun, 2019 1 commit
    • Sigurd Schneider's avatar
      [arm64] Fix handling of handles in assembler · 66412e0f
      Sigurd Schneider authored 
      Previously, the handle's location was used as a proxy for the heap
object, i.e, we put the handle into the constant pool, to avoid the
need for GC visiting the constant pool entries during code generation.
The handle locations are replaced by the corresponding heap object
when the code is copied to the heap.

This CL changes the handling in the assembler: Instead of putting
in the handle location (which is a machine word) we put in a small
index number into a table. This will be useful for putting 32bit
constants into the constant pool.

This new approach also has the advantage that ordering the
constant pool entries by value produces a deterministic order
after this change.

Change-Id: Id47d56d487a0b64d1d1504a47937c8779ee02b13
Bug: v8:7703
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648094
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62144}
      66412e0f
  31. 27 May, 2019 2 commits
  33. 23 May, 2019 1 commit
  35. 22 May, 2019 1 commit
  37. 21 May, 2019 1 commit
  39. 20 May, 2019 4 commits
  41. 17 May, 2019 2 commits
  43. 30 Apr, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[ptr-compr] New RelocInfo for compressed pointers." · ed319e84
      Mike Stanton authored 
      Failure addressed by not exposing the new test to the jitless environment.
(jgruber@ on TBR).

New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support
compressed pointers in generated code. Enum name EMBEDDED_OBJECT
changed to FULL_EMBEDDED_OBJECT.

RelocInfo::[set_]target_object() abstract away the difference between
FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT.

Compressed embedded objects can only be created at this time on
x64 with pointer compression turned on. Arm64 constant pools don't
support compressed objects at this time.

NOPRESUBMIT=true

Bug: v8:7703
TBR: jgruber@chromium.org
Change-Id: Ifff53b041bab09b4b8c3e16085e5df4aa2b99f4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588461Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61104}
      ed319e84
  45. 29 Apr, 2019 2 commits
  47. 11 Apr, 2019 1 commit
  49. 25 Feb, 2019 1 commit
  51. 15 Feb, 2019 1 commit
  53. 07 Feb, 2019 1 commit
  55. 30 Jan, 2019 2 commits
  57. 16 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [assembler] Allow to pass custom buffer implementations · 1a3aab51
      Clemens Hammacher authored 
      When generating an Assembler, you currently have two choices: Either
let the Assembler allocate a growable internal buffer, which is owned
by the Assembler. Or provide an externally allocated buffer, which
cannot grow.
This CL changes this interface to allow providing any implementation of
a buffer. The provided buffer can be a view to an externally owned
buffer, which still can grow.
This will be used to split WebAssembly compilation and code submission.
The buffer needs to be able to grow, but cannot be owned by the
Assembler because it has to survive until the code is submitted.

R=mstarzinger@chromium.org

Bug: v8:8689
Change-Id: Ib6c5ebffc8b71d0778944abac34f02c5cc7dbd79
Reviewed-on: https://chromium-review.googlesource.com/c/1411347
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58848}
      1a3aab51
  59. 24 Dec, 2018 1 commit