1. 16 Oct, 2015 1 commit
    • rmcilroy's avatar
      [Interpreter]: Basic support for iterating interpreter stack frames for GC. · 4b2fffae
      rmcilroy authored
      Adds basic support for iterating interpreter stack frames for GC. Currently
      InterpreterStackFrames are treated just like JavaScriptStackFrames since the
      JavaScriptFrame::IterateExpressions() will correctly iterate over all the
      local / temp interpeter Registers, and will iterate over the
      interpreter_entry_trampoline pc address. There is no need to explicitly
      iterate over the BytecodeArray object since that is held in a machine
      register in the bytecode handler which is marked as kMachTaggedAny by
      TurboFan, and so will get iterated appropriately when iterating the
      bytecode handler stub's stack frame.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1407513003
      
      Cr-Commit-Position: refs/heads/master@{#31342}
      4b2fffae
  2. 30 Sep, 2015 1 commit
  3. 01 Sep, 2015 1 commit
  4. 13 Jul, 2015 1 commit
  5. 25 Mar, 2015 1 commit
    • mstarzinger's avatar
      Switch full-codegen from StackHandlers to handler table. · 38a719f9
      mstarzinger authored
      This switches full-codegen to no longer push and pop StackHandler
      markers onto the operand stack, but relies on a range-based handler
      table instead. We only use StackHandlers in JSEntryStubs to mark the
      transition from C to JS code.
      
      Note that this makes deoptimization and OSR from within any try-block
      work out of the box, makes the non-exception paths faster and should
      overall be neutral on the memory footprint (pros).
      
      On the other hand it makes the exception paths slower and actually
      throwing and exception more expensive (cons).
      
      R=yangguo@chromium.org
      TEST=cctest/test-run-jsexceptions/DeoptTry
      
      Review URL: https://codereview.chromium.org/1010883002
      
      Cr-Commit-Position: refs/heads/master@{#27440}
      38a719f9
  6. 18 Mar, 2015 1 commit
    • mstarzinger's avatar
      Remove kind field from StackHandler. · 15f82138
      mstarzinger authored
      This relands commit 96f79568.
      
      This makes the Isolate::Throw logic not depend on a prediction of
      whether an exception is caught or uncaught. Such a prediction is
      inherently undecidable because a finally block can decide between
      consuming or re-throwing an exception depending on arbitray control
      flow.
      
      There still is a conservative prediction mechanism in place that
      components like the debugger or tracing can use for reporting.
      
      With this change we can get rid of the StackHandler::kind field, a
      pre-requisite to do table-based lookups of exception handlers.
      
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/997213003
      
      Cr-Commit-Position: refs/heads/master@{#27263}
      15f82138
  7. 16 Mar, 2015 2 commits
    • mstarzinger's avatar
      Revert of Remove kind field from StackHandler. (patchset #4 id:60001 of... · 5977ed02
      mstarzinger authored
      Revert of Remove kind field from StackHandler. (patchset #4 id:60001 of https://codereview.chromium.org/1002203002/)
      
      Reason for revert:
      Layout test failure in inspector/sources/debugger/debugger-pause-on-promise-rejection.html
      
      Original issue's description:
      > Remove kind field from StackHandler.
      >
      > This makes the Isolate::Throw logic not depend on a prediction of
      > whether an exception is caught or uncaught. Such a prediction is
      > inherently undecidable because a finally block can decide between
      > consuming or re-throwing an exception depending on arbitray control
      > flow.
      >
      > There still is a conservative prediction mechanism in place that
      > components like the debugger or tracing can use for reporting.
      >
      > With this change we can get rid of the StackHandler::kind field, a
      > pre-requisite to do table-based lookups of exception handlers.
      >
      > R=yangguo@chromium.org
      >
      > Committed: https://crrev.com/96f79568a926966ebcf0685bf9adc947f4e1fbff
      > Cr-Commit-Position: refs/heads/master@{#27210}
      
      TBR=yangguo@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1009903002
      
      Cr-Commit-Position: refs/heads/master@{#27215}
      5977ed02
    • mstarzinger's avatar
      Remove kind field from StackHandler. · 96f79568
      mstarzinger authored
      This makes the Isolate::Throw logic not depend on a prediction of
      whether an exception is caught or uncaught. Such a prediction is
      inherently undecidable because a finally block can decide between
      consuming or re-throwing an exception depending on arbitray control
      flow.
      
      There still is a conservative prediction mechanism in place that
      components like the debugger or tracing can use for reporting.
      
      With this change we can get rid of the StackHandler::kind field, a
      pre-requisite to do table-based lookups of exception handlers.
      
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1002203002
      
      Cr-Commit-Position: refs/heads/master@{#27210}
      96f79568
  8. 10 Mar, 2015 2 commits
  9. 03 Mar, 2015 1 commit
  10. 16 Jan, 2015 1 commit
  11. 01 Oct, 2014 1 commit
  12. 04 Aug, 2014 1 commit
  13. 09 Jul, 2014 1 commit
  14. 20 Jun, 2014 1 commit
  15. 03 Jun, 2014 1 commit
  16. 23 May, 2014 1 commit
  17. 29 Apr, 2014 1 commit
  18. 21 Mar, 2014 1 commit
  19. 14 Mar, 2014 1 commit
  20. 12 Feb, 2014 1 commit
  21. 23 Jul, 2013 1 commit
    • yurys@chromium.org's avatar
      Fix call stack sampling for the case when native callback invokes JS function · 97f8f91b
      yurys@chromium.org authored
      The SafeStackFrameIterator used by CPU profiler checked if Isolate::c_entry_fp is null and if it is not it would think that the control flow currently is in some native code. This assumption is wrong because the native code could have called a JS function but JSEntryStub would not reset c_entry_fp to NULL in that case. This CL adds a check in SafeStackFrameIterator::IsValidTop for the case when there is a JAVA_SCRIPT frame on top of EXIT frame.
      
      Also this CL changes ExternalCallbackScope behavior to provide access to the whole stack of the scope objects instead of only top one. This allowed to provide exact callback names for those EXIT frames where external callbacks are called. Without this change it was possible only for the top most native call.
      
      BUG=None
      R=loislo@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/19775017
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      97f8f91b
  22. 11 Jul, 2013 1 commit
  23. 28 Jun, 2013 1 commit
  24. 27 Jun, 2013 3 commits
  25. 25 Jun, 2013 1 commit
  26. 24 Jun, 2013 1 commit
    • yurys@chromium.org's avatar
      Simplify stack iterators implementation · f830fbea
      yurys@chromium.org authored
      In order to fix https://code.google.com/p/chromium/issues/detail?id=252097 I
      need to change SafeStackTraceFrameIterator. Stack iterators hierarchy looks
      excessively complicated and I'd like to flatten it a bit by removing some
      intermediate classes. In particular there are two hierarchies sharing
      JavaScriptFrameIteratorTemp<T> template for no good reason.
      
      This change extracts some of JavaScriptFrameIteratorTemp functionality directly
      into SafeStackTraceFrameIterator. This made it obvious that a few checks were
      performed twice.
      
      The rest of JavaScriptFrameIteratorTemp<T> is merged with
      JavaScriptFrameIterator. Now that the class is not a template some of its
      implementation is moved from frames-inl.h into frames.cc
      
      So in this change I removed JavaScriptFrameIterator and
      SafeJavaScriptFrameIterator. As the next step I'm going to merge
      SafeStackFrameIterator into SafeStackTraceFrameIterator.
      
      BUG=None
      R=loislo@chromium.org, svenpanne@chromium.org
      
      Review URL: https://codereview.chromium.org/16917004
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15275 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      f830fbea
  27. 08 May, 2013 1 commit
  28. 26 Apr, 2013 2 commits
  29. 05 Feb, 2013 1 commit
  30. 29 Jan, 2013 1 commit
  31. 18 Dec, 2012 1 commit
  32. 10 Dec, 2012 1 commit
  33. 05 Dec, 2012 1 commit
  34. 03 Dec, 2012 2 commits