1. 17 Nov, 2020 1 commit
  2. 10 Nov, 2020 1 commit
  3. 09 Nov, 2020 1 commit
  4. 07 Nov, 2020 1 commit
  5. 22 Oct, 2020 1 commit
  6. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored
      This patch introduces a new LocalIsolate and LocalFactory, which use
      LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
      us to remove those classes, as well as the related OffThreadSpace,
      OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
      OffThreadLogger becomes LocalLogger.
      
      LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
      us to additionally remove the concept of "Finish" and "Publish" that the
      OffThreadIsolate had, and allows us to internalize strings directly with
      the newly-concurrent string table (where the implementation can now move
      to FactoryBase).
      
      This patch also removes the off-thread support from the deserializer
      entirely, as well as removing the LocalIsolateWrapper which allowed
      run-time distinction between Isolate and OffThreadIsolate. LocalHeap
      doesn't support the reservation model used by the deserializer, and we
      will likely move the deserializer to use LocalIsolate unconditionally
      once we figure out the details of how to do this.
      
      Bug: chromium:1011762
      
      Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  7. 15 Jul, 2020 1 commit
  8. 13 Jul, 2020 1 commit
  9. 10 Jul, 2020 1 commit
  10. 25 May, 2020 1 commit
  11. 03 Mar, 2020 1 commit
    • Joyee Cheung's avatar
      [class] maintain private brand information on SFI · 0753cbea
      Joyee Cheung authored
      When an empty class is nested inside a class with private instance
      methods, like this:
      
        class Outer {
          constructor() {}
          #method() {}
          factory() {
            class Inner {
              constructor() {  }
            }
            return Inner;
          }
          run(obj) {
            obj.#method();
          }
        }
      
      The bytecode generator previously generate private brand
      initialization for the constructor of Inner by mistake,
      because during scope chain serialization/deserialization,
      the outer scopes of Inner and factory() are not allocated
      or serialized (as they are empty). In the eyes of the bytecode
      generator, it then appeared as if Outer is the direct outer
      scope of Inner's constructor.
      
      In order to work around this information loss, in this patch
      we rely on SharedFunctionInfo instead of the Context/ScopeInfo
      chain to maintain the information about private brand initialization.
      This is done by shrinking expected_nof_properties to 8 bits and
      freeing 8 bits for a second bitfield on the SFI.
      
      Design doc: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit#
      Bug: v8:9839, v8:8330, v8:10098
      
      Change-Id: I4370a0459bfc0da388052ad5a91aac59582d811d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056889
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66575}
      0753cbea
  12. 02 Mar, 2020 1 commit
  13. 18 Feb, 2020 1 commit
  14. 10 Feb, 2020 1 commit
  15. 07 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [ast] Cache allocated AstConsString · 7fa19160
      Leszek Swirski authored
      Allow caching the result of allocating AstConsStrings, to allow
      sharing of inferred names between functions.
      
      This is a partial revert of https://crrev.com/c/2020953, with
      the observation that *some* AstConsStrings are always flattened,
      while others are only ever used as ConsStrings, so we want to
      allow the allocation to be lazy while still caching the result.
      
      As a drive-by, cleanup the old AstConsString linked list fields.
      
      Bug: chromium:1011762
      Bug: chromium:1048082
      Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66168}
      7fa19160
  16. 06 Feb, 2020 1 commit
  17. 04 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add an OffThreadIsolate · 7a20b6b9
      Leszek Swirski authored
      The Factory/OffThreadFactory allows us to cleanly separate object
      construction behaviour between main-thread and off-thread in a
      syntactically consistent way (so that methods templated on the factory
      type can be made to work on both).
      
      However, there are cases where we also have to access the Isolate, for
      handle creation or exception throwing. So far we have been pushing more
      and more "customization points" into the factories to allow these
      factory-templated methods to dispatch on this isolate behaviour via
      these factory methods. Unfortunately, this is an increasing layering
      violation between Factory and Isolate, particularly around exception
      handling.
      
      Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
      way as OffThreadFactory is analogous to Factory. All methods which were
      templated on Factory are now templated on Isolate, and methods which
      used to take an Isolate, and which were recently changed to take a
      templated Factory, are changed/reverted to take a templated Isolate.
      OffThreadFactory gets an isolate() method to match Factory's.
      
      Notably, FactoryHandle is changed to "HandleFor", where the template
      argument can be either of the Isolate type or the Factory type (allowing
      us to dispatch on both depending on what is available).
      
      Bug: chromium:1011762
      Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66101}
      7a20b6b9
  18. 16 Jan, 2020 2 commits
    • Leszek Swirski's avatar
      [ast] Pre-walk array literals to detect all-doubles · dabc6eb5
      Leszek Swirski authored
      When buildin an array boilerplate description, we currently walk the
      array literal as if it had tagged pointers, and post-hoc copy it to
      a FixedDoubleArray if it had double elements kind.
      
      Now, we calculate the elements kind during the InitDepthAndFlags walk,
      and if the elements kind is Double, we allocate a FixedDoubleArray to
      start with, and convert the elements of the array literal directly to
      unboxed doubles in the array.
      
      Change-Id: I56561e0af2236e785498eb70cb37eddcb09a56ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002529
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65817}
      dabc6eb5
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored
      Add support for internalizing an AstValueFactory using the off-thread
      factory. Includes adding ConsString support to OffThreadFactory.
      
      This introduces a Handle union wrapper, which is used in locations that
      can store a Handle or an OffThreadHandle. This is used in this patch for
      the internalized "string" field of AST strings, and will be able to be
      used for other similar fields in other classes (e.g. the ScopeInfo
      handle in Scope, object boilerplate descriptor handles, the inferred
      name handle on FunctionLiterals, etc.). It has a Factory-templated
      getter which returns the appropriate handle for the factory, and a
      debug-only tag to make sure the right getter is used at runtime. This
      union wrapper currently decomposes implicitly to a Handle if the getter
      is not called, to minimise code changes, but this implicit conversion
      will likely be removed for clarity.
      
      Bug: chromium:1011762
      Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  19. 29 Nov, 2019 1 commit
  20. 27 Nov, 2019 1 commit
  21. 15 Nov, 2019 1 commit
  22. 16 Sep, 2019 1 commit
  23. 06 Sep, 2019 1 commit
  24. 21 Aug, 2019 1 commit
  25. 20 Aug, 2019 1 commit
  26. 09 Jul, 2019 1 commit
  27. 01 Jul, 2019 1 commit
    • Leszek Swirski's avatar
      [parser] Mark maybe_assigned recursively for shadowing vars · fc4bcce1
      Leszek Swirski authored
      The previous fix for this bug (crrev.com/c/1678365) pessimistically
      would mark all shadowed variables as maybe_assigned. Unfortunately,
      this doesn't work across a parse/preparse boundary, where the shadowing
      variable is found via Scope::AnalyzePartially while the shadowed
      variable is outside of the preparser entry point. In those cases, the
      referencing proxy is copied to the outer scope, in which case the
      dynamicness of the original lookup is lost and the maybe_assigned
      pessimisation no longer applies.
      
      This means that maybe_assigned status of a variable is dependent on
      which function is being parsed. In particular, it can cause bytecode
      to change on recompilation, causing issues for lazy source positions.
      
      This patch allows SetMaybeAssigned to walk its shadowed variables,
      and recursively set them to maybe_assigned too. Checking for
      maybe_assigned changing prevents this recursion from having a
      quadratic performance failure mode.
      
      Bug: v8:8510
      Bug: v8:9394
      Change-Id: Id19fe1fad5ec8f0f9aa03b00eb24497f88f71216
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677265
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62458}
      fc4bcce1
  28. 26 Jun, 2019 1 commit
  29. 18 Jun, 2019 1 commit
  30. 23 May, 2019 1 commit
  31. 21 May, 2019 1 commit
  32. 20 May, 2019 1 commit
  33. 15 May, 2019 1 commit
  34. 13 May, 2019 1 commit
  35. 10 May, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[class] implement private method declarations" · bf07d790
      Ross McIlroy authored
      This reverts commit b9191bd3.
      
      Reason for revert: Clusterfuzz bugs
      BUG=chromium:961507,chromium:961508
      
      Original change's description:
      > [class] implement private method declarations
      >
      > This patch implements the declarations of private methods, the access
      > of private methods would be left to a future patch.
      > When a private methods declaration is encountered, we now:
      >
      > - Create a brand symbol during class evaluation and store it in the
      >   context.
      > - Create the closures for the private methods
      > - Load the brand from the context and store it in the instance in the
      >   constructor.
      >
      > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
      >
      > Bug: v8:8330
      > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61387}
      
      TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com
      
      Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8330
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61406}
      bf07d790
  36. 09 May, 2019 1 commit
  37. 12 Mar, 2019 1 commit
  38. 25 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Skip arguments adaptor when target cannot observe arguments. · 75629d5f
      Benedikt Meurer authored
      When calling a known function from optimized code, where the number of
      actual arguments does not match the number of expected arguments,
      TurboFan has to call indirectly via the arguments adaptor trampoline,
      which creates an argument adaptor frame underneath the activation record
      for the callee. This is done so that the callee can still get to the
      actual arguments, using either
      
      1. the arguments object, or
      2. rest parameters (to get to superfluous arguments), or
      3. the non-standard Function.arguments accessor (for sloppy mode
         functions), or
      4. direct eval(), where we don't know whether there's a use of the
         arguments object hiding somewhere in the string.
      
      However going through the arguments adaptor trampoline is quite
      expensive usually, it seems to be responsible for over 60% of the
      call overhead in those cases.
      
      So this adds a fast path for the case of calling strict mode functions
      where we have an arguments mismatch, but where we are sure that the
      callee cannot observe the actual arguments. We use a bit on the
      SharedFunctionInfo to indicate that this is safe, which is controlled
      by hints from the Parser which knows whether the callee uses either
      arguments object or rest parameters.
      
      In those cases we use a direct call from optimized code, passing the
      expected arguments instead of the actual arguments. This improves the
      benchmark on the document below by around 60-65%, which is exactly
      the overhead of the arguments adaptor trampoline that we save in this
      case.
      
      This also adds a runtime flag --fast_calls_with_arguments_mismatches,
      which can be used to turn off the new behavior. This might be handy
      for checking the performance impact via Finch.
      
      Bug: v8:8895
      Change-Id: Idea51dba7ee6cb989e86e0742eaf3516e5afe3c4
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: http://bit.ly/v8-faster-calls-with-arguments-mismatch
      Reviewed-on: https://chromium-review.googlesource.com/c/1482735
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59825}
      75629d5f
  39. 15 Feb, 2019 1 commit