1. 12 Jun, 2017 2 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
  2. 09 Jun, 2017 1 commit
  3. 31 May, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Make prototype flags experimental · 45618a9a
      Clemens Hammacher authored
      Most prototype implementations are not fully supported in the
      interpreter. This is the case at least for exception handling, simd, and
      atomics. Any function can be redirected to the interpreter though,
      either by passing --wasm-interpret-all, or by dynamically redirecting to
      the interpreter for debugging.
      Making the flags experimental keeps the fuzzer from playing around with
      these flags.
      
      Drive-by: Refactor tests which explicitly set the prototype flag to use
      a new scope for that.
      
      R=ahaas@chromium.org
      BUG=chromium:727584
      
      Change-Id: I67da79f579f1ac93c67189afef40c6524bdd4430
      Reviewed-on: https://chromium-review.googlesource.com/519402
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45639}
      45618a9a
  4. 28 Apr, 2017 2 commits
    • Clemens Hammacher's avatar
      [wasm] [cleanup] Extract base class for Result<T> · af85b62f
      Clemens Hammacher authored
      This avoids generating redundant code for different template
      instantiations.
      I also introduce getters instead of accessing the fields directly.
      
      R=ahaas@chromium.org
      BUG=v8:6325
      
      Change-Id: I3e0eca9ef6a01e0a3ebb73f4f357bcb59e120f43
      Reviewed-on: https://chromium-review.googlesource.com/490166Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44976}
      af85b62f
    • Clemens Hammacher's avatar
      [wasm] Reduce test-specific code · 1a8e7d13
      Clemens Hammacher authored
      This reduces the amount of special paths for testing.
      Setup the memory used for testing exactly the same way as in real world.
      Also, always connect the interpreter to the instance being executed,
      and to the existing WasmInstance struct. This keeps information
      synchronized between interpreter and test runner.
      These changes allow us to execute e.g. GrowMemory from cctests either
      in the interpreter or in compiled code.
      
      R=ahaas@chromium.org
      
      Change-Id: Id4726d061f3cdba789275350f500d769d27d2d63
      Reviewed-on: https://chromium-review.googlesource.com/488561
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44966}
      1a8e7d13
  5. 26 Apr, 2017 2 commits
    • Eric Holk's avatar
      Revert "[wasm] Add guard pages before Wasm Memory" · 54be464f
      Eric Holk authored
      This reverts commit d7cdea6f.
      
      Reason for revert: Flakiness on bots
      
      Original change's description:
      > [wasm] Add guard pages before Wasm Memory
      > 
      > Although Wasm memory indices are all unsigned, they sometimes get assembled
      > as 32-bit signed immediates. Values in the top half of the Wasm memory space
      > will then get sign extended, causing Wasm to access in front of its memory
      > buffer.
      > 
      > Usually this region is not mapped anyway, so faults still happen as they are
      > supposed to. This change protects this region with guard pages so we are
      > guaranteed to always fault when this happens.
      > 
      > Bug: v8:5277
      > Change-Id: Id791fbe2a5ac1b1d75460e65c72b5b9db2a47ee7
      > Reviewed-on: https://chromium-review.googlesource.com/484747
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#44905}
      
      TBR=bradnelson@chromium.org,gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org,mseaborn@chromium.org,adamk@chromium.org,v8-reviews@googlegroups.com,wasm-v8@google.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Change-Id: Ia1d3e5dbf4f518815a9fd4197047077bc8e42816
      Reviewed-on: https://chromium-review.googlesource.com/487828Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44907}
      54be464f
    • Eric Holk's avatar
      [wasm] Add guard pages before Wasm Memory · d7cdea6f
      Eric Holk authored
      Although Wasm memory indices are all unsigned, they sometimes get assembled
      as 32-bit signed immediates. Values in the top half of the Wasm memory space
      will then get sign extended, causing Wasm to access in front of its memory
      buffer.
      
      Usually this region is not mapped anyway, so faults still happen as they are
      supposed to. This change protects this region with guard pages so we are
      guaranteed to always fault when this happens.
      
      Bug: v8:5277
      Change-Id: Id791fbe2a5ac1b1d75460e65c72b5b9db2a47ee7
      Reviewed-on: https://chromium-review.googlesource.com/484747
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44905}
      d7cdea6f
  6. 25 Apr, 2017 2 commits
  7. 10 Apr, 2017 2 commits
    • Clemens Hammacher's avatar
      [wasm] Refactor wasm::Result type · d50ebde7
      Clemens Hammacher authored
      - Store std::string instead of std::unique_ptr<char[]> for the error
        message.
      - Remove ErrorCode, which was just kSuccess and kError anyway. Error is
        now detected on whether error_msg_ is empty or not.
      - Refactor constructors for perfect forwarding; this will allow us to
        implement Result<std::unique_ptr<X*>>.
      - Refactor Decoder::toResult for perfect forwarding.
      - Remove output operators (operator<<) for Result; it was only used in
        the error case anyway. Print error message directly instead.
        The operator was problematic since it assumed the existence of an
        output operator for every T which is used in Result<T>.
      - Remove ModuleError and FunctionError, introduce general static
        Result<T>::Error method instead.
      
      R=ahaas@chromium.org
      
      Change-Id: I1e0f602a61ee9780fee2a3ed33147d431fb092ba
      Reviewed-on: https://chromium-review.googlesource.com/472748
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44518}
      d50ebde7
    • Andreas Haas's avatar
      [wasm] Refactor the Result object · e313bc17
      Andreas Haas authored
      Instead of storing {start} and {error_pc} we now store the
      {error_offset}, which is anyways the only value we use.
      
      R=clemensh@chromium.org
      
      Change-Id: Ifd9791eff5c9efce2e7e2a1989bf3b5eaa464a02
      Reviewed-on: https://chromium-review.googlesource.com/471527
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44510}
      e313bc17
  8. 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
  9. 05 Apr, 2017 2 commits
    • Clemens Hammacher's avatar
      [wasm] [decoder] Merge checked_read_leb and consume_leb · 02b4d0e6
      Clemens Hammacher authored
      Both methods decoded a LEB128 encoded integer, but only consume_leb
      incremented the pc pointer accordingly.
      This CL implements consume_leb by using checked_read_leb.
      
      It also refactors a few things:
      1) It removes error_pt, which was only avaible in checked_read_leb.
      2) It renames the error method to errorf, since it receives a format
         string. This also avoids a name clash.
      3) It implements sign extension directly in checked_read_leb instead of
         doing this in the caller.
      
      R=ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: I8058f57418493861e5df26d4949041f6766d5138
      Reviewed-on: https://chromium-review.googlesource.com/467150
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44405}
      02b4d0e6
    • mtrofin's avatar
      [wasm] Further simplify WasmCompiledModule. · 026ce285
      mtrofin authored
      Better demarcation between what's mutable because it is code-
      specialization specific, and what is provided at initialization.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2784233004
      Cr-Commit-Position: refs/heads/master@{#44395}
      026ce285
  10. 25 Mar, 2017 1 commit
    • kschimpf's avatar
      Hide WasmModule.origin field behind readable accessors. · 98ed1f9c
      kschimpf authored
      Besides adding accessors get_origin() and set_origin(), it creates easier test
      accessors is_wasm() and is_asm_js().
      
      This allows the possibility of caching boolean flags for is_wasm() and
      is_asm_js() without having to change any code except for the files containing
      the class definition for WasmModule.
      
      BUG= v8:6152
      R=bbudge@chromium.org,mtrofin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2771803005
      Cr-Commit-Position: refs/heads/master@{#44130}
      98ed1f9c
  11. 23 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Implement indirect function calls · b8f88601
      Clemens Hammacher authored
      This CL adds support for indirect function calls to the interpreter. It
      can indirectly call other wasm function in the same instance, which are
      then executed in the interpreter, or call imported functions.
      
      Implementing this required some refactoring:
      - The wasm interpreter now unwraps import wrappers on demand, instead
        of unwrapping all of them on instantiation and storing a vector of
        handles. This also avoids the DeferredHandleScope completely, instead
        we just store two global handles in the code map.
      - The interpreter gets the code table, function tables and signature
        tables directly from the attached wasm instance object. This ensures
        that the interpreter sees all updates to tables that might have been
        performed by external code.
      - There is now common functionality for calling a code object. This is
        used for direct calls to imported functions and for all indirect
        calls. As these code objects can also be wasm functions which should
        be executed in the interpreter itself, I introduce a struct to hold
        the outcome of calling the code object, or a pointer to
        InterpreterCode to be called in the interpreter.
      
      R=ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: I20fb2ea007e79e5fcff9afb4b1ca31739ebcb83f
      Reviewed-on: https://chromium-review.googlesource.com/458417
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44059}
      b8f88601
  12. 17 Mar, 2017 2 commits
  13. 15 Mar, 2017 2 commits
  14. 14 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Cleanup wasm interpreter · 0a4c5c44
      Clemens Hammacher authored
      This is a cleanup in preparation to implement calling imported
      functions via the wasm interpreter.
      For imported functions, we do not create entries in the
      interpreter_code_ vector any more.
      
      I also simplified the interface and removed unused or redundant return
      values. More things are now DCHECKed instead of bailing out.
      
      Also, we previously had two PushFrame methods: One is supposed to
      initialize the interpreter from external code (i.e. adds the first
      frame to the stack), the other one is used to push new frames on the
      frame stack for called functions. This CL renames the first to
      InitFrame, and makes it use the second one. The other remaining user is
      the DoCall method.
      
      R=titzer@chromium.org
      BUG=v8:5822
      
      Change-Id: Id09ff1e3256428fbd8c955e4664507a0c3167e53
      Reviewed-on: https://chromium-review.googlesource.com/453482
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43793}
      0a4c5c44
  15. 13 Mar, 2017 3 commits
    • eholk's avatar
      [wasm] Initial signal handler · 118c376f
      eholk authored
      This is basically the minimum viable signal handler for Wasm bounds checks.
      It includes the TLS check and the fine grained instructions checks. These
      two checks provide most of the safety for the signal handler. Future CLs will
      add code range and data range checks for more robustness.
      
      The trap handling code and data structures are all in src/trap-handler, with
      the code that actually runs in the signal handler confined to
      src/trap-handler/signal-handler.cc.
      
      This changes adds a new V8 API that the embedder should call from a signal
      handler that will give V8 the chance to handle the fault first. For hosts that
      do not want to implement their own signal handler, we include the option to
      install a simple one. This simple handler is also used for the tests.
      
      When a Wasm module is instantiated, information about each function is passed
      to the trap handler, which is used to classify faults. These are removed during
      the instance finalizer.
      
      Several future enhancements are planned before turning this on by default.
      Obviously, the additional checks will be added to MaybeHandleFault. We are
      also planning to add a two-level CodeObjectData table that is grouped by
      isolates to make cleanup easier and also reduce potential for contending on
      a single data structure.
      
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Original-Original-Commit-Position: refs/heads/master@{#43523}
      Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Original-Commit-Position: refs/heads/master@{#43755}
      Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Commit-Position: refs/heads/master@{#43759}
      118c376f
    • eholk's avatar
      Revert of [wasm] Initial signal handler (patchset #60 id:1170001 of... · aba151b9
      eholk authored
      Revert of [wasm] Initial signal handler (patchset #60 id:1170001 of https://codereview.chromium.org/2371833007/ )
      
      Reason for revert:
      ASAN breakage, such as https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/19111/steps/Check/logs/grow-memory
      
      Original issue's description:
      > [wasm] Initial signal handler
      >
      > This is basically the minimum viable signal handler for Wasm bounds checks.
      > It includes the TLS check and the fine grained instructions checks. These
      > two checks provide most of the safety for the signal handler. Future CLs will
      > add code range and data range checks for more robustness.
      >
      > The trap handling code and data structures are all in src/trap-handler, with
      > the code that actually runs in the signal handler confined to
      > src/trap-handler/signal-handler.cc.
      >
      > This changes adds a new V8 API that the embedder should call from a signal
      > handler that will give V8 the chance to handle the fault first. For hosts that
      > do not want to implement their own signal handler, we include the option to
      > install a simple one. This simple handler is also used for the tests.
      >
      > When a Wasm module is instantiated, information about each function is passed
      > to the trap handler, which is used to classify faults. These are removed during
      > the instance finalizer.
      >
      > Several future enhancements are planned before turning this on by default.
      > Obviously, the additional checks will be added to MaybeHandleFault. We are
      > also planning to add a two-level CodeObjectData table that is grouped by
      > isolates to make cleanup easier and also reduce potential for contending on
      > a single data structure.
      >
      > BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      >
      > Review-Url: https://codereview.chromium.org/2371833007
      > Cr-Original-Commit-Position: refs/heads/master@{#43523}
      > Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
      > Review-Url: https://codereview.chromium.org/2371833007
      > Cr-Commit-Position: refs/heads/master@{#43755}
      > Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b
      
      TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2744383002
      Cr-Commit-Position: refs/heads/master@{#43757}
      aba151b9
    • eholk's avatar
      [wasm] Initial signal handler · 338622d7
      eholk authored
      This is basically the minimum viable signal handler for Wasm bounds checks.
      It includes the TLS check and the fine grained instructions checks. These
      two checks provide most of the safety for the signal handler. Future CLs will
      add code range and data range checks for more robustness.
      
      The trap handling code and data structures are all in src/trap-handler, with
      the code that actually runs in the signal handler confined to
      src/trap-handler/signal-handler.cc.
      
      This changes adds a new V8 API that the embedder should call from a signal
      handler that will give V8 the chance to handle the fault first. For hosts that
      do not want to implement their own signal handler, we include the option to
      install a simple one. This simple handler is also used for the tests.
      
      When a Wasm module is instantiated, information about each function is passed
      to the trap handler, which is used to classify faults. These are removed during
      the instance finalizer.
      
      Several future enhancements are planned before turning this on by default.
      Obviously, the additional checks will be added to MaybeHandleFault. We are
      also planning to add a two-level CodeObjectData table that is grouped by
      isolates to make cleanup easier and also reduce potential for contending on
      a single data structure.
      
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Original-Commit-Position: refs/heads/master@{#43523}
      Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Commit-Position: refs/heads/master@{#43755}
      338622d7
  16. 07 Mar, 2017 1 commit
    • bjaideep's avatar
      AIX: Work around for malloc(0) behavior · 7c0f3f06
      bjaideep authored
      malloc(0) returning 0 is expected behavior on AIX but
      compiling with -D_LINUX_SOURCE_COMPAT, malloc(0) should
      return a valid pointer (which we do define for AIX). However,
      including cstdlib resets the behaviour of _LINUX_SOURCE_COMPAT.
      GCC bug: 79839
      
      R=jochen@chromium.org, titzer@chromium.org
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2732743002
      Cr-Commit-Position: refs/heads/master@{#43647}
      7c0f3f06
  17. 03 Mar, 2017 1 commit
    • clemensh's avatar
      [wasm] Prepare WasmCompilationUnit for lazy compilation · 7f68cbbf
      clemensh authored
      In lazy compilation, we only compile one function at a time, and we
      might not have the wire bytes of the whole module available.
      This CL prepares the WasmCompilationUnit for this setting.
      It will also be helpful for streaming compilation.
      
      Also, the ErrorThrower (which might heap-allocate) is not stored in the
      WasmCompilationUnit any more. Instead, it is passed to the
      FinishCompilation method which is allowed to heap-allocate.
      
      R=titzer@chromium.org, ahaas@chromium.org
      BUG=v8:5991
      
      Review-Url: https://codereview.chromium.org/2726553003
      Cr-Commit-Position: refs/heads/master@{#43573}
      7f68cbbf
  18. 02 Mar, 2017 1 commit
  19. 01 Mar, 2017 2 commits
    • bmeurer's avatar
      Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of... · 0b3e554e
      bmeurer authored
      Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of https://codereview.chromium.org/2371833007/ )
      
      Reason for revert:
      Breaks tree, i.e. https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/18928/steps/Check/logs/grow-memory
      
      Original issue's description:
      > [wasm] Initial signal handler
      >
      > This is basically the minimum viable signal handler for Wasm bounds checks.
      > It includes the TLS check and the fine grained instructions checks. These
      > two checks provide most of the safety for the signal handler. Future CLs will
      > add code range and data range checks for more robustness.
      >
      > The trap handling code and data structures are all in src/trap-handler, with
      > the code that actually runs in the signal handler confined to
      > src/trap-handler/signal-handler.cc.
      >
      > This changes adds a new V8 API that the embedder should call from a signal
      > handler that will give V8 the chance to handle the fault first. For hosts that
      > do not want to implement their own signal handler, we include the option to
      > install a simple one. This simple handler is also used for the tests.
      >
      > When a Wasm module is instantiated, information about each function is passed
      > to the trap handler, which is used to classify faults. These are removed during
      > the instance finalizer.
      >
      > Several future enhancements are planned before turning this on by default.
      > Obviously, the additional checks will be added to MaybeHandleFault. We are
      > also planning to add a two-level CodeObjectData table that is grouped by
      > isolates to make cleanup easier and also reduce potential for contending on
      > a single data structure.
      >
      > BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      >
      > Review-Url: https://codereview.chromium.org/2371833007
      > Cr-Commit-Position: refs/heads/master@{#43523}
      > Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
      
      TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org,eholk@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2723133003
      Cr-Commit-Position: refs/heads/master@{#43525}
      0b3e554e
    • eholk's avatar
      [wasm] Initial signal handler · a5af7fe9
      eholk authored
      This is basically the minimum viable signal handler for Wasm bounds checks.
      It includes the TLS check and the fine grained instructions checks. These
      two checks provide most of the safety for the signal handler. Future CLs will
      add code range and data range checks for more robustness.
      
      The trap handling code and data structures are all in src/trap-handler, with
      the code that actually runs in the signal handler confined to
      src/trap-handler/signal-handler.cc.
      
      This changes adds a new V8 API that the embedder should call from a signal
      handler that will give V8 the chance to handle the fault first. For hosts that
      do not want to implement their own signal handler, we include the option to
      install a simple one. This simple handler is also used for the tests.
      
      When a Wasm module is instantiated, information about each function is passed
      to the trap handler, which is used to classify faults. These are removed during
      the instance finalizer.
      
      Several future enhancements are planned before turning this on by default.
      Obviously, the additional checks will be added to MaybeHandleFault. We are
      also planning to add a two-level CodeObjectData table that is grouped by
      isolates to make cleanup easier and also reduce potential for contending on
      a single data structure.
      
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Commit-Position: refs/heads/master@{#43523}
      a5af7fe9
  20. 21 Feb, 2017 2 commits
    • clemensh's avatar
      [wasm] Test argument passing in the interpreter entry · e6819ee2
      clemensh authored
      Test the wasm interpreter entry stub by creating two wasm functions A
      and B, make A pass arguments to B, then redirect B to be executed in the
      interpreter.
      Test different number and types or arguments.
      
      BUG=v8:5822
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2651793003
      Cr-Commit-Position: refs/heads/master@{#43353}
      e6819ee2
    • mtrofin's avatar
      [wasm] Managed<T> ensures T's lifetime does not leak past Isolate's · caa1d4b2
      mtrofin authored
      Native resources allocated by v8, as internal implementation detail,
      and held by a Foreign object, must be released when the Isolate is
      torn down. Example: wasm::WasmModule allocated by wasm compile, and
      held throughout the lifetime of the WebAssembly.Module object.
      
      This change:
      - Extends Managed<CppType> with a mechanism for doing just that
      - Separates the role of Managed<CppType> to be strictly an owner of
      the lifetime of the native resource. For cases where that's not
      desirable, we can polymorphically use Foregin.
      - moves managed.h out of wasm, since it's not wasm-specific.
      
      BUG=680065
      
      Review-Url: https://codereview.chromium.org/2676513008
      Cr-Commit-Position: refs/heads/master@{#43350}
      caa1d4b2
  21. 10 Feb, 2017 1 commit
    • ahaas's avatar
      [wasm] Do not use setjmp/longjmp in cctests. · 79570f87
      ahaas authored
      The use of setjmp/longjmp makes the cctests in test-run-wasm and
      test-run-wasm-64 flaky on Windows, and I think that it is better not
      to use it. With this CL I replace it as follows:
      
      Similar to the setjmp/longjmp implementation we still call a C
      function when a trap happens. However, instead of calling longjmp in
      this C function we just set a flag which indicates that a trap
      happened and then return. After we return from the C function we leave
      the frame of the current wasm function and return with a RET
      instruction. At the end of a test the wasm test runner checks the flag
      to see if a trap happened.
      
      Please take a special look at the LeaveFrame function on arm64.
      
      R=titzer@chromium.org, clemensh@chromium.org, v8-arm-ports@googlegroups.com
      CC=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2685583003
      Cr-Commit-Position: refs/heads/master@{#43095}
      79570f87
  22. 01 Feb, 2017 1 commit
  23. 26 Jan, 2017 1 commit
  24. 23 Jan, 2017 2 commits
  25. 20 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Add tests for breakpoints · a1e04ef5
      clemensh authored
      Test that setting breakpoints works for wasm, and that they are hit
      correctly.
      This basically tests all the layers involved: Compiling and running
      wasm interpreter entries, passing arguments to the interpreter, storing
      break point infos in wasm objects, getting the right BreakLocation from
      wasm frames, and getting stack information from interpreted frames.
      
      BUG=v8:5822
      R=titzer@chromium.org, yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2629883002
      Cr-Commit-Position: refs/heads/master@{#42560}
      a1e04ef5
  26. 18 Jan, 2017 1 commit
  27. 15 Jan, 2017 1 commit