1. 01 Oct, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Consistently treat promise rejections as side-effecting. · 0195a5eb
      Benedikt Meurer authored
      Previously we'd treat %_AsyncFunctionReject (and %AsyncFunctionReject)
      as side-effect free (in async functions), but that's not correct, since
      promise rejections have side-effects (at the very least triggering the
      unhandled promise rejection machinery in the browser).
      
      This required a minor refactoring as previously we'd classify functions
      as side-effecting or not depending on whether they contain any calls to
      side-effecting intrinsics, no matter whether this call is actually
      executed or not. That would break REPL mode however if we'd generally
      treat all async functions with %_AsyncFunctionReject intrinsic calls as
      side-effecting, so instead of performing the intrinsic checks ahead of
      time, we now perform the test at execution time.
      
      Before: https://imgur.com/5BvJP9d.png
      After: https://imgur.com/10FanNr.png
      Fixed: chromium:1249275
      Change-Id: Ib06f945ba21f1e06ee9b13a1363fad342464fd9a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197712
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77183}
      0195a5eb
  2. 17 May, 2021 1 commit
    • Philip Pfaffe's avatar
      Reland "[ic] Fix handling of API properties with side effects" · b4942eb3
      Philip Pfaffe authored
      This is a reland of 0ce36e7d
      
      The reland includes two fixes:
      - Move the EvaluateGlobalForTesting into libv8 to avoid linkage issues
        and to avoid having to export ThreadLocalTop symbols.
      - Give the ExecutionMode enum a uint8_t backing type to avoid endianess
        issues.
      
      Original change's description:
      > [ic] Fix handling of API properties with side effects
      >
      > DebugEvaluate can evaluate expressions in side-effect-free mode, where
      > any operation that would cause observable side effects throws an
      > exception. Currently, when accessors are backed by callbacks, it's
      > possible that ICs call those accessors directly, bypassing the
      > side-effect checks. This CL introduces a bailouts to runtime in those
      > cases.
      >
      > Fixed: chromium:1201781
      > Also-By: ishell@chromium.org, pfaffe@chromium.org
      > Change-Id: Ie53bfb2bff7b3420f2b27091e8df6723382cf53c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857634
      > Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74507}
      
      Fixes: v8:11761
      Change-Id: I58cde8bd11ba0fc9d83adc19fa87733628ab6c13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891829Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74602}
      b4942eb3
  3. 12 May, 2021 1 commit
    • Maya Lekova's avatar
      Revert "[ic] Fix handling of API properties with side effects" · ba6a1a7c
      Maya Lekova authored
      This reverts commit 0ce36e7d.
      
      Reason for revert: Speculative revert for a Chromium build breakage causing a blocked roll - https://bugs.chromium.org/p/v8/issues/detail?id=11761
      
      Original change's description:
      > [ic] Fix handling of API properties with side effects
      >
      > DebugEvaluate can evaluate expressions in side-effect-free mode, where
      > any operation that would cause observable side effects throws an
      > exception. Currently, when accessors are backed by callbacks, it's
      > possible that ICs call those accessors directly, bypassing the
      > side-effect checks. This CL introduces a bailouts to runtime in those
      > cases.
      >
      > Fixed: chromium:1201781
      > Also-By: ishell@chromium.org, pfaffe@chromium.org
      > Change-Id: Ie53bfb2bff7b3420f2b27091e8df6723382cf53c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857634
      > Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74507}
      
      Change-Id: Ifb5c24682af29572591d436ab92b0304058e99af
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891650
      Auto-Submit: Maya Lekova <mslekova@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@{#74515}
      ba6a1a7c
  4. 11 May, 2021 1 commit
  5. 29 Dec, 2020 1 commit
  6. 29 Sep, 2020 1 commit
  7. 06 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [runtime] Move string table off-heap · 1546be9c
      Leszek Swirski authored
      Changes the isolate's string table into an off-heap structure. This
      allows the string table to be resized without allocating on the V8 heap,
      and potentially triggering a GC. This allows existing strings to be
      inserted into the string table without requiring allocation.
      
      This has two important benefits:
      
        1) It allows the deserializer to insert strings directly into the
           string table, rather than having to defer string insertion until
           deserialization completes.
      
        2) It simplifies the concurrent string table lookup to allow resizing
           the table inside the write lock, therefore eliminating the race
           where two concurrent lookups could both resize the table.
      
      The off-heap string table has the following properties:
      
        1) The general hashmap behaviour matches the HashTable, i.e. open
           addressing, power-of-two sized, quadratic probing. This could, of
           course, now be changed.
      
        2) The empty and deleted sentinels are changed to Smi 0 and 1,
           respectively, to make those comparisons a bit cheaper and not
           require roots access.
      
        3) When the HashTable is resized, the old elements array is kept
           alive in a linked list of previous arrays, so that concurrent
           lookups don't lose the data they're accessing. This linked list
           is cleared by the GC, as then we know that all threads are in
           a safepoint.
      
        4) The GC treats the hash table entries as weak roots, and only walks
           them for non-live reference clearing and for evacuation.
      
        5) Since there is no longer a FixedArray to serialize for the startup
           snapshot, there is now a custom serialization of the string table,
           and the string table root is considered unserializable during weak
           root iteration. As a bonus, the custom serialization is more
           efficient, as it skips non-string entries.
      
      As a drive-by, rename LookupStringExists_NoAllocate to
      TryStringToIndexOrLookupExisting, to make it clearer that it returns
      a non-string for the case when the string is an array index. As another
      drive-by, extract StringSet into a separate header.
      
      Bug: v8:10729
      Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69270}
      1546be9c
  8. 22 Jun, 2020 1 commit
  9. 06 Nov, 2019 2 commits
    • Simon Zünd's avatar
      Connect REPL mode to the V8 inspector · 702f2bad
      Simon Zünd authored
      There already exists a optional boolean flag 'replMode' for the
      'Runtime.evaluate' command. This CL ferries the flag from the inspector
      to DebugEvaluate::Global.
      
      The existing DebugEvaluate::GlobalREPL is removed in favor of a
      the REPLMOde enum to reduce code duplication.
      
      Bug: chromium:1018158
      Change-Id: Iafb43a3015b6876a02ac0db6cdfcac2cfa388862
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881149
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64801}
      702f2bad
    • Simon Zünd's avatar
      Introduce REPL mode · fbcc2e87
      Simon Zünd authored
      Design doc: bit.ly/v8-repl-mode
      
      This CL adds a new REPL mode that can be used via
      DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration
      of 'let' bindings at the moment. Example:
      
      REPL Input 1: let x = 21;
      REPL Input 2: let x = 42;
      
      This would normally throw a SyntaxError, but works in REPL mode.
      
      The implementation is done by:
        - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo}
          and script {Scope}.
        - Each global let declaration still gets a slot reserved in the
          respective {ScriptContext}.
        - When a new REPL mode {ScriptContext} is created, name clashes
          for let bindings are not reported as errors.
        - Declarations, loads and stores for global let in REPL mode are
          now "load/store global" instead of accessing their respective
          context slot directly. This causes a lookup in the ScriptContextTable
          where the found slot for each name is guaranteed to be the same
          (the first one).
      
      Bug: chromium:1004193, chromium:1018158
      Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64793}
      fbcc2e87
  10. 27 Sep, 2019 1 commit
  11. 11 Sep, 2019 1 commit
    • Simon Zünd's avatar
      Change debug-evaluate from a whitelist to a blacklist approach · 2e11dff7
      Simon Zünd authored
      This CL changes how variables are resolved during debug evaluate.
      We now re-parse the whole script when creating a ScopeIterator.
      This gives us accurate scope information for all parent scopes of the
      closure in which we stopped. Using this information, we build
      blacklists of stack-allocated variables. Each context on the chain
      in between the closure context up to the original native context is
      wrapped in a debug-evaluate context with such a blacklist attached.
      Variable lookup for debug-evalute contexts then works as follows:
      
        1) Look up in the materialized stack variables (stayed the same).
        2) Check the blacklist to find out whether to abort further lookup.
        3) Look up in the original context.
      
      Steps 1-3 is repeated for each debug-evaluate context, since they
      mirror the original context chain.
      
      R=ulan@chromium.org, yangguo@chromium.org
      
      Change-Id: Ied8e5786772c70566da9627ee3b7eff066fba2b4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795354Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63666}
      2e11dff7
  12. 12 Jul, 2019 1 commit
  13. 23 May, 2019 1 commit
  14. 19 Dec, 2018 1 commit
  15. 04 Sep, 2018 1 commit
  16. 05 Jul, 2018 1 commit
  17. 28 Jun, 2018 1 commit
    • Ross McIlroy's avatar
      [sfi] Remove DebugInfo field in SharedFunctionInfo. · c51bcd17
      Ross McIlroy authored
      Merges DebugInfo field into the function_identifier field, storing the function
      identifier in the DebugInfo. Also moves some debugging_hints bits to the SFI flags,
      and others to the DebugInfo. Finally, changes the logic to store debugger patched
      bytecode array on the SFI instead of the DebugInfo, simplifying the logic in the
      InterpreterEntryTrampoline.
      
      BUG=chromium:818642,chromium:783853
      TBR=hpayer@chromium.org
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: If440080c0f08fac4fb96f5e18dcc0eb9b86d4821
      Reviewed-on: https://chromium-review.googlesource.com/1115819
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54081}
      c51bcd17
  18. 21 Jun, 2018 1 commit
  19. 20 Jun, 2018 1 commit
  20. 18 Jun, 2018 1 commit
  21. 15 Jun, 2018 2 commits
    • Yang Guo's avatar
      Revert "[debugger] Rewrite the ScopeIterator/DebugEvaluate to use Scope rather... · 23b8d2fd
      Yang Guo authored
      Revert "[debugger] Rewrite the ScopeIterator/DebugEvaluate to use Scope rather than ScopeInfo for inner scopes."
      
      This reverts commit 9e27d473.
      
      Reason for revert: Layout Test failures: https://ci.chromium.org/buildbot/client.v8.fyi/V8-Blink%20Linux%2064/24123
      
      Original change's description:
      > [debugger] Rewrite the ScopeIterator/DebugEvaluate to use Scope rather than ScopeInfo for inner scopes.
      > 
      > This CL also bottlenecks all current scope handling in the ScopeIterator, and cleans up frame handling in debug-frames and the deoptimizer.
      > 
      > Change-Id: I061922a356ce17794262f8d77d5d7c824558fc50
      > Reviewed-on: https://chromium-review.googlesource.com/1095094
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53741}
      
      TBR=yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,jgruber@chromium.org,verwaest@chromium.org
      
      Change-Id: I892856056258e3c68b36409b8b2d69e7686fc385
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/1102377
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53756}
      23b8d2fd
    • Toon Verwaest's avatar
      Reland "[debugger] Rewrite the ScopeIterator/DebugEvaluate to use Scope rather... · 4936efb0
      Toon Verwaest authored
      Reland "[debugger] Rewrite the ScopeIterator/DebugEvaluate to use Scope rather than ScopeInfo for inner scopes."
      
      This is a reland of 9e27d473
      
      Original change's description:
      > [debugger] Rewrite the ScopeIterator/DebugEvaluate to use Scope rather than ScopeInfo for inner scopes.
      > 
      > This CL also bottlenecks all current scope handling in the ScopeIterator, and cleans up frame handling in debug-frames and the deoptimizer.
      > 
      > Change-Id: I061922a356ce17794262f8d77d5d7c824558fc50
      > Reviewed-on: https://chromium-review.googlesource.com/1095094
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53741}
      
      Change-Id: I05262fef66d852876b9bb2869339053629c9b51d
      Reviewed-on: https://chromium-review.googlesource.com/1102297Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53751}
      4936efb0
  22. 14 Jun, 2018 2 commits
  23. 11 Apr, 2018 1 commit
  24. 05 Apr, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      Reland "[debug] introduced runtime side effect check" · 71018812
      Alexey Kozyatinskiy authored
      This is a reland of 7a2c3713
      
      Original change's description:
      > [debug] introduced runtime side effect check
      > 
      > This CL demonstrates minimum valuable addition to existing debug evaluate
      > without side effects mechanism.
      > With this CL user can evaluate expressions like:
      > [a,b] // create any kind of temporary array literals
      > [a,b].reduce((x,y) => x + y, 0); // use reduce method
      > [1,2,3].fill(2); // change temporary arrays
      > 
      > The core idea: any change of the object created during evaluation without
      > side effects is side effect free. As soon as we try to store this temporary
      > object to object existed before evaluation we will terminate execution.
      > 
      > Implementation:
      > - track all objects allocated during evaluation and mark them as temporary,
      > - patch all bytecodes which change objects.
      > 
      > A little more details (including performance analysis): [1].
      > 
      > [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
      > 
      > Bug: v8:7588
      > Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
      > Reviewed-on: https://chromium-review.googlesource.com/972615
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52370}
      
      Bug: v8:7588
      Change-Id: Ibc92bf19155f2ddaedae39b0c576b994e84afcf8
      Reviewed-on: https://chromium-review.googlesource.com/996760Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52373}
      71018812
  25. 04 Apr, 2018 2 commits
    • Aleksey Kozyatinskiy's avatar
      Revert "[debug] introduced runtime side effect check" · 539a2443
      Aleksey Kozyatinskiy authored
      This reverts commit 7a2c3713.
      
      Reason for revert: msan is broken
      
      Original change's description:
      > [debug] introduced runtime side effect check
      > 
      > This CL demonstrates minimum valuable addition to existing debug evaluate
      > without side effects mechanism.
      > With this CL user can evaluate expressions like:
      > [a,b] // create any kind of temporary array literals
      > [a,b].reduce((x,y) => x + y, 0); // use reduce method
      > [1,2,3].fill(2); // change temporary arrays
      > 
      > The core idea: any change of the object created during evaluation without
      > side effects is side effect free. As soon as we try to store this temporary
      > object to object existed before evaluation we will terminate execution.
      > 
      > Implementation:
      > - track all objects allocated during evaluation and mark them as temporary,
      > - patch all bytecodes which change objects.
      > 
      > A little more details (including performance analysis): [1].
      > 
      > [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
      > 
      > Bug: v8:7588
      > Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
      > Reviewed-on: https://chromium-review.googlesource.com/972615
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52370}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,leszeks@chromium.org
      
      Change-Id: Ied1739c6308b13a4981189e0999f5912316cf456
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7588
      Reviewed-on: https://chromium-review.googlesource.com/996135Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52371}
      539a2443
    • Alexey Kozyatinskiy's avatar
      [debug] introduced runtime side effect check · 7a2c3713
      Alexey Kozyatinskiy authored
      This CL demonstrates minimum valuable addition to existing debug evaluate
      without side effects mechanism.
      With this CL user can evaluate expressions like:
      [a,b] // create any kind of temporary array literals
      [a,b].reduce((x,y) => x + y, 0); // use reduce method
      [1,2,3].fill(2); // change temporary arrays
      
      The core idea: any change of the object created during evaluation without
      side effects is side effect free. As soon as we try to store this temporary
      object to object existed before evaluation we will terminate execution.
      
      Implementation:
      - track all objects allocated during evaluation and mark them as temporary,
      - patch all bytecodes which change objects.
      
      A little more details (including performance analysis): [1].
      
      [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
      
      Bug: v8:7588
      Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
      Reviewed-on: https://chromium-review.googlesource.com/972615
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52370}
      7a2c3713
  26. 12 Mar, 2018 1 commit
  27. 06 Mar, 2018 1 commit
  28. 28 Feb, 2018 1 commit
  29. 29 Nov, 2017 1 commit
  30. 07 Sep, 2017 1 commit
  31. 01 Sep, 2017 1 commit
  32. 12 Apr, 2017 1 commit
  33. 10 Feb, 2017 1 commit
  34. 09 Feb, 2017 2 commits
  35. 12 Jan, 2017 1 commit