1. 05 Jul, 2021 1 commit
  2. 02 Mar, 2021 1 commit
  3. 01 Mar, 2021 1 commit
    • Dominik Inführ's avatar
      [heap] Safepointing with an atomic state · 17cba4f0
      Dominik Inführ authored
      To improve performance of parking, keep the thread state in an atomic
      variable instead of protecting it with a mutex.
      
      However the mutex was used e.g. to force Unpark() to block while the
      safepoint operation was still running. Therefore the safepoint algorithm
      has to change as well.
      
      Park() and Unpark() use CAS operation to transition the state.
      Safepoint() uses a relaxed load for checking whether a safepoint was
      requested. Since Safepoint(), Park() and Unpark() all have a slow path,
      there is no need for busy-waiting on the main thread.
      
      We need two more ThreadStates:
      * SafepointRequested: This state is set by GlobalSafepoint to force
          Running threads into the slow path on Safepoint() and Park(). This
          state also replaces the separate atomic<bool> safepoint_requested_
          field we used before.
      * ParkedSafepoint: This state is set by GlobalSafepoint as well to force
          parked threads into the slow path on Unpark().
      
      When stopping all threads, GlobalSafepoint transitions states from
      Running --> SafepointRequested and Parked --> ParkedSafepoint to force
      the slow path for all three methods. After performing the transition
      for each thread we know the exact number of Running threads and wait
      until each of them either reached a safepoint or parked itself.
      
      Design doc: https://docs.google.com/document/d/1p9klWyqT_AScAnK_PdHZTcNhZGzoBiYWPkUciIh2C58/edit?usp=sharing
      
      Bug: chromium:1177144, v8:10315
      Change-Id: I8697da915c7d18e2fb941f1bedf6181226408feb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704075Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73089}
      17cba4f0
  4. 03 Feb, 2021 1 commit
  5. 12 Jan, 2021 1 commit
    • Camillo Bruni's avatar
      [tools] Add DisableGCMole scope · d16a2a68
      Camillo Bruni authored
      Make sure gcmole detects issue in DisallowGarbageCollection scopes.
      
      DisallowGarbageCollection is widely used in the codebase to document
      code that doesn't allocate. However, this has the rather unexpected
      side-effect that gcmole is not run when such a scope is active.
      
      This CL changes the default behavior of gcmole to run even with
      DisallowGarbageCollection scopes present. This will give us the best
      results of both worlds, dynamic checks by the fuzzer, and static
      analysis by gcmole.
      
      To allow crazy local raw pointer operations there is a new
      DisableGCMole scope that explicitly disables gcmole.
      
      Change-Id: I0a78fb3b4ceaad35be9bcf7293d917a41f90c91f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615419Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72039}
      d16a2a68
  6. 04 Dec, 2020 1 commit
    • Leszek Swirski's avatar
      [gcmole] Improve performance · 18138f26
      Leszek Swirski authored
      Improve the performance of gcmole by
      
        * Precompiling the regexes in GCSuspectsCollector.Resolve
        * Merging those regexes into a single regex, using '|'
        * Changing multiprocess clang plugin invocation to threaded (running
          the plugin releases the GIL so this can efficiently thread). This
          uses a simple worker pool with a single work queue.
        * Change clang plugin invocation loop to yield after each invocation.
          This pipelines the dump-callees plugin and GCSuspectsCollector
          Parse/Resolve, so that the parse can happen while waiting for other
          callee dumps to finish.
      
      Change-Id: Ib9fca70dbcfd2f9d1aebc8bd11aa1d1f7d34e24a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562242Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarLiviu Rau <liviurau@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71617}
      18138f26
  7. 26 Nov, 2020 1 commit
  8. 20 Nov, 2020 1 commit
  9. 18 Nov, 2020 1 commit
  10. 17 Nov, 2020 1 commit
    • Leszek Swirski's avatar
      [asserts] Add combination assert scopes · 076687ab
      Leszek Swirski authored
      Add a "combination" assert scope class, which combines multiple existing
      assert scopes.  This will allow scopes with functional overlap, e.g.
      DisallowGarbageCollection and DisallowHeapAllocation, to share an assert
      type rather than rather than requiring users to remember to set both. To
      demonstrate this, this redefines DisallowGarbageCollection to a
      combination of DisallowHeapAllocation and a new DisallowSafepoints, and
      some of the DCHECKs checking both are simplified to only check one or
      the other, as appropriate.
      
      The combination classes become subclasses of the existing assert scopes,
      so that they can be used in their place as e.g. a function parameter,
      e.g. DisallowGarbageCollection can be passed to a function expecting
      const DisallowHeapAllocation&.
      
      As a drive-by, this also changes the per-thread assert scopes to use a
      bitmask, rather than a bool array, to store their per-thread data. The
      per-isolate scopes already used a bitmask, so this unifies the
      behaviour between the two.
      
      Change-Id: I209e0a56f45e124c0ccadbd9fb77f39e070612fe
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534814
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71231}
      076687ab
  11. 16 Nov, 2020 1 commit
  12. 27 Oct, 2020 2 commits
  13. 26 Oct, 2020 1 commit
  14. 04 Oct, 2020 1 commit
  15. 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
  16. 15 Sep, 2020 1 commit
  17. 14 Sep, 2020 1 commit
  18. 24 Jun, 2020 1 commit
  19. 22 Jun, 2020 1 commit
  20. 19 Jun, 2020 1 commit
  21. 18 May, 2020 1 commit
  22. 13 May, 2020 1 commit
  23. 08 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [gcmole] Update whitelist for src/heap · 38e7b6b3
      Leszek Swirski authored
      Most dead variable warnings in GCMole are false positives, either from
      failing to detect that TryEvacuateObject returning false means it didn't
      allocate, or a regex error thinking that GarbageCollectionReasonToString
      causes garbage collection (because the mangled version is something like
      GarbageCollectionReasonToString[...]GarbageCollectionReason, and that
      matches /Collect.*Garbage/).
      
      Update the whitelist and fix the "Collect.*Garbage" regex to only look
      at the function name.
      
      Bug: v8:9985
      Change-Id: I62284e97e4975a6a87616d1d535b2ac7958d17bb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989829
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65622}
      38e7b6b3
  24. 13 Dec, 2019 1 commit
  25. 26 Nov, 2019 2 commits
  26. 25 Nov, 2019 1 commit
  27. 09 Sep, 2019 2 commits
  28. 06 Sep, 2019 1 commit
  29. 30 Aug, 2019 1 commit
  30. 29 Aug, 2019 1 commit
  31. 31 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Reland "Add postmortem debugging helper library" · 0921e8f2
      Seth Brenith authored
      This is a reland of 517ab73f
      
      Updates since original: now compressed pointers passed to the function
      GetObjectProperties are required to be sign-extended. Previously, the
      function allowed zero-extended values, but that led to ambiguity on
      pointers like 0x88044919: is it compressed or is the heap range actually
      centered on 0x100000000?
      
      Original change's description:
      > Add postmortem debugging helper library
      >
      > This change begins to implement the functionality described in
      > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      > for investigating V8 state in crash dumps.
      >
      > This change adds a new library, v8_debug_helper, for providing platform-
      > agnostic assistance with postmortem debugging. This library can be used
      > by extensions built for debuggers such as WinDbg or lldb. Its public API
      > is described by debug-helper.h; currently the only method it exposes is
      > GetObjectProperties, but we'd like to add more functionality over time.
      > The API surface is restricted to plain C-style structs and pointers, so
      > that it's easy to link from a debugger extension built with a different
      > toolchain.
      >
      > This change also adds a new cctest file to exercise some basic
      > interaction with the new library.
      >
      > The API function GetObjectProperties takes an object pointer (which
      > could be compressed, or weak, or a SMI), and returns a string
      > description of the object and a list of properties the object contains.
      > For now, the list of properties is entirely based on Torque object
      > definitions, but we expect to add custom properties in future updates so
      > that it can be easier to make sense of complex data structures such as
      > dictionaries.
      >
      > GetObjectProperties does several things that are intended to generate
      > somewhat useful results even in cases where memory may be corrupt or
      > unavailable:
      > - The caller may optionally provide a type string which will be used if
      >   the memory for the object's Map is inaccessible.
      > - All object pointers are compared against the list of known objects
      >   generated by mkgrokdump. The caller may optionally provide the
      >   pointers for the first pages of various heap spaces, to avoid spurious
      >   matches. If those pointers are not provided, then any matches are
      >   prefixed with "maybe" in the resulting description string, such as
      >   "maybe UndefinedValue (0x4288000341 <Oddball>)".
      >
      > Bug: v8:9376
      >
      > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62882}
      
      Bug: v8:9376
      Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63008}
      0921e8f2
  32. 24 Jul, 2019 1 commit
    • Zhi An Ng's avatar
      Revert "Add postmortem debugging helper library" · 6747e3a1
      Zhi An Ng authored
      This reverts commit 517ab73f.
      
      Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
      
      Original change's description:
      > Add postmortem debugging helper library
      > 
      > This change begins to implement the functionality described in
      > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      > for investigating V8 state in crash dumps.
      > 
      > This change adds a new library, v8_debug_helper, for providing platform-
      > agnostic assistance with postmortem debugging. This library can be used
      > by extensions built for debuggers such as WinDbg or lldb. Its public API
      > is described by debug-helper.h; currently the only method it exposes is
      > GetObjectProperties, but we'd like to add more functionality over time.
      > The API surface is restricted to plain C-style structs and pointers, so
      > that it's easy to link from a debugger extension built with a different
      > toolchain.
      > 
      > This change also adds a new cctest file to exercise some basic
      > interaction with the new library.
      > 
      > The API function GetObjectProperties takes an object pointer (which
      > could be compressed, or weak, or a SMI), and returns a string
      > description of the object and a list of properties the object contains.
      > For now, the list of properties is entirely based on Torque object
      > definitions, but we expect to add custom properties in future updates so
      > that it can be easier to make sense of complex data structures such as
      > dictionaries.
      > 
      > GetObjectProperties does several things that are intended to generate
      > somewhat useful results even in cases where memory may be corrupt or
      > unavailable:
      > - The caller may optionally provide a type string which will be used if
      >   the memory for the object's Map is inaccessible.
      > - All object pointers are compared against the list of known objects
      >   generated by mkgrokdump. The caller may optionally provide the
      >   pointers for the first pages of various heap spaces, to avoid spurious
      >   matches. If those pointers are not provided, then any matches are
      >   prefixed with "maybe" in the resulting description string, such as
      >   "maybe UndefinedValue (0x4288000341 <Oddball>)".
      > 
      > Bug: v8:9376
      > 
      > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62882}
      
      TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9376
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62899}
      6747e3a1
  33. 23 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Add postmortem debugging helper library · 517ab73f
      Seth Brenith authored
      This change begins to implement the functionality described in
      https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      for investigating V8 state in crash dumps.
      
      This change adds a new library, v8_debug_helper, for providing platform-
      agnostic assistance with postmortem debugging. This library can be used
      by extensions built for debuggers such as WinDbg or lldb. Its public API
      is described by debug-helper.h; currently the only method it exposes is
      GetObjectProperties, but we'd like to add more functionality over time.
      The API surface is restricted to plain C-style structs and pointers, so
      that it's easy to link from a debugger extension built with a different
      toolchain.
      
      This change also adds a new cctest file to exercise some basic
      interaction with the new library.
      
      The API function GetObjectProperties takes an object pointer (which
      could be compressed, or weak, or a SMI), and returns a string
      description of the object and a list of properties the object contains.
      For now, the list of properties is entirely based on Torque object
      definitions, but we expect to add custom properties in future updates so
      that it can be easier to make sense of complex data structures such as
      dictionaries.
      
      GetObjectProperties does several things that are intended to generate
      somewhat useful results even in cases where memory may be corrupt or
      unavailable:
      - The caller may optionally provide a type string which will be used if
        the memory for the object's Map is inaccessible.
      - All object pointers are compared against the list of known objects
        generated by mkgrokdump. The caller may optionally provide the
        pointers for the first pages of various heap spaces, to avoid spurious
        matches. If those pointers are not provided, then any matches are
        prefixed with "maybe" in the resulting description string, such as
        "maybe UndefinedValue (0x4288000341 <Oddball>)".
      
      Bug: v8:9376
      
      Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62882}
      517ab73f
  34. 28 Jun, 2019 1 commit
  35. 23 May, 2019 1 commit
  36. 22 May, 2019 1 commit
  37. 14 May, 2019 1 commit