Skip to content

V
V8
Switch branch/tag
  1. 30 Jan, 2020 1 commit
  3. 23 Jan, 2020 1 commit
  5. 25 Nov, 2019 1 commit
  7. 28 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Use generated instance types, part 1 · 91e6421c
      Seth Brenith authored 
      This change begins making use of the fact that Torque now knows about
the relationship between classes and instance types, to replace a few
repetitive lists:

- Instance type checkers (single and range), defined in
  src/objects/instance-type.h
- Verification dispatch in src/diagnostics/objects-debug.cc
- Printer dispatch in src/diagnostics/objects-printer.cc
- Postmortem object type detection in
  tools/debug_helper/get-object-properties.cc

Torque is updated to generate four macro lists for the instance types,
representing all of the classes separated in two dimensions: classes
that correspond to a single instance type versus those that have a
range, and classes that are fully defined in Torque (with fields and
methods inside '{}') versus those that are only declared. The latter
distinction is useful because fully-defined classes are guaranteed to
correspond to real C++ classes, whereas only-declared classes are not.

A few other changes were required to make the lists above work:

- Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
  and avoid conflicts with the new macro-generated IsFiller method. This
  is the part I'm most worried about: I think the new name is an
  improvement for clarity and consistency, but I could imagine someone
  typing IsFiller out of habit and introducing a bug. If we'd prefer to
  keep the name IsFiller, my other idea is to rename FreeSpace to
  VariableSizeFiller and Filler to FixedSizeFiller.
- Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
  expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
- Normalized the dispatched behavior for BigIntBase and HeapNumber.
- Added a few new object printers.

Bug: v8:7793
Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64597}
      91e6421c
  9. 22 Oct, 2019 2 commits
  11. 19 Sep, 2019 2 commits
    • Igor Sheludko's avatar
      Reland "[ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly" · dc1a93b8
      Igor Sheludko authored 
      This is a reland of 6f9b2bd4

We must load JSTypedArray::base_pointer in TurboFan as tagged value otherwise
this value may become stale pointer after GC.

Original change's description:
> [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly
>
> On-heap typed arrays contain HeapObject value in |base_pointer| field
> and an offset in |external_pointer| field. When pointer compression is
> enabled we want to combine decompression with the offset addition.
> In order to do that we add an isolate root to the external_pointer value
> and therefore the data pointer computation can is a simple addition of
> a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
> and an |external_pointer| value.
>
> Bug: v8:9706
> Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63874}

Bug: v8:9706, chromium:1005599
Cq-Include-Trybots: luci.chromium.try:gpu-fyi-try-win10-nvidia-rel-64
Change-Id: I7bbd2a439306cdd11f2bb0dab5863498624d9740
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813744Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63898}
      dc1a93b8
    • Clemens Hammacher's avatar
      Revert "[ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly" · 815df7d2
      Clemens Hammacher authored 
      This reverts commit 6f9b2bd4.

Reason for revert: Fails on nvidia bots, blocking LKGR: https://ci.chromium.org/p/v8/builders/ci/Win%20V8%20FYI%20Release%20(NVIDIA)/5005

Original change's description:
> [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly
> 
> On-heap typed arrays contain HeapObject value in |base_pointer| field
> and an offset in |external_pointer| field. When pointer compression is
> enabled we want to combine decompression with the offset addition.
> In order to do that we add an isolate root to the external_pointer value
> and therefore the data pointer computation can is a simple addition of
> a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
> and an |external_pointer| value.
> 
> Bug: v8:9706
> Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63874}

TBR=ulan@chromium.org,neis@chromium.org,jgruber@chromium.org,ishell@chromium.org,verwaest@chromium.org

Change-Id: I901280dd191e78d02969600f775c4f0da796921f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9706
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813027Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63886}
      815df7d2
  13. 18 Sep, 2019 1 commit
  15. 08 Jul, 2019 1 commit
  17. 11 Jun, 2019 1 commit
  19. 04 Jun, 2019 1 commit
  21. 27 May, 2019 3 commits
    • Benedikt Meurer's avatar
      Reland "[typedarray] Move external/data pointer to JSTypedArray." · 70bd7cf0
      Benedikt Meurer authored 
      This is a reland of 4b86fea5 with
copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
(bug led to holes in new space, which was crashing reproducibly
on the ia32 bot).

Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
>
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
>
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
>
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
>
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}

Tbr: petermarshall@chromium.org
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61864}
      70bd7cf0
    • Clemens Hammacher's avatar
      Revert "[typedarray] Move external/data pointer to JSTypedArray." · e4db146a
      Clemens Hammacher authored 
      This reverts commit 4b86fea5.

Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045

Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
> 
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
> 
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
> 
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
> 
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}

TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org

Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61856}
      e4db146a
    • Benedikt Meurer's avatar
      [typedarray] Move external/data pointer to JSTypedArray. · 4b86fea5
      Benedikt Meurer authored 
      As the next step in supporting huge typed arrays in V8, this moves the
