1. 25 Aug, 2020 3 commits
  2. 19 Aug, 2020 1 commit
  3. 18 Aug, 2020 1 commit
  4. 03 Aug, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Check that all initial reservations succeed · c049a3bc
      Clemens Backes authored
      After allocating a new code space, we do some initial allocations in the
      new space (e.g. for the jump table). These allocations are not allowed
      to fail.
      If this in indeed what's happening in the linked bug, this CHECK will
      give fuzzers a chance to find us a reproducer.
      
      Drive-by: Introduce {WasmCodeAllocator::kUnrestrictedRegion} to remove
      magic constants.
      
      R=ahaas@chromium.org
      
      Bug: v8:1111266
      Change-Id: Ia76721653226bd4aa346b89ffab0c80f67892794
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2333250
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69204}
      c049a3bc
  5. 21 Jul, 2020 1 commit
    • 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
  6. 15 Jun, 2020 1 commit
    • Emanuel Ziegler's avatar
      [wasm] Do not log code of functions whose module is not fully loaded · 8ee54c92
      Emanuel Ziegler authored
      This is a reland of change Idb1061cafcba7a2a654a207402dca520f79a3bbe.
      The access to wire_bytes has been protected by using atomic operations.
      
      Under some circumstances, Wasm is trying to log code for which the
      wire bytes are not fully loaded yet. This can happen during streaming
      compilation when a few functions are already fully compiled but the
      engine is still streaming the remaining functions.
      
      If the profiler now kicks in, it will attempt to log these freshly
      compiled functions. As these functions will not be executed before
      the module is fully compiled, we can simply defer the logging in this
      case.
      
      R=clemensb@chromium.org
      
      Bug: chromium:1085852
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Change-Id: Iccb6607e8adb9fdaf6138d4ccd30de58d6a6cdff
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2230536
      Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68336}
      8ee54c92
  7. 05 Jun, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Fully tier up on Debugger.disable · 7637ed59
      Clemens Backes authored
      When the last debugger is disabled, we tier up the module to TurboFan.
      Doing this in the background creates problems with profiling, where the
      debugger is disabled before starting to profile, in order to guarantee
      profiling of top-tier code.
      
      Hence this CL changes the logic such that we only return from the
      {TierUpAllModulesPerIsolate} methods once tier up is complete. Since
      the DevTools frontend disables all debuggers before starting a profile,
      this will ensure that all new calls execute TurboFan code.
      Because of this change, the {TriggerRecompilation} method is renamed to
      {RecompileForTiering}.
      
      The test cases stay unchanged (do a busy wait until tier up is done),
      because in the multi-isolates tests it is not guaranteed that tier up is
      complete after disabling a single debugger.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10580
      Change-Id: I75c4b97825f856f562cfa656c11293d3b964898b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232539
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68212}
      7637ed59
  8. 03 Jun, 2020 1 commit
  9. 27 May, 2020 1 commit
  10. 25 May, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Avoid repeated recompilation · 447d7d67
      Clemens Backes authored
      If multiple isolates share the same module, and the debugger gets
      enabled, then we trigger tier down in each isolate separately. To avoid
      generating too much code, we only recompile functions that are not
      already in the right tier.
      
      This CL is only the first step towards an actual fix. Since we only
      check already installed code (and ignore compilations that are already
      scheduled), we might still compile the same functions multiple times. A
      second CL will make sure that only one recompilation is running at the
      same time.
      
      R=thibaudm@chromium.org
      
      Bug: chromium:1084369, v8:10359
      Change-Id: Ic4f9afac1add0fe8ad9e5d68f22d3d41ba2e52be
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2213438Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67957}
      447d7d67
  11. 20 May, 2020 1 commit
  12. 19 May, 2020 2 commits
  13. 18 May, 2020 1 commit
  14. 13 May, 2020 1 commit
  15. 12 May, 2020 1 commit
    • Clemens Backes's avatar
      Reland "[wasm][debug] Fix tier down for multiple isolates" · e62a7f76
      Clemens Backes authored
      This is a reland of 902f48bd, fixed
      to avoid lock inversion problems detected by TSan.
      
      Original change's description:
      > [wasm][debug] Fix tier down for multiple isolates
      >
      > If multiple isolates are using the same module, we need to keep it
      > tiered down as long as any isolate still has a debugger open.
      > Also, we cannot short-cut the {NativeModule::TierDown} method, since the
      > previously triggered tier down might not have finished yet.
      > For now, each isolate starts an independent tier down (i.e. a full
      > recompilation). We could optimize this later by skipping functions that
      > are already tiered down, or are already scheduled for tier down, but we
      > still need to wait for tier-down to finish on each isolate.
      >
      > R=thibaudm@chromium.org
      >
      > Bug: v8:10359
      > Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67716}
      
      Bug: v8:10359
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Change-Id: Ie98cf073fc79e5c6991df6d4466de7b560274070
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194451
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67754}
      e62a7f76
  16. 11 May, 2020 3 commits
    • Shu-yu Guo's avatar
      Revert "[wasm][debug] Fix tier down for multiple isolates" · 131fa2c9
      Shu-yu Guo authored
      This reverts commit 902f48bd.
      
      Reason for revert: Made TSAN unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/9480
      
      Original change's description:
      > [wasm][debug] Fix tier down for multiple isolates
      > 
      > If multiple isolates are using the same module, we need to keep it
      > tiered down as long as any isolate still has a debugger open.
      > Also, we cannot short-cut the {NativeModule::TierDown} method, since the
      > previously triggered tier down might not have finished yet.
      > For now, each isolate starts an independent tier down (i.e. a full
      > recompilation). We could optimize this later by skipping functions that
      > are already tiered down, or are already scheduled for tier down, but we
      > still need to wait for tier-down to finish on each isolate.
      > 
      > R=​thibaudm@chromium.org
      > 
      > Bug: v8:10359
      > Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67716}
      
      TBR=clemensb@chromium.org,thibaudm@chromium.org
      
      Change-Id: Ibf650e8b6143471b44f2822c1737e7de5f8bdb20
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10359
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194372Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67720}
      131fa2c9
    • Clemens Backes's avatar
      [wasm][debug] Fix tier down for multiple isolates · 902f48bd
      Clemens Backes authored
      If multiple isolates are using the same module, we need to keep it
      tiered down as long as any isolate still has a debugger open.
      Also, we cannot short-cut the {NativeModule::TierDown} method, since the
      previously triggered tier down might not have finished yet.
      For now, each isolate starts an independent tier down (i.e. a full
      recompilation). We could optimize this later by skipping functions that
      are already tiered down, or are already scheduled for tier down, but we
      still need to wait for tier-down to finish on each isolate.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10359
      Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67716}
      902f48bd
    • 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
  17. 06 May, 2020 1 commit
  18. 29 Apr, 2020 1 commit
  19. 28 Apr, 2020 1 commit
  20. 23 Apr, 2020 2 commits
  21. 22 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Fix performance bottleneck in DisjointAllocationPool · 7e0279fa
      Clemens Backes authored
      When compiling modules with many functions, the list of regions in the
      {DisjointAllocationPool} can become quite large if the functions die in
      a random order (which they typically do, since the order of Liftoff
      compilation is different than the order to TurboFan compilation; which
      work stealing, both are nondeterministic).
      Iterating the list of regions in the {DisjointAllocationPool} was thus
      linear in the number of regions, which is linear in the number of
      functions of the module. Since we insert new regions one by one, overall
      runtime was quadratic.
      
      This CL fixes this by switching from a linked list to a std::set.
      Merging a new region is thus logarithmic instead of linear, and overall
      we are {n*log(n)} instead of {n^2}.
      
      Note: For {AllocateInRegion} we still need to linearly iterate all
      regions that overlap the requested region, but this has not shown to be
      a problem so far.
      
      R=ahaas@chromium.org
      
      Bug: v8:10432
      Change-Id: I193e56c2abab782e386194fbe64dadfa250916f7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154797
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67303}
      7e0279fa
  22. 21 Apr, 2020 1 commit
  23. 17 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Don't publish code compiled for stepping · fb403653
      Clemens Backes authored
      This adds another enum value in the {ForDebugging} enum for stepping
      code.
      By not adding the code to the code table and jump table, we will never
      execute this code via a wasm function call. The code will only be used
      for the one frame where we want to step through.
      This speeds up stepping over recursive calls enormously, since the
      recursive calls don't run into the flooded breakpoints any more.
      It also fixes issues with non-local control flow, i.e. catching a trap
      and reentering the same wasm function.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10235
      Change-Id: Idb304dd465418f842016a20c21d68989bb78cf1d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153205
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67205}
      fb403653
  24. 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
  25. 14 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Store whether code was generated for debugging · 4721585b
      Clemens Backes authored
      This adds a flag to {WasmCode} objects to store whether this code was
      generated for debugging. This flag can be set for Liftoff code (in which
      case the code will e.g. have an extended prologue for debugging), but it
      can also be set for TurboFan, in case Liftoff bailed out when producing
      the debugging code.
      
      Having this flag allows us to remove the hack to pass the compilation
      results to {OnFinishedUnits} just to check whether we actually wanted to
      compile Liftoff functions.
      
      Drive-by: Replace the {ReachedRecompilationTierField} by a
      {MissingRecompilationField}, because all we need to know is if we are
      still waiting for that function to get recompiled.
      
      R=ahaas@chromium.org
      
      Bug: v8:10330,v8:10410
      Change-Id: Ia023df8955a60d9f5595a6cb2737e14d83baf716
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142259
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67119}
      4721585b
  26. 06 Apr, 2020 1 commit
  27. 03 Apr, 2020 3 commits
    • Clemens Backes's avatar
      [wasm] Reorganize source position lookup · 3aedafbb
      Clemens Backes authored
      Instead of two copies of the lookup code in frames.cc and wasm-debug.cc,
      put one lookup method on the WasmCode. This is where it belongs really,
      since the WasmCode is the main input to the function (besides the
      offset).
      
      Also refactor how source positions are computed in WasmCompiledFrame.
      Avoid going through the summary, which is unneccessarily complex. This
      also adds another {byte_offset} accessor which can be used for
      debugging.
      
      Bug: v8:10235
      Change-Id: I5c545ee302754b86009f09bedc5ff6e39ba664f6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135726Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66991}
      3aedafbb
    • Clemens Backes's avatar
      [wasm] Split adding code from publishing · e8ff83dd
      Clemens Backes authored
      Adding code can happen in parallel (it includes copying the code to the
      code region and relocation it). Publishing happens under one lock per
      native module though. We eventually want to avoid blocking on this lock
      for too long. This CL prepares that by splitting the actions of adding
      and publishing code.
      
      R=ahaas@chromium.org
      
      Bug: v8:10330, v8:10387
      Change-Id: Iddbdadfe32e691bbf5e7b387ea947579bc3376f3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134372
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66979}
      e8ff83dd
    • Clemens Backes's avatar
      [liftoff] Add code comments for OOL code · 2a303b1c
      Clemens Backes authored
      For easier debugging of Liftoff code generation issues, add code
      comments or out-of-line code.
      
      The name is generated from the {RuntimeStubId}. The respective name
      accessor is currently defined on the {NativeModule}, this CL makes it a
      top-level function so we can reuse it from Liftoff.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10235
      Change-Id: I7b99779217b9c052e34ad132eb34859b20548092
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134307
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66978}
      2a303b1c
  28. 19 Mar, 2020 2 commits
    • Andreas Haas's avatar
      [wasm] Introduce a TableCopy builtin · 1e1d4d82
      Andreas Haas authored
      This CL introduces a CSA builtin for the TableCopy instruction. This
      builtin allows to generate smaller code for both TurboFan and Liftoff,
      and easier code generation from Liftoff.
      
      The smaller code size comes from:
      * Parameters are passed through registers, not the stack.
      * Lower number of parameters: the call target, number of parameters, and
      context are not passed as parameters.
      * No int to smi conversion in generated code.
      
      R=clemensb@chromium.org
      
      Bug: v8:10281
      Change-Id: I4734b94c8a2aff08a5938504e3e36d0d2424f8ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110010
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66797}
      1e1d4d82
    • Andreas Haas's avatar
      [wasm] Introduce a WasmTableInit CSA builtin · ca5ee9d6
      Andreas Haas authored
      This CL introduces a CSA builtin for the TableInit instruction. This
      builtin allows to generate smaller code for both TurboFan and Liftoff,
      and easier code generation from Liftoff.
      
      The smaller code size comes from:
      * Parameters are passed through registers, not the stack.
      * Lower number of parameters: the call target, number of parameters, and
      context are not passed as parameters.
      * No int to smi conversion in generated code.
      
      The CL also introduces a small CSA function which takes an uint32 value
      and a max value as parameters and returns a Smi of the minimum of these
      two.
      
      R=clemensb@chromium.org, ishell@chromium.org
      
      Bug: v8:10281
      Change-Id: I40f248c20ec76e6ae9483a5e2907a68f42f2cb04
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106201
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66792}
      ca5ee9d6
  29. 16 Mar, 2020 1 commit
  30. 05 Mar, 2020 2 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