1. 19 Jan, 2021 2 commits
  2. 16 Dec, 2020 2 commits
  3. 20 Nov, 2020 1 commit
  4. 16 Nov, 2020 1 commit
    • Georg Neis's avatar
      [runtime] Yet another PropertyCell cleanup · 3728728d
      Georg Neis authored
      Main changes:
      
      - Remove the kUninitialized and kInvalidated cell type aliases. They
        were confusing because their meaning depended on the current value in
        the cell. I think kUninitialized was obsolete anyways.
      - Remove a DCHECK from the compiler. The property that was asserted,
        while true, is irrelevant.
      - Remove the obsolete function GetConstantType. The only left use was
        in the object printer, but it's pointless there because we already
        print the value anyways.
      
      Change-Id: Ic718c8ba39aeb5bf18f588535dfb755a023cb144
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536647Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71198}
      3728728d
  5. 13 Nov, 2020 1 commit
  6. 03 Nov, 2020 1 commit
  7. 28 Oct, 2020 1 commit
    • 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
  8. 05 Oct, 2020 1 commit
  9. 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
  10. 24 Sep, 2020 2 commits
  11. 22 Sep, 2020 3 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
    • Marja Hölttä's avatar
      [super ic] Fix more receiver vs lookup start object vs holder confusion · ab7e6df0
      Marja Hölttä authored
      The actual fix is in LoadIC::ComputeHandler (checking
      lookup_start_object == holder instead of receiver == holder) + the
      LookupIterator changes for preserving lookup_start_object.
      
      The rest is renaming / refactoring.
      
      Bug: v8:9237, chromium:1127653
      Change-Id: Ieef46fb46ababa79623951c48639429c5b552d2d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414039
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70045}
      ab7e6df0
  12. 15 Jul, 2020 1 commit
  13. 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
  14. 25 May, 2020 1 commit
  15. 28 Apr, 2020 1 commit
  16. 21 Apr, 2020 1 commit
  17. 16 Apr, 2020 1 commit
  18. 15 Apr, 2020 1 commit
  19. 03 Apr, 2020 1 commit
    • Bruce Dawson's avatar
      Revert "Speculative fix to crashes from a CPU bug" · e84e9b92
      Bruce Dawson authored
      This reverts commit 10360127.
      
      Reason for revert: This fix only had moderate impact and the
      underlying CPU bug has now been addressed.
      
      Original change's description:
      > Speculative fix to crashes from a CPU bug
      > 
      > For the last few months Chrome has been seeing many "impossible" crashes
      > on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes
      > only happen with 64-bit Chrome and only happen in the prologue of two
      > functions. The crashes come and go across different Chrome versions.
      > Analysis of most of the crashes shows that the address of the crashing
      > instruction follows some patterns:
      > 
      > When crashing in GetFieldIndex() the last byte of the address is always
      > 1c, 5c, 9c, or dc.
      > 
      > When crashing in UpdateCaches (fewer unique samples) the last byte of
      > the address is always 5d or 9d.
      > 
      > The address of the function is 0xc or 0xd bytes earlier so the crashing
      > functions always start with an address that ends in 10, 50, 90, or d0.
      > 
      > Those addresses are for the crashes on a load of the __security_cookie.
      > The crashes also occasionally happen on the two instructions that follow
      > the __security_cookie load in which case the crashing instruction's
      > address has been seen to end with 23 or a3. This corresponds to a
      > function start address of 10 or 90.
      > 
      > Since the crash involves reading incorrect instruction bytes when
      > crossing a 16-byte boundary and since the crash appears to only happen
      > with particular 16-byte alignments it seems reasonable to force the
      > function's alignments to a multiple of 32 to see if this reliably
      > avoids the crashes. This change uses the gcc/clang __attribute__
      > directive to force 32-byte alignment. I have tested this change enough to
      > verify that it triggers the desired alignment (with up to 31 "int 3"
      > instructions added for padding) but since I have never reproduced this
      > crash I have no way of testing its efficacy.
      > 
      > Bug: chromium:968683, chromium:964273
      > Change-Id: Ia6e1c6d1e044b84d274817374b25523303e78b51
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803775
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63804}
      
      TBR=brucedawson@chromium.org,verwaest@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:968683, chromium:964273
      Change-Id: I150ecfebeff95e8f63dbba74d78491867dc17736
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134728
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Bruce Dawson <brucedawson@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66977}
      e84e9b92
  20. 03 Mar, 2020 1 commit
  21. 10 Jan, 2020 2 commits
  22. 09 Jan, 2020 1 commit
  23. 19 Dec, 2019 1 commit
  24. 26 Nov, 2019 1 commit
  25. 20 Nov, 2019 1 commit
  26. 18 Oct, 2019 1 commit
  27. 16 Oct, 2019 1 commit
  28. 11 Oct, 2019 2 commits
  29. 23 Sep, 2019 1 commit
  30. 17 Sep, 2019 1 commit
  31. 16 Sep, 2019 2 commits
    • Bruce Dawson's avatar
      Speculative fix to crashes from a CPU bug · 10360127
      Bruce Dawson authored
      For the last few months Chrome has been seeing many "impossible" crashes
      on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes
      only happen with 64-bit Chrome and only happen in the prologue of two
      functions. The crashes come and go across different Chrome versions.
      Analysis of most of the crashes shows that the address of the crashing
      instruction follows some patterns:
      
      When crashing in GetFieldIndex() the last byte of the address is always
      1c, 5c, 9c, or dc.
      
      When crashing in UpdateCaches (fewer unique samples) the last byte of
      the address is always 5d or 9d.
      
      The address of the function is 0xc or 0xd bytes earlier so the crashing
      functions always start with an address that ends in 10, 50, 90, or d0.
      
      Those addresses are for the crashes on a load of the __security_cookie.
      The crashes also occasionally happen on the two instructions that follow
      the __security_cookie load in which case the crashing instruction's
      address has been seen to end with 23 or a3. This corresponds to a
      function start address of 10 or 90.
      
      Since the crash involves reading incorrect instruction bytes when
      crossing a 16-byte boundary and since the crash appears to only happen
      with particular 16-byte alignments it seems reasonable to force the
      function's alignments to a multiple of 32 to see if this reliably
      avoids the crashes. This change uses the gcc/clang __attribute__
      directive to force 32-byte alignment. I have tested this change enough to
      verify that it triggers the desired alignment (with up to 31 "int 3"
      instructions added for padding) but since I have never reproduced this
      crash I have no way of testing its efficacy.
      
      Bug: chromium:968683, chromium:964273
      Change-Id: Ia6e1c6d1e044b84d274817374b25523303e78b51
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803775Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63804}
      10360127
    • Joshua Litt's avatar
      [protectors] Move PromiseThenLookupChain protector to Protectors · 7c9c1039
      Joshua Litt authored
      Bug: v8:9463
      Change-Id: Ife5ea730166e76bdbe8b18eac1eb5688b7aaf150
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800513
      Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63795}
      7c9c1039
  32. 10 Sep, 2019 1 commit