1. 21 Feb, 2018 1 commit
  2. 19 Feb, 2018 1 commit
  3. 10 Jan, 2018 1 commit
  4. 18 Dec, 2017 1 commit
  5. 20 Nov, 2017 1 commit
  6. 16 Nov, 2017 1 commit
  7. 14 Nov, 2017 3 commits
  8. 03 Nov, 2017 2 commits
  9. 24 Oct, 2017 1 commit
  10. 16 Oct, 2017 1 commit
  11. 26 Sep, 2017 1 commit
    • Yang Guo's avatar
      [snapshot] add kProduceExhaustiveCodeCache option. · 7f9de3dc
      Yang Guo authored
      - Add kProduceExhaustiveCodeCache to v8::ScriptCompiler::CompileOptions
        to request eager compilation to add as much as possible to the code
        cache for the script.
      - Repurpose ParseInfo::kLazy flag.
      - Remove ParseInfo::kDebug flag.
      - Remove --serialize-toplevel as it has become obsolete.
      
      R=marja@chromium.org
      
      Bug: chromium:768705
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ife14f7a1d1c02e525f0b9dbfd2452013d67c7167
      Reviewed-on: https://chromium-review.googlesource.com/684019
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48160}
      7f9de3dc
  12. 15 Sep, 2017 1 commit
  13. 21 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Parsing] Always pass a valid character-stream into the parser · 1bc01952
      Ross McIlroy authored
      Changes the contract of the parser to have a valid character stream passed
      in the ParseInfo rather than the current situation where either:
       - it is passed explicitly (e.g., for streaming scripts)
       - a Script is passed and a character stream is created for this
       - or a source and encoding is passed in ParseInfo and the character stream
         is created from this.
      
      The parse info also now owns the character stream (in a unique_ptr). It
      can be destroyed using a new ResetCharacterStream() function. This will
      enable the character stream to be kept live if any functions are asm.js
      modules which were parsed, in order to be reused by the asm.js parser.
      
      BUG=v8:5203
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ifda167391b2eadb38ebf9fcb2f565d2ed9ea3c6f
      Reviewed-on: https://chromium-review.googlesource.com/616767
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47474}
      1bc01952
  14. 18 Aug, 2017 1 commit
  15. 14 Aug, 2017 1 commit
  16. 04 Aug, 2017 1 commit
  17. 27 Jul, 2017 3 commits
  18. 26 Jul, 2017 1 commit
  19. 25 Jul, 2017 1 commit
  20. 21 Jul, 2017 1 commit
  21. 13 Jul, 2017 1 commit
  22. 12 Jul, 2017 1 commit
  23. 30 Jun, 2017 1 commit
  24. 04 May, 2017 1 commit
  25. 03 May, 2017 1 commit
  26. 02 May, 2017 2 commits
  27. 25 Apr, 2017 2 commits
    • Michael Achenbach's avatar
      Revert "[parser] Inital parallel parse tasks implementation." · ef99f666
      Michael Achenbach authored
      This reverts commit 56a6fda3.
      
      Reason for revert: Makes tsan flaky:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/15038
      
      Original change's description:
      > [parser] Inital parallel parse tasks implementation.
      > 
      > While parsing top-level code eager functions are skipped just like lazy
      > ones, but also a parse task is created for each.
      > 
      > The parse tasks are run by the compiler dispatcher and can be executed
      > either on background thread or in idle time.
      > After parsing of top-level code finishes it waits for all unfinished
      > parser tasks - possibly picking up and executing them on current thread.
      > Afterwards parse task results are stitched together with top-level AST,
      > in case of failures eager functions are treated just like lazy -
      > parsing/compilation is retriggered for them in the runtime and proper
      > errors are generated (performance is not optimized for error case at
      > all).
      > 
      > BUG=v8:6093
      > 
      > Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
      > Reviewed-on: https://chromium-review.googlesource.com/483439
      > Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Jochen Eisinger <jochen@chromium.org>
      > Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#44849}
      
      TBR=marja@chromium.org,vogelheim@chromium.org,jochen@chromium.org,wiktorg@google.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:6093
      
      Change-Id: I17e689efee7d216d28a94a5c8147022ae7e830dd
      Reviewed-on: https://chromium-review.googlesource.com/486883Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44859}
      ef99f666
    • Wiktor Garbacz's avatar
      [parser] Inital parallel parse tasks implementation. · 56a6fda3
      Wiktor Garbacz authored
      While parsing top-level code eager functions are skipped just like lazy
      ones, but also a parse task is created for each.
      
      The parse tasks are run by the compiler dispatcher and can be executed
      either on background thread or in idle time.
      After parsing of top-level code finishes it waits for all unfinished
      parser tasks - possibly picking up and executing them on current thread.
      Afterwards parse task results are stitched together with top-level AST,
      in case of failures eager functions are treated just like lazy -
      parsing/compilation is retriggered for them in the runtime and proper
      errors are generated (performance is not optimized for error case at
      all).
      
      BUG=v8:6093
      
      Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
      Reviewed-on: https://chromium-review.googlesource.com/483439
      Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarJochen Eisinger <jochen@chromium.org>
      Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44849}
      56a6fda3
  28. 19 Apr, 2017 1 commit
    • Adam Klein's avatar
      Remove "calls eval" bit from ParseInfo and PreParseData · 9b512732
      Adam Klein authored
      There's no reason to keep track, for a preparsed function itself,
      whether that function calls eval. All that matters is that the ancestor
      scopes are marked as having an inner scope which calls eval. The function
      will have its "calls eval" bit persisted if/when it's fully parsed.
      
      The only "behavioral" change in this patch is the removal of a DCHECK.
      
      Bug: v8:6092
      Change-Id: I17e396c8a265030fe0ad941707e4a97972e6650b
      Reviewed-on: https://chromium-review.googlesource.com/481223
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44732}
      9b512732
  29. 28 Mar, 2017 1 commit
  30. 24 Mar, 2017 1 commit
  31. 28 Feb, 2017 1 commit
    • Adam Klein's avatar
      Accurately record eval calls in arrow parameter lists · fc023664
      Adam Klein authored
      Previously, we over-approximated Scope::scope_calls_eval_ in
      arrow functions: if either the outer scope or the arrow function
      parameters had a direct eval call, we marked both scopes as calling
      eval. This over-approximation kept getting us into trouble, though,
      especially when eager or lazy parsing would disagree about the
      "calls eval" bit.
      
      This patch instead tracks eval calls accurately, using a boolean on
      Scope::Snapshot that is reset as appropriately depending on whether
      a particular AssignmentExpression turned out to be an arrow parameter
      list or not.
      
      BUG=chromium:691687
      
      Change-Id: I527dc59b4d32a2797805ff26dc9f70b1311377b2
      Reviewed-on: https://chromium-review.googlesource.com/446094
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43499}
      fc023664
  32. 16 Feb, 2017 2 commits
    • jwolfe's avatar
      Implement new Function.prototype.toString --harmony-function-tostring · d1d4b9ce
      jwolfe authored
      For functions declared in source code, the .toString() representation
      will be an excerpt of the source code.
      * For functions declared with the "function" keyword, the excerpt
        starts at the "function" or "async" keyword and ends at the final "}".
        The previous behavior would start the excerpt at the "(" of the
        parameter list, and prepend a canonical `"function " + name` or
        similar, which would discard comments and formatting surrounding the
        function's name. Anonymous functions declared as function expressions
        no longer get the name "anonymous" in their toString representation.
      * For methods, the excerpt starts at the "get", "set", "*" (for
        generator methods), or property name, whichever comes first.
        Previously, the toString representation for methods would use a
        canonical prefix before the "(" of the parameter list. Note that any
        "static" keyword is omitted.
      * For arrow functions and class declarations, the excerpt is unchanged.
      
      For functions created with the Function, GeneratorFunction, or
      AsyncFunction constructors:
      * The string separating the parameter text and body text is now
        "\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n".
      * At one point, newline normalization was required by the spec here,
        but that was removed from the spec, and so this CL does not do it.
      
      Included in this CL is a fix for CreateDynamicFunction parsing. ')'
      and '`' characters in the parameter string are no longer disallowed,
      and Function("a=function(", "}){") is no longer allowed.
      
      BUG=v8:4958, v8:4230
      
      Review-Url: https://codereview.chromium.org/2156303002
      Cr-Commit-Position: refs/heads/master@{#43262}
      d1d4b9ce
    • mvstanton's avatar
      This is a workaround for the fact that %SetCode can "lose" the script for a js... · ae8f2820
      mvstanton authored
      This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script.
      
      Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up.
      
      BUG=v8:5946
      R=leszeks@chromium.org
      
      Review-Url: https://codereview.chromium.org/2684033007
      Cr-Original-Commit-Position: refs/heads/master@{#43240}
      Committed: https://chromium.googlesource.com/v8/v8/+/4123a3dd790495c40cf839990318a85c146e057d
      Review-Url: https://codereview.chromium.org/2684033007
      Cr-Commit-Position: refs/heads/master@{#43252}
      ae8f2820