1. 24 Jan, 2018 1 commit
  2. 09 Nov, 2017 1 commit
  3. 21 Jul, 2017 2 commits
  4. 13 Jul, 2017 1 commit
  5. 19 Jun, 2017 1 commit
    • jgruber's avatar
      [coverage] Add continuation counters · 95882f0e
      jgruber authored
      Track execution counts of the continuations of block structures (e.g.
      IfStatements) to capture cases in which execution does not continue after a
      block. For example:
      
      for (;;) {
        return;
      }
      // Never reached, tracked by continuation counter.
      
      A continuation counter only has a start position; it's range is implicitly
      until the next sibling range or the end of the parent range.
      
      Bug: v8:6000
      Change-Id: I8e8f1f5b140b64c86754b916e626eb50f0707d70
      Reviewed-on: https://chromium-review.googlesource.com/530846
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46006}
      95882f0e
  6. 15 May, 2017 1 commit
  7. 05 Apr, 2017 1 commit
  8. 09 Jan, 2017 1 commit
  9. 29 Nov, 2016 3 commits
  10. 13 Sep, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Merge {OsrPoll} with {Jump} bytecode. · c9864173
      mstarzinger authored
      This introduces a new {JumpLoop} bytecode to combine the OSR polling
      mechanism modeled by {OsrPoll} with the actual {Jump} performing the
      backwards branch. This reduces the overall size and also avoids one
      additional dispatch. It also makes sure that OSR polling is only done
      within real loops.
      
      R=rmcilroy@chromium.org
      BUG=v8:4764
      
      Review-Url: https://codereview.chromium.org/2331033002
      Cr-Commit-Position: refs/heads/master@{#39384}
      c9864173
  11. 19 Aug, 2016 1 commit
  12. 02 Aug, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Elide OSR polling from fake loops. · 962fd4ae
      mstarzinger authored
      This makes sure we are not inserting {OsrPoll} instructions for any
      statements that are not actually loops and have no back edges. Without
      back edges the {BytecodeGraphBuilder} is unable to deduce loop ranges
      and hence cannot construct a graph for OSR entry.
      
      R=neis@chromium.org
      TEST=mjsunit/regress/regress-5252
      BUG=v8:5252
      
      Review-Url: https://codereview.chromium.org/2200733002
      Cr-Commit-Position: refs/heads/master@{#38233}
      962fd4ae
  13. 22 Jul, 2016 1 commit
    • yangguo's avatar
      [debug] use catch prediction flag for promise rejections. · 6d0a4202
      yangguo authored
      This is in preparation to implementing exception prediction for async
      functions.  Each handler table entry can now predict "caught", "uncaught", or
      "promise". The latter indicates that the exception will lead to a promise
      rejection.
      
      To mark the relevant try-catch blocks, we add a new native syntax.
      try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
      prediction.
      
      The previous implementation of using the function to tell the relevant
      try-catch apart from inner try-catch blocks will not work for async functions
      since these can have inner try-catch blocks inside the same function.
      
      BUG=v8:5167
      
      Review-Url: https://codereview.chromium.org/2161263003
      Cr-Commit-Position: refs/heads/master@{#37966}
      6d0a4202
  14. 12 Jul, 2016 1 commit
  15. 04 May, 2016 1 commit
  16. 27 Apr, 2016 1 commit
  17. 12 Feb, 2016 2 commits
  18. 11 Feb, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Correctly thread through catch prediction. · ba55f559
      mstarzinger authored
      This change correctly sets the {CatchPrediction} field in exception
      handler tables for bytecode and optimized code. It also adds tests
      independent of promise handling for this prediction, to ensure all our
      backends are in sync on their prediction.
      
      R=rmcilroy@chromium.org,yangguo@chromium.org
      TEST=mjsunit/compiler/debug-catch-prediction
      BUG=v8:4674
      LOG=n
      
      Review URL: https://codereview.chromium.org/1690973002
      
      Cr-Commit-Position: refs/heads/master@{#33906}
      ba55f559
  19. 22 Jan, 2016 1 commit
  20. 20 Jan, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Implement exception handler table building. · 82716f1c
      mstarzinger authored
      This implements a first version of exception handler table construction
      within the interpreter. Note that the local control flow for try-catch
      and try-finally statements is still off, and also stack unwinding does
      not yet respect interpreter frames. But generated handler tables should
      be populated correctly already.
      
      R=oth@chromium.org
      BUG=v8:4674
      LOG=n
      
      Review URL: https://codereview.chromium.org/1607433005
      
      Cr-Commit-Position: refs/heads/master@{#33400}
      82716f1c
  21. 21 Dec, 2015 1 commit
  22. 16 Dec, 2015 2 commits
  23. 30 Oct, 2015 1 commit
  24. 29 Oct, 2015 1 commit
    • oth's avatar
      [Interpreter] Add support for for..in. · dcf757a1
      oth authored
      For..in introduces 3 new bytecodes ForInPrepare, ForInNext, and
      ForInDone to start a for..in loop, get the next element, and check if
      the loop is done.
      
      For..in builds upon new LoopBuilder constructs for conditionally
      breaking and continuing during iteration: BreakIf{Null|Undefined}
      and ContinueIf{Null|Undefined}. New conditional jump bytecodes
      support this succinctly: JumpIfNull and JumpIfUndefined.
      
      Add missing check to BytecodeLabel that could allow multiple
      forward referencess to the same label which is not supported.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1422033002
      
      Cr-Commit-Position: refs/heads/master@{#31651}
      dcf757a1
  25. 01 Oct, 2015 1 commit