1. 25 Feb, 2020 1 commit
  2. 24 Feb, 2020 1 commit
  3. 12 Feb, 2020 2 commits
  4. 10 Feb, 2020 1 commit
  5. 09 Feb, 2020 1 commit
    • Michael Achenbach's avatar
      Revert "[weakrefs] Schedule FinalizationGroup cleanup tasks from within V8" · 72fc962b
      Michael Achenbach authored
      This reverts commit 31d8ff7a.
      
      Reason for revert: https://crbug.com/v8/10190
      
      Original change's description:
      > [weakrefs] Schedule FinalizationGroup cleanup tasks from within V8
      > 
      > Deprecate the following explicit FinalizationGroup APIs in favor of
      > automatic handling of FinalizationGroup cleanup callbacks:
      >   - v8::Isolate::SetHostCleanupFinalizationGroupCallback
      >   - v8::FinaliationGroup::Cleanup
      > 
      > If no HostCleanupFinalizationGroupCallback is set, then
      > FinalizationGroup cleanup callbacks are automatically scheduled by V8
      > itself as non-nestable foreground tasks.
      > 
      > When a Context being disposed, all FinalizationGroups that are
      > associated with it are removed from the dirty list, cancelling
      > scheduled cleanup.
      > 
      > Bug: v8:8179
      > Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66184}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,syg@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8179
      Change-Id: If7869e9a5841803c10e748691f019a7d28f3b62e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043807Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66190}
      72fc962b
  6. 08 Feb, 2020 1 commit
  7. 07 Feb, 2020 1 commit
    • Mythri A's avatar
      Disable one shot optimizations · e85ffb46
      Mythri A authored
      We used to optimize functions that are expected to executed only
      once by not allocating feedback slots for some of the bytecodes. This
      would help in reducing the memory and avoiding initializing feedback
      that would be never used. With lazy feedback allocation, we don't
      allocate feedback vectors for most of such functions anyway.
      
      The generated bytecode for oneshot optimized functions is different and
      if we don't properly track this information we might end up generating
      different bytecode for the same function. This could causes problems
      when there is a mismatch between the feedback slots used by the new
      bytecode and the old bytecode. Since we potentially get most of the
      benefits of this optimization with lazy feedback vector allocation
      we can simplify the code by disabling this optimization.
      
      Bug: chromium:1045824
      Change-Id: Ib94605c8c766adc99f54c8333f780d2448caff5e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030918Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66172}
      e85ffb46
  8. 13 Jan, 2020 1 commit
  9. 26 Dec, 2019 1 commit
  10. 19 Dec, 2019 2 commits
    • Shu-yu Guo's avatar
      [weakrefs] Hold unregister tokens weakly · 45bb4498
      Shu-yu Guo authored
      Change unregister tokens to be held weakly instead of strongly. This
      enables the use case for an object to be used as its own unregister
      token.
      
      To avoid using an ephemeron table, FinalizationGroup's key_map is
      changed to key off unregister tokens' identity hashes. Because hashes
      may collide, a single key list may rarely contain multiple tokens. When
      a FinalizationGroup WeakCell's token becomes unreachable, during GC, it
      is removed from the the doubly linked key list and removed from the key
      map if it had a unique key.
      
      Bug: v8:8179
      Change-Id: If88fd2ab196e3f9a287990ae345117a0abb2f04d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970493
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65532}
      45bb4498
    • Shu-yu Guo's avatar
      Remove per-parameter position var scope · 1b450a17
      Shu-yu Guo authored
      The spec was normatively changed to simplify var scopes for parameter
      expressions. Previously there was a per-parameter var scope in sloppy
      mode so direct evals could introduce vars that did not escape the
      parameter position. That semantics is complex both for the programmer
      and implementation and has resulted in bugs in the past. Furthermore, it
      has never been fully interoperable (with Safari in particular). The spec
      was instead changed to be simpler: to have a single var scope for
      sloppy evals in parameters that encloses the parameter scope and body
      scope.
      
      This simplification lets us remove expression-scope-reparenter.
      
      Drive-by removal of stale reference to PatternRewriter.
      
      Bug: v8:7532
      Change-Id: Iade5594abe0009f7f3f6a1adad18628b17e1e779
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962471Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65517}
      1b450a17
  11. 29 Nov, 2019 1 commit
  12. 27 Nov, 2019 1 commit
  13. 25 Nov, 2019 1 commit
  14. 21 Nov, 2019 1 commit
  15. 20 Nov, 2019 1 commit
  16. 19 Nov, 2019 1 commit
  17. 14 Nov, 2019 1 commit
  18. 05 Nov, 2019 1 commit
  19. 04 Nov, 2019 1 commit
    • Joshua Litt's avatar
      Revert "Reland "[regexp] Clone match info for match indices."" · 1a6ffffb
      Joshua Litt authored
      This reverts commit d4574d18.
      
      Reason for revert: In addition to the earlier octane regression, this cl also created a regression in desktop browsing
      
      Bug: chromium:1019601
      
      Original change's description:
      > Reland "[regexp] Clone match info for match indices."
      > 
      > This reverts commit d7793c06.
      > 
      > Reason for revert: This cl *will* cause regexp regressions. We are trying to gauge the real world impact.
      > 
      > Original change's description:
      > > Revert "[regexp] Clone match info for match indices."
      > >
      > > This reverts commit dfd9ceb9.
      > >
      > > Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356 https://crbug.com/1015749
      > >
      > > Original change's description:
      > > > [regexp] Clone match info for match indices.
      > > >
      > > > The current behavior for generating match indices simply stashes a
      > > > pointer to the match info and then constructs the indices lazily.
      > > > However, it turns out the match info object used to create the result
      > > > object is the regexp_last_match_info living on native context, and thus
      > > > it can change between the creation of the result object and the generation
      > > > of indices. This cl clones the match info which will be safer.
      > > >
      > > > Bug: v8:9548
      > > > Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585
      > > > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#64356}
      > >
      > > TBR=jgruber@chromium.org,joshualitt@chromium.org
      > >
      > > # Not skipping CQ checks because original CL landed > 1 day ago.
      > >
      > > Bug: v8:9548, chromium:1015749
      > > Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236
      > > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#64407}
      > 
      > TBR=jgruber@chromium.org,joshualitt@chromium.org
      > 
      > 
      > Bug: v8:9548, chromium:1015749
      > Change-Id: I151511307e3d8752fdbde4b8247514031b141b08
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879587
      > Reviewed-by: Joshua Litt <joshualitt@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64587}
      
      TBR=jgruber@chromium.org,joshualitt@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9548, chromium:1015749
      Change-Id: Ie5a8e55338728aae33102d82e60a188f6440e8f5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898030Reviewed-by: 's avatarJoshua Litt <joshualitt@chromium.org>
      Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64749}
      1a6ffffb
  20. 28 Oct, 2019 1 commit
    • Joshua Litt's avatar
      Reland "[regexp] Clone match info for match indices." · d4574d18
      Joshua Litt authored
      This reverts commit d7793c06.
      
      Reason for revert: This cl *will* cause regexp regressions. We are trying to gauge the real world impact.
      
      Original change's description:
      > Revert "[regexp] Clone match info for match indices."
      >
      > This reverts commit dfd9ceb9.
      >
      > Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356 https://crbug.com/1015749
      >
      > Original change's description:
      > > [regexp] Clone match info for match indices.
      > >
      > > The current behavior for generating match indices simply stashes a
      > > pointer to the match info and then constructs the indices lazily.
      > > However, it turns out the match info object used to create the result
      > > object is the regexp_last_match_info living on native context, and thus
      > > it can change between the creation of the result object and the generation
      > > of indices. This cl clones the match info which will be safer.
      > >
      > > Bug: v8:9548
      > > Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585
      > > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#64356}
      >
      > TBR=jgruber@chromium.org,joshualitt@chromium.org
      >
      > # Not skipping CQ checks because original CL landed > 1 day ago.
      >
      > Bug: v8:9548, chromium:1015749
      > Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64407}
      
      TBR=jgruber@chromium.org,joshualitt@chromium.org
      
      
      Bug: v8:9548, chromium:1015749
      Change-Id: I151511307e3d8752fdbde4b8247514031b141b08
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879587Reviewed-by: 's avatarJoshua Litt <joshualitt@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64587}
      d4574d18
  21. 22 Oct, 2019 1 commit
  22. 21 Oct, 2019 2 commits
  23. 17 Oct, 2019 1 commit
    • Joshua Litt's avatar
      [regexp] Clone match info for match indices. · dfd9ceb9
      Joshua Litt authored
      The current behavior for generating match indices simply stashes a
      pointer to the match info and then constructs the indices lazily.
      However, it turns out the match info object used to create the result
      object is the regexp_last_match_info living on native context, and thus
      it can change between the creation of the result object and the generation
      of indices. This cl clones the match info which will be safer.
      
      Bug: v8:9548
      Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585
      Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64356}
      dfd9ceb9
  24. 16 Oct, 2019 2 commits
  25. 10 Oct, 2019 2 commits
    • Joyee Cheung's avatar
      [class] fix undefined private name access in computed property keys · 7fa12e2a
      Joyee Cheung authored
      This patch implements https://github.com/tc39/proposal-class-fields/pull/269
      and makes sure we always throw TypeError when there is invalid private
      name access in computed property keys.
      
      Before this patch, private name variables of private fields and methods
      are initialized together with computed property keys in the order they
      are declared. Accessing undefined private names in the computed property
      keys thus fail silently.
      
      After this patch, we initialize the private name variables of private
      fields before we initialize the computed property keys, so that invalid
      access to private fields in the computed keys can be checked in the IC.
      We now also initialize the brand early, so that invalid access to private
      methods or accessors in the computed keys throw TypeError during brand
      checks - and since these accesses are guarded by brand checks, we can
      create the private methods and accessors after the class is
      defined, and merge the home object setting with the creation
      of the closures.
      
      Bug: v8:8330, v8:9611
      Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64225}
      7fa12e2a
    • Joyee Cheung's avatar
      [class] implement static private methods · 4e8c6281
      Joyee Cheung authored
      This patch refactors the declaration and allocation of the class variable, and
      implements static private methods:
      
      
      - The class variable is declared in the class scope with an explicit
        reference through class_scope->class_variable(). Anonymous classes
        whose class variable may be accessed transitively through static
        private method access use the dot string as the class name. Whether
        the class variable is allocated depending on whether it is used.
        Other references of the class variable in the ClassLiteral AST node
        and the ClassInfo structure are removed in favor of the reference
        through the class scope.
      - Previously the class variable was always (stack- or context-)
        allocated if the class is named. Now if the class variable is only
        referenced by name, it's stack allocated. If it's used transitively
        by access to static private methods, or may be used through eval,
        it's context allocated. Therefore we now use 1 less context slots
        in the class context if it's a named class without anyone referencing
        it by name in inner scopes.
      - Explicit access to static private methods or potential access to
        static private methods through eval results in forced context
        allocation of the class variables. In those cases, we save its index
        in context locals in the ScopeInfo and deserialize it later, so that
        we can check that the receiver of static private methods is the class
        constructor at run time. This flag is recorded as
        HasSavedClassVariableIndexField in the scope info.
      - Classes that need the class variable to be saved due to
        access to static private methods now save a
        ShouldSaveClassVariableIndexField in the preparse data so that the
        bits on the variables can be updated during a reparse. In the case
        of anonymous classes that need the class variables to be saved,
        we also re-declare the class variable after the reparse since
        the inner functions are skipped and we need to rely on the preparse
        data flags to remember declaring it.
      
      Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit
      
      Bug: v8:8330
      Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64219}
      4e8c6281
  26. 24 Sep, 2019 1 commit
  27. 20 Sep, 2019 1 commit
  28. 16 Sep, 2019 1 commit
  29. 11 Sep, 2019 1 commit
  30. 06 Sep, 2019 1 commit
  31. 05 Sep, 2019 1 commit
  32. 30 Aug, 2019 1 commit
  33. 23 Aug, 2019 3 commits