1. 26 Nov, 2020 1 commit
  2. 11 Nov, 2020 1 commit
  3. 18 Jun, 2020 2 commits
  4. 09 Jun, 2020 1 commit
    • Clemens Backes's avatar
      [utils] Add OwnedVector::NewForOverwrite · ff2e485f
      Clemens Backes authored
      The existing {OwnedVector::New} value-initializes all elements, which
      means zeroing them in case on integral types. In many cases though we
      know that we will overwrite the content anyway, so the initialization is
      redundant.
      In the case of assembly buffers for wasm compilation, this zeroing
      showed up with several percent of execution times for some benchmarks.
      
      Hence this CL introduces a new {OwnedVector::NewForOverwrite} (along the
      lines of {std::make_unique_for_overwrite}), which only
      default-initializes the values (meaning no initialization for integral
      values).
      
      R=thibaudm@chromium.org
      
      Bug: v8:10576
      Change-Id: I8d2806088acebe8a264dea2c7ed74b0423671d4f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237140
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68268}
      ff2e485f
  5. 17 Apr, 2020 2 commits
    • Clemens Backes's avatar
      [base] Fix {StaticCharVector} and add {StaticOneByteVector} · e04eb281
      Clemens Backes authored
      {StaticCharVector}, according to its name, should return a
      {Vector<const char>}. For getting a {Vector<const uint8_t>}, the method
      should be called {StaticOneByteVector}, analog to the
      {OneByteVector} methods that already exist.
      
      Also, {StaticCharVector} is constexpr, but {StaticOneByteVector} cannot
      be, since it contains a {reinterpret_cast}. The same holds for
      {Vector::cast} in general.
      
      This CL
      - changes the return type of {StaticCharVector} to be
        {Vector<const char>},
      - introduces a new {StaticOneByteVector} which returns
        {Vector<const uint8_t>},
      - fixes constexpr annotations at various methods returning {Vector}s,
      - refactors users of {StaticCharVector} to either use
        {StaticOneByteVector} instead, or work on {char} if that makes more
        sense.
      
      R=leszeks@chromium.org
      
      Bug: v8:10426
      Change-Id: I71e336097e41ad30f982aa6344ca3d67b3a01fe3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154196
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67213}
      e04eb281
    • Clemens Backes's avatar
      [base][vector] Test constexpr factories · 80e5e2b4
      Clemens Backes authored
      Test some constexpr factories. StaticCharVector is not actually
      constexpr, this will be fixed in a follow-up CL.
      
      R=leszeks@chromium.org
      
      Bug: v8:10426
      Change-Id: I16fdf79cd7d4b3f54d7cf73e15bdff2306810f06
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154192
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67210}
      80e5e2b4
  6. 05 Mar, 2020 3 commits
    • Clemens Backes's avatar
      Reland "[wasm] Further reduce the size of WasmCode" · 13cdf3a7
      Clemens Backes authored
      This is a reland of 79398ab0
      
      Original change's description:
      > [wasm] Further reduce the size of WasmCode
      >
      > Also, save dynamic allocations (plus their memory overhead).
      > This is realized by storing the relocation information, source position
      > table, and protected instruction information together in one "metadata"
      > byte array.
      > For each of the three components, we just store their size, such that
      > the accessors can return the respecitive {Vector} views as before.
      >
      > This makes each WasmCode object 24 bytes smaller on 64-bit
      > architectures. It also saves a few more bytes per code object because
      > less padding is needed for the individual allocations, and each dynamic
      > allocation comes with some constant memory overhead.
      >
      > Since the protected instructions will just be stored in a byte array
      > now, some APIs are refactored to just return that byte array directly
      > (instead of an array of {ProtectedInstructionData}). This also
      > simplifies serialization and deserialization, and will allow for
      > switching to a more compact representation in the future.
      >
      > Drive-by: Add some more checks to {Vector::cast} to protect against
      >   undefined behaviour.
      >
      > R=ahaas@chromium.org
      >
      > Bug: v8:10254
      > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66596}
      
      Tbr: ahaas@chromium.org
      Bug: v8:10254
      Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66598}
      13cdf3a7
    • Clemens Backes's avatar
      Revert "[wasm] Further reduce the size of WasmCode" · 28afd1c9
      Clemens Backes authored
      This reverts commit 79398ab0.
      
      Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10186
      
      Original change's description:
      > [wasm] Further reduce the size of WasmCode
      > 
      > Also, save dynamic allocations (plus their memory overhead).
      > This is realized by storing the relocation information, source position
      > table, and protected instruction information together in one "metadata"
      > byte array.
      > For each of the three components, we just store their size, such that
      > the accessors can return the respecitive {Vector} views as before.
      > 
      > This makes each WasmCode object 24 bytes smaller on 64-bit
      > architectures. It also saves a few more bytes per code object because
      > less padding is needed for the individual allocations, and each dynamic
      > allocation comes with some constant memory overhead.
      > 
      > Since the protected instructions will just be stored in a byte array
      > now, some APIs are refactored to just return that byte array directly
      > (instead of an array of {ProtectedInstructionData}). This also
      > simplifies serialization and deserialization, and will allow for
      > switching to a more compact representation in the future.
      > 
      > Drive-by: Add some more checks to {Vector::cast} to protect against
      >   undefined behaviour.
      > 
      > R=​ahaas@chromium.org
      > 
      > Bug: v8:10254
      > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66596}
      
      TBR=jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,tebbi@chromium.org
      
      Change-Id: Id80aa82cfce8942879031032b322ee66855b5600
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10254
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089933Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66597}
      28afd1c9
    • Clemens Backes's avatar
      [wasm] Further reduce the size of WasmCode · 79398ab0
      Clemens Backes authored
      Also, save dynamic allocations (plus their memory overhead).
      This is realized by storing the relocation information, source position
      table, and protected instruction information together in one "metadata"
      byte array.
      For each of the three components, we just store their size, such that
      the accessors can return the respecitive {Vector} views as before.
      
      This makes each WasmCode object 24 bytes smaller on 64-bit
      architectures. It also saves a few more bytes per code object because
      less padding is needed for the individual allocations, and each dynamic
      allocation comes with some constant memory overhead.
      
      Since the protected instructions will just be stored in a byte array
      now, some APIs are refactored to just return that byte array directly
      (instead of an array of {ProtectedInstructionData}). This also
      simplifies serialization and deserialization, and will allow for
      switching to a more compact representation in the future.
      
      Drive-by: Add some more checks to {Vector::cast} to protect against
        undefined behaviour.
      
      R=ahaas@chromium.org
      
      Bug: v8:10254
      Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66596}
      79398ab0
  7. 20 Feb, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Avoid unnecessary jump tables · 1403fd7d
      Clemens Backes authored
      If multiple code spaces are created, each of them currently gets its own
      jump table (on 64 bit platforms). Since we try to allocate new code
      spaces right after existing ones, this is often not necessary. We could
      instead reuse the existing jump table(s).
      This saves code space for the unneeded jump tables and avoid the cost of
      patching the redundant jump tables when we replace code objects.
      
      This CL implements this by checking whether an existing jump table (or
      pair of far jump table and (near) jump table) fully covers a new code
      space, and reuses the existing jump table in that case.
      
      R=ahaas@chromium.org
      
      Change-Id: Id8751b9c4036cf8f85f9baa2b0be8b2cfb5716ff
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043846Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66364}
      1403fd7d
  8. 20 Jan, 2020 1 commit
  9. 26 Nov, 2019 1 commit
  10. 25 Nov, 2019 1 commit
  11. 16 Oct, 2019 1 commit
  12. 13 Sep, 2019 1 commit
  13. 12 Jul, 2019 1 commit
  14. 24 May, 2019 1 commit
  15. 23 May, 2019 1 commit
  16. 03 May, 2019 1 commit
  17. 02 May, 2019 2 commits
    • Clemens Hammacher's avatar
      Revert "[wasm][gc] Free WasmCode objects" · 3ad63aef
      Clemens Hammacher authored
      This reverts commit b6fb2707.
      
      Reason for revert: TSan issues, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/26177
      
      Original change's description:
      > [wasm][gc] Free WasmCode objects
      > 
      > This adds the next step to freeing code: We free the actual C++
      > {WasmCode} objects. This will cause UAF if any C++ code uses stale
      > references.
      > The underlying machine code will still not be freed.
      > 
      > For simplicity, this CL changes the vector of owned_code to an ordered
      > set, such that lookup and removal is much simpler. The drawback is that
      > insertion is now more expensive.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: v8:8217
      > Change-Id: I07fc81167816637fbaad6c06ff79e3f952f2fde8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593080
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61165}
      
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      
      Change-Id: I167a8d806a8c6ac1c90e0743cdf86d492389bbed
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8217, v8:9200
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593305Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61176}
      3ad63aef
    • Clemens Hammacher's avatar
      [wasm][gc] Free WasmCode objects · b6fb2707
      Clemens Hammacher authored
      This adds the next step to freeing code: We free the actual C++
      {WasmCode} objects. This will cause UAF if any C++ code uses stale
      references.
      The underlying machine code will still not be freed.
      
      For simplicity, this CL changes the vector of owned_code to an ordered
      set, such that lookup and removal is much simpler. The drawback is that
      insertion is now more expensive.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8217
      Change-Id: I07fc81167816637fbaad6c06ff79e3f952f2fde8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593080
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61165}
      b6fb2707
  18. 30 Apr, 2019 1 commit
  19. 29 Apr, 2019 2 commits
    • Clemens Hammacher's avatar
      [cleanup] Remove {StrLength} function · 423b357b
      Clemens Hammacher authored
      The {Vector} class does not use it any more. External uses should be
      converted to {size_t} instead of {int}.
      This CL removes the function from vector.h and updates all users to
      either use {size_t}, or cast to {int} explicitly. In tests, no further
      checks are needed if the string is a constant.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:9183
      Change-Id: I60f99302504c74d8a7c79b147ca01d8ba61b6879
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587393Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61092}
      423b357b
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      Our {Vector} template provides both {start} and {begin} methods. They
      return exactly the same value. Since the {begin} method is needed for
      iteration, and is also what standard containers provide, this CL
      switches all uses of the {start} method to use {begin} instead.
      
      Patchset 1 was auto-generated by using this clang AST matcher:
          callExpr(
              callee(
                cxxMethodDecl(
                  hasName("start"),
                  ofClass(hasName("v8::internal::Vector")))
              ),
              argumentCountIs(0))
      
      Patchset 2 was created by running clang-format. Patchset 3 then
      removes the now unused {Vector::start} method.
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  20. 24 Apr, 2019 1 commit
  21. 23 Apr, 2019 3 commits
    • Clemens Hammacher's avatar
      Switch more {int} to {size_t} in Vector · 9cdb251c
      Clemens Hammacher authored
      The {Vector} class stores the size in a {size_t} since a while, but
      many accessors and constructors still accept an {int}. This CL removes
      all {int} uses except for the explicit {length()} accessor. It also
      adds a comment to avoid this accessor if possible.
      The {StrLength} function still has several users outside of vector.h,
      which I plan to remove in a follow-up CL.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8834
      Change-Id: I33c5b0e8b8b2cb3531716c1d99e4516a13d6ba1f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578480Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60950}
      9cdb251c
    • Clemens Hammacher's avatar
      [wasm][gc] Fix several minor issues · 0820ee1a
      Clemens Hammacher authored
      This CL fixes some issues with GC.
      1) It removes dead code from the set of potentially dead code to avoid
         considering the same code for GC again and again.
      2) It resets the {new_potentially_dead_code_size_} counter to avoid
         triggering too many GCs.
      3) When code becomes dead after GC, do not unconditionally free it; just
         decrement its ref count (there might still be {WasmCodeRefScope}s
         holding the code alive).
      4) Update the comment of the ref count to be more accurate.
      
      R=titzer@chromium.org
      
      Bug: v8:8217
      Change-Id: I28e5a1fed74411b8473bb66ddbad3ffe7643f266
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1574518
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60949}
      0820ee1a
    • Clemens Hammacher's avatar
      Disallow copy and assign of EmbeddedVector · 06d750b5
      Clemens Hammacher authored
      EmbeddedVector lives on the stack only, and should not be implicitly
      copied or assigned.
      This also removes remaining uses of the removed Vector::set_start
      method.
      
      R=sigurds@chromium.org
      
      Bug: v8:9142
      Change-Id: I829e6ffad6b1a30baa6c874265e92d615dd0c981
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578458Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60940}
      06d750b5
  22. 03 Apr, 2019 1 commit
  23. 26 Feb, 2019 1 commit
  24. 21 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      Reland "[wasm] Split compilation in three stages" · 6c2e35b9
      Clemens Hammacher authored
      This is a reland of 4e1d7c87.
      Failure on arm and arm64 is fixed by https://crrev.com/c/1411885.
      
      Original change's description:
      > [wasm] Split compilation in three stages
      >
      > In order to refactor ownership between objects in wasm compilation, the
      > compilation (executed by background tasks) is split in three stages:
      > getting a compilation unit (while holding a mutex), executing the work
      > (without any mutex and without keeping the NativeModule alive), and
      > submitting the work (with a mutex again).
      >
      > This CL prepares this design by splitting compilation from submission.
      > Both steps are still executed right after each other. This will be
      > changed in a follow-up CL.
      >
      > R=titzer@chromium.org
      > CC=mstarzinger@chromium.org
      >
      > Bug: v8:8689
      > Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902
      > Reviewed-on: https://chromium-review.googlesource.com/c/1414920
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58929}
      
      TBR=titzer@chromium.org
      
      Bug: v8:8689
      Change-Id: I58ff07d0e0ac8df0f6ee23c416f992954f4673d2
      Reviewed-on: https://chromium-review.googlesource.com/c/1422748Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58959}
      6c2e35b9
  25. 18 Jan, 2019 2 commits
    • Michael Achenbach's avatar
      Revert "[wasm] Split compilation in three stages" · b7cc4f7a
      Michael Achenbach authored
      This reverts commit 4e1d7c87.
      
      Reason for revert:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/14986
      
      Original change's description:
      > [wasm] Split compilation in three stages
      > 
      > In order to refactor ownership between objects in wasm compilation, the
      > compilation (executed by background tasks) is split in three stages:
      > getting a compilation unit (while holding a mutex), executing the work
      > (without any mutex and without keeping the NativeModule alive), and
      > submitting the work (with a mutex again).
      > 
      > This CL prepares this design by splitting compilation from submission.
      > Both steps are still executed right after each other. This will be
      > changed in a follow-up CL.
      > 
      > R=​titzer@chromium.org
      > CC=​mstarzinger@chromium.org
      > 
      > Bug: v8:8689
      > Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902
      > Reviewed-on: https://chromium-review.googlesource.com/c/1414920
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58929}
      
      TBR=titzer@chromium.org,clemensh@chromium.org
      
      Change-Id: Ic3d0287b354ef5f834b76bc2cdc096d2231f4477
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8689
      Reviewed-on: https://chromium-review.googlesource.com/c/1422917Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58932}
      b7cc4f7a
    • Clemens Hammacher's avatar
      [wasm] Split compilation in three stages · 4e1d7c87
      Clemens Hammacher authored
      In order to refactor ownership between objects in wasm compilation, the
      compilation (executed by background tasks) is split in three stages:
      getting a compilation unit (while holding a mutex), executing the work
      (without any mutex and without keeping the NativeModule alive), and
      submitting the work (with a mutex again).
      
      This CL prepares this design by splitting compilation from submission.
      Both steps are still executed right after each other. This will be
      changed in a follow-up CL.
      
      R=titzer@chromium.org
      CC=mstarzinger@chromium.org
      
      Bug: v8:8689
      Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902
      Reviewed-on: https://chromium-review.googlesource.com/c/1414920Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58929}
      4e1d7c87
  26. 03 Jan, 2019 1 commit
  27. 02 Jan, 2019 1 commit
  28. 15 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      [base] Introduce VectorOf helper · 3ad032b7
      Clemens Hammacher authored
      We often need to create a {Vector} view of data owned by a container
      like {std::vector}. The canonical way to do this is this:
      Vector<T>{vec.data(), vec.size()}
      
      This pattern is repeating information which can be deduced
      automatically, like the type T.
      
      This CL introduces a {VectorOf} helper which can construct a {Vector}
      for any container providing a {data()} and {size()} accessor, and uses
      it to replace the pattern above.
      
      R=ishell@chromium.org
      
      Bug: v8:8238
      Change-Id: Ib3a11662acc82cb83f2b4afd07ba88e579d71dba
      Reviewed-on: https://chromium-review.googlesource.com/c/1337584Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57538}
      3ad032b7
  29. 12 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Reset StreamingProcessor on error · 3b64603d
      Clemens Hammacher authored
      After the first decoder error, the streaming processor should not be
      called again. To enforce this, reset the {processor_} field. This also
      makes the {ok_} field redundant.
      Note that this refactoring is also necessary for a future CL which
      makes the {StreamingProcessor} keep the {AsyncCompileJob} alive. By
      resetting the processor, we also remove that link.
      
      R=ahaas@chromium.org
      
      Bug: v8:7921
      Change-Id: I42f5ed26a8f26c3dc8db5676557a0d82021e132e
      Reviewed-on: https://chromium-review.googlesource.com/c/1329179
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57435}
      3b64603d
  30. 12 Jul, 2018 1 commit
  31. 27 Jun, 2018 1 commit