1. 24 May, 2019 1 commit
  2. 29 Mar, 2019 1 commit
  3. 18 Mar, 2019 1 commit
  4. 23 Oct, 2018 1 commit
  5. 09 Aug, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Add WasmFeatures to enable/detect features · 6aa2a253
      Ben L. Titzer authored
      This CL introduces a set of configuration options implemented as
      a struct of booleans that together comprise the set of enabled
      or detected features. The configuration options replace command-line
      flags that were checked deep in the implementation. As such, it is
      necessary to plumb them through multiple levels of abstraction.
      
      R=ahaas@chromium.org
      CC=mstarzinger@chromium.org
      BUG=chromium:868844
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637
      Reviewed-on: https://chromium-review.googlesource.com/1163670Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55018}
      6aa2a253
  6. 01 Aug, 2018 1 commit
  7. 24 Jul, 2018 1 commit
  8. 20 Jul, 2018 1 commit
  9. 18 Jul, 2018 1 commit
  10. 18 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Store WasmModule in shared_ptr during async compilation · 6be6ec00
      Clemens Hammacher authored
      We currently store the {WasmModule} (generated during decoding) in a
      unique_ptr and pass ownership to the {WasmModuleObject} after
      compilation.
      I plan to move the {Managed<NativeModule>} from {WasmCompiledModule} to
      {WasmModuleObject}, which will force us to create the
      {WasmModuleObject} *before* compilation, so that the {CompilationState}
      is available during compilation.
      
      This CL prepares that refactoring by storing the {WasmModule} in a
      {shared_ptr} in the {AsyncCompileJob}. Note that it will eventually be
      stored in a {shared_ptr} in the {Managed} anyway.
      
      R=titzer@chromium.org
      
      Change-Id: Iac5e3c1067af2801e938f77a455a68807801526a
      Reviewed-on: https://chromium-review.googlesource.com/1104117
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53801}
      6be6ec00
  11. 19 Apr, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Tear apart the WasmCompilationUnit · 0da7ec58
      Clemens Hammacher authored
      This refactoring is a big step towards separating Turbofan-related code
      from backend independent code. This will allow us to include way less
      headers from "src/compiler" at various places.
      
      The {WasmCompilationUnit} contained information for Turbofan
      compilation, and for Liftoff compilation. This CL tears this apart, such
      that {WasmCompilationUnit} holds backend-independent information, plus
      a pointer to either {LiftoffCompilationUnit} or
      {TurbofanWasmCompilationUnit}. These pointers are opaque, so that
      {function-compiler.h}, defining {WasmCompilationUnit}, does not need to
      include any Turbofan specific or Liftoff specific headers.
      
      R=ahaas@chromium.org, titzer@chromium.org, mstarzinger@chromium.org
      
      Bug: v8:7570, v8:6600
      Change-Id: I024c9a23508ee1b4b3cbe1d068c8e785d732daca
      Reviewed-on: https://chromium-review.googlesource.com/1016640
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52684}
      0da7ec58
  12. 16 Mar, 2018 1 commit
  13. 13 Mar, 2018 1 commit
    • Stephan Herhut's avatar
      [wasm] Parse function names on demand · 49a1a9a4
      Stephan Herhut authored
      Function names are optional in wasm and might not be present for most
      functions. Instead of storing an empty name with each function, this
      change loads names, if present, on first access of the name.
      
      This also fixes an inconsistency with streaming compilation. Under
      streaming compilation, functions are compiled before parsing the name
      section. Hence, they always received an empty name. With this change,
      assignment of names is typically deferred until the whole module was
      parsed.
      
      Bug: chromium:820291
      Change-Id: I86d76aa40b7c45897d152725547795c8b6b9b9ba
      Reviewed-on: https://chromium-review.googlesource.com/955647
      Commit-Queue: Stephan Herhut <herhut@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51909}
      49a1a9a4
  14. 11 Jan, 2018 1 commit
  15. 13 Oct, 2017 1 commit
  16. 15 Sep, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Streaming compilation for WebAssembly. · 549692cb
      Andreas Haas authored
      In this CL I implement streaming compilation for WebAssembly,
      as described in the design doc I have sent out already.
      
      In this implementation the decoding of sections other than the
      code section is done immediately on the foreground thread.
      Eventually all decoding should happen in the background. I
      think it is acceptable to do the decoding on the foreground
      thread for now because I have finished it already, and
      decoding in the background would add even more complexity to
      this CL.
      
      Bug:v8:6785
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I285e1e5e1a5a243113c92571b25ee9bae551d0ed
      Reviewed-on: https://chromium-review.googlesource.com/631721Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48022}
      549692cb
  17. 14 Sep, 2017 1 commit
  18. 28 Aug, 2017 1 commit
    • Michael Starzinger's avatar
      [asm.js] Correctly set minimum memory size to zero. · 89f839e5
      Michael Starzinger authored
      This makes sure the minimum memory size for WebAssembly modules derived
      from asm.js is set to zero. It allows instatiation without allocating an
      underlying memory, when such memory is unused. It also fixes a bug in
      patching of embedded memory sizes for asm.js modules.
      
      R=ahaas@chromium.org
      TEST=mjsunit/regress/regress-crbug-759327
      BUG=chromium:759327
      
      Change-Id: If5a965b96a03cbb5ba15bc41fbaf359f74961f41
      Reviewed-on: https://chromium-review.googlesource.com/637912
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47646}
      89f839e5
  19. 19 Aug, 2017 2 commits
  20. 18 Aug, 2017 1 commit
  21. 08 Aug, 2017 1 commit
    • Mircea Trofin's avatar
      [wasm] Consolidate ownership of instantiation/specialization parameters · f9d4090b
      Mircea Trofin authored
      This CL consolidates ownership of parameters used to compile code (which
      we always specialize) in 2 places:
      - ModuleEnv for compile-time data
      - WasmCompiledModule for runtime data
      
      The parameters in question are: memory size and start; globals start; 
      address of indirect function tables (and their signatures, respectively); 
      and address to be used for wasm call sites.
      
      Ideally, we'd collapse this down to one place, however, we need
      specialization data to survive serialization. We can achieve this we get off 
      the GC heap and use a different wasm code serializer.
      
      The CL:
      - removes aliasing of parts of the specialization data, and moves
      to using ModuleEnv as a token of passing around compile-time data, instead
      of a mixture of ModuleEnv, WasmInstance, and some other structures. ModuleEnv
      is responsible for providing a consistent view of the specialization data,
      e.g. valid memory sizes (multiples of page size), and matching sized function
      tables and signatures.
      
      - removes WasmInstance, as its data is now contained by ModuleEnv.
      
      - removes ModuleBytesEnv. We now pass the wire bytes explicitly. They can't
      always be assumed as present (e.g. streaming compilation), and probably more
      refactoring may need to happen once streaming compilation lands and we
      better understand our dependencies.
      
      Change-Id: Id7e6f2cf29e51b5756eee8b6f8827fb1f375e5c3
      Reviewed-on: https://chromium-review.googlesource.com/592531
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47229}
      f9d4090b
  22. 02 Aug, 2017 3 commits
    • Karl Schimpf's avatar
      Reland "Start migration of try/throw/catch to match proposal." · ad49b7b4
      Karl Schimpf authored
      This is a reland of 470a1001
      Original change's description:
      > Start migration of try/throw/catch to match proposal.
      > 
      > This CL does the first baby steps on moving the current (experimental)
      > exception handling to match that of the WebAssembly proposal.
      > 
      > It does the following:
      > 
      > 1) Use exception tags instead of integers.
      > 
      > 2) Only handle empty exception signatures (i.e. no values associated
      >    with the exception tag.
      > 
      > 3) Only handle one catch clause.
      > 
      > 4) Be sure to rethrow the exception if the exception tag does not match.
      > 
      > Note: There are many things that need to be fixed, and are too
      > numerous to list here. However, the code should have TODO's on each
      > missing parts of the implementation.
      > 
      > Also note that the code currently doesn't handle nested catch blocks,
      > nor does it change the throw value being an integer. Rather, the
      > integer value is still being thrown, and currently is the exception
      > tag. Therefore, we don't build an exception object. This is the reason
      > why this CL doesn't handle exceptions that pass values.
      > 
      > Also, the current implementation still can't handle multiple modules
      > because tag resolution (between) modules has not be implemented yet.
      > 
      > Bug: v8:6577
      > Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
      > Reviewed-on: https://chromium-review.googlesource.com/591910
      > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
      > Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47087}
      
      Bug: v8:6577
      Change-Id: I41c3309827c292cb787681a95aaef7cf9b931835
      Reviewed-on: https://chromium-review.googlesource.com/598968Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
      Commit-Queue: Brad Nelson <bradnelson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47100}
      ad49b7b4
    • Ulan Degenbaev's avatar
      Revert "Start migration of try/throw/catch to match proposal." · 41daf8a5
      Ulan Degenbaev authored
      This reverts commit 470a1001.
      
      Reason for revert: GC stress bot failures.
      https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Mac%20GC%20Stress/builds/14522
      
      
      Original change's description:
      > Start migration of try/throw/catch to match proposal.
      > 
      > This CL does the first baby steps on moving the current (experimental)
      > exception handling to match that of the WebAssembly proposal.
      > 
      > It does the following:
      > 
      > 1) Use exception tags instead of integers.
      > 
      > 2) Only handle empty exception signatures (i.e. no values associated
      >    with the exception tag.
      > 
      > 3) Only handle one catch clause.
      > 
      > 4) Be sure to rethrow the exception if the exception tag does not match.
      > 
      > Note: There are many things that need to be fixed, and are too
      > numerous to list here. However, the code should have TODO's on each
      > missing parts of the implementation.
      > 
      > Also note that the code currently doesn't handle nested catch blocks,
      > nor does it change the throw value being an integer. Rather, the
      > integer value is still being thrown, and currently is the exception
      > tag. Therefore, we don't build an exception object. This is the reason
      > why this CL doesn't handle exceptions that pass values.
      > 
      > Also, the current implementation still can't handle multiple modules
      > because tag resolution (between) modules has not be implemented yet.
      > 
      > Bug: v8:6577
      > Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
      > Reviewed-on: https://chromium-review.googlesource.com/591910
      > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
      > Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47087}
      
      TBR=bradnelson@chromium.org,eholk@chromium.org,kschimpf@chromium.org
      
      Change-Id: I01dc8c40cc1057333a988c1d275ce5f457b0cb64
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6577
      Reviewed-on: https://chromium-review.googlesource.com/598847Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47090}
      41daf8a5
    • Karl Schimpf's avatar
      Start migration of try/throw/catch to match proposal. · 470a1001
      Karl Schimpf authored
      This CL does the first baby steps on moving the current (experimental)
      exception handling to match that of the WebAssembly proposal.
      
      It does the following:
      
      1) Use exception tags instead of integers.
      
      2) Only handle empty exception signatures (i.e. no values associated
         with the exception tag.
      
      3) Only handle one catch clause.
      
      4) Be sure to rethrow the exception if the exception tag does not match.
      
      Note: There are many things that need to be fixed, and are too
      numerous to list here. However, the code should have TODO's on each
      missing parts of the implementation.
      
      Also note that the code currently doesn't handle nested catch blocks,
      nor does it change the throw value being an integer. Rather, the
      integer value is still being thrown, and currently is the exception
      tag. Therefore, we don't build an exception object. This is the reason
      why this CL doesn't handle exceptions that pass values.
      
      Also, the current implementation still can't handle multiple modules
      because tag resolution (between) modules has not be implemented yet.
      
      Bug: v8:6577
      Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
      Reviewed-on: https://chromium-review.googlesource.com/591910Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
      Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47087}
      470a1001
  23. 10 Jul, 2017 1 commit
  24. 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
  25. 27 Jun, 2017 1 commit
  26. 26 Jun, 2017 1 commit
  27. 23 Jun, 2017 2 commits
  28. 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
  29. 12 Jun, 2017 2 commits
    • 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
    • Clemens Hammacher's avatar
      [wasm] Decode and use module name · 237d21b2
      Clemens Hammacher authored
      * add functionality to wasm-module-builder.js to emit the module name
        in the name section.
      * extend WasmModule to store the module name length and offset.
      * add functionality to module-decoder.cc to decode the module name.
      * use the module name for printing stack traces. more uses should
        follow.
      * extend one message test to contain a module name.
      
      R=ahaas@chromium.org
      
      Change-Id: I94e6f1f2eb99cb656a92a85bb7afe0742292046f
      Reviewed-on: https://chromium-review.googlesource.com/530366Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45846}
      237d21b2
  30. 09 Jun, 2017 1 commit
  31. 17 May, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Refactor the module decoder to work with section bytes · a8424d59
      Andreas Haas authored
      This CL refactors the module decoder so that it can process a list of
      section buffers instead of one module buffer. This change is needed for
      streaming compilation. Streaming compilation may require additional
      changes.
      
      This CL introduces the following interface to the module decoder:
      StartDecoding -- starts the decoding
      DecodeModuleHeader -- decodes the module header
      DecodeSection -- decodes the section
      FinishDecoding -- finishes the decoding and returns the WasmModule
      
      Aside from the different interface the biggest change to the module
      decoder is the introduction of a buffer_offset, which is the offset
      of the current section buffer of the module decoder in the module bytes.
      This buffer_offset is used to translate from section offsets to module
      offsets and back.
      
      Another nice change is that the module decoder does not have a zone
      anymore. Instead the zone is stored directly in the WasmModule where
      it belongs. Zone ownership is also more obvious now.
      
      R=mtrofin@chromium.org, clemensh@chromium.org
      
      Change-Id: I815d777ec380f4c617c39e828ea0c9746c0bae20
      Reviewed-on: https://chromium-review.googlesource.com/505490
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45374}
      a8424d59
  32. 08 May, 2017 2 commits
  33. 07 Apr, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Implement extensible name section · 1a73f73b
      Clemens Hammacher authored
      The format of the name section changed recently. It now contains
      subsections of different type (currently for function names or local
      variable names).
      This CL changes our internal wasm module builders (in JS and C++) to
      emit this new format, and changes the decoder to understand it.
      We currently only parse the function name section, and ignore names of
      local variables. I will later extend this to parse local variable names
      when needed for debugging.
      
      R=ahaas@chromium.org, rossberg@chromium.org
      BUG=v8:6222
      
      Change-Id: I2627160c25c9209a3f09abe0b88941ec48b24434
      Reviewed-on: https://chromium-review.googlesource.com/470247
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Rossberg <rossberg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44492}
      1a73f73b
  34. 20 Mar, 2017 1 commit