1. 27 Nov, 2017 1 commit
  2. 22 Nov, 2017 1 commit
  3. 18 Oct, 2017 1 commit
  4. 13 Oct, 2017 2 commits
  5. 15 Sep, 2017 1 commit
  6. 06 Sep, 2017 1 commit
  7. 05 Sep, 2017 1 commit
  8. 29 Aug, 2017 1 commit
  9. 25 Aug, 2017 1 commit
  10. 07 Aug, 2017 2 commits
    • Clemens Hammacher's avatar
      [wasm] [debug] Implement calling imported wasm functions · c39c6eba
      Clemens Hammacher authored
      The interpreter was not able to call imported wasm functions (hitting
      UNIMPLEMENTED). This CL fixes this by creating a "CWasmEntry", which is
      signature-specific. It has JS linkage and receives the wasm code object
      to call and a buffer containing all arguments (similar to the
      interpreter entry). It loads all arguments from the buffer and calls the
      given code object.
      The c-wasm-entry code objects are cached per instance, such that we
      only create them once per signature.
      
      These wasm entry stubs will also allow us to call back to compiled code
      from the interpreter, which we might want to do to reduce the slowdown
      of executing wasm for debugging.
      
      R=titzer@chromium.org
      
      Bug: chromium:735792
      Change-Id: I7fecec3a7bec62a9de40fff115b684759b12a28b
      Reviewed-on: https://chromium-review.googlesource.com/600308
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47195}
      c39c6eba
    • Ben L. Titzer's avatar
      Simplifications to frames.h and frames.cc. · dc34289b
      Ben L. Titzer authored
      Move unnecessarily public methods from frames.h into .cc file.
      Remove dead StackFrame::SetCallerFp().
      
      R=mstarzinger@chromium.org
      
      Bug: 
      Change-Id: I7b66a430cfb01bb38046c9e92f504134ba8316a3
      Reviewed-on: https://chromium-review.googlesource.com/602271Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47181}
      dc34289b
  11. 03 Aug, 2017 2 commits
  12. 01 Aug, 2017 1 commit
  13. 27 Jun, 2017 1 commit
  14. 26 Jun, 2017 1 commit
  15. 15 Jun, 2017 2 commits
    • Leszek Swirski's avatar
      Revert "[frames] Make interpreted frame detection stricter (reland)" · 920796b3
      Leszek Swirski authored
      This reverts commit b7a036a6.
      
      Reason for revert: We don't want to ever access the heap when walking the stack
      
      Original change's description:
      > [frames] Make interpreted frame detection stricter (reland)
      > 
      > When iterating over stack frames, make the interpreted frame detection
      > require that the frame header contains the bytecode array.
      > 
      > Currently, the stack frame iterator supports bytecode handlers that
      > don't create stack frames by checking if the top of the stack (i.e. the
      > return address) is the interpreter entry trampoline. However, optimized
      > code tail called from the interpreter entry trampoline can move the
      > stack pointer without clearing the stack, which means it can end up with
      > a pointer into the interpreter entry trampoline on the top of its stack
      > (in an uninitialized value), and be interpreted as an interpreted frame.
      > 
      > To avoid such optimized code frames being interpreted as interpreted
      > frames, we now additionally test the frame header, to see if it contains
      > a valid pointer to a BytecodeArray.
      > 
      > Reland of https://chromium-review.googlesource.com/c/535646/
      > 
      > Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a
      > Reviewed-on: https://chromium-review.googlesource.com/536935
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45959}
      
      TBR=kozyatinskiy@chromium.org,leszeks@chromium.org
      
      Change-Id: I52a62c8e11af4d1565af92f10113b955f8c2c2f2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/536938Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45960}
      920796b3
    • Leszek Swirski's avatar
      [frames] Make interpreted frame detection stricter (reland) · b7a036a6
      Leszek Swirski authored
      When iterating over stack frames, make the interpreted frame detection
      require that the frame header contains the bytecode array.
      
      Currently, the stack frame iterator supports bytecode handlers that
      don't create stack frames by checking if the top of the stack (i.e. the
      return address) is the interpreter entry trampoline. However, optimized
      code tail called from the interpreter entry trampoline can move the
      stack pointer without clearing the stack, which means it can end up with
      a pointer into the interpreter entry trampoline on the top of its stack
      (in an uninitialized value), and be interpreted as an interpreted frame.
      
      To avoid such optimized code frames being interpreted as interpreted
      frames, we now additionally test the frame header, to see if it contains
      a valid pointer to a BytecodeArray.
      
      Reland of https://chromium-review.googlesource.com/c/535646/
      
      Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a
      Reviewed-on: https://chromium-review.googlesource.com/536935Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45959}
      b7a036a6
  16. 09 Jun, 2017 1 commit
  17. 07 Jun, 2017 1 commit
    • danno's avatar
      Inline Array.prototype.forEach in TurboFan · 90c3a2d5
      danno authored
      This CL contains a few pieces:
      
      - A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
        graphs, which--when triggered--swizzle the values in the the FrameState to be
        parameters to a typically TF-generated builtin that resumes execution to finish
        the slow-case functionality.
      - Continuation builtins that have special handling in the deoptimizer and their own
        new frame type to ensure that the values they need to begin executing can be stashed
        away and restored immediately before the builtin is called via a trampoline that runs
        when the continuation builtin's frame execution resumes.
      - An implementation of Array.prototype.forEach in TurboFan that can be used to
        inline it. The inlined forEach implementation uses the checkpoints mechanism
        described above to deopt in the middle of the forEach in the cases that optimization
        invariants are violated. There is a slightly different continuation stub for each
        deopt point in the forEach implementation to ensure the correct side-effects, i.e.
        that the deopt of the builtin isn't programmatically observable.
      
      Review-Url: https://codereview.chromium.org/2803853005
      Cr-Commit-Position: refs/heads/master@{#45764}
      90c3a2d5
  18. 10 May, 2017 1 commit
  19. 25 Apr, 2017 1 commit
    • ulan's avatar
      Decouple root visitors from object visitors. · e671ed36
      ulan authored
      This patch adds a new interface called RootVisitor and changes the root
      iteration functions to accept a RootVisitor instead of an ObjectVisitor.
      
      Future CLs will change ObjectVisitor to provide the host object to all
      visiting functions, which will bring it in sync with static visitors.
      
      Having separate visitors for roots and objects removes ambiguity in
      VisitPointers and reduces chances of forgetting to record slots.
      
      This is intended as pure refactoring. All places that require behavior
      change are marked with TODO and will addressed in future CLs.
      
      BUG=chromium:709075
      
      Review-Url: https://codereview.chromium.org/2801073006
      Cr-Commit-Position: refs/heads/master@{#44852}
      e671ed36
  20. 19 Apr, 2017 1 commit
  21. 13 Apr, 2017 1 commit
  22. 12 Apr, 2017 1 commit
  23. 07 Apr, 2017 1 commit
  24. 06 Apr, 2017 2 commits
    • Franziska Hinkelmann's avatar
      Revert "[builtins] don't inline calls for common Promise ops in async builtins" · c931820d
      Franziska Hinkelmann authored
      This reverts commit 9461fe24.
      
      Reason for revert: Breaks a test in Node.js: 
       parallel/test-util-inspect
      
      === release test-util-inspect ===                                              
      Path: parallel/test-util-inspect
      #
      # Fatal error in , line 0
      # unreachable code
      #
      
      ==== C stack trace ===============================
      
      
      Original change's description:
      > [builtins] don't inline calls for common Promise ops in async builtins
      > 
      > InternalResolvePromise, InternalPromiseReject and
      > InternalPerformPromiseThen generate quite a lot of code.
      > 
      > This change adds 3 new TF stubs which inline calls to these builtins.
      > These stubs are invoked rather than inlining those operations listed
      > above directly. This is done for Async Iteration builtins, as well as
      > Async Function builtins. Promise builtins are left as they were, and
      > continue to inline these calls.
      > 
      > This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
      > release build.
      > 
      > BUG=v8:5855
      > R=​gsathya@chromium.org, jgruber@chromium.org
      > 
      > Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
      > Reviewed-on: https://chromium-review.googlesource.com/461269
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#44445}
      
      TBR=mstarzinger@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,v8-reviews@googlegroups.com,bmeurer@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5855
      
      Change-Id: Iabcdf8b025cc9b053a858f8e74389638ac000ba0
      Reviewed-on: https://chromium-review.googlesource.com/469946Reviewed-by: 's avatarFranziska Hinkelmann <franzih@chromium.org>
      Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44448}
      c931820d
    • Caitlin Potter's avatar
      [builtins] don't inline calls for common Promise ops in async builtins · 9461fe24
      Caitlin Potter authored
      InternalResolvePromise, InternalPromiseReject and
      InternalPerformPromiseThen generate quite a lot of code.
      
      This change adds 3 new TF stubs which inline calls to these builtins.
      These stubs are invoked rather than inlining those operations listed
      above directly. This is done for Async Iteration builtins, as well as
      Async Function builtins. Promise builtins are left as they were, and
      continue to inline these calls.
      
      This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
      release build.
      
      BUG=v8:5855
      R=gsathya@chromium.org, jgruber@chromium.org
      
      Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
      Reviewed-on: https://chromium-review.googlesource.com/461269
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44445}
      9461fe24
  25. 02 Mar, 2017 1 commit
  26. 21 Feb, 2017 1 commit
  27. 02 Feb, 2017 1 commit
    • yangguo's avatar
      [debugger] account for inlined functions when stepping. · d9399cc3
      yangguo authored
      - Remove obsolete BreakLocatorType.
      - Perform PrepareStepOnThrow after OnException event, in case stepping
        was scheduled in the exception event.
      - Use frame count instead of frame pointer for stepping. Frame pointer
        is not reliable due to possible deopts.
      - Consistently check for inlined functions in inlined frames.
      - Use SharedFunctionInfo in FloodWithOneshot and EnsureDebugInfo.
      
      R=jgruber@chromium.org
      BUG=v8:5901
      
      Review-Url: https://codereview.chromium.org/2664793002
      Cr-Commit-Position: refs/heads/master@{#42878}
      d9399cc3
  28. 24 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Implement stepping in wasm code · 3dea55b4
      clemensh authored
      Implement stepping by remembering the current step action in the wasm
      interpreter handle in WasmDebugInfo, and using it when continuing
      execution in the interpreter.
      The control flow is as follows: After module compilation, the user sets
      a breakpoint in wasm. The respective function is redirected to the
      interpreter and the breakpoint is set on the interpreter. When it is
      hit, we notify all debug event listeners, which might prepare stepping.
      When returning from these listeners, before continuing execution, we
      check whether stepping was requested and continue execution in the
      interpreter accordingly.
      
      Stepping from Wasm to JS and vice versa will be implemented and tested
      in a follow-up CL. Testing this requires breakpoints and stepping in
      Wasm to be exposed via the inspector interface, such that we can write
      an inspector test. This mixed JS-Wasm-execution is hard to set up in a
      cctest.
      
      R=titzer@chromium.org, yangguo@chromium.org
      BUG=
      
      Review-Url: https://codereview.chromium.org/2649533002
      Cr-Commit-Position: refs/heads/master@{#42624}
      3dea55b4
  29. 19 Jan, 2017 1 commit
    • clemensh's avatar
      Clarify the order of frame summaries and rename getters · 453a1df2
      clemensh authored
      Document that frame summaries are bottom-to-top, i.e. caller before
      callee, rename FrameSummary::GetFirst to FrameSummary::GetBottom and
      introduce FrameSummary::GetTop.
      For debugged JavaScript frames, it does not really matter which of the
      functions we call, so I replaced a few GetFirst by GetTop instead of
      GetBottom because it matches the semantics more closely.
      
      This CL also reverts part of http://crrev.com/2621953002 by changing
      BreakLocation::FromFrame back to accept a DebugInfo and a
      JavaScriptFrame. We don't plan to create BreakLocations for wasm.
      
      R=yangguo@chromium.org
      BUG=v8:5822
      
      Review-Url: https://codereview.chromium.org/2647433002
      Cr-Commit-Position: refs/heads/master@{#42505}
      453a1df2
  30. 13 Jan, 2017 3 commits
  31. 12 Jan, 2017 1 commit
    • clemensh's avatar
      Refactor FrameSummary for JS and Wasm frames · df5417ae
      clemensh authored
      Wasm frames can be either compiled or interpreted. For interpreted wasm
      frames, there is only one physical stack frame representing an
      arbitrary stack of interpreted functions. Hence the physical stack
      frame needs to provide a summary of the underlying functions.
      Summaries were tailored for JavaScript frames before. Now they are
      universal.
      
      The refactored FrameSummaries are now also used in the FrameInspector,
      and from the StackFrame objects themselves, to avoid code duplication.
      
      All dispatch is implemented "manually", making the FrameSummary still
      stack-allocatable.
      
      BUG=v8:5822
      R=yangguo@chromium.org, titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2619353006
      Cr-Commit-Position: refs/heads/master@{#42279}
      df5417ae
  32. 11 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Introduce WasmToInterpreterFrame · 81700ddf
      clemensh authored
      and rename WasmFrame to WasmCompiledFrame.
      The WasmToInterpreterFrames are not used yet; this will follow in a
      follow-up CL (see tracking bug for the overall picture).
      Those frames will represent frames for WASM_TO_INTERPRETER stubs, which
      call from wasm code to the wasm interpreter, implemented in C++.
      They will support the Summarize method to inspect the stack frames in
      the wasm interpreter.
      
      R=yangguo@chromium.org, titzer@chromium.org
      BUG=v8:5822
      
      Review-Url: https://codereview.chromium.org/2623773004
      Cr-Commit-Position: refs/heads/master@{#42213}
      81700ddf
  33. 19 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Always provide a wasm instance object at runtime · 21a85c4a
      clemensh authored
      When executing wasm code for testing, we did not create a
      WasmInstanceObject and link it to the generated code. This required
      some special handling at runtime (mainly for stack trace generation).
      This CL always provides the WasmInstanceObject, such that e.g. function
      names can be resolved the usual way.
      The module bytes referenced by the WasmCompiledModule linked with the
      WasmInstanceObject do not hold a valid wasm module yet. Instead, we
      just add the bytes we need, and make the objects in WasmModule point to
      those bytes (currently only used for function names). Those bytes will
      not be parsed at runtime anyway.
      
      R=titzer@chromium.org
      CC=jgruber@chromium.org
      BUG=v8:5620
      
      Review-Url: https://codereview.chromium.org/2551053002
      Cr-Commit-Position: refs/heads/master@{#41809}
      21a85c4a