1. 21 Jul, 2021 2 commits
  2. 20 Jul, 2021 1 commit
    • Mythri A's avatar
      Reland "[sparkplug] Support bytecode / baseline code flushing with sparkplug" · 3ae733f9
      Mythri A authored
      This is a reland of ea55438a. Relanding
      after a fix lands here:
      https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures
      were caused because baseline code could be flushed during the process
      of deoptimization after we choose which entry (InterpreterEnterAt* /
      BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect
      baseline code but it could be flushed before we execute the builtin. The
      fix is to defer the decision.
      
      Original change's description:
      > [sparkplug] Support bytecode / baseline code flushing with sparkplug
      >
      > Currently with sparkplug we don't flush bytecode / baseline code of
      > functions that were tiered up to sparkplug. This CL adds the support to
      > flush baseline code / bytecode of functions that have baseline code too.
      > This CL:
      > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
      > JSFunction as a custom weak pointer where the code is treated as weak if
      > the bytecode corresponding to this function is old.
      > 2. Updates GC to handle the functions that had a weak code object during
      > the atomic phase of GC.
      > 3. Updates the check for old bytecode to also consider when there is
      > baseline code on the function.
      >
      > This CL doesn't change any heuristics for flushing. The baseline code
      > will be flushed at the same time as bytecode.
      >
      > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
      > Bug: v8:11947
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75674}
      
      Bug: v8:11947
      Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75810}
      3ae733f9
  3. 12 Jul, 2021 2 commits
    • Mythri Alle's avatar
      Revert "[sparkplug] Support bytecode / baseline code flushing with sparkplug" · a079f057
      Mythri Alle authored
      This reverts commit ea55438a.
      
      Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview
      
      Original change's description:
      > [sparkplug] Support bytecode / baseline code flushing with sparkplug
      >
      > Currently with sparkplug we don't flush bytecode / baseline code of
      > functions that were tiered up to sparkplug. This CL adds the support to
      > flush baseline code / bytecode of functions that have baseline code too.
      > This CL:
      > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
      > JSFunction as a custom weak pointer where the code is treated as weak if
      > the bytecode corresponding to this function is old.
      > 2. Updates GC to handle the functions that had a weak code object during
      > the atomic phase of GC.
      > 3. Updates the check for old bytecode to also consider when there is
      > baseline code on the function.
      >
      > This CL doesn't change any heuristics for flushing. The baseline code
      > will be flushed at the same time as bytecode.
      >
      > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
      > Bug: v8:11947
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75674}
      
      Bug: v8:11947
      Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75679}
      a079f057
    • Mythri A's avatar
      [sparkplug] Support bytecode / baseline code flushing with sparkplug · ea55438a
      Mythri A authored
      Currently with sparkplug we don't flush bytecode / baseline code of
      functions that were tiered up to sparkplug. This CL adds the support to
      flush baseline code / bytecode of functions that have baseline code too.
      This CL:
      1. Updates the BodyDescriptor of JSFunction to treat the Code field of
      JSFunction as a custom weak pointer where the code is treated as weak if
      the bytecode corresponding to this function is old.
      2. Updates GC to handle the functions that had a weak code object during
      the atomic phase of GC.
      3. Updates the check for old bytecode to also consider when there is
      baseline code on the function.
      
      This CL doesn't change any heuristics for flushing. The baseline code
      will be flushed at the same time as bytecode.
      
      Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
      Bug: v8:11947
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75674}
      ea55438a
  4. 21 Jun, 2021 1 commit
  5. 10 Jun, 2021 1 commit
  6. 02 Jun, 2021 2 commits
  7. 27 May, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Implement array.copy (experimental) · dfdc8f68
      Manos Koukoutos authored
      Changes:
      - Add --experimental-wasm-gc-experiments flag.
      - Add array.copy opcode. Implement it in decoding and code generation
        behind the new flag.
      - Add WasmCodeBuilder::BoundsCheckArrayCopy. Move BoundsCheckArray to
        the private section.
      - Add WasmArrayCopy and WasmArrayCopyWithChecks builtin.
      - Add WasmArrayCopy runtime function.
      - Add WasmArray::ElementSlot.
      - Always print two hex digits in CHECK_PROTOTYPE_OPCODE.
      - In test-gc, print the thrown-error message if the function should not
        throw.
      - In test-gc, add GetResultObject with one argument.
      
      Bug: v8:7748
      Change-Id: I58f4d37e254154596cdef5e78482b55260dd3782
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912729
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74806}
      dfdc8f68
  8. 06 Apr, 2021 1 commit
  9. 22 Mar, 2021 2 commits
    • Clemens Backes's avatar
      [wasm][debug] Leave stepping code early · 0de9a7e6
      Clemens Backes authored
      Stepping code that is left on the stack will repeatedly call the
      WasmDebugBreak function. This has no observable effect, except for
      severe slowdown of execution. In the linked bug, we were executing at
      least another few million instructions in the same frame, so it appeared
      that it never finishes.
      
      This CL fixes that by replacing stepping code with non-stepping code if
      the WasmDebugBreak runtime function is called from stepping code but we
      are not stepping (any more).
      Adding a test for this is difficult, since this only has an effect on
      performance.
      
      R=thibaudm@chromium.org
      
      Bug: chromium:1153308
      Change-Id: I02feb04a156dfe81ca76ce26f0af131c470ef7a3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2775575
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73567}
      0de9a7e6
    • Clemens Backes's avatar
      [wasm] Remove template arguments from FrameFinder · 77f452ed
      Clemens Backes authored
      The frame types to skip are only used in the constructor, hence pass
      them as an initializer_list instead of template arguments.
      
      R=thibaudm@chromium.org
      
      Bug: v8:11384
      Change-Id: I3ee57076a94514e5755f6f6541ebd9222306a634
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2775574Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73562}
      77f452ed
  10. 19 Mar, 2021 1 commit
  11. 05 Mar, 2021 2 commits
  12. 23 Feb, 2021 1 commit
  13. 18 Feb, 2021 1 commit
  14. 17 Feb, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Refactor runtime functions for throw · 98966f56
      Clemens Backes authored
      We made two runtime calls: The first one allocated the exception object
      containing a FixedArray of exception values, the second call did the
      actual throw. Inbetween the code was filling the values array.
      This CL refactors this to only allocate the FixedArray initially, fill
      it, and then allocate the actual exception and throw it both from the
      second runtime function.
      This avoids a WasmGetOwnProperty call to find the values array.
      
      R=thibaudm@chromium.org
      
      Bug: v8:11453
      Change-Id: I091aaa5c7bfb2b5579fc92c953adf582e6cc175a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697359
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72811}
      98966f56
  15. 12 Feb, 2021 3 commits
    • Clemens Backes's avatar
      [wasm][debug] Implement instrumentation breakpoints · 15f3392a
      Clemens Backes authored
      This CL adds support for instrumentation breakpoints in wasm. The
      request for "break on entry" is set on the script, and we need to keep
      it stored there because there might not be any instances of that wasm
      module yet. Once instances get created, the flag value is transferred to
      all instances. The flag stored there is then checked in the function
      prologue in Liftoff debugging code. This ensures that we will stop at
      the first valid break position in any function within that module.
      Hitting that instrumentation breakpoint will then clear the flag from
      the script and from all other live instances (in the same isolate).
      
      A first basic test is contained in this CL. More tests will be added
      later.
      
      R=thibaudm@chromium.org, bmeurer@chromium.org
      
      Bug: chromium:1151211
      Change-Id: I5442d4044934988269becececc03699b850d51d7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690588Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72701}
      15f3392a
    • Benedikt Meurer's avatar
      [stack-traces] Simplify and speedup stack trace collection. · eed0d27c
      Benedikt Meurer authored
      Following up on https://crrev.com/c/2689185, this CL significantly
      simplifies the whole implementation of the stack trace capturing.
      
      Before this CL, capturing any stack trace (for the purpose of the API or
      Error.stack) would roughly work like this:
      
        1. The CaptureStackTrace() function uses the StackFrameIterator to
           walk the system stack. For each native frame it uses the
           FrameSummary abstraction to get all (including potentially inlined)
           frames. For each of those it appends a record consisting of six
           elements to a FrameArray (this holds pointers to the actual
           closures and receivers).
        2. Afterwards the FrameArray is shrinked to the required size, and a
           new FixedArray is allocated, and initialized with new
           StackTraceFrame objects where each holds a reference to the
           FrameArray, the index of the frame, and an initially uninitialized
           StackFrameInfo reference. This new FixedArray is then returned from
           CaptureStackTrace() and either stored on a message object or
           provided to the API as v8::StackTrace.
      
      The new approach removes a lot of the machinery in between and directly
      creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
      These StackFrameInfo objects are directly exposed as v8::StackFrame on
      the public API, and they hold the six fields that were previously stored
      flat in the FrameArray. This not only avoids a lot of copying around of
      data and creation of temporary objects and handles, but most importantly
      unifies and simplifies the stack frame function inside StackFrameInfo,
      so you no longer need to wonder which function / object might be
      responsible for a certain API.
      
      There's still a lot of room for improvement. In particular we currently
      don't cache the source position for a given StackFrameInfo (or
      globally), but rather recompute it every time. This is still very fast,
      significantly faster than the previous approach.
      
      There are some notable (potentially user visible) changes:
      
        - The CallSite#GetPosition() method now consistently returns the
          Wasm module relative bytecode offset for all Wasm frames (previously
          it'd return the function relative bytecode offset for non-asm.js
          Wasm frames).
        - The column and line numbers returned from StackFrameInfo methods are
          consistently 1-based now, instead of sometimes being 0-based (Wasm)
          and sometimes being 1-based (JS and asm.js Wasm). The only
          potentially noticable difference is that for
          CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
          that was wrong and useless anyways.
        - CallSite#GetThis() would sometimes return the_hole, another bug
          flushed out by this CL.
      
      The CL also contains some other not noteworthy drive-by-cleanups.
      
      Fixed: chromium:1057211
      Bug: chromium:1077657, chromium:1069425, v8:8742
      Bug: chromium:1127391, chromium:1098530, chromium:981541
      Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72694}
      eed0d27c
    • Thibaud Michaud's avatar
      [wasm][eh] Add metrics for exception events · 27b8ad20
      Thibaud Michaud authored
      Sample elapsed time between two consecutive exception events of the same
      type (throw/rethrow/catch). This will give us an idea of how frequently
      exception handling features are used at runtime during the origin trial.
      
      R=ahaas@chromium.org
      
      Bug: v8:8091
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Change-Id: Ic3095eeeca08d2e079a507a492f10d2efb5ecfd2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684367Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72685}
      27b8ad20
  16. 02 Feb, 2021 1 commit
  17. 29 Jan, 2021 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Add test for code garbage-collection · f18ced0f
      Clemens Backes authored
      This adds a regression test for https://crrev.com/c/2652488. The test
      reduces the available code space such that it would trigger an OOM
      condition if code is not garbage-collected.
      In order to guarantee garbage-collection in all configurations, an
      explicit interrupt check is added to the WasmDebugBreak runtime
      function.
      
      R=thibaudm@chromium.org
      
      Bug: chromium:1168564
      Change-Id: I8fce7aa5128c9e3c9a7e2d2e7397c394fec7de85
      Cq-Include-Trybots: luci.v8.try:v8_linux64_asan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_mac64_asan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652490
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72435}
      f18ced0f
  18. 08 Dec, 2020 3 commits
    • Clemens Backes's avatar
      Reland "[wasm] Pass the script ID to code logging" · a58a5e59
      Clemens Backes authored
      This is a reland of ab4d9717.
      The original CL did a std::move before the final use of the NativeModule.
      PS2 removes that.
      
      TBR=petermarshall@chromium.org, thibaudm@chromium.org
      
      Original change's description:
      > [wasm] Pass the script ID to code logging
      >
      > We didn't pass a script ID with the code creation events for profiling.
      > This made DevTools lose the connection to the wasm script, hence
      > jumping from the profiler entry to the source did not work.
      >
      > This CL changes the timing of code logging a bit such that the script is
      > always allocated before logging. In the queue of code to be logged we
      > then also store the script ID, and finally set it on the {CodeEntry}
      > object.
      >
      > R=thibaudm@chromium.org
      >
      > Bug: chromium:1125986
      > Change-Id: I2248c1d520bc819436bbe732373f7a3446b64f48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575057
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71654}
      
      Bug: chromium:1125986
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Change-Id: I2a7c5fe04fff726836b1279e3d05b1702a4efb76
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2578980Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71663}
      a58a5e59
    • Clemens Backes's avatar
      Revert "[wasm] Pass the script ID to code logging" · 8d013ea1
      Clemens Backes authored
      This reverts commit ab4d9717.
      
      Reason for revert: UBSan issues: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/14184/overview
      
      Original change's description:
      > [wasm] Pass the script ID to code logging
      >
      > We didn't pass a script ID with the code creation events for profiling.
      > This made DevTools lose the connection to the wasm script, hence
      > jumping from the profiler entry to the source did not work.
      >
      > This CL changes the timing of code logging a bit such that the script is
      > always allocated before logging. In the queue of code to be logged we
      > then also store the script ID, and finally set it on the {CodeEntry}
      > object.
      >
      > R=​thibaudm@chromium.org
      >
      > Bug: chromium:1125986
      > Change-Id: I2248c1d520bc819436bbe732373f7a3446b64f48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575057
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71654}
      
      TBR=petermarshall@chromium.org,clemensb@chromium.org,thibaudm@chromium.org
      
      Change-Id: I03c90c77b55e770797a6d66b1d778992a047e07a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1125986
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575070Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71660}
      8d013ea1
    • Clemens Backes's avatar
      [wasm] Pass the script ID to code logging · ab4d9717
      Clemens Backes authored
      We didn't pass a script ID with the code creation events for profiling.
      This made DevTools lose the connection to the wasm script, hence
      jumping from the profiler entry to the source did not work.
      
      This CL changes the timing of code logging a bit such that the script is
      always allocated before logging. In the queue of code to be logged we
      then also store the script ID, and finally set it on the {CodeEntry}
      object.
      
      R=thibaudm@chromium.org
      
      Bug: chromium:1125986
      Change-Id: I2248c1d520bc819436bbe732373f7a3446b64f48
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575057
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71654}
      ab4d9717
  19. 26 Nov, 2020 1 commit
  20. 18 Nov, 2020 1 commit
    • Andreas Haas's avatar
      [wasm] Fix trap handler DCHECK in IsValidRefValue · 1bd9b66c
      Andreas Haas authored
      There is a flag in the WebAssembly trap handler that is set whenever
      WebAssembly code is entered, and that is reset when WebAssembly code is
      left. In runtime functions we have DCHECKs in place that check the
      value of this flag.
      
      This flag is only needed when trap handlers are enabled though. When
      trap handlers are disabled, the flag is not enabled and disabled
      consistently. DCHECKs should therefore only check the flag value when
      trap handlers are actually enabled.
      
      R=manoskouk@chromium.org
      CC=vkont@google.com
      
      Bug: v8:10982
      Change-Id: I3325f6057ff8d9c39d029ef04c55792162d927f6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545708Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71261}
      1bd9b66c
  21. 11 Nov, 2020 1 commit
  22. 06 Nov, 2020 1 commit
  23. 22 Oct, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][memory64] Prepare atomic builtins for i64 indexes · 729235c2
      Clemens Backes authored
      The offset (also called "address") passed to the atomic builtins was
      32-bit until now. With memory64, we will have to also accept 64-bit
      values there, or at least values within the allocatable memory range.
      This CL thus changes the builtins to receive uintptr values instead of
      uint32, and pass them on to the runtime functions as double (as before).
      The runtime then casts them back to uintptr_t instead of uint32_t.
      
      Liftoff is extended to zero-extend the uint32 value if needed. TurboFan
      already passed a machine-word sized integer before.
      
      Drive-by: Rename some "address" to "offset" to make the semantics more
      clear.
      
      R=ahaas@chromium.org
      CC=​​manoskouk@chromium.org
      
      Bug: v8:10949
      Change-Id: I66968cc99a908775156c952da46d2f26219ffb58
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489685
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70700}
      729235c2
  24. 21 Oct, 2020 1 commit
  25. 14 Oct, 2020 1 commit
  26. 21 Sep, 2020 1 commit
  27. 18 Sep, 2020 2 commits
  28. 11 Aug, 2020 1 commit
  29. 28 Jul, 2020 1 commit
  30. 24 Jul, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Don't automatically remove breakpoints · 6880a8dd
      Clemens Backes authored
      Out of the four listed reasons, two are obsolete now, since stepping
      does not modify the code table any more. The first reason also cannot
      happen any more, since removing a breakpoint will also patch the stack
      of the isolate, and even if not, removing a breakpoint which is not set
      will have no effect (not even a stack rewriting). The same applies for
      the last listed reason.
      
      So overall, this code is not needed any more, since it has no effect.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10611
      Change-Id: I773ac2515b66e8bf66cb035c315db552024485c3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316299Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69041}
      6880a8dd