1. 19 May, 2022 1 commit
  2. 26 Apr, 2022 1 commit
    • Andreas Haas's avatar
      [wasm] Add check that lazy compilation does not trigger a GC · b22f0e6d
      Andreas Haas authored
      For lazy compilation there is one generic lazy compilation builtin that
      spills all registers on the stack and then triggers the compilation of
      the called function. Some of these registers may contain references.
      If a GC was triggered during lazy compilation, the GC would have to
      know which spill slots on the stack contain references.
      
      This CL adds a check to guarantee that no GC can be triggered during
      lazy compilation. Thereby it is not necessary for the GC to know which
      spill slots contain references.
      
      If successful, lazy compilation indeed does not allocate on the heap
      and therefore cannot trigger a GC. However, when compilation fails, an
      error objects needs to be allocated and thrown. This allocation may
      trigger a GC, but that's not a problem, because the reference
      parameters which may get corrupted by the GC will not be used anyways,
      because the called function will never get executed after the failed
      compilation.
      
      R=clemensb@chromium.org
      
      Fixes: v8:11366
      Change-Id: Ic526d169d4e80ba83f517970ff234e669f854331
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599474Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80187}
      b22f0e6d
  3. 27 Jan, 2022 1 commit
    • Andreas Haas's avatar
      [wasm] Adjust EstimateNativeModuleCodeSize to dynamic tiering · ea8da506
      Andreas Haas authored
      With dynamic tiering, the total amount of code generated for a
      WebAssembly module decreases significantly. However, the amount of
      code space we reserved for generated code has not been adjusted yet.
      This CL adds a parameter for dynamic tiering to
      EstimateNativeModuleCodeSize. If dynamic tiering is used, then the code
      space reserved for TurboFan gets reduced to a quarter of the code space
      without dynamic tiering.
      
      Reserving a quarter of the space seems to be still quite generous. Even
      Google Earth, seems to use a lot of its code, only needs less than 20%.
      
      R=clemensb@chromium.org
      
      Bug: chromium:1285334
      Change-Id: I7dce0821b5e46d7240dfb1523031de84b1fe1348
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420307Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78826}
      ea8da506
  4. 14 Jan, 2022 1 commit
  5. 01 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Enqueue tasks for non-eager inner funcs · 5ab1ec1e
      Leszek Swirski authored
      Add suppose for compiling non-eager, non-top-level inner functions in
      parallel, using the compiler dispatcher. This behaviour can be enabled
      with --parallel-compile-tasks-for-lazy.
      
      There are a couple of consequences:
      
        * To support this we need support for off-thread ScopeInfo
          deserialization, so this adds that too.
        * The previous --parallel-compile-tasks flag is renamed to the more
          descriptive --parallel-compile-tasks-for-eager-toplevel.
        * Both parallel-compile-tasks flags are moved onto
          UnoptimizedCompileFlags so that they can be enabled/disabled on a
          per-compile basis (e.g. enabled for streaming, disabled for
          re-parsing).
        * asm.js compilations can now happen without an active Context (in
          the compiler dispatcher's idle finalization) so we can't get a
          ContextId for metric reporting; we'd need to somehow fix this if we
          wanted asm.js UKM but for now it's probably fine.
        * Took the opportunity to clean up some of the "can preparse" logic in
          the parser.
      
      Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78183}
      5ab1ec1e
  6. 12 Nov, 2021 1 commit
  7. 07 Oct, 2021 1 commit
  8. 08 Sep, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Add unit tests for code protection · c9704cf7
      Clemens Backes authored
      This adds some basic tests for WebAssembly code protection, in four
      different configurations:
      - no protection
      - mprotect-based protection
      - PKU-based protection
      - PKU with fallback to mprotect
      
      If PKU is not supported by the OS or hardware, then PKU is identical to
      no protection, and PKU with fallback is identical to mprotect. We always
      execute all four configurations anyway.
      If protection is effective, we expect code to be writable within a
      {CodeSpaceWriteScope}, and not writable otherwise. When trying to write
      to non-writable code, we expect a crash of the process (checked via
      {ASSERT_DEATH_IF_SUPPORTED}).
      
      R=jkummerow@chromium.org
      CC=​mpdenton@chromium.org
      
      Bug: v8:11974
      Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_dbg_ng
      Change-Id: I4ec0ce9426f70ff41a292b9ea25be1e8956a670e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3138210
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76726}
      c9704cf7
  9. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored
      This is a reland of d1b27019
      
      Fixes include:
      Adding missing file to bazel build
      Forward-declaring classing before friend-classing them to fix win/gcc
      Add missing v8-isolate.h include for vtune builds
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
      Bug: v8:11965
      Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  10. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored
      This reverts commit d1b27019.
      
      Reason for revert: Broke vtune build, tsan build and possibly others
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Bug: v8:11965
      Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored
      This moves every single class/function out of include/v8.h into a
      separate header in include/, which v8.h then includes so that
      externally nothing appears to have changed.
      
      Every include of v8.h from inside v8 has been changed to a more
      fine-grained include.
      
      Previously inline functions defined at the bottom of v8.h would call
      private non-inline functions in the V8 class. Since that class is now
      in v8-initialization.h and is rarely included (as that would create
      dependency cycles), this is not possible and so those methods have been
      moved out of the V8 class into the namespace v8::api_internal.
      
      None of the previous files in include/ now #include v8.h, which means
      if embedders were relying on this transitive dependency then it will
      give compile failures.
      
      v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      that Chrome continue to compile but that change will be reverted once
      those transitive #includes in chrome are changed to include it directly.
      
      Full design:
      https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      
      Bug: v8:11965
      Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  11. 21 Jun, 2021 1 commit
  12. 18 Jun, 2021 1 commit
  13. 16 Mar, 2021 1 commit
  14. 19 Jan, 2021 1 commit
  15. 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
  16. 19 Oct, 2020 1 commit
  17. 28 Sep, 2020 1 commit
    • Jakob Kummerow's avatar
      [wasm] Make an "incumbent context" available after async compilation · 74e42008
      Jakob Kummerow authored
      A Wasm module's start function might be imported from JavaScript, and
      as such might contain calls to Blink. For such a case, we must make
      sure that an "incumbent context" is available. Usually, having any
      JavaScript function on the stack is enough to ensure that; but in the
      special case of async compilation, the "success" task is executed
      directly from the event loop, so we have to manually enter a context.
      
      Additionally, we need to ensure that such a start function's own context
      is properly entered: in addition to setting it as the current context
      on the isolate (as the function call sequence is doing), we have to
      register it in the list of entered contexts, as if v8::Context::Enter
      had been used.
      
      Bug: chromium:1096558
      Change-Id: I12679ab49ee764572e3742da24889dcd55c29160
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292248Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70175}
      74e42008
  18. 24 Sep, 2020 1 commit
  19. 22 Sep, 2020 2 commits
  20. 17 Aug, 2020 1 commit
  21. 05 Aug, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Switch compilation to Jobs API · 0c837e83
      Clemens Backes authored
      Use the new jobs API for WebAssembly compilation. This avoids having to
      schedule as many background tasks as there are worker threads. Instead
      the one job specifies the maximum concurrency, which changes dynamically
      as new compile jobs become available.
      This also avoids the artificial deadline we used to ensure that other
      tasks get some share of the CPU resources if needed.
      
      Even though this CL moves actual wasm function completely over to the
      Jobs API, other similar tasks (like wrapper compilation) are still using
      the Task API and need to be ported in a follow-up CL.
      Also, we are still using the same priority for baseline compilation and
      tier up. We should split this in a follow-up CL to have two jobs with
      different priorities. This will also allow us to only block on baseline
      compilation where we currently block on both.
      
      R=ahaas@chromium.org
      CC=gab@chromium.org
      
      Bug: chromium:1101340
      Change-Id: I5656697753346e5fdb15d578425cdb949ac6e364
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280100
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69239}
      0c837e83
  22. 28 Jul, 2020 1 commit
  23. 21 Jul, 2020 2 commits
    • Arnaud Robin's avatar
      [wasm] Implement dynamic tiering in wasm · f181dff3
      Arnaud Robin authored
      On desktop systems, we use a very basic tiering strategy: Everything is
      initially compiled with Liftoff, and once that is done, the module can
      start being used. Concurrently to the execution, we re-compile all code
      with TurboFan, and hot-swap each function once TurboFan finishes.
      
      We should start using a more dynamic strategy where each function is
      tiered-up when judged necessary. This change will then tier-up each
      liftoff function once it has been called 5 times.
      
      I then added a counter in the native module, that is updated directly
      from Liftoff code, and a runtime call is then made when the counter
      reaches the goal.
      
      R=clemensb@chromium.org
      CC=​thibaudm@chromium.org
      
      Bug: v8:10728
      Change-Id: I8dc2b02fdff8d97781bb1cf496886594b3d7f644
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2306803
      Commit-Queue: Arnaud Robin <arobin@google.com>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68971}
      f181dff3
    • Clemens Backes's avatar
      [wasm] Use jobs API for wrapper compilation · 7cfd1a88
      Clemens Backes authored
      Move wrapper compilation to the jobs API. Moving function compilation is
      much more complex and will be done in a follow-up CL.
      
      R=ahaas@chromium.org
      CC=krivoy@chromium.org
      
      Bug: chromium:1101340
      Change-Id: I0749e52a88264b725bba28252a6c76ae3338bb0e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2301933Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68965}
      7cfd1a88
  24. 24 Jun, 2020 1 commit
  25. 23 Jun, 2020 1 commit
  26. 11 May, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Make recompilation isolate-independent · 14984372
      Clemens Backes authored
      Passing an isolate to {RecompileNativeModule} feels wrong, since
      compilation and the generated code are totally isolate-independent. In
      fact, the isolate is only used for updating counters.
      Instead of passing the counters instead, this CL just refactors the code
      to support a nullptr for the counters everywhere (some code paths
      already supported that). The few recompilation would not make a
      significant difference in the histograms anyway, and even have the risk
      of skewing the data.
      
      Drive-by 1: Rename {TierUp} to {StartTierUp} and update comments.
      Drive-by 2: Remove non-actionable TODO.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10359
      Change-Id: Ic027f939bbc55398b90784922130fe1fe5573b0c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187638Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67708}
      14984372
  27. 16 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Clean up tiering logic · a776ccaa
      Clemens Backes authored
      This cleans up several parts of the tiering logic.
      1) Instead of using the {ExecutionTier} to specify whether we do tier up
         or down, we introduce a new {TieringState} enum and use that
         consistently (also where a {bool} was used before).
      2) When tiering up or tiering down, always recompile all functions. It's
         very unlikely that we can reuse previous code anyway (tiering down is
         cheap enough to just always do it, and when tiering up we need to
         recompile everything anyway).
      3) Remove the {WasmEngine::RecompileAllFunctions} method and inline the
         implementation into callers.
      4) Drive-by: Remove some obsolete comments and fix or extend others.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10410
      Change-Id: Ic765c6760dd97473ccfd469f22a2514695075587
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151355Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67175}
      a776ccaa
  28. 09 Apr, 2020 3 commits
  29. 27 Feb, 2020 1 commit
  30. 03 Feb, 2020 1 commit
    • Thibaud Michaud's avatar
      Reland "Reland "[wasm] Cache streaming compilation result"" · ab6c4669
      Thibaud Michaud authored
      This is a reland of 9781aa07
      
      Original change's description:
      > Reland "[wasm] Cache streaming compilation result"
      >
      > This is a reland of 015f379a
      >
      > Original change's description:
      > > [wasm] Cache streaming compilation result
      > >
      > > Before compiling the code section, check whether the
      > > bytes received so far match a cached module. If they do, delay
      > > compilation until we receive the full bytes, since we are likely to find
      > > a cache entry for them.
      > >
      > > R=clemensb@chromium.org
      > >
      > > Bug: v8:6847
      > > Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
      > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66000}
      >
      > Bug: v8:6847
      > Change-Id: I0b5acffa01aeb7dade3dc966392814383d900015
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022951
      > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66047}
      
      Bug: v8:6847
      Change-Id: I272f56eee28010f34cc99df475164581c8b63036
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030741
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66081}
      ab6c4669
  31. 30 Jan, 2020 2 commits
  32. 27 Jan, 2020 1 commit