1. 07 May, 2021 1 commit
  2. 06 May, 2021 2 commits
  3. 03 May, 2021 1 commit
  4. 30 Apr, 2021 1 commit
  5. 12 Apr, 2021 1 commit
    • Wenyu Zhao's avatar
      Allowing map word to be used for other state in GC header. · 5e0b94c4
      Wenyu Zhao authored
      This CL adds features to pack/unpack map words.
      
      Currently V8 cannot store extra metadata in object headers -- because V8
      objects do not have a proper header, but only a map pointer at the start
      of the object. To store per-object metadata like marking data, a side
      table is required as the per-object metadata storage.
      
      This CL enables V8 to use higher unused bits in a 64-bit map word as
      per-object metadata storage. Map pointer stores come with an extra step
      to encode the metadata into the pointer (we call it "map packing").
      Map pointer loads will also remove the metadata bits as well (we call it
      "map packing").
      
      Since the map word is no longer a valid pointer after packing, we also
      change the tag of the packed map word to make it looks like a Smi. This
      helps various GC and barrier code to correctly skip them instead of
      blindly dereferencing this invalid pointer.
      
      A ninja flag `v8_enable_map_packing` is provided to turn this
      map-packing feature on and off. It is disabled by default.
      
      * Only works on x64 platform, with `v8_enable_pointer_compression`
        set to `false`
      
      Bug: v8:11624
      Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73915}
      5e0b94c4
  6. 06 Apr, 2021 1 commit
    • Shu-yu Guo's avatar
      Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 627b6b2f
      Shu-yu Guo authored
      This is a reland of e28dadc2
      
      The original failure was due to a stale Win32 bot. The reland failure
      was due to idempotent task deduplication returning the exact same
      failure. See crbug/1196064
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Bug: v8:11460
      > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Auto-Submit: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73790}
      
      Bug: v8:11460
      No-Try: true
      Tbr: ishell@chromium.org
      Tbr: rmcilroy@chromium.org
      Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73795}
      627b6b2f
  7. 05 Apr, 2021 4 commits
    • Shu-yu Guo's avatar
      Revert "Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"" · 562c4251
      Shu-yu Guo authored
      This reverts commit 15c78b45.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32277/overview
      
      Original change's description:
      > Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"
      >
      > This is a reland of e28dadc2
      >
      > Relanding to see if Win32 rel failures from
      > https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
      > were infra flakes. Could not repro on try bots.
      >
      > Original change's description:
      > > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      > >
      > > Currently, IsolateRoot is both the address of the Isolate root and the
      > > base address of the pointer compression reservation. This CL teases the
      > > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      > >
      > > - In addition to V8_COMPRESS_POINTERS, add a
      > >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      > >
      > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      > >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      > >   aliases to GetPtrComprCageBase.
      > >
      > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      > >
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      >
      > No-Try: true
      > Bug: v8:11460
      > Tbr: ishell@chromium.org
      > Tbr: rmcilroy@chromium.org
      > Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169
      > Reviewed-by: Shu-yu Guo <syg@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73792}
      
      Bug: v8:11460
      Change-Id: Ifee92d622c43a91c15f45ef94ff739237bd2024b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806545
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73793}
      562c4251
    • Shu-yu Guo's avatar
      Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 15c78b45
      Shu-yu Guo authored
      This is a reland of e28dadc2
      
      Relanding to see if Win32 rel failures from
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
      were infra flakes. Could not repro on try bots.
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      
      No-Try: true
      Bug: v8:11460
      Tbr: ishell@chromium.org
      Tbr: rmcilroy@chromium.org
      Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73792}
      15c78b45
    • Francis McCabe's avatar
      Revert "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 07a9ff4d
      Francis McCabe authored
      This reverts commit e28dadc2.
      
      Reason for revert: failed test262 tests;; see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/steps?succeeded=true&debug=false
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Bug: v8:11460
      > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Auto-Submit: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73790}
      
      Bug: v8:11460
      Change-Id: I19d0e28194fcdb28e89f129a7694ca3fe29fa17a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806168
      Auto-Submit: Francis McCabe <fgm@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73791}
      07a9ff4d
    • Shu-yu Guo's avatar
      [ptr-cage] Rename IsolateRoot to PtrComprCageBase · e28dadc2
      Shu-yu Guo authored
      Currently, IsolateRoot is both the address of the Isolate root and the
      base address of the pointer compression reservation. This CL teases the
      two uses apart by renaming IsolateRoot to PtrComprCageBase.
      
      - In addition to V8_COMPRESS_POINTERS, add a
        V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      
      - Rename GetIsolate* helpers to GetPtrComprCageBase. When
        V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
        aliases to GetPtrComprCageBase.
      
      - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      
      Bug: v8:11460
      Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73790}
      e28dadc2
  8. 29 Mar, 2021 1 commit
  9. 23 Mar, 2021 1 commit
    • Frank Emrich's avatar
      [dict-proto] TF support for constants in dictionary mode protos, pt. 2 · afe9020f
      Frank Emrich authored
      This CL is part of a  series that implements Turbofan support for
      property accesses satisfying the following conditions:
      1. The holder is a dictionary mode object.
      2. The holder is a prototype.
      3. The access is a load.
      
      This feature will only be enabled if the build flag
      v8_dict_property_const_tracking is set.
      
      This particular CL implements support for the case that the property
      in question is a data property, meaning that the given
      PropertyAccessInfo has kind kDataDictionaryProtoConstant.
      Support for accessor properties is added in a separated CL.
      
      Bug: v8:11248
      Change-Id: I8794127d08c3d3aed6ec2a3eb19c4c82bdf2d1df
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718229
      Commit-Queue: Frank Emrich <emrich@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73603}
      afe9020f
  10. 08 Mar, 2021 1 commit
    • Frank Emrich's avatar
      [dict-proto] SwissNameDictionary rollout in runtime code, pt. 3 · 416fae86
      Frank Emrich authored
      This CL is part of a series that makes SwissNameDictionary available
      as a new property backing store. Previously, the flag
      v8_dict_mode_prototypes allows selecting between NameDictionary and
      OrderedNameDictionary as the backing store used for all dictionary
      mode objects. This series of CLs changes this such that enabling the
      flag causes SwissNameDictionary being used instead of
      OrderedNameDictionary. The behavior for when the flag is not set
      remains unchanged (= use NameDictionary).
      
      This particular CL just collects many small changes, including some
      CSA changes where runtime calls are necessary.
      
      Bug: v8:11388
      Change-Id: I38fd18098fc641a5d92a986da251a6b3ac09411a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739642
      Commit-Queue: Frank Emrich <emrich@google.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73257}
      416fae86
  11. 05 Mar, 2021 1 commit
    • Frank Emrich's avatar
      [dict-proto] SwissNameDictionary rollout in runtime code, pt. 1 · fc7ca518
      Frank Emrich authored
      This CL is part of a series that makes SwissNameDictionary available
      as a new property backing store. Currently, the flag
      v8_dict_mode_prototypes allows selecting between NameDictionary and
      OrderedNameDictionary as the backing store used for all dictionary
      mode objects. This series of CLs changes this such that enabling the
      flag causes SwissNameDictionary being used instead of
      OrderedNameDictionary. The behavior for when the flag is not set
      remains unchanged (= use NameDictionary).
      
      This particular CL
      a) moves two operations from ordered-hash-table.cc to
      swiss-name-dictionary.cc (which were itself just copies of existing
      functions, see the existing TODOs about cleaning this up).
      
      b) adds a new getter for the SwissNameDictionary backing store,
      called JSReceiver::property_dictionary_swiss.
      
      c) contains a first wave of replacing usages of
      OrderedNameDictionary with SwissNameDictionary.
      
      Bug: v8:11388
      Change-Id: Ie6b45571aee3646c0c0d3937b3c25f0f033810dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732676Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Frank Emrich <emrich@google.com>
      Cr-Commit-Position: refs/heads/master@{#73213}
      fc7ca518
  12. 03 Mar, 2021 1 commit
  13. 24 Feb, 2021 1 commit
  14. 22 Feb, 2021 1 commit
  15. 19 Feb, 2021 1 commit
    • Georg Neis's avatar
      Revert "[compiler] Direct heap reads for JSArrayRef" · 3cfe4fe0
      Georg Neis authored
      This reverts commit 76a2ab06.
      
      Reason for revert: A few issues, e.g.
      https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8854931126653780144/+/u/Check__flakes_/ArrayWithCowElements
      
      Original change's description:
      > [compiler] Direct heap reads for JSArrayRef
      >
      > There are two aspects to the non-JSObject parts of JSArrayRef:
      >
      > - JSArrayRef::length. Relevant only in two spots, 1. when reading
      > (immutable) array boilerplates and 2. for GetOwnCowElement.
      >
      > - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
      > store. Relies on the invariant that cow backing stores are immutable.
      >
      > This CL renames the length accessor to length_unsafe to make the
      > danger explicit at callsites.
      >
      > For GetOwnCowElement the refactor is slightly larger, since we now
      > need to read into the backing store while keeping full control of
      > object reads (e.g. JSArray::length and JSArray::elements_kind). We
      > make all reads explicit at the call site by requiring that elements,
      > elements kind, and length are passed in as arguments to
      > GetOwnCowElement. Inside GetOwnCowElement, consistency between these
      > is *not* guaranteed due to concurrency. At runtime, consistency *is*
      > guaranteed through the reference-equality check on the elements seen
      > during compilation. The actual elements read is implemented in
      > ConcurrentLookupIterator::GetOwnCowElement.
      >
      > Bug: v8:7790
      > Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72834}
      
      Bug: v8:7790, chromium:1180012
      Change-Id: I50e72380c544b2b78e1e3dc87a8249281b710912
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704666
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72860}
      3cfe4fe0
  16. 18 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Direct heap reads for JSArrayRef · 76a2ab06
      Jakob Gruber authored
      There are two aspects to the non-JSObject parts of JSArrayRef:
      
      - JSArrayRef::length. Relevant only in two spots, 1. when reading
      (immutable) array boilerplates and 2. for GetOwnCowElement.
      
      - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
      store. Relies on the invariant that cow backing stores are immutable.
      
      This CL renames the length accessor to length_unsafe to make the
      danger explicit at callsites.
      
      For GetOwnCowElement the refactor is slightly larger, since we now
      need to read into the backing store while keeping full control of
      object reads (e.g. JSArray::length and JSArray::elements_kind). We
      make all reads explicit at the call site by requiring that elements,
      elements kind, and length are passed in as arguments to
      GetOwnCowElement. Inside GetOwnCowElement, consistency between these
      is *not* guaranteed due to concurrency. At runtime, consistency *is*
      guaranteed through the reference-equality check on the elements seen
      during compilation. The actual elements read is implemented in
      ConcurrentLookupIterator::GetOwnCowElement.
      
      Bug: v8:7790
      Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72834}
      76a2ab06
  17. 16 Feb, 2021 1 commit
  18. 12 Feb, 2021 1 commit
  19. 11 Feb, 2021 1 commit
  20. 19 Nov, 2020 1 commit
  21. 13 Nov, 2020 1 commit
  22. 04 Nov, 2020 1 commit
  23. 28 Oct, 2020 2 commits
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
    • Daniel Vogelheim's avatar
      [api] TC39 Dynamic Code Brand checks · aabe6406
      Daniel Vogelheim authored
      https://github.com/tc39/proposal-dynamic-code-brand-checks
      
      An experimental implementation of the TC39 "Dynamic Code Brand Checks". This
      implementation sticks an API-only symbol on each "code kind" object, which
      is more flexible, but costs memory for each instance.
      
      Bug: chromium:1096017
      Change-Id: Idfeca035c61204ca0cea8ec735fdfa40a49d85e4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339618
      Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70842}
      aabe6406
  24. 19 Oct, 2020 1 commit
  25. 09 Oct, 2020 1 commit
  26. 07 Oct, 2020 1 commit
  27. 29 Sep, 2020 1 commit
  28. 25 Sep, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] refactor: use -tq only in filenames derived from .tq files" · 21b58516
      Tobias Tebbi authored
      This is a reland of 64caf2b0
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      >
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      >
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      >
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      Bug: v8:7793
      TBR: hpayer@chromium.org jgruber@chromium.org
      Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70137}
      21b58516
  29. 22 Sep, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] refactor: use -tq only in filenames derived from .tq files" · 92aaace1
      Francis McCabe authored
      This reverts commit 64caf2b0.
      
      Reason for revert: Seems to be causing a failure:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      > 
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      > 
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      > 
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      TBR=jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70065}
      92aaace1
    • Tobias Tebbi's avatar
      [torque] refactor: use -tq only in filenames derived from .tq files · 64caf2b0
      Tobias Tebbi authored
      This is to establish a naming rule for Torque-generated files:
      - If the file is called foo/bar-tq..., then it is derived from a
        file foo/bar.tq
      - Otherwise it doesn't belong to a specific .tq file.
      
      So far, we attached -tq to all Torque-generated file names, where it
      sometimes corresponded to a .tq file name and sometimes not.
      It is not necessary to add -tq to file names to indicate that they are
      Torque-generated, since they are already in a directory called
      torque-generated, and we always refer to them as
      "torque-generated/filename", so there is no confusion even though some
      files now have the same name as a corresponding hand-written file, for
      example factory.cc.
      
      TBR: hpayer@chromium.org
      Bug: v8:7793
      Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70060}
      64caf2b0
  30. 23 Jul, 2020 1 commit
  31. 10 Jul, 2020 1 commit
    • Leszek Swirski's avatar
      [hashtable] Allow GlobalDictionary to have holes · 82726b64
      Leszek Swirski authored
      Rather than marking deleted GlobalDictionary entries with a "The Hole"
      valued PropertyCell, we now remove those PropertyCells entirely and
      use the standard HashTable deleted item marker (also the Hole).
      
      This comes with several simplifications:
      
        1) We no longer need a customizable IsKey method on HastTable shapes,
           which was only used by GlobalDictionary to mark "The Hole" cells
           as not real keys,
        2) We can get rid of IsLive/IsKey from the Shape entirely, and define
           it directly in the HashTable, which will also allow us (in the
           future) to encourage caching of "undefined" and "Hole" where used
           for IsKey checks,
        3) PropertyCell invalidation doesn't necessarily have to allocate a
           new replacement cell (specifically, on deletion), nor does it have
           to deal with cells that contain the Hole,
        4) kNeedsHoleCheck is renamed to kMatchNeedsHoleCheck (to be explicit
           that this is only needed to guard IsMatch, which may do an
           indentity comparison and thus not need the HoleCheck guard). It's
           also moved out of BaseShape and into the various shapes that
           define IsMatch, to make them more explicitly think about the
           value,
        5) Modified some while loops into for loops to allow clearer use of
           "continue" on successful hole checks.
      
      Change-Id: If591cbb6b49d59726bdc615413aba4f78fd64632
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292230
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68807}
      82726b64
  32. 02 Jul, 2020 1 commit
  33. 10 Jun, 2020 1 commit
    • Georg Neis's avatar
      [runtime] Fix reentrancy bug in JSFunction::EnsureHasInitialMap · 0817d7ee
      Georg Neis authored
      Foozie came up with a mind-boggling example hitting a similarly
      mind-boggling bug: object construction (JSObject::New) wants to create
      the constructor's function initial map (JSFunction::GetDerivedMap ->
      JSFunction::EnsureHasInitialMap). To do so, it calls
      JSFunction::CalculateExpectedNofProperties. This harmless sounding
      function triggers compilation of the function. Since we're running with
      --always-opt, this is an optimizing compilation. Turbofan ends up
      depending on the function's "prototype" property, for which it wants to
      create the initial map so that it can install the code dependency. That
      is, EnsureHasInitialMap is reentered. At this point there is no further
      compilation attempt because the bytecode now exists. The initial map is
      created and installed on the function, and TF records the code
      dependency on that map. When CalculateExpectedNofProperties returns
      control to the outer EnsureHasInitialMap, yet another initial map is
      created and set on the function, forgetting the previous one and thus
      the code dependency.
      
      I'm not sure if this bug can only be observed with --always-opt. The fix
      is general.
      
      Bug: chromium:1092011
      Change-Id: I8b972748e49b9eb8f06fa17ea9ca037de2bd7532
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238570Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68292}
      0817d7ee
  34. 03 Jun, 2020 1 commit