external/data pointer from the FixedTypedArrayBase backing store to the
JSTypedArray instance itself, and replaces the special backing stores
with a plain ByteArray (removing all the code for the FixedTypedArrayBase
class hierarchy). By doing so, we can drastically simplify the system
around typed arrays.

Note: Several places in the code base used to check the instance type
of the elements backing store of a JSTypedArray instead of checking the
elements kind on the JSTypedArray map directly. Those had to be fixed,
since the backing store is now always a ByteArray.

Drive-by-fix: Move all the typed elements access related code into the
elements.cc file to properly encapsulate the accesses.

Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61855}
      4b86fea5
  23. 23 May, 2019 1 commit
  25. 21 May, 2019 1 commit
  27. 15 May, 2019 1 commit
  29. 07 May, 2019 1 commit
    • Peter Marshall's avatar
      Reland "[typedarray] Make JSTypedArray::length authoritative." · 330e5ba2
      Peter Marshall authored 
      This is a reland of ad44c258

Patchset 2 is the original CL
Patchset 3 fixes some misuses of FixedArrayBase::length() and adds some
DCHECKS to flush out any more misuses.
Patchset 4 adds the PPC/S390 port by miladfar@ca.ibm.com.

Original change's description:
> [typedarray] Make JSTypedArray::length authoritative.
>
> This is the first step towards full huge typed array support in V8.
> Before this change, the JSTypedArray::length and the elements backing
> store length (FixedTypedArrayBase::length) were used more or less
> interchangeably to determine the number of elements in a JSTypedArray.
>
> With this change we disentangle these two lengths, and instead make
> JSTypedArray::length authoritative. For on-heap typed arrays, the
> FixedTypedArrayBase::length will remain the number of elements in the
> backing store, but for the off-heap typed arrays, this length will be
> set to 0 (matching the fact that the FixedTypedArrayBase instance does
> not contain any elements itself).
>
> This also unifies the JSTypedArray::set_/length() and length_value()
> methods to only have JSTypedArray::set_/length() which returns/takes
> size_t values. Currently this still requires the values to be in Smi
> range, but later we will extend this to allow arbitrary size_t values
> (in the safe integer range).
>
> Bug: v8:4153, v8:7881
> Change-Id: Iff9089130bb31fa9e08e0cf913e7ab52c3dbf107
> Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543729
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60648}

Bug: v8:4153, v8:7881, v8:9105
Change-Id: Ic38f833071a723642ebc6f82a4012dbc0878ef98
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594435Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61275}
      330e5ba2
  31. 02 May, 2019 1 commit
  33. 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
  35. 29 Apr, 2019 2 commits
  37. 15 Apr, 2019 1 commit
    • Peter Marshall's avatar
      [cleanup] Clean up space names in the heap · a32c97cc
      Peter Marshall authored 
      - Remove AllocationSpaceName() which was in SHOUTY_CASE and did not
  actually handle CODE_LO_SPACE.
- Make GetSpaceName() static because it is.
- Change callers of old AllocationSpaceName() to use GetSpaceName().
- Change the input type to a AllocationSpace rather than int given the
  function crashes on invalid values.

Space::name() now returns a lower case result but this is only used by
functions guarded by gc_verbose or trace_fragmentation so I don't think
this will break anything.

Change-Id: Ice9a955365d4a22233af7ba39126ad8e5cff2aab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565474
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Auto-Submit: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60842}
      a32c97cc
  39. 19 Mar, 2019 1 commit
  41. 13 Mar, 2019 1 commit
  43. 15 Feb, 2019 1 commit
  45. 13 Feb, 2019 1 commit
  47. 08 Feb, 2019 6 commits
  49. 07 Feb, 2019 1 commit
  51. 06 Feb, 2019 1 commit
  53. 29 Jan, 2019 1 commit
  55. 23 Jan, 2019 1 commit
    • Jakob Gruber's avatar
      [arm] Add missing RELATIVE_CODE_TARGET iteration · b766299d
      Jakob Gruber authored 
      Code object iteration was missing logic for RELATIVE_CODE_TARGET
reloc entries. Garbage collection could thus miss objects that were
referenced only as targets of pc-relative calls or jumps.

RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
at mksnapshot-time.

This exposed another issue in that the interpreter entry trampoline
copy we generate for profiling *did* contain relative calls in
runtime-accessible code. This is a problem, since code space on arm is,
by default, too large to be fully addressable through pc-relative
calls. This CL thus also disables the related
FLAG_interpreted_frames_native_stack feature on arm.

Drive-by: Ensure the builtins constants table does not contain Code
objects.

Bug: v8:8713,v8:6666
Change-Id: Idd914b46970ad08f9091fc72113fa7aed2732e71
Reviewed-on: https://chromium-review.googlesource.com/c/1424866Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59023}
      b766299d
  57. 18 Jan, 2019 1 commit
  59. 15 Jan, 2019 1 commit