1. 02 Aug, 2017 1 commit
  2. 01 Aug, 2017 1 commit
    • Annie Sullivan's avatar
      Revert "[wasm] redirect wasm calls to js functions through a GCed table" · 25f03308
      Annie Sullivan authored
      This reverts commit eb65f35e.
      
      Reason for revert: Broke jetstream benchmark on android.
      
      BUG=chromium:750828
      
      Original change's description:
      > [wasm] redirect wasm calls to js functions through a GCed table
      > 
      > With this patch, rather than embedding the JSReceiver address directly
      > in the WasmToJS wrappers, we put that in a fixed array with global handle
      > scope and instead embed the location of the handle and the index in the
      > wrapper. This ensures that the wrapper doesn't need to be patched if the
      > GC kicks in. This is needed to get the WASM code off the GCed heap.
      > 
      > R=​mtrofin@chromium.org
      > 
      > Bug: 
      > Change-Id: Ie5a77a78cdecec51b04f702c63b8e4285e6a2d8d
      > Reviewed-on: https://chromium-review.googlesource.com/581682
      > Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46884}
      
      TBR=mtrofin@chromium.org,aseemgarg@google.com,aseemgarg@chromium.org,clemensh@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: I26f49ee0a1fe73cc5d8852ded87b56638be39ebf
      Reviewed-on: https://chromium-review.googlesource.com/596268
      Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47059}
      25f03308
  3. 25 Jul, 2017 1 commit
    • Aseem Garg's avatar
      [wasm] redirect wasm calls to js functions through a GCed table · eb65f35e
      Aseem Garg authored
      With this patch, rather than embedding the JSReceiver address directly
      in the WasmToJS wrappers, we put that in a fixed array with global handle
      scope and instead embed the location of the handle and the index in the
      wrapper. This ensures that the wrapper doesn't need to be patched if the
      GC kicks in. This is needed to get the WASM code off the GCed heap.
      
      R=mtrofin@chromium.org
      
      Bug: 
      Change-Id: Ie5a77a78cdecec51b04f702c63b8e4285e6a2d8d
      Reviewed-on: https://chromium-review.googlesource.com/581682
      Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46884}
      eb65f35e
  4. 18 Jul, 2017 1 commit
  5. 14 Jul, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Update signature map on indirect calls · 883db26e
      Clemens Hammacher authored
      The code was already there, but there was a bug in it: Because of the
      missing reference, we were only updating a *copy* of the signature map,
      hence the update had no effect.
      This intentially is a minimal CL, in order to allow for easy
      backmerging.
      More mitigations and tests are coming in a separate CL.
      
      R=titzer@chromium.org
      
      Change-Id: Ifb462093f4b8f4d5380b6774636537c67c2b676c
      Reviewed-on: https://chromium-review.googlesource.com/570278Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46664}
      883db26e
  6. 13 Jul, 2017 1 commit
  7. 10 Jul, 2017 5 commits
  8. 07 Jul, 2017 2 commits
    • titzer's avatar
      [wasm] Use WeakFixedArray for list of instances sharing a WasmMemoryObject. · 0a61361e
      titzer authored
      This CL refactors the WasmMemoryObject and WasmInstanceObject classes to
      use WeakFixedArray instead of using a doubly-linked list of instances. This
      simplifies the lifetime management of instances by not requiring them to
      be unlinked from this list upon GC. It also simplifies the iteration over
      the instances using a given WasmMemoryObject.
      
      Note that, contrary to my naive assumption at the outset, it is still necessary for the InstanceFinalizer (called upon a WasmInstanceObject death) to unlink itself from a WasmMemoryObject's instances list, due to finalizer ordering.
      
      R=deepti@chromium.org, mlippautz@chromium.org
      BUG=
      
      Review-Url: https://codereview.chromium.org/2972803002
      Cr-Commit-Position: refs/heads/master@{#46482}
      0a61361e
    • titzer's avatar
      [wasm] Introduce instance types for WebAssembly.* objects. · 17001a05
      titzer authored
      This CL refactors the internal representation of JavaScript-exposed
      WebAssembly objects to be more like other such objects in V8. By introducing
      a new instance type for each of the JS-exposed types, we get more robust
      typechecking without using embedder fields (which were previously used
      when these objects where instance type JS_API_OBJECT).
      
      In addition to the new instance types, the subclasses X of JSObject
      (WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
      now have appropriate Is##X() methods on Object and are now robust.
      
      BUG=v8:6547
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2964943002
      Cr-Commit-Position: refs/heads/master@{#46475}
      17001a05
  9. 03 Jul, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Decode local names for debugging · 07752032
      Clemens Hammacher authored
      When providing scope information (containing the value of local
      variables of live stack frames), decode the local variable names of all
      functions in a wasm module and store this in the WasmDebugInfo
      structure.
      Use these names to actually name the reported locals, instead of using
      the default names "param#<d>" and "local#<d>". These names are only used
      as fallbacks for locals which were not assigned a name.
      
      R=titzer@chromium.org,kozyatinskiy@chromium.org
      BUG=v8:6245
      
      Change-Id: Ibf7d30e392248ef5590177cd8b6329239b45e018
      Reviewed-on: https://chromium-review.googlesource.com/548495
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46379}
      07752032
  10. 30 Jun, 2017 1 commit
    • Mathias Bynens's avatar
      [elements] Rename FAST elements kinds · 26c00f4a
      Mathias Bynens authored
      The `FAST_` prefix doesn’t make much sense — they’re all just different cases
      with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
      vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
      
      This patch renames the FAST elements kinds as follows:
      
      - e.g. FAST_ELEMENTS => PACKED_ELEMENTS
      - e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
      
      The following exceptions are left intact, for lack of a better name:
      
      - FAST_SLOPPY_ARGUMENTS_ELEMENTS
      - SLOW_SLOPPY_ARGUMENTS_ELEMENTS
      - FAST_STRING_WRAPPER_ELEMENTS
      - SLOW_STRING_WRAPPER_ELEMENTS
      
      This makes it easier to reason about elements kinds, and less confusing to
      explain how they’re used.
      
      R=jkummerow@chromium.org, cbruni@chromium.org
      BUG=v8:6548
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
      Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46361}
      26c00f4a
  11. 29 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Use pending exceptions consistently · d6aed443
      Clemens Hammacher authored
      In our internal code, we should only use pending exceptions. They will
      be converted to scheduled exceptions on the API boundary.
      Hence, the ErrorThrower just sets a pending exception; it should never
      have to think about scheduled exceptions. The new
      ScheduledErrorThrower inherits from ErrorThrower and reschedules any
      pending exceptions in its destructor (turning them into scheduled
      exceptions).
      In some situations, there might already be a scheduled exception, e.g.
      when calling other API methods (v8::Value::Get). In this case, the
      ErrorThrower should also not set another pending exception. For the
      reasons mentioned above, this can only be handled in the
      ScheduledErrorThrower, which is used the API methods.
      
      This fixes one DCHECK failure and one TODO about scheduled exceptions
      if no instance can be created, because the start function throws.
      
      R=mtrofin@chromium.org, mstarzinger@chromium.org
      BUG=v8:6232,chromium:736256
      
      Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2
      Reviewed-on: https://chromium-review.googlesource.com/548641
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46314}
      d6aed443
  12. 28 Jun, 2017 1 commit
  13. 27 Jun, 2017 2 commits
  14. 26 Jun, 2017 3 commits
  15. 23 Jun, 2017 3 commits
  16. 22 Jun, 2017 1 commit
    • kschimpf's avatar
      Fix use of history timers in background threads. · d4a10807
      kschimpf authored
      HistoryTimer's can't run in the background because they use a timer
      with a simple api of Start() and Stop(). This CL fixes this problem
      by building a base class TimedHistogram that doesn't have a timer.
      
      The class HistoryTimer is modified to use this base class so that
      uses that run on the foreground thread do not need to be modified.
      
      It also adds a new class TimedHistogramScope that defines the timer
      in this class. This allows the corresopnding TimedHistogram class to
      be type safe.
      
      BUG=v8:6361
      
      Review-Url: https://codereview.chromium.org/2929853003
      Cr-Commit-Position: refs/heads/master@{#46150}
      d4a10807
  17. 13 Jun, 2017 2 commits
  18. 12 Jun, 2017 4 commits
    • Mircea Trofin's avatar
      [wasm] Initialize parallel jobs with less memory. · b29bfffd
      Mircea Trofin authored
      Avoid constructing zones and large zone objects when initializing
      WasmCompilationUnit. The main reason we did that is so we can cache
      the CEntryStub node, which requires a code object, obtainable only
      on the main thread. We need that value, however, on background threads,
      which is also where we need the aforementioned large objects. We only
      need that for the WasmCompilationUnits being currently compiled, which
      is a number proportional to the number of background threads provided
      by the embedder. Specifically, one zone is needed only for the duration
      of the background compilation, while the second zone needs to survive 
      past that, so the compilation results may be committed to the GC heap
      as Code objects.
      
      The problem with these large objects is that the first allocation
      in a Zone is at minimum 8KB. We used to allocate 2 zones. For
      modules with 200K functions, that means 3.2GB of memory pre-allocated
      before any of it is actually needed.
      
      This change attaches a Handle to the CEntryStub on the WasmCompilationUnits,
      and delays zone creation to when needed. The change also adds a way to 
      cache CEntryStubs in a JSGraph from a given Code handle - limited to the
      scenario needed by wasm (and removable once we get wasm off the GC heap,
      which subsumes removing this dependency on CEntryStubs)
      
      An additional constraint for this change is that we want it to be easily 
      back-mergeable to address chromium:723899.
      
      For the wasm payload in question, collecting the max memory used by d8
      using /usr/bin/time --format='(%Xtext+%Ddata %Mmax)', we get the 
      following numbers (in KB):
      
      - unchanged: 3307480
      - patch 1: 1807140 (45% reduction)
      - patch 3: 1230320 (62% reduction from first)
      - patch 5/6: 519368 (84% reduction from first)
      
      Bug: chomium:732010, chromium:723899
      Change-Id: I45b96792daf8a9c8dc47d45fb52da75945a41401
      Reviewed-on: https://chromium-review.googlesource.com/530193
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45880}
      b29bfffd
    • Clemens Hammacher's avatar
      [wasm] [cleanup] Introduce WireBytesRef struct · 07b115f8
      Clemens Hammacher authored
      In many places in WasmModule and contained structs we store references
      into the wire bytes as pairs of offset and length.
      This CL introduces a WireBytesRef struct which encapsulates these two
      connected fields. This makes it easier to pass them and assign them as
      one unit.
      
      R=ahaas@chromium.org, mtrofin@chromium.org
      BUG=v8:6474
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I4f2a40d848a51dc6f6f599f9253c3c6ed6e51627
      Reviewed-on: https://chromium-review.googlesource.com/530687
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45859}
      07b115f8
    • Andreas Haas's avatar
      [wasm] Introduce a compilation manager for WebAssembly · 291f8dcf
      Andreas Haas authored
      This CL is the first step in introducing a compilation manager for
      asynchronous compile jobs in WebAssembly.
      
      The compilation manager holds a list of currently active
      AsyncCompileJobs. With the compilation manager these compile jobs get
      deallocated when the isolate shuts down. Note that this CL is not enough
      to provide a graceful isolate shutdown. For this we have to wait for all
      compilation tasks to finish before we shut down, and we have to make the
      tasks stateless. I plan to do these changes in separate CLs.
      
      R=clemensh@chromium.org, mtrofin@chromium.org
      
      BUG=v8:6436
      
      Change-Id: I9a6e165dd2ef6d33944ca303fed49f7940eea7a2
      Reviewed-on: https://chromium-review.googlesource.com/528079Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45858}
      291f8dcf
    • Clemens Hammacher's avatar
      [wasm] [cleanup] Remove CompileInstantiateWasmModuleForTesting · 6a36b2a0
      Clemens Hammacher authored
      This is a testing-only function, which is semantically equivalent to a
      SyncCompile followed by SyncInstantiate.
      We add a new SyncCompileAndInstantiate function to do those two steps
      in one go, and use this method instead.
      For AsmJs modules, a new testing function CompileAndRunAsmWasmModule is
      introduced.
      
      This is part of our effort to reduce the number of special paths for
      testing. It is connected with
      https://chromium-review.googlesource.com/529210, but should not
      conflict with it.
      After landing both CLs, we can later also get rid of
      InstantiateModuleForTesting.
      
      R=ahaas@chromium.org, mtrofin@chromium.org
      BUG=v8:6474
      
      Change-Id: I7891e968370d5eb68803076ce2639c65a2799dcc
      Reviewed-on: https://chromium-review.googlesource.com/529844Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45852}
      6a36b2a0
  19. 09 Jun, 2017 1 commit
  20. 07 Jun, 2017 2 commits
    • Andreas Haas's avatar
      [wasm] Extract module compilation code into module-compiler.cc · c7892d35
      Andreas Haas authored
      This CL extracts the classes CompilationHelper, InstantiationHelper,
      and AsyncCompileJob from wasm-module.cc and puts them into
      module-compiler.{h|cc}. This is necessary to introduce a
      WasmCompilationManager which is known to the isolate and manages the
      lifetime of all AsyncCompileJobs.
      
      In addition to the mechanical changes of copying the code and splitting
      class declaration from instantiation, I did the following changes:
      
      * I renamed the CompilationHelper to ModuleCompiler.
      * A finalizer function is passed to the InstantiationHelper as a
        parameter.
      * Adjusted UpdateDispatchTable in wasm-module.cc to make it available in
        wasm-module.h, also with the internal signature.
      * Duplicate the ResolvePromise/RejectPromise helper functions.
      
      I did not rename InstantiationHelper because I could not come up with a
      good name, and it could benefit from a small special refactoring anyways.
      
      BUG=v8:6436
      R=clemensh@chromium.org, mtrofin@chromium.org
      
      Change-Id: I4abe854c36dfc995b34c9d7b3e7ec0f4f0aa562e
      Reviewed-on: https://chromium-review.googlesource.com/525572
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45773}
      c7892d35
    • Andreas Haas's avatar
      [wasm] Refactor Table.Set · 3a4ba583
      Andreas Haas authored
      The old implementation of Table.Set in wasm-js.cc accessed information
      which should be hidden from this level of abstraction, e.g. the internal
      structure of a WasmTableObject. With this CL, all that is done in
      wasm-js.cc is the extraction of parameters. The actual logic is happening
      in wasm-module.{h|cc}. This CL will also make refactoring wasm-module.cc
      easier.
      
      R=clemensh@chromium.org, mtrofin@chromium.org
      
      Change-Id: Ifbce6f739459dffc9f9d47e4cd8227638867f3e9
      Reviewed-on: https://chromium-review.googlesource.com/525694
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45754}
      3a4ba583
  21. 06 Jun, 2017 1 commit
  22. 29 May, 2017 2 commits
  23. 26 May, 2017 1 commit
  24. 24 May, 2017 1 commit
    • kschimpf's avatar
      Create a thread safe version of StatsCounters and use. · fbbc0ff2
      kschimpf authored
      Creates a new class StatsCounterThreadSafe to be used by counters that
      can be updated when compiling/decoding etc. are done using workers.
      
      Does this by using a mutex on all opreations.
      
      Also updates the StatsCounterThreadSafe constructor to force counter
      initialization, as well as method Reset(). In addition, whenever the
      method StatsTable::SetCounterFunction() is called (from the main
      thread), it forces counter initialization for all thread safe stats
      counters.
      
      BUG=v8:6361
      
      Review-Url: https://codereview.chromium.org/2887193002
      Cr-Commit-Position: refs/heads/master@{#45526}
      fbbc0ff2