1. 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
  2. 09 Mar, 2017 1 commit
  3. 02 Mar, 2017 1 commit
  4. 01 Mar, 2017 4 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
    • Peter Marshall's avatar
      Revert "[builtins] Port TypedArrayInitialize to CodeStubAssembler." · a8e15e8f
      Peter Marshall authored
      This reverts commit b23b2c10.
      
      Reason for revert: Makes Linux debug bot sad
      
      Original change's description:
      > [builtins] Port TypedArrayInitialize to CodeStubAssembler.
      > 
      > Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
      > because we always go to the C++ builtin. Port the builtin to CSA
      > to improve performance, and to clean up the implementation, which is
      > split across multiple files and pieces at the moment.
      > 
      > This CL increases the performance with --future to roughly the same
      > as with crankshaft.
      > 
      > BUG=v8:5977
      > 
      > Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
      > Reviewed-on: https://chromium-review.googlesource.com/445717
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#43518}
      
      TBR=cbruni@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,v8-reviews@googlegroups.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5977
      
      Change-Id: I5d5bc8b4677a405c716d78e688af80ae9c737b4a
      Reviewed-on: https://chromium-review.googlesource.com/448558Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43520}
      a8e15e8f
    • Peter Marshall's avatar
      [builtins] Port TypedArrayInitialize to CodeStubAssembler. · b23b2c10
      Peter Marshall authored
      Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
      because we always go to the C++ builtin. Port the builtin to CSA
      to improve performance, and to clean up the implementation, which is
      split across multiple files and pieces at the moment.
      
      This CL increases the performance with --future to roughly the same
      as with crankshaft.
      
      BUG=v8:5977
      
      Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
      Reviewed-on: https://chromium-review.googlesource.com/445717
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43518}
      b23b2c10
  5. 28 Feb, 2017 2 commits
  6. 24 Feb, 2017 1 commit
  7. 17 Feb, 2017 1 commit
  8. 16 Feb, 2017 1 commit
  9. 14 Feb, 2017 1 commit
  10. 13 Feb, 2017 4 commits
  11. 10 Feb, 2017 1 commit
  12. 08 Feb, 2017 1 commit
  13. 07 Feb, 2017 1 commit
  14. 06 Feb, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root feedback vectors at function literal site. · aea3ce3d
      mvstanton authored
      TypeFeedbackVectors are strongly rooted by a closure. However, in modern
      JavaScript closures are created and abandoned more freely. An important
      closure may not be present in the root-set at time of garbage collection,
      even though we've cached optimized code and use it regularly. For
      example, consider leaf functions in an event dispatching system. They may
      well be "hot," but tragically non-present when we collect the heap.
      
      Until now, we've relied on a weak root to cache the feedback vector in
      this case. Since there is no way to signal intent or relative importance,
      this weak root is as susceptible to clearing as any other weak root at
      garbage collection time.
      
      Meanwhile, the feedback vector has become more important. All of our
      ICs store their data there. Literal and regex boilerplates are stored there.
      If we lose the vector, then we not only lose optimized code built from
      it, we also lose the very feedback which allowed us to create that optimized
      code. Therefore it's vital to express that dependency through the root
      set.
      
      This CL does this by creating a strong link to a feedback
      vector at the instantiation site of the function closure.
      This instantiation site is in the code and feedback vector
      of the outer closure.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2674593003
      Cr-Commit-Position: refs/heads/master@{#42953}
      aea3ce3d
  15. 31 Jan, 2017 1 commit
  16. 30 Jan, 2017 2 commits
  17. 24 Jan, 2017 2 commits
  18. 23 Jan, 2017 3 commits
  19. 20 Jan, 2017 1 commit
    • franzih's avatar
      [runtime] Allocate space for computed property names. · 399f36b5
      franzih authored
      Allocate space in the backing store for computed property names.
      
      The property backing store was pre-allocated for the constant
      properties up to the first non-constant (computed name) property.
      To use lowering for storing data properties in literals
      with computed property names effectively, a fast store is needed, i.e.,
      available space in the property backing store for properties
      with computed names.
      
      backing_store_size is the number of all properties (including
      computed names, but without __proto__)
      that is calculated in the ast and passed to the runtime function that allocates
      the property backing store. backing_store_size and
      constant_properties constitute a BoilerplateDescription.
      
      backing_store_size might be slightly too high because computed names
      can evaluate to the same name, but that should be a rare
      case so over-allocating is OK.
      
      If a property is __proto__, we don't store it as a regular
      property, because the map changes. Keep track of
      has_seen_proto in the parser to calculate the
      backing store size correctly.
      
      BUG=v8:5625
      
      Review-Url: https://codereview.chromium.org/2632503003
      Cr-Commit-Position: refs/heads/master@{#42576}
      399f36b5
  20. 19 Jan, 2017 1 commit
  21. 18 Jan, 2017 2 commits
  22. 17 Jan, 2017 2 commits
  23. 13 Jan, 2017 3 commits