1. 18 Oct, 2016 1 commit
    • caitp's avatar
      [builtins] implement Array.prototype[@@iterator] in TFJ builtins · 86d0dd36
      caitp authored
      Implements the variations of CreateArrayIterator() in TFJ builtins
      (ArrayPrototypeValues, ArrayPrototypeEntries and ArrayPrototypeKeys), and
      provides two new Object types with numerous maps which identify certain
      behaviours, which will be useful for inlining.
      
      Removes src/js/array-iterator.js entirely
      
      Also adds support for printing Symbol literals inserted by the Parser during
      desugaring when FLAG_print_builtin_ast is set to true.
      
      BUG=v8:5388
      R=bmeurer@chromium.org, cbruni@chromium.org
      TBR=ulan@chromium.org
      
      Review-Url: https://codereview.chromium.org/2405253006
      Cr-Commit-Position: refs/heads/master@{#40373}
      86d0dd36
  2. 14 Oct, 2016 1 commit
    • jgruber's avatar
      [regexp] Turn last match info into a simple FixedArray · f60a7c4f
      jgruber authored
      Now that all accesses to the last match info are in C++ and TF code, we can
      finally turn the last match info into a FixedArray. Similar to the ArrayList,
      it uses its first field to store its length and grows dynamically in amortized
      O(1) time.
      
      Unlike previously, this means that the last match info pointer stored on the
      context can actually change (in case the FixedArray needs to grow).
      
      BUG=v8:5339
      
      Review-Url: https://codereview.chromium.org/2415103002
      Cr-Commit-Position: refs/heads/master@{#40308}
      f60a7c4f
  3. 13 Oct, 2016 4 commits
  4. 12 Oct, 2016 1 commit
  5. 11 Oct, 2016 1 commit
  6. 10 Oct, 2016 1 commit
  7. 07 Oct, 2016 1 commit
  8. 30 Sep, 2016 3 commits
    • neis's avatar
      Reland: [modules] Properly initialize declared variables. · 42724232
      neis authored
      Before evaluating a module, all variables declared at the top-level
      in _any_ of the modules in the dependency graph must be initialized.
      This is observable because a module A can access a variable imported
      from module B (e.g. a function) at a point when module B's body hasn't
      been evaluated yet.
      
      We achieve this by implementing modules internally as generators with
      two states (not initialized, initialized).
      
      R=adamk@chromium.org
      BUG=v8:1569
      CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg
      
      Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
      Committed: https://crrev.com/8c52a411583e870bd5ed100864caa58f491c5d88
      Review-Url: https://codereview.chromium.org/2375793002
      Cr-Original-Original-Commit-Position: refs/heads/master@{#39871}
      Cr-Original-Commit-Position: refs/heads/master@{#39892}
      Cr-Commit-Position: refs/heads/master@{#39900}
      42724232
    • jgruber's avatar
      [regexp] Port RegExp.prototype.exec to TurboFan · db99bdff
      jgruber authored
      This ports RegExp.prototype.exec to a TurboFan builtin.
      
      LastMatchInfo is now stored on the context in order to be able to access
      it from the stub.
      
      Unmodified RegExp instances go through a fast path of accessing the
      lastIndex property as an in-object field, while modified instances call
      into runtime for lastIndex loads and stores.
      
      Octane/regexp shows slight improvements (between 0 and 5%) with this CL.
      
      BUG=v8:5339
      
      Review-Url: https://codereview.chromium.org/2375953002
      Cr-Commit-Position: refs/heads/master@{#39899}
      db99bdff
    • bmeurer's avatar
      Revert of Reland: [modules] Properly initialize declared variables. (patchset... · 669cb71e
      bmeurer authored
      Revert of Reland: [modules] Properly initialize declared variables. (patchset #6 id:100001 of https://codereview.chromium.org/2375793002/ )
      
      Reason for revert:
      Speculative revert for christmas tree
      
      Original issue's description:
      > Reland: [modules] Properly initialize declared variables.
      >
      > Before evaluating a module, all variables declared at the top-level
      > in _any_ of the modules in the dependency graph must be initialized.
      > This is observable because a module A can access a variable imported
      > from module B (e.g. a function) at a point when module B's body hasn't
      > been evaluated yet.
      >
      > We achieve this by implementing modules internally as generators with
      > two states (not initialized, initialized).
      >
      > R=adamk@chromium.org
      > BUG=v8:1569
      > CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg
      >
      > Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
      > Committed: https://crrev.com/8c52a411583e870bd5ed100864caa58f491c5d88
      > Cr-Original-Commit-Position: refs/heads/master@{#39871}
      > Cr-Commit-Position: refs/heads/master@{#39892}
      
      TBR=adamk@chromium.org,mstarzinger@chromium.org,machenbach@chromium.org,neis@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2387593002
      Cr-Commit-Position: refs/heads/master@{#39896}
      669cb71e
  9. 29 Sep, 2016 3 commits
    • neis's avatar
      Reland: [modules] Properly initialize declared variables. · 8c52a411
      neis authored
      Before evaluating a module, all variables declared at the top-level
      in _any_ of the modules in the dependency graph must be initialized.
      This is observable because a module A can access a variable imported
      from module B (e.g. a function) at a point when module B's body hasn't
      been evaluated yet.
      
      We achieve this by implementing modules internally as generators with
      two states (not initialized, initialized).
      
      R=adamk@chromium.org
      BUG=v8:1569
      CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg
      
      Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
      Review-Url: https://codereview.chromium.org/2375793002
      Cr-Original-Commit-Position: refs/heads/master@{#39871}
      Cr-Commit-Position: refs/heads/master@{#39892}
      8c52a411
    • machenbach's avatar
      Revert of [modules] Properly initialize declared variables. (patchset #5... · 7496c9de
      machenbach authored
      Revert of [modules] Properly initialize declared variables. (patchset #5 id:80001 of https://codereview.chromium.org/2375793002/ )
      
      Reason for revert:
      Suspect for causing win64 debug problems:
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12646
      
      Original issue's description:
      > [modules] Properly initialize declared variables.
      >
      > Before evaluating a module, all variables declared at the top-level
      > in _any_ of the modules in the dependency graph must be initialized.
      > This is observable because a module A can access a variable imported
      > from module B (e.g. a function) at a point when module B's body hasn't
      > been evaluated yet.
      >
      > We achieve this by implementing modules internally as generators with
      > two states (not initialized, initialized).
      >
      > R=adamk@chromium.org
      > BUG=v8:1569
      >
      > Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
      > Cr-Commit-Position: refs/heads/master@{#39871}
      
      TBR=adamk@chromium.org,mstarzinger@chromium.org,neis@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2379063002
      Cr-Commit-Position: refs/heads/master@{#39873}
      7496c9de
    • neis's avatar
      [modules] Properly initialize declared variables. · f4dfb6fb
      neis authored
      Before evaluating a module, all variables declared at the top-level
      in _any_ of the modules in the dependency graph must be initialized.
      This is observable because a module A can access a variable imported
      from module B (e.g. a function) at a point when module B's body hasn't
      been evaluated yet.
      
      We achieve this by implementing modules internally as generators with
      two states (not initialized, initialized).
      
      R=adamk@chromium.org
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2375793002
      Cr-Commit-Position: refs/heads/master@{#39871}
      f4dfb6fb
  10. 26 Sep, 2016 1 commit
    • jgruber's avatar
      Enable component builds for fuzzers · 22606f0c
      jgruber authored
      V8 is collecting a growing amount of fuzzers, all of which take substantial
      space on the bots and in chromium build archives. This CL improves that
      situation by allowing component (shared library) builds for almost all fuzzers.
      
      The parser fuzzer is handled as an exception since it would require exporting a
      large number of additional functions.
      
      A component build results in about a 50-100x improvement in file size for each
      fuzzer (~50M-100M to around 1.1M).
      
      BUG=chromium:648864
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
      
      Review-Url: https://codereview.chromium.org/2360983002
      Cr-Commit-Position: refs/heads/master@{#39709}
      22606f0c
  11. 23 Sep, 2016 1 commit
    • littledan's avatar
      Improve stack traces for async functions · f296dad9
      littledan authored
      This patch tracks the stack of async functions differently from other
      Promise async stack tracking. With this patch, the stack trace of a
      callstack of async functions should look similarly to the call stack
      if all of the functions were synchronous. An example can be found in
      the updated test expectations: https://codereview.chromium.org/2362923002 .
      
      The new stack traces are implemented using existing mechanisms in the
      inspector. The inspector has two ways to save async stack traces: recurring
      and non-recurring stacks. An example of a non-recurring stack is setTimeout,
      and a recurring one is saved for setInterval. Recurring stacks are deleted
      only when a special "cancel" function is called, rather than being deleted
      after being used the first time. Previous Promise async stack tracking always
      used non-recurring stacks.
      
      For async functions, this patch saves a recurring stack. The top frame of
      the stack is duplicated, as the resuming function contains a similar frame;
      the devtools frontend is responsible for removing or marking this frame,
      which it can do based on seeing the [async function] line which follows it.
      The second frame will instead be provided by the resuming execution
      context. The recurring stack is saved when the async function is entered, and
      it is deleted from a finally block. The id of the stack is saved in the outer
      Promise being constructed by the async function. When an intermediate
      throwaway Promise will be triggered as a reaction, it will be identified as
      such based on its debugging metadata, and the corresponding async function's
      recurring stack will be used.
      
      BUG=v8:4483
      
      Review-Url: https://codereview.chromium.org/2357423002
      Cr-Commit-Position: refs/heads/master@{#39695}
      f296dad9
  12. 21 Sep, 2016 2 commits
  13. 16 Sep, 2016 1 commit
  14. 13 Sep, 2016 1 commit
    • littledan's avatar
      Mark await expressions as caught or uncaught · edb4d315
      littledan authored
      Handle some examples of the "asynchronous case" by marking await expressions
      as either caught or uncaught; in the caught case, this marks the Promise passed
      in as having a catch predicted. The marking is done in AST numbering, which
      chooses between two different runtime function calls based on catch prediction.
      
      BUG=v8:5167
      
      Review-Url: https://codereview.chromium.org/2276243002
      Cr-Commit-Position: refs/heads/master@{#39394}
      edb4d315
  15. 12 Sep, 2016 4 commits
  16. 02 Sep, 2016 1 commit
  17. 01 Sep, 2016 1 commit
  18. 29 Aug, 2016 1 commit
  19. 26 Aug, 2016 1 commit
    • littledan's avatar
      Desugar async/await to create the resulting Promise upfront · 5386c006
      littledan authored
      As part of the work to implement catch prediction for async functions,
      the resulting Promise that is the output of the function needs to be
      available earlier for a couple reasons:
      - To be able to do %DebugPushPromise/%DebugPopPromise over the body
        of the async function
      - To be able to pass the resulting promise into AsyncFunctionAwait
        in order to set up the dependency chains
      
      This patch creates the Promise earlier and pushes it onto the debug
      stack; a later patch will set up the dependency chain. Although the
      debug stack is set up, it's not anticipated that this will change
      the catch prediction helpfully yet, as everything will still likely
      be predicted as 'caught' for now, as before.
      
      R=caitp@igalia.com,yangguo@chromium.org
      CC=neis@chromium.org,gsathya@chromium.org
      BUG=v8:5167
      
      Review-Url: https://codereview.chromium.org/2233923003
      Cr-Commit-Position: refs/heads/master@{#38957}
      5386c006
  20. 22 Aug, 2016 1 commit
  21. 10 Aug, 2016 1 commit
  22. 09 Aug, 2016 1 commit
  23. 03 Aug, 2016 1 commit
  24. 02 Aug, 2016 2 commits
  25. 01 Aug, 2016 3 commits
  26. 29 Jul, 2016 1 commit