1. 20 Jul, 2021 1 commit
  2. 16 Jul, 2021 2 commits
  3. 13 Jul, 2021 1 commit
  4. 12 Jul, 2021 1 commit
  5. 09 Jul, 2021 1 commit
  6. 08 Jul, 2021 1 commit
    • Camillo Bruni's avatar
      [d8] Disable d8.promise.setHooks with correctness fuzzing · 060c2cb1
      Camillo Bruni authored
      Setting promise hooks after running some promise-related code has hard
      to control side-effects that make correctness fuzzing difficult.
      
      Certain Promise functions are optimized and avoid creating intermediate
      Promises. Dynamically enabled Promise hooks combined with --force-slow-path,
      which would cause us to always create those intermediate Promises, will
      get us very differet callbacks if the hooks are enabled half-way.
      
      The exepected usage pattern is to only use setHooks if there are no
      pending promises, something that cannot be guaranteed for fuzzing.
      
      Bug: chromium:1202465
      Change-Id: Ifa96f2db9c441b6f5da696b88a1c087160ec8eeb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013355Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75637}
      060c2cb1
  7. 01 Jul, 2021 1 commit
  8. 30 Jun, 2021 1 commit
  9. 29 Jun, 2021 1 commit
  10. 24 Jun, 2021 1 commit
  11. 23 Jun, 2021 1 commit
  12. 22 Jun, 2021 2 commits
  13. 14 Jun, 2021 1 commit
  14. 11 Jun, 2021 1 commit
    • Dan Elphick's avatar
      [build] Reduce size of inline header cycles · c26965bd
      Dan Elphick authored
      This removes/replaces header includes with the aim of shrinking the
      size of the inline header cycle. Specifically before this CL, there was
      a single Strongly-Connected Component comprising 60 header files from
      src/objects and src/heap.
      
      Now there are two 2 SCCs. The src/heap SCC has 6 files and depends on
      the src/objects SCC, which has 50 files. Additionally some previously
      implicit dependencies have been added.
      
      Dependencies calculated using:
      git grep "#include \"" *.h *.cc | sed 's/:#include "/ /;s/".*$//' | \
      awk 'BEGIN {print "digraph deps {" } END {print "}"} {print "\""$1"\" -> \""$2"\""}'
      
      SCCs found using sccmap from graphviz.
      
      Also removes unused Cell::FromValueAddress method.
      
      Change-Id: Ib19d00ccd14e490ee64d57be4d99b1b3686ac32a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2951734Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75103}
      c26965bd
  15. 10 Jun, 2021 1 commit
  16. 08 Jun, 2021 4 commits
  17. 07 Jun, 2021 3 commits
    • Seth Brenith's avatar
      Fix counting ignition dispatches · 82b673bc
      Seth Brenith authored
      The flag --trace-ignition-dispatches has been broken for a long time,
      since it was not designed to work with bytecode handlers that are
      generated ahead of time by mksnapshot. This splits the existing
      --trace-ignition-dispatches logic into two separate parts:
      
      1. A gn argument which instructs mksnapshot to include dispatch counting
         in the bytecode handlers, and ensures that the Interpreter allocates
         the array of counters, and
      2. A runtime flag which enables the ignition-statistics extension which
         implements the JS-accessible function getIgnitionDispatchCounters().
      
      Change-Id: I89323425697f5641451f67b9ddcc0303b8ca209f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2937564Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#74992}
      82b673bc
    • Clemens Backes's avatar
      [d8] Check that we never block in predictable mode · 44e7d0e1
      Clemens Backes authored
      Since there is only a single thread in predictable mode, we should never
      wait for more work. That would be an immediate deadlock.
      This CL adds code to never wait, and instead checks after processing all
      messages that we would not need to wait (i.e. that all work was
      completed). This turns deadlocks into FATAL errors.
      
      R=ahaas@chromium.org
      
      Bug: v8:11848
      Change-Id: If61305d634803fc43678238dc6e9d3a2f35793c8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940886Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74966}
      44e7d0e1
    • Clemens Backes's avatar
      [d8][predictable] Don't wait for background work · c7a8627b
      Clemens Backes authored
      This fixes a little mistake from https://crrev.com/c/2182453. In
      predictable mode (where we do not have any threads for executing
      background work) we are executing everything on the main thread, but we
      should never wait for background work to be spawned. Otherwise we can
      deadlock if the last background task spawned new foreground work, but we
      keep waiting for more background work to arrive.
      
      Generally, any blocking in predictable mode will block forever, because
      there is no one to spawn any work concurrently (foreground or
      background). But the blocking for foreground work has to be there for
      non-predictable mode, thus keep it for now, and only remove waiting for
      background work.
      
      R=ahaas@chromium.org
      
      Bug: v8:11848
      Change-Id: I51c976f6858db8120baa4c47d28840a1041d7fea
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940885Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74962}
      c7a8627b
  18. 04 Jun, 2021 2 commits
  19. 03 Jun, 2021 1 commit
  20. 02 Jun, 2021 1 commit
    • Camillo Bruni's avatar
      Reland "[mjsunit][tools][d8] Full roundtrip tickprocessor test" · 99bfa28b
      Camillo Bruni authored
      This is a reland of ed7e4554:
      - fixing platform names for tickprocessor
      - UnixCppEntriesProvider => LinuxCppEntriesProvider
      - MacCppEntriesProvider => MacOSCppEntriesProvider
      
      Original change's description:
      > [mjsunit][tools][d8] Full roundtrip tickprocessor test
      >
      > - Add os.d8Path property
      > - Add os.name property
      > - Change tickprocssor test to use command line arguments for testing
      >   various configurations
      > - Change tickprocessor test to create a temporary v8.log and read it
      >   back in on linux only
      > - Rearrange code in tickprocessor.mjs to allow instantiating the
      >   CppEntriesProvider directly
      > - Drop complete symbol-list for tickprocessor-test-large.log for better
      >   code searching in V8
      >
      > Change-Id: Ib56dd0a1ba5377282c84c4de6f17e2fd69ee8123
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929120
      > Reviewed-by: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74892}
      
      Change-Id: I5e121ba11f407af50108a2712d27c32867a22eb0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929382Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74902}
      99bfa28b
  21. 01 Jun, 2021 3 commits
  22. 31 May, 2021 1 commit
  23. 27 May, 2021 2 commits
  24. 26 May, 2021 1 commit
    • Vicky Kontoura's avatar
      [web snapshot] Support mjsunit tests · c32ba7e0
      Vicky Kontoura authored
      This CL adds support for testing web snapshots through mjsunit tests.
      To allow for taking and using web snapshots from JavaScript, two
      methods, Realm.takeWebSnapshot() and Realm.useWebSnapshot(), are
      introduced in d8.
      
      Both of these methods accept a Realm as a parameter, allowing for
      mjsunit tests to create and use the snapshot in different realms.
      
      To return the snapshot data, Realm.takeWebSnapshot() creates and
      returns a snapshot object with the snapshot data stored as an embedder
      field.
      
      Bug: v8:11525, v8:11706
      Change-Id: I6e514e10eabf5bdb96d81e2697d4ddc49d92de73
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905610Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Vicky Kontoura <vkont@google.com>
      Cr-Commit-Position: refs/heads/master@{#74783}
      c32ba7e0
  25. 25 May, 2021 1 commit
  26. 18 May, 2021 2 commits
  27. 14 May, 2021 1 commit
  28. 12 May, 2021 1 commit