1. 22 Jan, 2019 1 commit
  2. 18 Dec, 2018 1 commit
  3. 07 Dec, 2018 1 commit
  4. 23 Nov, 2018 1 commit
  5. 31 Oct, 2018 1 commit
  6. 24 Oct, 2018 1 commit
  7. 20 Sep, 2018 1 commit
  8. 12 Jul, 2018 1 commit
  9. 04 Jul, 2018 1 commit
  10. 26 Jun, 2018 1 commit
  11. 25 Jun, 2018 1 commit
    • Camillo Bruni's avatar
      Reland "[parser][log] Log script id during background compilation" · e7f5c5cc
      Camillo Bruni authored
      This reverts commit a800e050.
      
      Original change's description:
      > Revert "[parser][log] Log script id during background compilation"
      >
      > This reverts commit aafd5c52.
      >
      > Reason for revert: Tentative revert for
      >
      > https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/24825
      > https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20msvc/3242
      >
      > Original change's description:
      > > [parser][log] Log script id during background compilation
      > >
      > > - Add separate script-create, script-reserve-id and script-details log events
      > > - Add log events for CompilationCache hits and puts
      > > - Simplify function event logging by only pass along the script id
      > > - Explicitly create Scripts in parse-processor.js on script events only
      > > - Create a temporary script id in the ParseInfo for use during background
      > >   parsing and compilation
      > > - Clean up ParseInfo initialization to centralize creation and use of
      > >   script ids
      > > - Allow creating Scripts with predefined script ids
      > >
      > > Bug: chromium:757467, chromium:850038
      > > Change-Id: I02dfd1d5725795b9fe0ea94ef57b287b934a1efe
      > > Reviewed-on: https://chromium-review.googlesource.com/1097131
      > > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#53978}
      >
      > TBR=ulan@chromium.org,cbruni@chromium.org,gsathya@chromium.org,leszeks@chromium.org
      >
      > Change-Id: I629f72f51d5e086e2b54658c1fdd18cec268aab2
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: chromium:757467, chromium:850038
      > Reviewed-on: https://chromium-review.googlesource.com/1112538
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53984}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,cbruni@chromium.org,gsathya@chromium.org,leszeks@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:757467, chromium:850038
      Change-Id: I3088c86362c06ee50464f1f14e25350b1b8048ad
      Reviewed-on: https://chromium-review.googlesource.com/1112539Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53994}
      e7f5c5cc
  12. 22 Jun, 2018 2 commits
  13. 21 Jun, 2018 1 commit
  14. 03 May, 2018 1 commit
  15. 09 Apr, 2018 1 commit
  16. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  17. 22 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Introduce a dedicated FeedbackCell. · aff1f378
      Benedikt Meurer authored
      This is preparatory cleanup work for eventually tracking the functions
      (rather than concrete closures) in the CALL_IC, also for builtins like
      the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
      adds a new FeedbackCell type, which is used by JSFunctions consistently
      now to reference the feedback vector (or undefined if not the function
      is not compiled yet or is a native/asm.js function).
      
      This also changes the calling convention for FastNewClosure builtin and
      the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
      instead of the parent FeedbackVector and the slot index. In addition we
      eliminate the now unused %InterpreterNewClosure runtime function.
      
      Bug: v8:2206, v8:7253, v8:7310
      Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
      Reviewed-on: https://chromium-review.googlesource.com/928403
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51474}
      aff1f378
  18. 21 Feb, 2018 1 commit
  19. 19 Feb, 2018 1 commit
  20. 14 Feb, 2018 1 commit
  21. 12 Feb, 2018 1 commit
    • Caitlin Potter's avatar
      [esnext] implement spec change to TaggedTemplate callsite caching · d3ca0d00
      Caitlin Potter authored
      Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
      which has been ratified and pulled into the specification. In particular,
      template callsite objects are no longer kept in a global, eternal Map, but
      are instead associated with their callsite, which can be collected. This
      prevents a memory leak incurred by TaggedTemplate calls.
      
      Changes, summarized:
      
          - Remove the TemplateMap and TemplateMapShape objects, instead caching
            template objects in the feedback vector.
          - Remove the `hash` member of TemplateObjectDescriptor, and the Equals
            method (used by TemplateMap)
          - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
            to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
            that a new feedback vector is always created for eval() containing tagged
            templates, even when the CompilationCache is used.
          - GetTemplateObject bytecode now takes a feedback index, and only calls
            into the runtime if the feedback is Smi::kZero (uninitialized).
      
      BUG=v8:3230, v8:2891
      R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
      rmcilroy@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
      Reviewed-on: https://chromium-review.googlesource.com/624564
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51248}
      d3ca0d00
  22. 18 Oct, 2017 1 commit
  23. 05 Oct, 2017 1 commit
  24. 22 May, 2017 1 commit
  25. 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
  26. 06 Apr, 2017 1 commit
  27. 30 Mar, 2017 1 commit
  28. 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
  29. 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
  30. 30 Jun, 2016 1 commit
  31. 06 Jun, 2016 1 commit
  32. 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
  33. 20 Aug, 2015 1 commit
  34. 01 Jun, 2015 1 commit
  35. 19 May, 2015 1 commit
  36. 18 May, 2015 2 commits
  37. 27 Mar, 2015 1 commit