1. 22 May, 2017 1 commit
  2. 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
  3. 06 Apr, 2017 1 commit
  4. 30 Mar, 2017 1 commit
  5. 16 Feb, 2017 1 commit
    • 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
  6. 06 Feb, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root feedback vectors at function literal site. · aea3ce3d
      mvstanton authored
      TypeFeedbackVectors are strongly rooted by a closure. However, in modern
      JavaScript closures are created and abandoned more freely. An important
      closure may not be present in the root-set at time of garbage collection,
      even though we've cached optimized code and use it regularly. For
      example, consider leaf functions in an event dispatching system. They may
      well be "hot," but tragically non-present when we collect the heap.
      
      Until now, we've relied on a weak root to cache the feedback vector in
      this case. Since there is no way to signal intent or relative importance,
      this weak root is as susceptible to clearing as any other weak root at
      garbage collection time.
      
      Meanwhile, the feedback vector has become more important. All of our
      ICs store their data there. Literal and regex boilerplates are stored there.
      If we lose the vector, then we not only lose optimized code built from
      it, we also lose the very feedback which allowed us to create that optimized
      code. Therefore it's vital to express that dependency through the root
      set.
      
      This CL does this by creating a strong link to a feedback
      vector at the instantiation site of the function closure.
      This instantiation site is in the code and feedback vector
      of the outer closure.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2674593003
      Cr-Commit-Position: refs/heads/master@{#42953}
      aea3ce3d
  7. 30 Jun, 2016 1 commit
  8. 06 Jun, 2016 1 commit
  9. 28 Sep, 2015 1 commit
    • jkummerow's avatar
      objects-inl.h: Remove ACCESSORS_TO_SMI macro · 7117acd2
      jkummerow authored
      Replacing it with SMI_ACCESSORS.
      This change makes accesses to Smi fields in objects more regular (the
      accessors now always consume/return an int rather than a Smi*), which
      avoids a bunch of manual Smi::FromInt() and Smi::value() conversions,
      and is a step on the way towards being able to generate objects-inl.h.
      
      Review URL: https://codereview.chromium.org/1371893002
      
      Cr-Commit-Position: refs/heads/master@{#30975}
      7117acd2
  10. 20 Aug, 2015 1 commit
  11. 01 Jun, 2015 1 commit
  12. 19 May, 2015 1 commit
  13. 18 May, 2015 2 commits
  14. 27 Mar, 2015 1 commit
  15. 12 Feb, 2015 1 commit
  16. 04 Feb, 2015 1 commit
    • marja's avatar
      Introduce LanguageMode, drop StrictMode. · c7851da4
      marja authored
      This enables adding more language modes in the future.
      
      For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
      use a sequence of language modes which are progressively stricter, but we can
      express the language mode as combination of features.
      
      For now, LanguageMode can only be "sloppy" or "strict", and there are
      STATIC_ASSERTS in places which need to change when more modes are added.
      
      LanguageMode is a bit like the old LanguageMode when "extended" mode was still
      around (see https://codereview.chromium.org/8417035 and
      https://codereview.chromium.org/181543002 ) except that it's transmitted through
      all the layers (there's no StrictModeFlag).
      
      BUG=
      
      Review URL: https://codereview.chromium.org/894683003
      
      Cr-Commit-Position: refs/heads/master@{#26419}
      c7851da4
  17. 29 Jan, 2015 1 commit
  18. 31 Oct, 2014 1 commit
  19. 28 Oct, 2014 1 commit
  20. 19 Sep, 2014 1 commit
  21. 18 Sep, 2014 2 commits
  22. 04 Aug, 2014 1 commit
  23. 03 Jun, 2014 1 commit
  24. 29 Apr, 2014 1 commit
  25. 25 Apr, 2014 1 commit
  26. 11 Apr, 2014 1 commit
  27. 09 Apr, 2014 1 commit
  28. 08 Apr, 2014 1 commit
  29. 11 Mar, 2014 1 commit
  30. 23 Dec, 2013 1 commit
  31. 30 Jul, 2013 1 commit
  32. 05 Jul, 2013 1 commit
  33. 12 Mar, 2013 1 commit
  34. 25 Oct, 2012 1 commit
  35. 28 Aug, 2012 1 commit
  36. 24 Nov, 2011 1 commit
    • keuchel@chromium.org's avatar
      Introduce extended mode. · 1e9a7267
      keuchel@chromium.org authored
      This CL introduces a third mode next to the non-strict
      (henceforth called 'classic mode') and 'strict mode'
      which is called 'extended mode' as in the current
      ES.next specification drafts. The extended mode is based on
      the 'strict mode' and adds new functionality to it. This
      means that most of the semantics of these two modes
      coincide.
      
      The 'extended mode' is entered instead of the 'strict mode'
      during parsing when using the 'strict mode' directive
      "use strict" and when the the harmony-scoping flag is
      active. This should be changed once it is fully specified how the 'extended mode' is entered.
      
      This change introduces a new 3 valued enum LanguageMode
      (see globals.h) corresponding to the modes which is mostly
      used by the frontend code. This includes the following
      components:
      * (Pre)Parser
      * Compiler
      * SharedFunctionInfo, Scope and ScopeInfo
      * runtime functions: StoreContextSlot,
        ResolvePossiblyDirectEval, InitializeVarGlobal,
        DeclareGlobals
      
      The old enum StrictModeFlag is still used in the backend
      when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
      * SetProperty runtime function, Delete builtin
      * StoreIC and KeyedStoreIC
      * StubCache
      
      Review URL: http://codereview.chromium.org/8417035
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      1e9a7267
  37. 14 Nov, 2011 1 commit
  38. 29 Jun, 2011 1 commit
    • vitalyr@chromium.org's avatar
      Suspend runtime profiler as soon as we exit JS. · 90c9f1b9
      vitalyr@chromium.org authored
      Lots of web pages have really frequently firing timers that keep the
      profiler thread spinning if we require a period of JS inactivity
      before suspending the profiler. While it's possible to throttle it by
      increasing the sleep delay and adjusting the duration of the required
      inactive period, it seemed much simpler to just stop it immediately on
      exiting JS.
      
      Stopping the profiler this way effectively turned off two optimization
      heuristics: 1) eager optimization (it's reset on waking up the
      profiler and now the profiler wakes up much more frequently) and 2)
      optimization throttling based on JS to non-JS state ratio (the ratio
      is now 100%). I removed these two heuristics and found no performance
      regressions so far.
      
      R=ager@chromium.org
      BUG=crbug.com/77625
      TEST=none
      
      Review URL: http://codereview.chromium.org/7274024
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8472 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      90c9f1b9